시스템이란 무엇인가?

애초에 이글은 동료에게 시스템 맥락도^[1]_{Context diagram}를 설명하며 쓰던 글인데 독자 타겟을 바꿔 포괄적으로 시스템을 둘러싼 오해를 드러낼 목적으로 고쳤다.

시스템은 사용자를 포함하는가?

시스템 맥락을 그리는 일은 20년 가까이 해오던 일종의 틀에 박힌 일이다. 그런데, 배경 지식이나 경험 없이 처음으로 그려보려고 질문하는 동료를 만나는 순간 새삼 없던 흥미가 솟아나는 기분이었다. 누군가에게 무언가를 알려주는 일이 갖는 마법같은 효과는 이렇게 순간적으로 생겨나는 에너지인지도 모르겠다. 그렇게 동료에게 그리는 방법을 알려준 이후에 여운이 남아 있어 어느 틈에 스스로 다음과 같은 질문을 던졌다.

시스템은 사용자를 포함하는가? 그렇지 않으면, 사용 대상 객체만 지칭하는가?

물론, 시스템 맥락을 그릴 때는 규명대상인 시스템을 가운데 두고 경계를 그린 후에 유관 시스템이나 사용자^[2]를 바깥에 그린다. 바깥에 그렸다고 꼭 시스템 일부가 아니라고 단정하지 말자. 물리적으로는 시스템 바깥에 있기는 하다. 하지만, 그림은 그저 설계자의 인지와 결정사항을 도형으로 그렸을 뿐이란 점을 잊지 말자.

출처: https://en.wikipedia.org/wiki/System_context_diagram

경계_Boundary를 규정하여 적합한 접합면 즉, 인터페이스를 규명하기 위해 구분해서 그릴 뿐이다. 그렇다고 사용자가 시스템의 일부가 아니라고 해야 할까?

시스템은 유기체란 사실

생각이 여기에 미치자 업계 동료 관계였던 시절, 그러니까 지금으로부터 대략 6, 7년 전에 들었던 현 베터코드 CTO의 발언이 떠올랐다.

시스템은 유기체인데, (개발을 해보지 않은 그들은) 그 사실을 모른다

또한 그는 필자가 일하는 팀에 합류한 후에 우리가 만들던 내용을 Micro Service, Docker로 할 수 밖에 없었다고 했다. 무엇을 어떻게 만들 것인가 이전에 만드는 사람들 즉, 개발 조직과 그들의 행동 변화를 중요하게 생각했기 때문이다. 우리가 전과 다른 무엇을 만들겠다고 각오하면, 만들 대상에 대한 계획이상으로 우리의 체질 개선이 중요하다.

필자의 경험과 그 기저에 깔린 생각을 고려하면, 은연중에 시스템을 만드는 사람을 시스템의 일부라고 생각하고 있다 하겠다.  그 생각을 드러내 생각해보니, 필자는 만드는 사람뿐만 아니라 사용하는 사람도 시스템의 일부라고 생각한다는 사실이 분명해진다.

정복하고 나눠라 (나눠서 정복하지 말고)

마침 창준님이 페북에 시선을 끄는 글을 올렸다.

애자일이나 TDD에 대한 가장 흔한 오해 중 하나는 그 방식들이 divide and conquer를 장려한다는 생각이다.

그리고 얼마 후에 훌륭한 댓글로 설명을 보충해주셨다.

"In XP, we don’t divide and conquer. We conquer and divide. First we make something that works, then we bust that up and and solve the little parts." --Kent Beck (옛날에 한 말이라 지금은 좀 입장이 다를 수도 있음)

그리고 크리스토퍼 알렉산더(패턴의 아버지)에 따르면, 자연물은 additive하기보다 differentiative한 과정을 통해 성장을 하는데(예를 들어 애기가 뱃속에서 손가락이 하나씩 완성되어 나가는 것이 아니라, 작은 덩어리가 생기고 거기에서 가지가 분화해 나가는 과정), 건축물을 만드는 과정도 이와 유사할 때 더 복잡성을 다루기가 쉽고 더 좋은 결과물을 낼 수 있다고 말합니다. 그런면에서 패턴을 하나씩 추가하는 식으로 건축을 하는 것은 프랑켄슈타인을 만들 수 있다고. (자세한 내용은 Nature of Order 참고)

어떤 경우는 문제를 나누면 본질이 흐려질 때가 있다. 그런 경우는 어떤 때일까?

시작부터 실패하는 프로젝트 계획

이 글을 쓸 즈음 바로 관찰할 수 있는 일이 벌어졌다. 서울에 있는 지인이 IT 시스템에 대한 자신의 계획을 설명했다. 시스템을 구성하는 기능을 쭉 펼치면서 개별 요소에 대한 개선책(divide and conquer 전형)을 설명하고 의견을 듣기를 바랬다. 필자는 그가 원하는 식으로 답을 하지 않았다. 이렇게 분할하여 접근하는 방식을 인정하는 순간 프로젝트는 반드시 실패한다고 단호하게 답했다. 필자의 실패 경험과 필자가 관찰한 실패 경험을 모두 풀어놓아 그에게 강한 인상을 주고 싶었다.^[3]

필자가 전하려 했던 핵심 메시지는 이렇게 요약할 수 있다.

어떤 기능을 개선하고, 어떤 기능은 그대로 쓰고... 이런 소통의 틀을 인정하는 일은 IT와 비즈니스를 분리하여 사고하는 전제를 인정하는 것인데, '그 틀' 자체가 실패를 보장한다.

필자의 과거 경험을 예로 들며 조직에 작동하는 정치적 맥락이나 가정을 구체적으로 설명했으나 여기 모두 공유할 수는 없다. 대신 다시 한번 창준님의 페이스북 글을 인용한다.

고객에게 가치를 전달하는 측면을 보자면 divide and conquer는 제대로 가치를 주지 못할 수 있습니다. 왜냐하면 experience를 주기보다 feature를 주기 때문입니다. 특히 user story를 제대로 못쓰면 더 그런 것 같습니다.

더 설명을 달면 어두운 글이 될까봐 여기서 화제를 바꿔본다.

기획의 정수는 종심타격從心打擊

필자의 멘토중에 탁월한 기획력을 갖춘 IT 컨설턴트가 있었다.  그는 한때 군사 지식에 대한 매니아로 관련 칼럼을 읽고 짬이 나면 필자에게 맛깔스럽게 설명하는 일을 즐겼다. 특히, 그가 종심타격從心打擊 에 대해 실감나게 설명하는 장면을 잊을 수 없다^[4]. 그가 종심타격을 설명할 때는 고구려의 철기병 이야기를 실감나게 풀어냈다. 중원의 다수 병력과 싸울 때 고구려가 썼던 방식인데, 소수정예 철기병이 한쪽 수비벽을 뚫어내고 그대로 적장이 있는 본진의 막사를 초토화 했다고 그는 말했다. 

그때를 회상하면 그의 문제 풀이법 자체가 종심타격이라 부를만 했다. 어쩌면 그가 그토록 실감나게 종심타격을 설명할 수 있었던 이유가 직업 일상에 응용하여 몸에 익혀 쓰던 탓인지도 모르겠다. 그는 의뢰인과 일상을 많은 시간을 함께 하면 정보를 입수했다. 그렇게 시간과 노력을 투자해서 주변의 이해관계자의 정황을 포괄적으로 이해한 후, 홀로 집중해서 핵심 문제를 건드리는 한 장의 그림을 그려냈다. 그리고, 그렇게 그려낸 맥락을 기초로 1년이 넘는 기간의 프로젝트에서 벌어지는 복잡다단한 이슈를 통제해나갔다. 

출처: http://bemil.chosun.com/nbrd/bbs/view.html?b_bbs_id=10044&pn=0&num=48790

그래서, 시스템이란 무엇인가?

필자 입장에서는 유사한 자극을 주는 사건과 생각을 연결했는데, 독자를 위한 기획이 아니라 의식의 흐름대로 썼다. 그래서, 누군가에게는 장황한 글일 수 있겠다. 이쯤에서 다시 제목의 질문으로 돌아가보자. 그래서, 시스템이란 무엇인가? 위키피디아 정의를 보자.

A system is a regularly interacting or interdependent group of items forming a unified whole.

첫 문장은 별다른 영감을 주지 않는다.

Every system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment,  ...

필자가 찾던, 어쩌면 찾는 내용이 있을지도 모른다고 기대했던 내용이 두번째 문장에 있다. 시스템은 영향을 주는 환경에 둘러싸인 일시적인 경계로 묘사된다고 한다. 분명 일시적인 경계(temporal boundaries)란 표현이 있다. 이를 부연하기 위해 위키피디아에선 OPEN 이란 이름을 붙여 그림도 그려 두었다. 점선^[5]을 보자.

출처: https://en.wikipedia.org/wiki/System

필자가 주장하는 시스템 개념은 만드는 사람과 사용하는 사람을 모두 포함한다. 만드는 이들은 시스템을 만들면서 소통하고 갈등하고 발전한다. 동시에 시스템을 사용하는 사용자 경험은 다시 시스템의 입력^[6]으로 작용한다. 그래서, 다시 만드는 사람과 시스템의 상호작용으로 이어진다.

그렇게 사고하면, 일시적인 경계(temporal boundaries)란 표현이 매력적으로 보인다. 또한, 시스템을 지속 가능하게 하려면 필연적으로 만드는 조직의 직업 일상을 살펴야 한다는 논리가 힘을 받는다. 이를 테면 필자가 앞서 서술했던 논리 말이다.

무엇을 만드느냐 만큼이나 체질 개선이 중요하다

또한, 지속적으로 사용자 체험을 개선하고 사용자 가치로 부합하지 않으면 존재를 걱정해야 할 수 있다. 그래서, 사용자 가치를 확인할 수 어렵게 비즈니스와 개발 혹은 IT를 나누는 접근은 시스템에서 환경에 대한 센서를 제거하는 일에 비유할 수 있고, 앞서 위키피디아의 정의를 차용하면 폐쇄형 시스템이라 할 수 있다.

요약

시스템을 이해할 때는 시스템을 만드는 사람과 사용하는 사람을 포함해서 정의해야 경쟁력을 갖는다. 경쟁력이란 새로운 단어를 요약에 넣는 이유는 경계를 지속적으로 바꾸어 나가야 살아남기 때문이다. 그 일시적 경계가 적합한지 검증하기 위해서 사용자 경험이나 만드는 조직의 기민한 협업 등을 지표로 쓸 수 있다.

주석

[1] 맥락도라니 필자 스스로도 어색하기 짝이 없지만, 가급적 우리말 자연어처럼 읽는 상황을 연출해본다.

[2] UML 표기법을 사용하면 유관 시스템이나 사용자를 액터_Actor로 표기한다.

[3] 솔직히 마음속에는 절대 필자 의견을 따르지 않으리라 알지만, 그저 신념을 말하는 것이 필자가 당시 할 수 있는 행동이었다.

[4] 꽤 많은 사람들에게 필자도 그 이야기를 전해왔다.

[5] 요즘 아들에게 '인체'란 책을 읽어주면서 우리 몸을 구성하는 다양한 계통 즉, 인체의 하위 시스템에 대해 강제로 공부중인데, 새삼스럽게 발견하고 놀란 사실은 각 계통들이 단단히 막힌 것이 아니라 어느 정도 열려 있다는 사실이다. 글이 장황해질까봐 다루지 않았는데, 글 쓰는데 영감을 제공했다.

[6] 소프트웨어 공학에서 흔히 말하는 요구사항이란 이름으로 명시적으로 온다고 생각한 분들은 틀에 박힌 일상에서 벗어나는 용기를 내보시길 바란다. 그리고, 호기심을 채워서 다시 한번 세상을 살펴보시길 권한다.