신기술 밀림 속 생존전략 Part 1: 말잔치를 벗어나 본질 바라보기 |


새로운 기술이 등장하여 널리 보급되기 이전에는 미신이나 오해가 있기 마련이다. 이런 현상은 자연스러운 것이기 때문에 심각하게 걱정할 필요는 없다. 하지만 종종 그냥 지나쳐버리기 찜찜한 일들을 목격한다. 더구나 신기술에 대한 무지를 상술로 이용하는 것 아닌가 하는 의심이 생기는 일들을 접하면 살짝 분노를 느끼기도 한다.
UCC용 하드 디스크?
여자 친구와 시내를 함께 걷고 있는데 여자 친구가 “UCC용 하드 디스크는 뭐가 달라?” 하며 물었다. 궁금해서 묻는 것은 아니었고, 광고에 묻어나는 장삿속을 비웃는 말투였다. 동영상을 촬영할 수 있는 디지털 사진기 광고였던 것 같은데 아마도 하드 디스크 용량이 넉넉해 동영상 저장에 유리하다는 의미가 아닐까 추정된다. 하지만 UCC 저장을 위해 특별한 하드 디스크가 필요한 것은 아니다. 그래서인지 호감이 가지 않는 광고 문구다.
최근 부쩍 UCC라는 말이 널리 통용되는 것 같다. UCC라는 말은 처음에는 웹 사이트 기획자나 이른바 ‘웹 2.0’에 관심이 있는 사람들 사이에서 널리 이야기되었다. 그러던 것이 TV 뉴스나 주류 매체에서 ‘일반 사용자가 올리는 동영상’을 UCC로 지칭하면서 일반인에게 익숙해진 듯하다. 재미있는 동영상이 널리 퍼질수록 UCC라는 말도 점차 일상에서 쓰이는 낱말이 되어 갔다. UCC의 인기를 돈벌이에 활용하려는 업체들의 발빠른 대응이 UCC라는 말을 더욱 많은 사람들에게 노출한 탓도 있을 것이다.

그림 1. UCC 검색결과
검색엔진에서 UCC를 검색어로 검색해보면, 업체들이 노력한 흔적을 쉽게 찾아볼 수 있다. UCC용 디지털 사진기, 마이크, DRM 등이 첫 화면을 장식한다. 분명 일반 사용자가 만들어서 올린 동영상은 UCC다. 그리고 UCC를 돕기 위한 기기를 파는 것은 잘못된 일도 아니다. 하지만 UCC의 본고장에서 UCC를 통해 웹 문화 혹은 웹을 활용 형태가 발전해가고 있는 모습을 보면 우리의 UCC가 아쉽게 느껴진다.
UCC가 무언인지부터 다시 살펴보자. UCC는 User Created Content의 약자로 UGC(User Generated Content)라고도 한다. 전통적으로 컨텐츠의 생산자와 소비자 층은 확연히 구분되어 왔기 때문에 일반 사용자가 직접 창작하거나 제작에 지대한 영향을 제공하여 생산된 컨텐츠는 UCC라고 구분되어 불린다. 디지털 비디오 관련 기술 발전, 블로그나 위키와 같은 소프트웨어의 등장, 그리고 mp3p 보급과 포드캐스팅 관련 기술 발달과 같은 기술적인 요인 덕분에 사용자들은 쉽게 컨텐츠를 제작하고 공개할 수 있게 되었다. 동시에 오픈 소스를 비롯한 유연한 라이선스 정책 등은 이러한 컨텐츠의 배포와 공유를 촉진시켰다.
플리커나 유튜브, 그리고 위대한 사이트 위키백과 등의 발전 방향을 유심히 보면 우리의 UCC는 조금은 본질을 벗어나 있다는 느낌마저 받는다. 그래도 희망적인 소식은 있다. 아직 가시적인 성과를 확인하기에는 이르지만, 스프링노트류의 서비스를 보면 국내에서도 UCC를 통해 부가가치를 창출할 수 있는 가능성에 대한 기대감이 생긴다. 이 글을 읽은 독자라면 UCC라는 말을 들으면 단순히 재미있는 동영상을 떠올리기보다는 사용자가 더 적극적이고 창의적인 방식으로 웹을 활용할 수 있는 환경을 떠올렸으면 좋겠다.
AOP에 웬 관리자 관점? 설계자 관점?
UCC의 편향된 사용 문제는 오용이라고 할 정도는 아니다. 최근에 완전한 오용 사례를 접했다. 국내 유명 소프트웨어 업체의 자료에서 AOP 기술을 완전히 왜곡하여 사용한 것을 발견한 것이다.
AOP(Aspect Oriented Programming)는 최근에 나온 프로그래밍 패러다임으로 주로 프로그램의 모듈화에 초점을 맞춘 개념이다. 프로그램의 기능을 업무적 기준으로 분할하면 나누어진 모듈에 흩어져 포함되는 기능이 생긴다. 가령, 어떤 업무를 수행할 권한이 있는 사용자의 접근인가를 확인하는 부분은 대부분의 업무에 공통으로 적용된다. 이와 같은 기능을 ‘crosscutting concerns’라고 하는데 이를 별도 모듈로 다루는 프로그래밍 패러다임이 바로 AOP다.
만약 UML이나 UP(Unified Process)를 접해본 사람이라면 위에서 설명한 내용이 이해가 가지 않더라도, AOP가 Philippe Kruchten의 4+1 뷰와는 완전히 다른 것이라는 정도는 알 수 있을 것이다.

그림 2. Philippe Kruchten의 4+1 뷰
한편, 이클립스를 사용해본 개발자라면 AOP와 Perspective가 혼동할 만한 것이 아니라는 정도는 쉽게 알 수 있다.

그림 3. 이클립스의 Perspective
업체의 명성을 고려해보면 상상할 수 없는 일이다. 해당 개발도구가 AOP를 적용했는지 그렇지 않은지는 알 수 없지만, 자료에 소개된 내용은 AOP와는 아무런 상관이 없는 내용이다.
AOP가 비교적 신기술이라 자료를 볼 고객들이 아직 그 내용을 정확하게 이해하고 있지 못할 가능성이 높다는 점을 감안하면, AOP라는 용어를 더욱 조심스럽게 다뤄야 하는 것이 직업인의 자세가 아닐까?
SOA 열풍, 왜 도입하는가부터 분명히 하자
필자의 은사이자 전산학을 전공한 교수님께서 ‘Loosely Coupled’라는 서적을 매우 높게 평가하셨다. 내용을 읽어보니 웹 서비스가 요구되는 상황에 대한 설명이 뛰어난 책이었다. 교수님 말씀에 따르면 웹 서비스 관련 서적이 주로 기술적인 세부 내용에만 초점이 맞춰져 있어서, 도무지 왜 웹 서비스를 도입하고 어디에 써먹을 것인지에 대해 논하는 서적을 찾기가 드물다는 것이다. 교수님이 언급한 현상은 필자가 최근 프로젝트에서 SOA가 다뤄지는 양상을 통해 받은 인상과 비슷했다. 많은 사람들이 SOA를 이야기하고, SOA를 적용해야 한다고 하는데 왜 하는지에 대해서는 명확하게 이야기하는 사람들을 보지는 못했다.
SOA(Service Oriented Architecture)란 무엇인가? 위키백과의 설명에서도 널리 합의된 정의는 존재하지 않는다고 한다. 그만큼 혼선이 많다는 이야기다. ‘서비스를 지향한다’는 표현은 다소 모호한 의미지만, 특정 플랫폼 구현에 대한 종속성이 적은 어느 정도 독립적인 서비스의 연계(loosely coupled services)를 통해 업무 프로세스나 사용자의 요구를 지원하는 것을 의미한다. SOA는 접근 방법의 하나이기 때문에 반드시 어떤 특별한 소프트웨어가 필요한 것은 아니다. 물론, 업계 대형 벤더들이 주도하는 웹 서비스 표준과 제품이 출시되어 있기는 하다. 하지만 그것은 SOA 구현을 가능하게 하는 하나의 옵션에 지나지 않는다. 게다가 아직 SOA에 대한 정의조차도 충분히 수렴되지 못한 상태다. 그런 상태에서 SOA로 무언가 진행한다는 것은 분명한 목적을 갖고 행하는 것일까?
미국의 유명 IT 컨설팅 업체인 ThoughtWorks의 SOA 관련 리더인 Jim Webber 박사의 발표 자료는 다음과 같은 내용으로 시작된다.
There are two things money cannot buy:
1. Love(Lennon/McCartney)
2. An SOA(Webber)
돈으로 살 수 없는 것이 두 가지가 있는데 하나는 사랑이고, 다른 하나는 SOA라는 이야기다. 뭔가 잘못된 현실을 비판하는 흥미로운 도입부다.
NetworkComputing.com의 독자 설문에서 가장 혐오하는(despise) 기술 1위로 SOA가 꼽혔다고 한다. 우리의 이야기가 아니라 미국의 이야기지만 타산지석으로 삼을 만하다.

그림 4. NWC의 2007년 독자 설문 조사
누군가 SOA라는 것이 무언가 대단한 결과를 가져온다고 믿고 많은 돈과 노력을 쏟아 부었다고 가정해보자. 그리고 나서 얻은 결과는 매우 미미했다면, SOA를 칭송하겠는가? 아니면, 혐오(despise)하겠는가?
이러한 현상이 SOA의 진면목은 아닐 것이다. 필자는 SOA가 자연스러운 시스템의 발전 방향이라고 생각한다. 다만, 현재 SOA를 논하는 많은 이야기들이 어쩌면 아직은 내용이 불충분한 말들이거나 더러는 왜곡된 이야기일 수 있다는 점을 지적하고 싶다.
맺음말
지금까지 신기술 관련 용어만 강조되면서 생긴 몇 가지 부정적 사례들을 살펴보았다. 사실 신기술이 나오자마자 그 개념을 처음부터 정확히 파악하기는 쉽지 않다. 그래서 앞서 말했듯이 오해가 생기는 것은 자연스러운 현상이다. 하지만 문제는 기술이 보급되면서 그와 같은 상황이 개선되지 않고 무심결에 또는 의도적으로 그런 현상을 악용하는 경우가 생긴다는 것이다. 이로 인해 현란한 용어에 혹해 정작 중요한 신기술이 왜 필요한지에 대한 맥락은 제대로 보지 못하고 놓치는 경우도 많다. 다음 회에는 신기술 초창기의 미신 못지 않은 골칫거리인 FUD(Fear, uncertainty and doubt)에 대해 살펴보겠다.
참고 자료
- http://en.wikipedia.org/wiki/User-created_content
- http://en.wikipedia.org/wiki/Aspect-oriented_programming
- The architecture of Web applications (developerWorks)
- http://en.wikipedia.org/wiki/Service-oriented_architecture
- Guerrilla SOA
- http://www.networkcomputing.com/gallery/2006/1109/1109f1poll1.jhtml
[지난 Special Issue 보기]
|