Rob Howard
Microsoft Corporation

2001년 10월
출처:MSDN http://www.microsoft.com/korea/msdn/library/ko-kr/dnaspnet/html/asp09272001.aspx

XML 웹 서비스는 정보를 HTML의 한계로부터 벗어나게 해준 원조자로서, 산업계로부터 찬사를 받고 있습니다. W3C에 제출된 프로토콜인 SOAP을 사용하면, 데이터는 XML로 인코드되고, 여러 인터넷 프로토콜들(가장 대표적인 것으로는 HTTP)을 사용하여 전송될 수 있습니다.

송신자와 수신자 모두가 메시지 형식(즉, SOAP이 정의한 프로토콜)에 동의한다면, 정보는 플랫폼에 독립적인 방식으로 쉽게 교환될 수 있습니다.

Microsoft는 XML 웹 서비스의 성공을 이루어 나감에 있어서 지도자 역할을 하고 있습니다. 이의 비전을 제시할 뿐만 하니라, 기술들과 제품들을 구현함으로써 말입니다. 그리고, 또한, XML 웹 서비스를 지원하는 가장 기대되는 제품 중의 하나도 바로 Microsoft의 ASP.NET입니다.

1.ASP.NET으로 XML 웹 서비스 구축하기

ASP.NET은 웹 서비스를 쉽게 구축할 수 있게 해 줍니다. 기존의 웹 개발자들(PERL/CGI에 대해 좋은 추억을 가진 자들이 여기에 해당됩니다)에게 ASP가 혁신적인 웹 개발이었던 것과 마찬가지로, ASP.NET은 XML(SOAP 프로토콜을 따르는)이나 HTML을 생산해내는 웹 응용 프로그램을 구축하는데 있어 혁신적일 것입니다.

언급한대로, ASP.NET으로 XML 웹 서비스를 구축하는 것은 간단합니다.
개발자로서, 우리는 사용자 정의 특성이 표기된 메서드 정의들을 갖는 클래스를 작성합니다.
이들은 모두 .asmx 확장자를 사용하는 파일 안에 존재해야 합니다.
다음은 간단한 웹 서비스의 예입니다.

<%@ WebService Language="C#" Class="SimpleMath" %>
 


using System.Web.Services; 






public class SimpleMath 
{
 
 [WebMethod] 
 public int Add(int a, int b) 
 { 
 return a+b; 
 }
 
}

다음의 SOAP 메시지가 이 서비스에게로 보내질 수 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<Add xmlns="http://tempuri.org/" /> <a>5</a> <b>8</b> </Add>
</soap:Body>
</soap:Envelope>

그러면, ASP.NET XML 웹 서비스는 적절하게 응답할 것입니다.

<?xml version="1.0" encoding="utf-8"?> 
<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/ 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
<soap:Body> 
<AddResponse xmlns="http://tempuri.org/" /> 
<AddResult>13</AddResult> </AddResponse> 
</soap:Body> 
</soap:Envelope>

개발자에게 주어지는 이익은 명확합니다.
즉, XML, HTTP, SOAP 및 XML 웹 서비스를 구축하기 위해 사용되는 다른 모든 프로토콜들을 이해할 필요가 없다는 것입니다.
대신, 개발자는 솔루션을 구축하는 데에만 집중할 수 있습니다.

2.보안은 어떻습니까?

개발자들의 핵심 관심사 중에 하나는 보안입니다. 위의 예제는 '연결(the wire)' 상에서 두 개의 XML 웹 서비스 사이에 보내진 것이 무엇인지를 보여주고 있습니다. 여러분도 알겠지만, 교환은 일반 텍스트로 이루어졌습니다. 데이터가 일반 텍스트로 전송되고, 최종 목적지에 도달하기 위해 인터넷을 통해서 발송되었기 때문에, 누군가가 잠재적으로 메시지 교환을 볼 수도 있을 것입니다.

위의 예제의 경우라면, 이것이 문제가 되지는 않을 것입니다. 하지만, 만일, 이러한 데이터 교환이 은행으로의 요청으로 이루어지고 있고, 응답이 계좌번호와 잔고의 목록을 포함한다면? 또는 신용카드 번호와 같은 뭔가 보다 흥미로운 정보를 반환하는 요청이라면? 그렇다면, 다른 사람에게 이 정보가 보여지기를 결코 원하지 않을 것입니다!

3.암호화 지원하기

교환해야 할 데이터가 있고, 누군가가 이를 훔쳐보기를 원하지 않는 경우라면,
암호화를 통해서 통신을 보안적이게 해야만 합니다.

SOAP 사양은 XML 웹 서비스에 대한 암호화를 정의하고 있지는 않습니다.
대신, 이는 SOAP 프로토콜의 구현자의 몫으로 남겨져 있습니다.

많은 경우, 권장되는 보안 표준은 HTTPS(secure HTTP)입니다.

HTTPS 상에서의 SOAP은 안전합니다.
HTTP 메시지의 헤더들과 본문을 포함하는 전체 HTTP 메시지는 공개된 비대칭 암호화 알고리즘을 사용하여 암호화됩니다.

그렇지만, 이러한 암호화의 형식은 전송 프로토콜(HTTP)에 종속적입니다.
반면, SOAP 메시지는 전송-독립적인 프로토콜입니다.
SOAP 메시지는 HTTP, SMTP, TCP, UDP 등을 사용하여 전송될 수 있습니다.
SOAP 메시지는 라우팅 될 수 있으며, 다른 곳으로 메시지를 라우팅할 수도 있습니다. 즉, 서버는 최종 목적지가 확정되지 않은 메시지를 받을 수 있다는 것입니다. 라우팅되는 동안, 서로 다른 전송 프로토콜들이 사용될 수도 있습니다.
예를 들면, HTTP->UDP->SMTP->HTTP와 같이 말입니다.
그렇기 때문에, 보안에 대한 전송 프로토콜 상의 종속성은 본질적인 문제를 가지고 있습니다.
예를 들면, 라우팅 서버가 메시지를 읽기 위해서 이를 복호화할 수 있어야 하고, 그 다음 다른 전송 프로토콜에 대해 재 암호화할 수 있어야만 함에 따라, 얼마나 많은 트러스트가 라우팅 서버들 상에 놓여져야 합니까?와 같은 질문이 그것입니다. 그 외의 질문들은 다음과 같습니다.

비록 위의 문단에 완벽하게 부합한다 하더라도, 많은 경우에 있어 HTTPS가 보안적인 SOAP 메시지 교환을 위해 권장되는 해결책이라는 것을 기억하십시오.

왜냐하면, 오늘날 거의 모든 XML 웹 서비스가 전송 프로토콜로 HTTP를 사용하고 있고, 극소수의 XML 웹 서비스들만이 현재 메시지 라우팅을 지원하기 때문입니다.

반면, SOAP 메시지의 암호화를 지원하는 ASP.NET 웹 서비스를 구축하는 것은 쉽게 가능합니다. 암호화는 전송 프로토콜에서 종속성을 제거하고, 메시지의 오직 선택한 부분들만이 암호화될 수 있게 해주는 공개 암호화 알고리즘을 사용하여 이룰 수 있습니다.
예를 들면, 밑의 해결책은 단일 전달 Data Encryption Standard(DES) 암호화(양쪽 업체 모두가 공용 키를 공유해야만 하는 공개 대칭 암호화 알고리즘)를 사용하고 있으며, 오직 메시지의 본문만이 암호화됩니다
(라우팅 서버가 헤더들을 읽을 수 있게 합니다. 본문은 읽을 수 없습니다)

4.SOAP 확장(ASP.NET Webservice 암호화 설정하기)

ASP.NET 웹 서비스에 대해 구현할 암호화 지원은 SOAP 확장의 형태로 이루어집니다.
SOAP 확장은 ASP.NET 웹 서비스를 구현하는 개발자들이 단순히 메서드에 또 다른 특성을 추가함으로써(WebMethod 특성과 함께) 가능하며, 메시지는 암호화되거나 복호화 됩니다.

다음은 이러한 새로운 확장을 갖는 ASP.NET 웹 서비스의 코드 예제입니다.

<%@ WebService Language="C#" Class="CreditCardService" %> 
using System.Web.Services; 
public class CreditCardService 
{ 
 [WebMethod] [EncryptionExtension(Encrypt=EncryptMode.Response)] 
 public string GetCreditCardNumber() 
 { 
 return "MC: 4111-1111-1111-1111"; 
 } 
}
 

이는 매우 단순한 예제이긴 합니다만, GetCreditCardNumber 메서드에 단순히 하나의 사용자 정의 특성을 추가했다는 사실에 주목할 필요가 있습니다.

 [EncryptionExtension(Encrypt=EncryptMode.Response)] 

이것이 우리가 잠시 살펴보려 하는 사용자 정의 SOAP 확장 특성의 소스입니다. 이 기사를 쓰고 있는 시점에는, Encrypt=EncryptMode.Response와 Decrypt=DecryptMode=Request만이 지정 가능합니다(물론, EncryptMode.None과 Decrypt.None 값도 가능합니다).

요청은 일반 텍스트로 웹 서비스에게 전송될 수 있으나, 응답들은 암호화될 것입니다.

다음은 전형적인 교환이 어떤 지를 보여줍니다.
우선 요청이 들어옵니다.

<?xml version="1.0" encoding="utf-8"?> 
<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/ 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
<soap:Body> 
<GetCreditCardNumber xmlns="http://tempuri.org/" /> 
</soap:Body> 
</soap:Envelope> 

그 다음, 응답이 옵니다.

<?xml version="1.0" encoding="utf-8"?> 
<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/ 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body> 
<GetCreditCardNumber xmlns="http://tempuri.org/"> 
<GetCreditCardNumberResult>
83 151 243 32 53 95 86 13 190 134 188 241 198 209 72 114 122 38
 180 34 194 138 16 97 221 195 239 86 26 152 94 27 
</GetCreditCardNumberResult> 
</GetCreditCardNumber> 
</soap:Body> 
</soap:Envelope> 

확연하게 보이듯이, 응답은 여전히 유효한 SOAP 메시지입니다.
하지만, 신용카드 번호는 일반 텍스트로 전송하는 대신, 암호화된 바이트들의 배열로 교환됩니다.

여기에 또 다른 보안 문제가 있다는 사실도 기억하십시오.
예를 들면, 메서드는 아마도 GetCreditCardNumber라고 불려서는 안될 것입니다.
그 명칭은 숙련된 해커에게 귀뜸이 되는 정보가 될 수도 있을 테니 말입니다.
그렇긴 하지만, 역시나 요점은 XML 웹 서비스에 의해 보내지는 데이터가 여전히 HTTP, SMTP, 혹은 다른 전송 프로토콜 상에서 라우팅될 수 있는 유효한 SOAP 메시지로 전송된다는 것입니다

- 올바른 키를 가지고 있는 최종 클라이언트만이 메시지를 복호화할 수 있기에,
메시지의 보안은 안전합니다.
.NET 클라이언트들의 경우, 이는 wsdl.exe나
Visual Studio .NET에 의해 생성되는 프록시 클래스에 단순히 특성을 추가하는 문제일 뿐입니다.

... [SoapDocumentMethodAttribute(http://tempuri.org/GetCreditCardNumber, 
Use= SoapBindingUse.Literal, ParameterStyle= SoapParameterStyle.Wrapped)] 

[EncryptionExtension(Decrypt=DecryptMode.Request)] 
public string GetCreditCardNumber() 
{ 
 object[] results = this.Invoke("GetCreditCardNumber", new object[0]); 
 return ((string)(results[0])); 
} ...

위의 경우들 모두에서, 우리는 SOAP 확장을 사용하고 있습니다. SOAP 확장이란 SOAP 직렬화(serialization) 프로세스와 저 수준에서 상호작용을 할 수 있게 해 주는, 우리가 개발하는 클래스들(SoapExtension에서 파생된)을 말합니다. 밑의 도표에서, 빨간 별표들은 SOAP 확장을 통해서 상호작용을 할 수 있는 기회 시점들을 나타내고 있습니다.

그림 1. SOAP 직렬화와(serialization) 직렬화 해제(deserialization)

자. 그럼 이제 SOAP EncryptionExtension의 코드를 살펴보도록 하겠습니다.
단, 전체 소스가 아닌 작은 일부 구역들만을 살펴보려 합니다. 전체 소스를 원하시면 http://www.gotdotnet.com/team/rhoward (영문) 를 살펴보시기 바랍니다.

EncryptionExtension 클래스는
System.Web.Services.Protocols 네임스페이스에 있는 SoapExtension에서 파생됩니다.

SoapExtension에서 상속된 클래스들은 반드시 몇몇 메서드들과 속성들을 구현해야만 합니다. 그 중 가장 중요한 것은 다음에서 보여지고 있듯이, ProcessMessage(SoapMessage message) 메서드입니다.

public class EncryptionExtension : SoapExtension 
{ 


public override void ProcessMessage(SoapMessage message) 
{ switch (message.Stage) 
{ case SoapMessageStage.BeforeSerialize: break;
 case SoapMessageStage.AfterSerialize: Encrypt(); 
break; 
case SoapMessageStage.BeforeDeserialize: Decrypt(); 
break; 
case SoapMessageStage.AfterDeserialize: break;
 default: throw new Exception("invalid stage"); } } ... 
} 

재정의된 메서드 안에서, 우리는 SOAP 메시지 직렬화와 상호작용하기 위한 네 단계의 기회(위의 도표에서 표기한 것처럼)를 갖습니다. EncryptionExtension의 경우는, 암호화와 복호화를 위해서 오직 AfterSerialize와 BeforeDeserialize 단계에만 관여하고 있습니다. 만일, 예를 들어, 응답이 직렬화된 후에 GetCreditCardNumber 웹 서비스로 요청이 들어온다면, 우리의 EncryptionExtension는 ProcessMessage ()로부터 Encrypt()를 호출할 것입니다.

private void Encrypt() 
{ 
newStream.Position = 0; 
if ((encryptMode == EncryptMode.Request) || 
(encryptMode == EncryptMode.Response)) 
{ newStream = EncryptSoap(newStream); 
} Copy(newStream, oldStream); 
} 

Encrypt() 메서드 안에서는 EncryptionExtension 특성의 EncryptMode 속성이 설정되었는 지를 검사합니다. 만일, 이것이 EncryptMode.Request나 EncryptMode.Response로 설정되었다면, 내부 메서드인 EncryptSoap()가 호출됩니다. EncryptSoap()은 SOAP 메시지를 나타내는 스트림을 받고, 암호화된 값들을 갖는 새로운 스트림을 반환합니다.

 public MemoryStream EncryptSoap(Stream streamToEncrypt) 
{ 
streamToEncrypt.Position = 0; 
XmlTextReader reader = new XmlTextReader(streamToEncrypt); 
XmlDocument dom = new XmlDocument(); 
dom.Load(reader); 
XmlNamespaceManager nsmgr = new XmlNamespaceManager(dom.NameTable); 
nsmgr.AddNamespace("soap", http://schemas.xmlsoap.org/soap/envelope/); 

XmlNode node = dom.SelectSingleNode("//soap:Body", nsmgr); 
node = node.FirstChild.FirstChild; byte[] outData = Encrypt(node.InnerText); 
StringBuilder s = new StringBuilder(); 
for(int i=0; i<outData.Length; i++) 
{ 
if(i==(outData.Length-1)) s.Append(outData[i]); 
else s.Append(outData[i] + " "); 
} 
node.InnerText = s.ToString(); 
MemoryStream ms = new MemoryStream(); 
dom.Save(ms); ms.Position = 0; 
return ms; 
} 

EncryptSoap() 안에서는 soap:Body 안에 있는 첫 번째 노드를 암호화합니다. 적절한 XmlNode가 선택되고, 노드 안에 있는 텍스트는 문자열을 받아서 바이트들의 배열을 반환하는 Encrypt()에게로 다시 전달됩니다. 다음은 문자열을 암호화하기 위해 .NET DES 클래스들을 사용하고, 암호화된 값의 바이트 배열을 반환하는 Encrypt() 메서드입니다.

 private byte[] Encrypt(string stringToEncrypt) 
{ 

DESCryptoServiceProvider des = new DESCryptoServiceProvider(); 
byte[] inputByteArray = Encoding.UTF8.GetBytes(stringToEncrypt); 
MemoryStream ms = new MemoryStream(); 
CryptoStream cs = new CryptoStream(ms, des.CreateEncryptor( key, IV ), 
CryptoStreamMode.Write); cs.Write(inputByteArray, 0, inputByteArray.Length);
 cs.FlushFinalBlock(); return ms.ToArray(); 
} 

많은 사람들이 이 해결책이 .NET에 특화된 것이 아니냐고 물어오곤 합니다만, 이는 전혀 그렇지 않습니다. 하지만, 양쪽 업체 모두가 여기에 DES 암호화가 사용되었다는 것을 알고 있어야 하고, .NET 기반이 아닌 호출자도 DES 알고리즘을 사용해야 한다는 요구조건은 있습니다(DES는 공개적으로 사용 가능한 알고리즘임을 기억하십시오).

위의 예제를 보강하고자 한다면, 다음의 것들을 고려해 보십시오.

• 비대칭 암호화를 지원합니다: 호출자는 암호화를 위해서 서버의 공개 키를 사용하고, 서버는 응답을 암호화하기 위해서 클라이언트의 키를 사용합니다.
• 현재 예제는 오직 일반 텍스트 요청과 암호화된 응답만을 제공하고 있습니다.
• 인증정보 전송을 위한 SOAP 헤더들과 그들의 상세정보에 대해 암호화를 지원합니다.

5.요약

여러분도 아시다시피, ASP.NET 웹 서비스는 대단히 강력합니다.
대부분의 개발자들은 SOAP 확장의 능력을 완전하게 이해하고 있지 못하며, SOAP 확장이 웹 서비스에 대한 모든 종류의 새롭고 흥미로운 것들을 하기 위해서 어떻게 사용될 수 있는지도 잘 이해하지 못하고 있습니다.

예를 들면, ProcessMessage()에 의해 제공되는 기능성으로 인해서, XML 압축, 라우팅, 암호화, 로깅, 지불 처리 등과 같은 ASP.NET 웹 서비스 선택들을 구축하는 것은 상당히 쉽습니다.

이러한 해법을 사용하면, SOAP을 여전히 사용하면서 인터넷 너머로 안전하게 통신할 수 있는 XML 웹 서비스를 구축하는 것이 가능합니다.

Rob Howard는 .NET 프레임워크 팀의 ASP.NET 프로그램 매니저입니다. 그는 시간이 날 때마다 주로 가족과 함께 보내거나, 혹은 동부 워싱턴에서 계류낚시를 즐깁니다. 

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

(0) (0)

출처: 월간웹 2009.10

작성: 아이파트너즈, 전략기획본부

타임지는 매년 50개의 베스트 웹사이트를 선정해서 간략한 설명과 함께 제공을 하고 있다.  목록에 선정된 웹 사이트를 살펴보면 마케터나 크리에이티브 디자이너 또는 엔지니어들의 눈높이에서 보았을 때 최상의 웹 사이트라기보다는 일반인들의 눈높이에서 보는 사용성, 기능성, 유행 트랜드에 맞춘 사이트들이 많은 비중을 차지하고 있음을 볼 수가 있다.  2009년도 베스트 웹 사이트 목록을 보면 6위에 트위터가 올라와있는데, 트위터에 붙은 설명을 보면, 위에서 말한 것과 같이 지극히 개인적인 평을 붙여놓고 있는데, 그 내용은 다음과 같다.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

스티브 존슨은 마이크로-블로깅 사이트에 관한 타임지 커버스토리를 쓰면서 "트위터에 대해서 한가지 확실하게 이야기 할 수 있는 것은, 정말 형편없는 첫인상을 준다는 것"이라고 썼다. 그리고 그 말은 사실이다: 당신은 트위터를 좋아하던 아니면 증오할 것이다.  트위터를 증오하는 사람들은 뭔가 이야기를 할 가치가 있는 것은 140자 안에 쓸 것이 없다라고 고집을 한다. 트위터를 사랑하는 사람은 헤밍웨이의 가장 유명한 단편소설을 인용을 하는데: "팝니다: 애기신발, 한번도 신지 않았음" 어쨌던, 트위터는 우리들 주변 도처에 존재를 하고, 애쉬톤 커처나 샤킬 오닐이 트위터를 잘못 사용하는 것은 그들의 영화보다 훨씬 덜 해롭다.
(출처: 50 Best Web Sites, www.time.com)

비즈니스 적용 사례

이러한 지극히 개인적인 잡담용 도구인 트위터가 이제는 기업의 유용한 비즈니스도구로의 사용이 점차 확대가 되고 있는데, 이번 기사는 그러한 사례들에 대해서 살펴보기로 하자.  기업들은 트위터를 고객과의 “실시간” 커뮤니케이션 도구로 사용을 하고 있는데, 적용이 가능한 부분들은 1차적으로는 고객관계관리, 위기관리, 기업평판관리, 이벤트 알림이, 제품 프로모션과 영업지원 등 이 있고, 2차적으로는 직원 채용, 마켓 리서치 등이라고 할 수 있다.

1. @comcastcares

마케팅그룹인 에버딘그룹의 조사에 의하면 트위터를 이용하는 기업은 그렇지 않은 기업대비 17배나 높은 고객만족도를 가지고 있다고 한다.  2008년 4월 미국의 유명 케이블회사인 컴캐스트의 프랭크 엘리아슨은 트위터 상에 컴캐스트에 대한 좋지 않은 글들이 돌아다니는 것을 발견하고 @comcastcares라는 트위터를 시작하였고, 이 핸들을 통하여 고객에게 문제해결 방법, 온라인 상의 자료, 새로운 상품에 대한 홍보를 제공하고 있고, 물론 프랭크의 주요고객에 대한 서비스도 제공을 하고 있는데, 프랭크의 고객지원팀은 트위터를 이용하여 연간 21,000 건의 고객 불만 사례를 접수하고 해결을 하였다.

컴캐스트는 현재 11명으로 이루어진 소셜미디어 팀을 구성을 하고 하나의 핸들을 사용을 하는 것이 아닌, 프랭크의 @comcastcares, @comcastdoug, @comcastgeroge 와 같이 각 고객지원담당자 별로 트위터 핸들을 만들고 아침 7시부터 저녁 11시까지의 근무시간에 적어도 한 명의 고객지원자가 응대를 하고 있다.

고객의 입장에서도 트위터를 고객지원센터의 한 종류로 선호를 하는 이유는 전화를 걸고, 상담원이 연결이 될 때까지 따분한 엘리베이터 음악을 듣지 않아도 되고, 140자로 간단하게 적어서 보내면 된다는 것과 웹 사이트 이외에도 SMS, 모바일 어플리케이션, 데스크탑 위젯 등의 다양한 접근 플랫폼을 제공하고 있다는 매력을 지니고 있기 때문이다.

@comcastcares

2. @jetblue

소형 항공사인 제트블루는 항공사의 평판 관리와 떨어지는 매출관리를 위해서 고객에게 “기업”의 딱딱한 이미지가 아닌 “사람”의 부드러운 느낌을 전달하기 위해서 @jetblue라는 핸들을 만들었고, 이 핸들을 통해서 항공사의 잘못된 이미지 관리, 고객의 불평 접수 및 응대를 하고 있다.  2009년 7월에는 @jetblue의 추종자들에게는 편도요금을 9달러 – 약 만원-으로 제공을 하여 현재 10,000명이 넘는 추종자 그룹을 형성을 하고있다.  온라인에서 @jetblue에 추종자로 등록을 하면 @jetblue는 수 분내로 등록인의 follower로 등록을 하여, 그 사람의 트위터 내용들을 모니터링을 하는 등 적극적인 고객 평판관리에 나서고 있다.

3.@delloutlet 

델 컴퓨터는 트위터에 델 리퍼제품을 등록을 하여, 트위터 상의 추종자(follower)들에게 델이 제공을 하는 새로운 구매기회를 알려주고 있다.  델은 트위터 상에 약 12,000 명의 추종자를 보유하고 있으며, @delloutlet을 오픈을 한 첫해에 약 6억 원 어치의 리퍼 제품을 판매하였고, 현재는 백만명 이상의 추종자, 매출액은 약 36억원에 달하고 있다. 델은 현재 43명으로 구성이 된 소셜 미디어팀을 구성 트위터에서 80여개의 핸들을 가지고 고객지원은 물론 각 지역별 마케팅 정보의 수집을 진행을 하고 있다.

@delloutlet에 등록을 하는 사용자들은 사실은 델에게 마케팅 이메일을 그들에게 발송을 할 수 있는 허락을 주는 것이지만, 사용자들은 자신들만의 특별한 클럽에 가입을 한다는 느낌을 받는 것으로 이야기 되고 있다.

@delloutlet

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

(0) (0)

http://channy.creation.net/blog/668

http://mushman.co.kr/2690730

위와 같은 블로그가 대표적인 사용기네요.

뭐 굳이 안보셔도 SNS들은 대부분 성격이 비슷합니다.

1. 이메일가입 및 인증

2. 개인설정으로 프로필 수정

3. 글 또는 리플작성

4. @리플대상아이디 할말  //  #그룹명 할말

5. 좀 더 편하게 사용하기 위한 어플리케이션 제공

대략 이런 기능들이 있고요.

야머에는 파일 첨부 기능이 있는데 용량 제한은 어떻게 되는지 모르겠습니다. :)

- URL : https://www.yammer.com/

- App : https://www.yammer.com/company/applications

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

(0) (0)