人-ware : In Silva Veritas

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

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

흔히들 데이터 양이 많으면 비즈니스 로직이 복잡해진다고 생각할 수 있다. 하지만, 데이터의 양과 비즈니스 로직의 복잡도는 그리 관계가 없다. 오히려 데이터 내의 개념들의 양과 더 깊은 관계가 있다. 가장 단순하게 게시판 글을 생각해봐도 그 내용이 한없이 길어도 단순히 내용만을 보여준다면 비즈니스 로직은 그리 복잡할 것은 없다. 하지만, 그 게시판의 글의 내용에 대한 의미들을 분석해서 나름대로 체계적으로 보여준다면 이는 이를 어떻게 보여주어야 하는 개념들만큼 복잡도가 증가하며 그 개념들 간의 관계까지 고려한다면 기하급수적인 비즈니스 로직이 생겨날 수 밖에 없다.

TodaysArt 2008 - 16n _ ƒ5³ by Haags Uitburo

게시글을 서론, 본론, 결론의 형태로 묶음 단위를 생각해서 화면에 보여준다면, 텍스트 내에서 이를 구분할 수 있는 구분자가 삽입되어서 저장되어야 하며, 조회 역시 이를 체크해서 서론, 본론, 결론의 형태로 화면 출력을 해주어야 한다. 다시 여기에 이들 간의 관계를 엮는다면 서론은 반드시 본론 앞에 오고, 본론은 반드시 결론 앞에 온다는 규칙을 추가해볼 수 있다. 또한, 이들은 각각 서로 다른 화면에서 서론만 보여주거나, 본론의 일부, 혹은 결론의 일부를 보여줄 수도 있을 것이다. 물론, 좀더 복잡해진다면 서론과 본론, 혹은 결론끼리의 조합도 생각해볼 수 있다. 이제 비즈니스 규칙은 좀 더 세분화되고 복잡해지기 시작한다. 처음에는 단순하게 게시글이라는 하나의 큰 데이터 덩어리로 생각했는데, 해당 내용에 대한 분석의 의미를 더함으로써 비즈니스 로직은 더 복잡하게 된다.

지금의 웹과 기술은 기존의 단순한 정보 덩어리를 하나의 관점에서 처리하는 시대에서 그 정보 덩어리를 좀더 의미있는 정보의 조각으로 세분화시켜서 차별화나 더 자세한 정보를 표현하고자 한다. 이는 데이터에서부터 비즈니스 로직까지, 혹은 아키텍처 영역까지도 영향을 미친다. 단순히 하나의 텍스트 덩어리에 구분값을 삽입하던 정보는 여기 저기 찣겨져서 흘러다녀야 하며, 때로는 전혀 다른 정보와 조합을 해야 한다.

아주 적은 양의 데이터라 하더라도 데이터가 사용되는 목적과 지점, 그리고, 그 데이터의 구조, 관계에 대한 의미들이 비즈니스 로직의 복잡도를 증가시키게 된다. 빅 데이터 시대에 이러한 비즈니스 복잡도의 영역도 같이 고려해볼 수 있다. 단순히 데이터가 큰 것만을 관리하는 형태가 아니라, 데이터와 데이터의 관계, 세분화 등의 내용은 앞으로 더 크게 확장되고 고려해야 할 영역이 된다.

이와 같은 형태의 시스템을 위해서는 무엇보다도 정확한 의미의 규칙을 정의하는 것이 무엇보다 중요하다. 서론, 본론, 결론의 세부분으로 나누는 규칙은 서론과 결론으로도 의미가 있는지, 혹은 본론과 결론 만으로도 구성된 정보가 사용될 수 있는지, 혹은 본론의 일부 영역을 어느 영역까지를 의미하는지를 명확하게 정할 필요가 있다. 규칙의 명확화는 바로 시스템에 그대로 적용되며, 이는 시스템의 특성이나 사용자의 영역별로도 상당히 세분화가 될 수 있다. 과거의 '게시글을 화면에 보여준다'라는 규칙은 서론, 본론, 결론을 어떠한 조합으로 어떠한 순서로, 그리고 화면의 크기나 사용자의 특성별로 어떻게 보여줄지에 대한 더 자세한 규칙을 필요로 한다. 규칙의 세분화로 인해서 이를 처리하는 비즈니스 로직은 점차 복잡해질 수 밖에 없다.

또한, 데이터 사이의 조합의 영역에는 새로운 형태의 정보나 규칙이 발생된다. 서론과 결론이라는 두가지 영역이 조합되어서 순서, 표현방법 등 다양한 개념들이 더 나타나며, 이를 처리하기 위한 별도의 영역도 생겨난다. 단순히 데이터의 결합이 정보 양의 증가만을 의미하는 것이 아니라 더 복잡하고 거대한 비즈니스 로직을 만들어내며 이러한 경우의 수들이 증가함에 따라 검증하는 노력 역시 급증할 수 밖에 없다. 더 확장성을 고려한다면, 서론, 본론, 결론의 영역이 서로 조합이 가능하도록 전반적인 아키텍처 구조를 개선시킬 수도 있다. 심지어는 게시글 이외에도 타시스템이나 다른 유형의 광고성 글들도 조합될 수 있는 형태도 고려해야 한다.

데이터가 증가하는 것 못지 않게 비즈니스 로직의 증가 역시 무시할 수 없으며, 단순히 양의 증가가 비즈니스 로직의 복잡도를 말해주지 않는다. 데이터가 가지는 의미와 내재적인 구문의 파악이 먼전 선행되어야 이러한 비즈니스 로직의 복잡도를 관리할 수 있는 형태로 구성이 가능하다. 

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

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

작업을 수행하는 사람들은 늘 흔적을 남기기 마련이며, 이를 SW에서는 산출물이라고 말한다. 즉, 어떠한 활동을 하든지 간에 그 흔적이 어떠한 형태로든 존재하기 마련인 것이다. SW 개발하는 입장에서 설계와 구현의 정확한 구분을 한다는 것은 사실 거의 불가능한 영역이기도 하다. 설계를 개발 단계 중에 정해진 기간으로 놓고 그 단계 내에서 산출물을 강요하는 식의 방식은 설계의 본연의 목적을 잃을 가능성이 너무나도 높다.

Anonymity; and the Internet. by Stian Eikeland

우리는 어떤 일을 하게 될때 머리속으로 먼저 무엇을 어떻게 수행할지를 가늠해본다. 좀더 깊이 생각하는 사람은 다양한 대안들을 생각해보고 각각의 장단점을 비교하여 사전 시뮬레이션까지도 고려하여 최적의 해결책이라고 여기는 방식을 선택하기도 한다. SW 개발에서 설계는 바로 이러한 활동들과 마찬가지이다. 설계는 비즈니스의 요구사항을 이해하고, 이를 시스템 관점에서 어떻게 구현할 것인지를 사전에 고민해보는 시간이다. 물론, 그러한 고민에는 다양한 제약사항들이 포함되어서 고려되는 것이 좋다. 하지만, 지금의 시스템이 단순하지도 않으며, 상당히 복잡한 비즈니스 로직이 이미 가지고 있는 상태이며, 서로 다른 시스템들의 관계까지 포함되어 있기 때문에 모든 사항을 고려해서 설계한다는 것은 거의 불가능한 일이다. 물론, 이는 경험으로 축적된 지식을 가진 사람이라면 다양한 조건들을 고려해서 설계를 할 수도 있다. 그렇다 하더라도, 설계 단계에서 고려는 그 이후 구현 시점에서 많은 부분이 바뀐다고 봐야 한다.

하지만, 아무리 경험을 많이 한 사람이라고 하더라도 설계때 만든 것을 가지고 SW를 이미 절반을 만들었다고 볼 수는 없다. SW에서도 재고라는 개념을 도입해보면, 만들어진 설계 산출물은 SW 구현을 위한 재고라고도 볼 수 있다. 현실세계에서의 재고와 SW에서의 재고의 차이는 눈에 보이는 물품의 재고는 바로 팔아서 현금화가 가능하다는 것이다. 실제 투입된 비용보다도 더 싸게 팔 수도 있겠지만, 어찌되었든 이는 명확하게 자산에 해당한다. 그렇지만, 구현되지 못한 SW의 설계는 아무리 많이 가지고 있다고 하더라도 현금화가 되지 못한다. 실제로 금융업계에서도 설계문서를 만들어서 파는 곳도 있지만, 이를 가지고 무엇을 할 수 있다는 것인가. 종이 인쇄비 만큼만 값어치가 있을 것이다. 만일 설계 문서만으로 가격을 책정한다면 많은 내용을 포함하는 설계와 단순한 몇가지 그림을 포함하는 설계, 이 두가지 중에서 어떤 것이 가격을 더 높게 쳐줄 것인가.

이를 다른 시각에서 보도록 하자. 금융 시스템은 상당히 복잡한 시스템들이 많이 있으며, 비즈니스 로직 또한 상당하다. 소스 코드 양도 천만 라인이 넘는 경우도 허다하며, 많은 인력과 오랜 경험의 축적으로 쌓여 있다. 금융 시스템의 설계의 양은 페이스북이나 트위터의 설계의 양보다도 훨씬 많을 것이다. 그럼 금융 시스템의 설계 문서와 페이스북의 설계 문서의 가치는 어떻게 책정할 것인가. (아직 해당 시스템이 구현되지 않았다고 가정한다) 결론적으로 그 가치는 아무도 모른다. 설계의 양이 많고 복잡하다고 해서 구현된 SW가 가치가 더 있다고 말할 수도 없으며, 아주 단순한 몇장의 그림만을 가진 설계로부터 구현된 SW가 가치가 훨씬 떨어진다고 말할 수 없다.

설계는 가치가 0인 산물을 만들어낸다. 그러한 가치를 매겨주는 것이 바로 우리나라의 SW 프로젝트의 특징이다. 설계가 가치를 가지는 것은 바로 사용자의 PC(디바이스) 앞에서 동작하는 SW가 있고, 그 사용자에게 가치를 줄 때 바로 의미가 있다.

그렇다면, (현물적인) 가치를 전혀 갖지 못하는 설계를 만드는 이유는 무엇일까. 우선은 커뮤니케이션과 가시화를 말한다. SW 시스템은 생명주기를 가진다. 즉, 개발 단계라는 탄생에서부터 운영을 거쳐 파기까지 길거나 짧은 시간을 거쳐서 사용자와 상호작용을 하게 된다. 그 기간 동안에 다양하고 많은 사람들이 관여를 할 수 밖에 없다. 소스 코드를 일일히 뒤져서 무슨 문제가 있고, 어떠한 상태인지를 파악하기란 지금의 시스템에서는 힘들기 때문에 이를 가시화시켜서 문서화해서 커뮤니케이션을 한다. 프로젝트의 산출물로의 가치는 바로 이러한 이유로 출발하게 된다. 그리고 그렇게 만들어진 문서는 점점 다양한 내용을 넣으려고 하고 종류나 내용이 많아지게 된다. 개발하는 입장에서는 바로 봐야할 문서가 많아지고 도통 서로간의 연관관계조차도 파악하기 힘든 경우도 많다. 이러한 설계문서는 운영이나 유지보수에 필요한 내용이 갱신되리라고 보장할 수도 없다.

설계 활동에 대한 가치를 떨어뜨리는 행위들은 매번 SW 개발 프로젝트를 수행할 때마다 반복해서 발생되며, 여기에 설계가 가지는 단어에 대한 반감을 가지게 만든다. 실제로 하나의 개념에 대해서 10가지가 넘는 문서들을 만들고 이를 보고 개발자에게 개발하라고 말하지만, 개발자는 어떠한 문서도 보지 않고 바로 해당 설계를 만든 사람에게 입과 귀로 그 내용을 듣는 경우가 허다하다. 이러한 식의 설계 활동은 전혀 개발에 도움을 주지 않으며, 오히려 개발자에게 부담만을 안겨준다.

현실적으로 제대로 된 설계를 만나보기가 힘들다. 개발자들에게 설계를 보고 만들라고 입버릇처럼 말하지만, 이를 곧이 곧대로 듣고 개발하는 사람들은 큰 낭패를 보거나 실력없는 개발자로 낙인찍히기 딱 알맞다. 설계와 구현은 사실 그 경계가 모호하고 거의 없다고 봐야 한다. 실행력이 없는 기획이나 설계는 가치가 전혀 없는 것과 마찬가지로 생각하고 사고한 것을 소스 코드로 구현할 수 있는 능력이야 말로 SW를 구현하는데 있어서 필요한 능력이라고 볼 수 있다. 정말 설계한대로 소스코드를 만들어낸다면 대단한 SW를 만들 수 있다고 생각한다면, 이는 아주 큰 오해 중에 하나이다. 설계는 세밀한 구현체와는 달리 동작하는 SW의 윤곽을 보여준다. 그 윤곽은 다양한 관점에서 바라볼 수 있는 시각을 제시하며 SW가 가지는 여러가지 제약들을 고려할 수 있는 단초를 제공한다. UML이 그러한 부분을 제시해줄 수도 있겠지만, 클래스 다이어그램 한가지만으로도 한가지 기능의 다양한 측면들을 그려낼 수 있다. 이를 그려낼 수 있는 능력이 설계자가 가지는 능력이지만, 이는 결국 구현체를 미리 머리 속에서 그려낼 수 있는 능력이기도 하다. 역으로 설계의 능력을 가진 자가 설계 문서를 만들지 않고 코드를 바로 작성하면서 머리 속에서 설계를 생각하는 것 역시 설계의 능력을 가졌다고 볼 수 있다. 즉, 설계를 통해 구현체의 투상을 볼 수 있어야 하며, 구현체를 통해서 설계를 가늠해볼 수 있어야 한다.

설계의 가치를 인정하지 않는 것은 아니다. 설계는 분명 그 자체로 가치가 충분하며 설계자의 의도가 명확할 때에만 그리고 남을 이해시킬 수 있는 관점을 정확하게 제시할 때 그 가치가 제대로 발휘된다. 물론 구현체로써도 설계 문서를 가지고 설명이 된다면 더할 나위 없을 것이다. 설계는 그 누구를 위한 것보다도 개발자 자신을 위한 산출물을 만들어낼 때에 그 가치가 있다. 아무리 단순한 기능이라고 하더라도 하나 둘 제약사항이 들어가기 시작하면 처음에 단순한 모델이 복잡한 구현체로 변모했음을 알 수 있을 것이다. 시스템을 단순히 CRUD를 가지는 기능 덩어리로 바라보는 관점은 이제는 바뀌어야 한다. 과거의 시스템은 하나의 기능을 수행하기 위해서 사용하는 시스템의 자원을 지금의 시스템에서 제공하는 기능이 사용하는 시스템의 자원과 비교를 한다면 엄청나고 복잡할 것이다. 때로는 이러한 기능을 한 사람이 아닌 여러 사람이 공동으로 개발하는 경우도 많다. 이를 소스 코드만으로 분석하려고 한다면 그리고 이를 말로만 설명하려 한다면 엄청난 오해와 곡해로 인해서 전혀 예상했던 기능과는 다른 기능이 만들어질 것이다. 이미 그 때에는 되돌리기에는 너무나 많은 노력을 투여했기 때문에 그 복잡성에 더해 새로운 복잡성을 만들어내기도 한다.

구현시 수없시 많은 재반복 작업을 경험해본 적이 있는가. 그렇다면 우선은 설계를 만들어서 전체적인 윤곽을 그려보라. 거기에서 장단점을 볼 수 있는가. 단점을 극복할 수 있는 방법을 추가해보라. 설계를 먼저 그러한 용도를 사용해본다면 반복되는 구현 작업을 최소화시킬 수 있을 것이다. 설계는 구현을 하는 방법을 최적으로 하기 위한 전략을 구상하고 예측할 수 있게 만드는 장치로 활용한다는 사고를 가진다면 설계 작업이 더 없이 필요함을 느낄 것이다. 코딩은 단순한 작업이 아니다. 결코 단순해질 수 없는 작업이며, 앞으로도 더 복잡해졌으면 복잡해졌지 단순해질 수 없는 작업이다.

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

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

SW에서 통합이라는 이슈가 불거진건 어제 오늘 일이 아니다. 그동안의 다양한 프로젝트들은 SI(System Integration)라는 이름 하에 진행되었으며, 그 내용 역시 서로 다른 다양한 시스템을 대상으로 통합을 위한 활동을 하는 것들이 포함된다. 하지만, 통합이라는 단어가 가지는 어감에 대해서는 시스템을 대하는 태도에 따라서 전혀 다른 아키텍처나 구조를 가지는 결과를 낳는다. 우선 통합과 반대가 되는 단어로는 분산을 들 수 있다. 통합과 유사하거나 같이 사용되는 단어로는 일관성 내지 표준화 정도로 볼 수 있다. 하지만, 이러한 단어들은 모두 통합을 위한 기본적인 토대가 되는 개념으로 서로 어느 정도는 상존될 수 밖에 없다. 아니, 반대와 유사한 개념들이 모두 공존하도록 아키텍처나 설계 구조를 만드는 노력이 오히려 필요하다.

통합은 겉에서 보기에는 서로 다른 종류의 시스템들이 유기적인 형태로 연결되어야 한다는 것을 의미하지만, 속내를 들여다 보면 데이터의 전송 방식과 표현 방식 등 상당히 많은 문제를 안고 있는 것이 사실이다. 또한, 동일한 의미의 단어라 하더라도 시스템 간에 서로 다른 의미로 사용되고, 그 안에 들어있는 데이터 역시 그 값이 동일하다고 하더라도 서로 다른 의미로 사용된다. 기존 시스템을 새로운 시스템으로 구성하려는 노력은 수많은 데이터들과의 싸움이기도 하다.

때로는 서로 다른 프로세스를 조정하는 역할을 필요로 하기도 하다. 프로세스에 대한 조정은 결국 필요한 컴포넌트를 어떻게 적절하게 조합할 것인가로 귀결되며, 결국 프로세스를 조정하게끔 어느 정도로 서비스의 크기(granularity)로 만들 것인가를 결정해야 한다.

통합은 특정 결합을 위한 도구만으로 해결되기는 어렵다. EAI(Enterprise Application Integration) 솔루션들이 아무리 막강한 기능을 제공한다고 하더라도 통합을 위한 인터페이스의 명세를 확정하지 않는 한 결국 시스템의 의존관계만 높아질 뿐이다.

통합은 순서가 중요하다.

모든 프로젝트가 그렇듯이 소프트웨어 개발에 있어서 선후 개발 순서는 상당히 중요한 이슈이다. 동시 다발적으로 개발이 진행되는 프로젝트라고 하더라도 사용하는 인터페이스들간의 관계는 분석/설계 단계에서 식별되어야 하며, 실제 구현 단계에서는 이러한 인터페이스는 더 많이 나타나게 된다. 이를 위해서는 비즈니스 분석의 Value Chain 과 프로세스 모델링이 식별되어야 하며, 이를 토대로 통합 및 구현을 위한 일정을 상세화시켜야 한다. 이를 각 개발 파트에게 맡겨놓는다면 전체적인 식별이 안된 상태에서 하위 모듈만을 식별해서 끼워맞추는 방식으로 진행되기 때문에 통합에 있어서 상당한 어려움이 발생될 수 밖에 없다.

Divide & Conquer라는 원칙으로 모듈을 식별하는 방식은 마치 기능적 세분화(functional decomposition)의 방식과도 유사하지만, 이러한 원칙을 어느 상세 레벨까지 분화를 할 것인가에 대한 것과 이를 어떠한 용도를 사용할 것인가를 고려해야 한다. 이 원칙은 커다란 하나의 덩어리를 서로 관련이 있는 것으로 뭉치는 방식으로 양측의 교집합을 최소화시켜야 한다. 예를 들어, 요즘과 같이 다양한 채널에 응대하는 서비스를 만들어야 하는 시스템의 경우 양쪽 채널에 동일한 서비스를 제공함에도 불구하고 서로 다른 채널이라는 기준으로 기능 세분화를 하다보니, 이러한 교집합을 무시한채 서로 다른 채널 덩어리를 식별하여 시스템을 개발하여 동일한 비즈니스 개념의 변경에 효과적으로 대처하기 어렵게 만드는 결과를 초래하기도 한다.

궁극적으로 이러한 모듈이나 서브시스템, 컴포넌트는 전체적인 관점에서 식별되어야 하며, 이에 대한 개발/통합 순서까지도 식별되어야 한다. 통합이 어려운 점은 개발할 시스템 대상이 불명확하거나, 이를 각 개발파트에 맡김으로써 전체적인 시스템 구성 원칙이 제각각이어서 결국 통합 지점에서는 상당히 어려운 형태로 만들어지기 때문이다.

명세는 시스템 인터페이스 이상의 내용이 포함되어 있어야 한다.

일반적으로 명세는 크게 문법적인(syntactic) 개념과 문맥적인(semantic) 개념으로 나뉜다. 전자를 외관에 비유하면 후자는 내관에 비유할 수 있다. 즉, 외형적인 측면과 내면적인 측면으로 나뉘어 볼 수 있는데, 통합에 있어서 표준적인 명세를 마련하는 게 상당히 중요하지만, 외형적인 측면만으로 고려하고 이를 명세의 완성으로 생각하여 구현하다가 그 내포적인 의미로 인해서 상당한 지연이나 추가 개발 노력이 들어가는 경우가 허다하다. 외형적인 부분은 기술적인 영역에 포함되어 있지만, 내면적인 부분은 크게 업무 프로세스와 그 프로세스에서 처리하는 데이터로 나뉠 수 있다. 이러한 내용들은 문서화가 되기 어려우며, 문서화가 되어 있다고 하더라도 여기저기 산재해 있어서 이를 모두 고려해서 통합을 만들어낸다는게 사실상 불가능한 것처럼 보인다. 데이터만 하더라도 요청을 보내는 측과 그 요청을 처리하는 측에서 다르게 해석할 수도 있으며, 각각의 영역에서 번역이나 해석을 달리 할 수 있다.

이러한 내용들은 어디에도 문서화되어 있지 않는 경우도 있으며, 오로지 이를 운영하는 사람의 머리 속에 남아 있거나 그 사람마저 조직에서 떠나면 어느 누구도 알지 못하는 경우가 많다. 이러한 상태에서 문서화/명세화된 수는 크게 의미가 없을 수 있으며, 결국 인터페이스만 바라보고 개발하기 어렵게 되며, 양측의 코드를 상세하게 분석하는 추가적인 시간이나 노력을 들이는 경우가 대부분이다. 또한, 이러한 데이터들 자체가 코드화가 되어 있어서 사실상 분석한다고 하더라도 시간이 걸릴 수 밖에 없는 영역이 되어버린다. 차라리 명확하게 풀어서 사용하는게 더 나을 수도 있다. 지금의 시스템은 이전 시스템과 달리 용량의 엄청난 증가를 수용할 수 있는 단계이기 때문에 ABC와 같은 코드보다 NOT_FOUND라는 형태의 보고 이해기 쉬운 형태로 사용하여 부수적인 문서를 보지 않더라도 이해할 수 있게 만드는게 더 나을 수 있다.

시스템 통합은 궁극적으로 사람의 통합을 의미한다.

시스템을 통합하는 것은 결국 이를 사용하는 사람들이 각기 다른 시스템을 편하게 사용하기 위함도 있으며, 중복이나 모자란 부분을 가감하여 더 나은 서비스를 제공하여 보다 가치있고 더 나은 업무를 하기 위함이다. 통합은 궁극적으로 비즈니스의 변화를 가져올 수 밖에 없으며, 이는 수년 동안 익혔던 시스템에 대한 기능을 사용했던 업무를 다른 형태로 변화시켜서 새로운 업무 형태로 만들어야 됨을 의미한다.

이는 두개의 시스템은 단순히 연결되는 것만이 전부다가 아니라는 것이다. 두개의 시스템이 연결됨으로써 최종사용자의 업무는 더 복잡해지거나 더 많은 정보를 다루게 될 수도 있는 결과를 초래할 수도 있음을 의미한다. 제대로 만들어진 통합은 오히려 이러한 불편함을 줄이도록 혹은 개선하도록 만들어지게끔 하는 것이 목표겠지만, 기존 기능을 과감하게 없애지 못하는 문화나 기존 멤버들의 이기주의는 오히려 더 복잡한 기능만을 제공하는 통합을 낳게 된다.

통합된 시스템을 만들기 이전에 이러한 내용에 대해서 먼저 사람과의 통합을 시도해야 할 것이며, 이는 SW를 만드는 영역이 아니라고 볼 수도 있다. 하지만, SW 개발이 무조건적으로 요구사항을 수용하여 시스템의 모습을 원칙에서 벗어나게끔 만드는 것은 가급적 회피해야 한다. 또한, 요구사항을 만들어내는 사람들이 전체 사용자를 대변할 수 있다고도 볼 수 없다. 그들이 이해하는 것은 그들만의 언어이기 때문에 그 저변에 있는 컨텍스트를 이해할 필요가 있으며, 그러한 시도를 할 때 결국 사용자들에게 적합한 시스템 통합을 만들 수 있기 때문이다.


N-스크린, 클라우드, 빅데이터, 융합 등의 키워드로 상당한 IT 기술의 새로운 국면인 것처럼 말들을 하지만, 정작 이를 만드는 실행자들의 입장에서는 별반 차이를 느끼기는 어렵다. 오히려 그동안의 SW 원칙이라고 불리웠던 내용들이 더 강조되고 더 충실히 지켜야 하는 것이 되어가는 상태인 것 같다.