calmglow (최진호)

성공한 서비스나 비즈니스 모델의 초기 사업계획은 실패한 것과 비교할때 훌륭할까? 아마 대부분 그렇게 생각할지도 모르겠다. 훌륭하고 환타스틱한 아이디어가 서비스를 성공에 이르게할지도 모른다.
하지만 요 며칠 신규 사업을 구상하면서 이전에 회사에서 성공했던 사업들의 계획서를 운 좋게 구해서 읽어보면 모호하고 엉뚱하고 무의미했던 내용이 적잖고 여타 다른 계획과 큰 차이를 느낄수가 없다.
사업은 결국 디테일과 끈기, 팀웍이 성공으로 이끄는 것이 아닌가 싶기도 하고.. 물론 전혀 엉뚱하고도 건질것 없는,시장 분석 엉터리로 된 계획에 의한 망할게 뻔한 사업도 있지만,
사업이 바라보는 시장의 방향만 어느 정도 맞다면 계획단계에선 조금 어설프고 엉성하다고 비웃을 일은 아닌것 같다.

만약 IT업종 중에 가장 재미있는 직업이 뭐냐고 물어본다면 나는 개발자라고 답할 것이다. 하지만 가장 되고 싶은 직업을 물어본다면 나는 아키텍트라고 답할 것이다.
하지만 나는 그동안 내 자신을 아키텍트라고 감히 말하기 부끄러워했다. 처음 개발을 시작할 때부터 나는 12년 전부터 JSTORM이라는 자바 학술모임을 통해 Software Engineering과 디자인 패턴등에 일찍이 관심을 가졌고 그 이후로도 줄곧 여러 프로젝트에 참여해오면서 산출물의 아키텍처에 일정 부분 영향을 끼쳐왔지만 그것만 가지고 IT아키텍트라고 할 수는 없지 않은가?

비록 10년이 넘는 IT경력의 기간이었지만 IT 아키텍처를 심도깊게 고민하고 그것을 위해 많은 stakeholder들과 대화하여 중지를 모으고 결국은 완성품을 만들어내는 아키텍트의 본질적인 업무를 한 것은 아니었는데, 사실 그동안 아키텍트로의 길은 언제나 열려있었다. 그럼에도 불구하고 선뜻 아키텍트의 길을 가지 않았던 이유는, 우리나라에서 제대로 된 아키텍트의 업무를 할 수 있는 자리가 많지 않았으며 개발이나 기술영업과 지원 등 다양한 실무 경험이 바탕이 되지 않는 뿌리가 약한 아키텍트가 되고 싶지 않았기 때문이었다.

시간은 흘러 어느덧 IT바닥에, 그것도 엔터프라이즈 IT 바닥에 12년 넘게 개발자로, Java EE 전문가로 지내다가 얼마 전부터 OO텔레콤에서 아키텍트의 역할을 수행하게 되었다. 이제는 스스로를 아키텍트라고 부를 수 있는가 자문해보면, 경험은 많아졌는데 기본과 기초는 다 잊어버린, 뿌리 한쪽이 영 부실한 아키텍트가 아닌가 싶다.

IT 아키텍트는 많은 IT 경험과 IT 지식, 그리고 인간에 대한 이해를 기본 소양으로 하고 있다. 과연 나를 아키텍트라고 자랑스럽게 부를 날이 언제 오게될런지 모르겠으나 나는 즐겁게 그 날을 위해 조금씩 준비하겠다.
나는.. (언젠가는) 아키텍트이다.

출처, 한겨레21 903호

스마트폰 열풍과 함께 개인들뿐만 아니라 기업들도 내부직원과 고객을 위한 스마트폰/태블릿용 앱을 유행처럼 만들고 있다. 그러나 예전 웹기반 서비스를 구축할 때처럼의 품질 검증 절차만을 갖고 출시하다가는 아주 아주 큰코 다치기 쉽다.

작은 회사의 경우 옆의 직원이 무엇을 잘 하는지 뭘 잘먹는지 까지도 알만큼 서로 공유하는 게 많아서 일처리도 빠르지만,
회사 규모가 30명 이상만 되도 의사소통에 많은 어려움을 겪는다. 이름도 가물가물 외근이 많은 직원은 심지어 얼굴도 가물가물...

그래서! Facebook이나 twitter와 같이 빠른 소식 전파와 복잡한 관계를 잘 소화해내는 인프라에 많은 기업들이 관심을 갖는다.

우리 회사에도 내부에 facebook이나 트위터같은 걸 도입하면 기업 문화가 확~ 달라지지 않을까?

그래서 함 여러 벤더들을 동원해서 찾아봤다. 기업에 SNS를 도입해서 성공적으로 운영중인 사례가 있는지. 물론 구글이나 facebook같은 회사들 말고. 있기는 있다. 하지만 모두 해외 사례이고 그것도 그다지 많다고만 볼 수는 없는 홍보성 자료일 뿐.
대부분 직원들의 활발한 참여를 통한 기업 내부의 소셜네트워크라고 불리울만큼의 그것은 찾아보기 힘들었다.

IBM에 다닐 때, 그래도 IBM은 지식 공유문화가 대단히 활발해서 매우 매우 즐거운 경험을 했다. 하지만 그것도 해외직원들하고의 네트워크였지, 국내 IBM직원들과는 왕래가 없었다. 심지어는 Lotus팀 직원들 조차도.

나의 현재 고정관념(?)으로는 국내 기업에서의 SNS는 시기상조라는 생각이다.

SNS는 기본적으로 수평적인 네트워크를 지향한다. 그러나 한국 기업의 문화는 이러한 수평적 네트워크가 매우 취약하다. 내가 맘 놓고 내 활동을 드러내는 행위는, 누군가 나를 감시하는 눈빛이 있을 때에는 절대 활발할 수가 없다. (당연하잖아!) 대체 어느 한국 기업 조직에서 서로간에 눈치보며 생활하지 않고 자유롭게 이름 대놓고 의견개진할 수 있겠는가?

다만 소셜네트워크의 일부 개념을 도입을 통해 기업 문화의 변화를 꾀해볼 수는 있을 것 같다. 이런 경우에도 점진적인 솔루션 도입과 더불어 문화의 변화까지 아우르는 묘수가 필요하지 않나 싶다.
점진적인 소셜 네트워크 서비스의 기업 도입의 경우 가장 첫번째 시작점은 바로 개인 프로파일 서비스일 것이다. 회사에서의 직원 개개인이 자신의 Identity를 가지고 조금씩 관계를 확장시켜 나가는 관문을 마련해주는 것이다. 그럼으로써 개인 전문성과 네트워크를 확장해나갈 수 있지 않을까라고 생각한다.

우리는 알게 모르게 MS Window의 GUI 고정관념에 많은 영향을 받고 있습니다.
화면에서 어떤 명령을 실행하는 방식이 마우스로 메뉴의 어떤 명령을 클릭하는 것만이 유일한 방법은 아니죠.
스마트폰의 시대에 살고 있지만 기본적으로 우리가 컴퓨터에 명령을 내리는 방식 자체는 근본적으로 달라지지 않았습니다.
여전히 메뉴를 클릭하여 명령을 실행하고 세부 옵션 사항을 클릭하죠.

애플리케이션이 무엇이건 보다 직관적이고 똑똑하게 명령을 실행할 수 있는 방법은 없을까요?

우분투(Ubuntu)는 새롭게 다가올 12.04버전부터 HUD(Head-Up Display)라는 GUI 인터페이스를 선보입니다.



우분투의 HUD는 메뉴를 근본적으로 없애려는 시도입니다.
컴퓨터는 나의 취향을 알고 있고 자주 실행하는 명령의 흐름을 이해합니다. 그리고 나의 명령에 즉각적으로 반응합니다.
위의 동영상에서는 주로 키보드를 사용하고 있지만 궁극적으로 우분투의 HUD가 구현해내려는 기본 환경은 음성인식 기반입니다. 아이폰의 Siri와 유사한 기술로 보다 컴퓨터 OS의 근본적인 인터페이스의 변화를 꾀하고 있는 것입니다.
우분투가 항상 그랬듯, 시작은 서투르고 버그 투성이(?)이지만 몇 년 후에는 정말 근사한 인터페이스의 혁명을 맞이하게 되지 않을까 기대해봅니다.

이 글을 쓰기에 앞서 우선 나는  REST에 대하여 아주 우호적이며, 국내 어떤 개발자보다 일찍(2003년) REST를 기업에 적용해서 그 장점과 단점을 누구보다 충분히 알고 있다는 것을 언급하고 싶다.

이미 이 글을 여기까지 읽었다면 REST에 대해서 아는 이 일거라 가정하고 좀 더 나의 고민을 풀어가보겠다.

엔터프라이즈 애플리케이션을 비롯하여 대부분의 애플리케이션은 추상화 과정을 통해 그 아키텍처에 계층을 구성하고 이 계층이 많아질 수록 추상화가 높아지며 그 계층이 보통 다음과 같이 세가지 이상의 단계로 구성이 된다.

• Data Access 계층
• Domain 계층
• 서비스 계층
• (Presentation 계층)

이렇게 계층화를 시도하면 서비스 계층에서는 주로 Use case의 비즈니스 관점의 업무로직을 다루게 되어 보다 재사용 가능하고 유연한 구조를 획득하게 된다. 이 서비스에서는 다양한 내부 트랜잭션들을 수행하기 마련이다. 따라서 Data access에서 서비스 계층으로 나아갈 수록 인터페이스는 보다 Coarse grained하게 그 특성이 변하게 된다.

XX은행에서 돈을 '이체한다'라는 서비스는 실제로는 다양한 업무 트랜잭션을 내부에 감추고 있고 이러한 추상화를 통해 개발 생산성 뿐만 아니라 성능적인 문제에 있어서도 훨씬 더 나은 효과를 가져다주기 마련이다.

그런데 Web 2.0시대에 오면서 REST api를 여러 엔터프라이즈 프로젝트나 모바일 관련 프로젝트 등에서 자주 사용되고 있는 것을 접하고는 하는데, 과연 REST의 특성이 이러한 Coarse grained한 업무 서비스 설계에 어울리는 인터페이스인가 하는 진지한 고민을 할 필요가 있다는 게 이 글의 요지이다.

REST는 말 그대로 자원에 대한 접근을 URL과 HTTP method를 통해 허용하는 방식이다. 그러다보니 아무리 서비스스러운 API 설계를 잘한다고 해도 그 근간은 Domain이나 Data 위주일 수밖에 없다. 조금이라도 복잡한 비즈니스 트랜잭션을 수행하려면 자원관점에서는 설계하기 까다로운 상황이 자주 발생하며, 이러한 복합 트랜잭션이나 업무 트랜잭션 처리를 presentation, client 영역에 떠넘기게 되는 상황이 발생하곤 한다.

이게 왜 문제냐면, 이러한 진지한 고민없이 REST를 주요 인터페이스로 프로젝트를 끌고 가다보면 Open직전에 Coarse grained하지 않은 client와 서비스간 잦는 호출 문제로 인하여 성능에 엄청난 악영향을 미치게 되기 때문이다. REST는 아키텍트가 설계하기는 편하지만 여러가지 비즈니스이슈와 성능 및 트랜잭션 이슈등을 무시하게 되는 상황을 만들 여지가 큰 인터페이스인 것이다.

클라이언트 개발자는 REST가 편하다고 엄청나게 많은 비동기 AJAX call을 서버에 때려버리고, 예전같으면 page call 트랜잭션 한번이면 끝날 것을 수없이 많은 fine grained한 call로 성능을 느리게 만들어버린다.

따라서 내가 이야기하고 싶은 결론은, 유행이라고 하여 REST와 AJAX기반의 fine grained한 클라이언트와 서버간 통신을 남발하다가는 프로젝트 말미에 엄청난 고생을 할 여지가 있으니, REST는 꼭 필요한 때에만 사용하는 것이 좋지 않겠는가 하는 것이다.
굳이 꼭 main interface로 써야한다면 REST를 굳이 domain model 관점에서 인터페이스 구성하지 말고 정말 업무로직 관점에서 설계하여 애초에 자원 접근은 막고 업무로직 기반의 Coarse grained한 서비스를 설계하는 자세가 필요할 것이다.