크리에이티브 커먼즈 라이선스
Creative Commons License

시스템을 만들때에 사용자(user)의 요구를 충족시키는 것이 제일 목적이라고 말한다. 보통 사용자라고 함은 시스템이 제공하는 서비스를 직접 사용해서 원하는 것(가치)을 얻는 행위를 하는 액터를 일컫는다. 이러한 사용자는 불특정 다수가 될 수도 있겠지만, 업무 시스템과 같이 특정 업무를 위한 시스템의 경우에는 명확한 업무 사용자가 정의된다. 어떠한 사용자이든 이들은 시스템을 직접 다루거나 처리하는 형태가 아닌 그저 수동적으로 시스템이 일방적으로 제공하는 서비스를 사용할 뿐이다.


하지만, 최근의 시스템들은 사용자들에게 어느정도는 능동적인 행위를 부여하는 형태로 서비스를 제공하기 시작한다. 예전에는 HTML을 그저 브라우저를 통해 화면에 보여지는 요소를 만드는 형태로만 쳐다보았다면, 지금의 사용자들은 직접 자신만의 HTML을 조작하기를 원하고 많은 시스템들이 그러한 서비스들을 제공하고 있다. HTML 조작이 어려운 사용자들에게는 단순한 형태의 템플릿에서부터 복잡한 조합을 할 수 있는 템플릿까지 제공하여 사용자들의 입맛에 맞게 구성하라고 내어준다. 더 나아간다면 사용자들의 행위나 형태를 분석하여 자동으로 짐작하여 다양한 화면을 보여주기도 한다.



James, I think your cover's blown!
James, I think your cover's blown! by laverrue 저작자 표시



이러한 사용자에 대한 관점(viewpoint)은 점점 시스템을 조작할 수 있는 뷰(view)까지도 확대되고 있는 것이다. 이해관계자(stakeholder)는 이러한 사용자들을 포함하여 시스템을 둘러싸고 있는 다양한 이해관계(interest)와 관심사(concern)를 가지는 모든 사람(요즘에 사람 뿐만 아니라, 여러 시스템이 연계되고 외부에 서비스들을 오픈해주기 때문에 이러한 범주까지도 포괄하는 형태이다.)을 통칭한다. 시스템을 사용하는 사람만 보더라도 단순히 서비스를 제공하는 수동적인 형태가 아닌 능동적으로 시스템을 조작할 수 있는 기능까지도 부여하는 추세로 본다면 그보다 범주가 더 큰 이해관계자들이 원하는 시스템에서의 기능까지를 고려한다면 너무나도 많은 기능들을 시스템에서 제공되어야 할 상황이다.


시스템을 운영하는 사람들은 일일히 그 많은 서버를 관리하지 않고, 한번의 클릭으로 수십, 수백, 수천대의 서비를 관리하기 원한다. 시스템에서 문제가 발생되면 어떤 문제인지, 그리고 누가 해결해야 하는지, 얼마나 빨리 복구될 수 있는지에 대해서 통지받기 원한다. 심지어 시스템의 하드웨어에 대한 수명이나 상태까지도 자동으로 납품업자에게까지 알려주어 구매 프로세스가 자동으로 발생되기까지도 원하는 경우도 있다.


이제 시스템은 가만히 두면 사람들이 알아서 모이는 그러한 서비스를 제공해서는 더 이상 그 가치를 발휘하지 못한 상태까지 진화한 것이다. 이러한 상황에서 시스템을 만드는 아키텍트에게도 여러모로 고민거리들이 점차 늘어가기만 한다. 점점 늘어만 가는 이해관계자들과 이들의 요구는 그 끝을 알기가 점점 힘들어진다.


아키텍트에게 이해관계자들의 관심사는 시스템을 만드는 가장 중요한 요소가 된다. 이해관계자들이 많아지고, 이들이 관심을 갖는 분야가 다양할수록 신경써야 하는 (혹은 만들어야 하는) 아키텍처 요소들이 늘어난다는 것이다. 사실 얼마나 많은 이해관계자들을 만족시킬 것인가에 대한 정답은 없다. 하지만, 이 물음을 역으로 생각해본다면 이해관계자들은 어떠한 시스템에 만족을 하는가로 바꿔볼 수 있을 것이다. 즉, 이해관계자들이 만족하는 시스템을 찾아서 그 속성을 분석해야 됨을 의미한다. 이해관계자들이 만족하는 시스템은 자신들이 예전에 직접 경험했던 것일 수도 있고, 혹은 광고나 컨퍼런스 같은 곳에서 마케팅 요소가 가미된 시스템일 수도 있다. 혹은 최근에 유행하는 트렌드일 수도 있고, 때로는 스스로의 상상에 의해서 만들어낸 것일 수도 있다.


그러나, 무엇보다도 이해관계자들이 만족하는 시스템은 시스템을 사용함으로 인해서 자신의 가치가 더 돋보이게 만드는 것일게다. 즉, 해당 시스템을 사용함으로써 남들보다 돋보이고 더 효과적이고 효율적인 정보를 사용하고 있다는 느낌을 받는 시스템이 이해관계자 입장에서 비용을 들인 가치를 얻게 된다. 개발자 입장에서 시스템을 다루어야 하는데 여러가지 감시 체계나 복잡한 절차를 통해 자신의 작업을 다른 이에게 잘하고 있는지를 증명하게 만든다면 그 스스로 시스템을 다룬다는 자부심보다 남의 물건에 흠집이 나지 않게 조심스럽게 다루어야 한다는 강박관념을 더 받을 것이다. 웹페이지 어디 구석에 쳐박혀 있는 정보를 보기 위해서 다양한 인증 체계와 수많은 브라우저의 종료를 거치고 나서야 원하는 것을 얻는다면 사람을 위한 시스템이 아닌 시스템을 위한 사람으로 만든다는 감정으로 스스로의 자존감에 훼손이 발생되었다는 느낌을 받을 것이다.


시스템의 아키텍처를 만드는 아키텍트로써 이해관계자들의 요구를 충족시키는 것이 가장 큰 임무이다. 그러한 임무는 결국에는 이해관계자의 자존감을 높여줄 수 있는 시스템을 만드는 일이다. 이제 기술의 한계(혹은 기술을 구현할 수 있는 당사자의 한계)를 넘어서 다시 인간답게 살기 원하는 질을 제공하는게 시스템의 목적이 되었다. 얼마나 많은 이해관계자를 만족시켜야 하는지에 대한 물음은 아키텍트 스스로 인간에게 가치를 높여주는 시스템을 만들었는가로 다시 자문하게 만든다.


저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
오늘 스티브 잡스가 세상을 떠나면서 그의 추모가 인터넷에서 활발하다. 개인적으로도 그와 같이 동시대에 살았다는 것이 그리고, 그의 작품인 아이폰과 아이패드를 사용할 수 있었다는 것인 행운이었지 않았나 싶다. (사실, 맥도 사용하고 싶지만 경제적인 여력이 없어 그가 가지고 있는 SW에 대한 생각이나 열정을 고스란히 느끼기에는 한계가 있을 것이라고 생각한다.) 스티브 잡스는 IT 업종에 속해 새로운 길을 제시했을 뿐만 아니라, 그는 대중에서 뛰어난 연설을 했던 연설가로도 손색이 없다. 혹자는 스티브가 최고의 프로그래머라고 말하는 사람도 있지만, 실은 그가 프로그래머는 아니었다. 어느 자료나 문서를 보더라도 스티브가 코드를 작성한 프로그래머라는 이야기를 들어본 적은 없다.



하지만, 그에게서 IT를 이끄는 힘을 느낄 수 있는 것은 어찌 보면 그의 철학이라는 생각이 든다. 그는 그가 속한 프로그래머들에게 자기가 생각하고 있는 SW가 가질 수 있는 모든 것들을 강요하거나 때로는 설득하고 이끌었다. 초기 애플을 만들 때도 그랬고, 그 다음에 애플을 떠나 다른 것을 할 때도 그랬고, 다시 애플에 돌아와서도 그랬다. 물론, 상세한 그의 사상들은 바뀌었는지 몰라도 그가 꿈꾸고 그가 생각하는 것들을 고스란히 SW에 녹이기를 원했고, 그러한 사상은 결국 애플이 만든 SW에 고스란히 녹아들어갔다. 그가 생각하는 기술들은 사실 그가 최초로 고안한 것들도 아니고, 직접 만든 것들도 아니다. 이미 SW 업계에서는 여기 저기서 사용되거나 실용화된 것들이다. 그럼에도 불구하고, 그를 위대하다고 말할 수 있는 사실은 그가 만들고자 했던, 그리고 만들었던 SW들에는 나름의 애플과 스티브의 철학이 있기 때문이다.

철학이 있는 아키텍처는 사실 어떠한 공식적인 표현이나 문서로 말할 수 있는 성질이 아닐 수도 있다. 스티브의 아키텍처라고 할 수 있는 애플이 만든 SW의 아키텍처들은 사용성의 강점과 더불어서 간단성(simplicity)의 묘미를 맛볼 수 있는 것들이다. 이를 표현할 수 있는 산출물이 어떠한 것들이 있는지 지금의 개발 프로세스에서 매핑시켜보면 알 것이다. 어떠한 산출물이 이러한 성질을 표현할 수 있을 것인가. 하지만, 우리의 SW 개발은 산출물로 대변되는 기성품과 같이 찍어대는 형태로 만들어낸다는 생각을 한다. 거기에는 어떠한 아키텍트의 사상이나 철학이 녹아들어가기를 원하지 않는 마치 감정이 없는 문서만을 만들기를 강요하는 것 같다.

가장 많이 사용되고, 검증되고, 최고의 성능과 품질을 보장하는 SW만을 조립하는 것이 아키텍처일까. 그리고, 그러한 아키텍처가 가장 최고의 아키텍처라고 생각하는가. 이에 대한 대답은 물론 아니다라는 것이다. 아키텍처는 기본적으로 가지는 성질과 품질이 있으며, 여기에 철학을 더해서 품격이라고 말하고 싶다. 즉, SW 아키텍처에는 품격이 있으며, 그 품격은 기본적인 SW 아키텍처가 가지는 요소 이외에 해당 아키텍트가 SW에 가미하고 싶은 철학(사상)이 존재해야지만 품격이 완성된다고 본다.

스티브도 그랬던 것처럼(스티브를 SW 아키텍트로 바라본다면) 본인이 추구하던 SW 아키텍처는 때로는 그 당시에 혁신이라고 말할 만큼 고객들에게 흠뻑 빠질만하게 잘 만들어진 것일 수도 있었지만, 때로는 대중의 외면을 받을 만큼 시대를 너무나 앞서는 현실 가능성이 없는 형태일 수도 있다. 그러나, 스티브는 이러한 자신만의 철학을 결코 포기하지 않고, 나름대로 현실과의 타협과 설득을 통해서 결국 스트브의 아키텍처를 완성했다. (적어도 난 스티브 잡스의 아키텍처는 존재한다고 보고 그러한 아키텍처가 애플을 성장하게 만든다고 본다.)

우리나라의 수많은 SW 중에서 '누구'의, 혹은 '어떠한 조직'의 아키텍처라고 불릴 수 있는 것들이 있을까. 아니, 그렇게 불리는 것을 허용하는가. SW 아키텍처는 이를 만든 사람의 특성이 나타날 수 있어야 하며, 이게 SW 아키텍처의 품격이지 아닐까. 
저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
점점 더 많은 기계 장치와 IT가 결합되면서 IT 기술 역시 새로운 개념과 기존 기술의 발전된 형태로 그 모습을 새로 하고 있습니다. 현재 우리에게 피부로 직접 와 닿는 것은 바로 스마트 폰이 그 대표적인 예일겁니다. 스마트 폰의 프로그래밍 기술들은 자체적인 레파지토리와 프로세스를 제어할 수 있는 기법들을 포함하며, 이는 새로운 HTML5 에서도 그대로 나타납니다. 특히, 장비에 특화된 기능들이 IT 기술과 만나면서 클라이언트 영역 내에서도 서비스를 주고 받는 또 다른 클라이언트-서버 형태의 아키텍처가 형성됩니다. 여기에 디바이스끼리의 커뮤니케이션 경로를 연결하면 그러한 형태는 더 복잡해지고, 극대화되어 또 다른 WWW 형태의 아키텍처가 만들어집니다. 결국, 기존에 우리가 프로그래밍을 해왔던 전형적인 CS 유형의 아키텍처는 노드와 노드 사이의 연결 형태이고, 그 노드는 서로가 서버이자 클라이언트가 될 수 밖에 없는 아키텍처가 만들어집니다.

이러한 현상들은 디바이스나 클라이언트가 제어하거나 풍부한 기능을 가지면 가질수록 더 심해지며, 이를 지원하는 IT 기술 역시 상당한 영역까지 클라이언트 영역으로 옮기게 만듭니다. 지금 새로 업데이트되거나 업그레이드되는 스마트폰 OS나 브라우저 기술들은 점점 더 많고 풍부한 - 이러한 개념들은 기존에 서버에서만 존재했었고, 클라이언트에서는 전혀 그러한 기술을 흉내내기 힘들었던 - API들로 채워지고 있습니다. 지금의 클라이언트들은 기존의 무식하고 답답했던 모습에서 점점 더 스마트하고 나름대로 사고를 할 수 있는 형태로 변해가고 있습니다. 이와 같은 아키텍처에서 비즈니스 로직들은 결국 클라이언트로 이전하는게 오히려 더 나을 수도 있으며, 그러한 아키텍처가 더 안정적일 수 있습니다.

클라이언트는 전체 상황을 수집하는 능력과 주시하는 능력을 가지게 되며, 이를 기반으로 자체적으로 판단과 결정을 할 수 있는 권한을 가지게 되며, 결국 기존에 서버에서만 존재하고 중요하다고 생각되던 비즈니스 로직을 가지게 됩니다. '스마트'하다는 표현은 비즈니스 로직이 존재하고, 그것도 풍부한 상태로 있다라는 것을 의미합니다.

이러한 '스마트'한 클라이언트와 서버와의 관계는 참으로 불편한 관계를 형성할 수 밖에 없습니다. 기존의 서버에서는 중앙 집중적으로 처리하려는 많은 비즈니스 로직을 통해서 클라이언트를 통제하고 좌우할 수 있었지만, 지금은 상황이 다소 바뀌게 됩니다. 즉, 서버가 가지고 있던 상당한 비즈니스 로직을 '스마트'한 클라이언트로 이전할 수 밖에 없으며, 이를 통제하기도 힘듭니다. 만일 이를 기존처럼 통제하고 중앙화시키려 한다면, 클라이언트가 가지는 복잡한 네트워크와 상황을 모두 끌어안아야 하는데 이는 더 심각한 문제를 유발시킬 수 밖에 없습니다.

'스마트'한 클라이언트를 서버 입장에서 제어할 수 있는 방법은 클라이언트가 필요한 적절한 시점에 관련 통지/결정을 하는 일입니다. 즉, 특정 클라이언트가 서버에게 요청하는 형태가 아니라, 서버가 보내주는 메시지에 귀를 귀울이고 있는 클라이언트에게 보내주는 방식이 필요합니다. 스마트 폰에서는 notification이라는 서비스를 통해서 서버로부터 다른 클라이언트로 전송되는 메시지를 받는 방식이 대표적인 그 예입니다. 전파를 수신하는 입장에서는 그 전파가 어디로부터 오는지, 어떤 경로를 통해서 전달되는지를 신경쓸 필요가 없습니다. 오직 안테나만을 세우고, 주파수를 맞추면 됩니다.

서버에서 이러한 서비스를 하려면, 기존의 클라이언트로부터의 요청을 처리하는 능력보다 이러한 메시지를 전달하려고 하는 아키텍처에 더 집중할 밖에 없습니다. 이러한 아키텍처를 가능하게 개념이 바로 Cloud 입니다. Cloud 가 단지 인프라적인 측면에서만 접근한다고 보면, 좋은 도구나 솔루션을 통해서 해결하려고 하겠지만, 궁극적으로 Cloud를 사용하고자 하는 지점과 적절한 비즈니스를 선정하는 노력이 필요합니다. 또한, Cloud 영역을 단순히 인프라의 확장과 가용성의 보장이라는 차원에서만 생각해서는 안되는 이유는 그 안에서 전달되는 메시지가 있기 때문입니다. 이 메시지는 짧은 문장과 같이 단순한 문자열도 있겠지만, 복잡한 멀티미디어나 전자 문서까지도 포함될 수 있습니다. 기존의 흑백 TV 시절에 전달되는 내용이 흑/백이라는 아주 단순한 내용이라면, 디지탈로 전달되는 내용은 원 소스인 동영상을 포함해서 이에 관련된 메타정보까지를 포함하게 됩니다. 관련된 메타정보들을 같이 보내주려면 결국은 서버 입장에서 Cloud라는 아키텍처 상에서 비즈니스 로직을 어떻게 조합하여 메시지를 만들 것인가라는 문제에 부딪히게 됩니다. 여기서 Cloud의 개념은 단지 인프라의 차원을 넘어서게 되며, 아키텍트 입장에서 바라본 Cloud는 서버(메시지 송신측)와 클라이언트(메시지 수신측) 입장에서 어떠한 경로와 방법을 사용하는지를 인식하지 못하게 사용할 수 있는 또 다른 자원의 형태로 인식하게 됩니다.

결국은 Cloud는 전혀 다른 영역들의 공간을 연결해주는 매개체이며, 이를 통해서 서로 부족하거나 아쉬운 부분들을 얻음으로써 (혹은 기존 비즈니스의 변형된 형태로) 해당 영역의 비즈니스를 완성해갑니다. 이러한 IT 기술의 변화는 기존 중앙집중 형태의 아키텍처에 새로운 가능성을 열어주게 됩니다. 즉, 기존 아키텍처가 서버 중심의 아키텍처만을 고집하고 고려했다면 이제는 '스마트'한 클라이언트의 아키텍처라는 영역을 열어주고 더욱 이에 고려할 다양한 영역을 증진시켜줍니다. 

'스마트'한 클라이언트의 출현은 아키텍처나 개발자에게는 오히려 더 많은 짐을 지게 합니다. 더 다양하고 풍부한 아키텍처들이 만들어지고 하나의 비즈니스를 완성하기 위해서 더 많은 기술들과 비즈니스의 조합을 통해서만 가능해지기 때문입니다. 점점 더 복잡도가 늘어나며, 고려할 사항들이 많아집니다. 이에 대한 준비가 필요하지만, 우리들은 결국 이전 기술로부터 이를 극복할 수 밖에는 없을 것입니다. 이러한 환경에서 비즈니스 로직의 재사용과 서비스의 확대/재생산의 개념은 가장 중요한 개념들일 것입니다. 또한, 기존의 기술이 어느 한사람의 노력으로 배포/테스트가 가능했다면, 지금은 10배가 넘는 노력을 들여도 힘듭니다. 배포/테스트 자동화에 대한 노력이 더 절실한 상태입니다.

'스마트'한 디바이스/클라이언트의 출현은 점점 더 시스템 개발을 더 어렵게 할 뿐만 아니라, 유지보수도 더 힘들게 합니다. 또한, 더 복잡한 아키텍처를 필요로 합니다. 이를 대처하는 현명한 방법은 명확한 영역 구분과 느슨한 연결고리, 효율적인 비즈니스 분산과 조합의 키워드로 해결책을 마련하는 것입니다. 복잡한 것을 먼저 해결하려는 노력보다는 단순한 것을 해결하면서 좀 더 복잡한 것들을 조합하려는 시도가 더 나은 선택일 수 있습니다. 구현하려는 비즈니스가 복잡하기 때문에 시스템을 복잡하게 구성할 필요는 없습니다. 단순하더라도 중요하고 핵심이 되는 개념을 원칙에 맞게 적용하려는 노력이 더 필요할 것 같습니다.
저작자 표시 비영리 동일 조건 변경 허락
신고

+ Recent posts

티스토리 툴바