애초에 이 글은 동료에게 시스템 맥락도(Context diagram)를 설명하며 쓰던 글인데, 독자 타겟을 바꿔 포괄적으로 시스템을 둘러싼 오해를 드러낼 목적으로 고쳤다.
시스템은 사용자를 포함하는가?
시스템 맥락을 그리는 일은 20년 가까이 해오던 일종의 틀에 박힌 일이다. 그런데, 배경 지식이나 경험 없이 처음으로 그려보려고 질문하는 동료를 만나는 순간 새삼 없던 흥미가 솟아나는 기분이었다. 누군가에게 무언가를 알려주는 일이 갖는 마법 같은 효과는, 이렇게 짧은 순간 솟아나는 에너지인지도 모르겠다. 그렇게 동료에게 방법을 알려준 이후에도 여운이 남아 있어, 스스로 다음과 같은 질문을 던졌다.
시스템은 사용자를 포함하는가? 그렇지 않으면 사용 대상 객체만 지칭하는가?
물론, 시스템 맥락을 그릴 때는 규명 대상인 시스템을 가운데 두고 경계를 그린 후 유관 시스템이나 사용자(※ UML표기법을 따르면 유관 시스템이나 사용자를 액터Actor로 표기한다)를 바깥에 그린다. 하지만 바깥에 그렸다고 꼭 시스템 일부러 아니라 단정하지는 말자. 물리적으로는 시스템 바깥에 있기는 하다. 하지만 그림은 그저 설계자의 인지와 결정 사항을 도형으로 그렸을 뿐이라는 점도 잊지 말자.
경계(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의 전형)을 설명하고 의견을 듣기를 바랬다.
필자는 그가 원하는 식으로 답을 하지 않았다. 이렇게 분할하여 접근하는 방식을 인정하는 순간 프로젝트는 반드시 실패한다고 단호하게 답했다. 필자의 실패 경험과 필자가 관찰한 실패 경험을 모두 풀어놓아 그에게 강한 인상을 주고 싶었다.
필자가 전하려 했던 핵심 메시지는 이렇게 요약할 수 있다.
어떤 기능을 개선하고, 어떤 기능은 그대로 쓰고… 이런 소통의 틀을 인정하는 일은 IT와 비즈니스를 분리하여 사고하는 전제를 인정하는 것인데, ‘그 틀’ 자체가 실패를 보장한다.
필자의 과거 경험을 예로 들며 조직에 작동하는 정치적 맥락이나 가정을 구체적으로 설명했으나 여기 모두 공유할 수는 없다. 대신 다시 한번 창준님의 페이스북 글을 인용한다.
고객에게 가치를 전달하는 측면을 보자면 divide and conquer는 제대로 가치를 주지 못할 수 있습니다. 왜냐하면 experience를 주기보다 feature를 주기 때문입니다. 특히 user story를 제대로 못쓰면 더 그런 것 같습니다.
더 설명을 달면 어두운 글이 될까 봐 여기서 화제를 바꿔본다.
기획의 정수는 종심타격從心打擊이다
필자의 멘토 중 탁월한 기획력을 갖춘 IT 컨설턴트가 있었다. 그는 한때 군사 지식에 대한 매니아로 관련 칼럼을 읽고 짬이 나면 필자에게 맛깔스럽게 설명하는 일을 즐겼다.
특히, 그가 종심타격從心打擊에 대해 실감 나게 설명하던 장면을 잊을 수 없다. 그는 고구려의 철기병 이야기를 열심히 풀어냈다. 중원의 다수 병력과 싸울 때 고구려가 썼던 방식인데, 소수정예 철기병이 한쪽 수비벽을 뚫어내고 그대로 적장이 있는 본진의 막사를 초토화 했다는 것이다.
그가 말한 문제 풀이법 자체가 종심타격이라 부를 만했다. 어쩌면 그가 그토록 실감 나게 종심타격을 설명할 수 있었던 이유가 직업 일상에 응용하여 몸에 익혀 쓰던 탓인지도 모르겠다.
그는 의뢰인과 일상을 많은 시간을 함께 보내면서 정보를 입수했다. 그렇게 시간과 노력을 투자해서 주변 이해관계자의 정황을 포괄적으로 이해한 후, 홀로 집중해서 핵심 문제를 건드리는 한 장의 그림을 그려냈다. 그리고, 그렇게 그려낸 맥락을 기초로 1년이 넘는 기간의 프로젝트에서 벌어지는 복잡다단한 이슈를 통제해나갔다.
그래서, 시스템이란 무엇인가?
이쯤에서 다시 제목의 질문으로 돌아가 보자. 그래서, 시스템이란 무엇인가? 위키피디아 정의를 보자.
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 이란 이름을 붙여 그림도 그려 두었다. 점선을 보자.
필자가 주장하는 시스템 개념은 만드는 사람과 사용하는 사람을 모두 포함한다. 만드는 이들은 시스템을 만들면서 소통하고 갈등하고 발전한다. 동시에 시스템을 사용하는 사용자 경험은 다시 시스템의 입력으로 작용한다. 그래서, 다시 만드는 사람과 시스템의 상호작용으로 이어진다.
그렇게 사고하면, 일시적인 경계(temporal boundaries)란 표현이 매력적으로 보인다. 또한, 시스템을 지속 가능하게 하려면 필연적으로 만드는 조직의 직업 일상을 살펴야 한다는 논리가 힘을 받는다. 이를 테면 필자가 앞서 서술했던 논리 말이다.
‘무엇을 만드느냐’만큼 체질 개선이 중요하다
또한, 지속적으로 사용자 체험을 개선하고 사용자 가치로 부합하지 않으면 존재를 걱정해야 할 수 있다. 그래서, 사용자 가치를 확인할 수 어렵게 비즈니스와 개발 혹은 IT를 나누는 접근은 시스템에서 환경에 대한 센서를 제거하는 일에 비유할 수 있다. 이는 앞서 위키피디아의 정의를 차용하면 폐쇄형 시스템이라 할 수 있다.
요약
시스템을 이해할 때는 시스템을 만드는 사람과 사용하는 사람을 포함해서 정의해야 경쟁력을 갖는다. 경쟁력이란 새로운 단어를 요약에 넣는 이유는 경계를 지속적으로 바꾸어 나가야 살아남기 때문이다. 그 일시적 경계가 적합한지 검증하기 위해서 사용자 경험이나 만드는 조직의 기민한 협업 등을 지표로 쓸 수 있다.
원문: popit
