진짜 문제는 무엇이고, 가장 중요한 변수는 무엇인가?
월요안영회 2023
구독 중인 Kent Beck의 글 <Design Intuition>이 여러 가지 생각을 하게 해서 이를 기록합니다.
(진짜) 문제란 무엇인가?
다음 문장은 저에게 아쉬움과 후회를 선사했던 두 가지 사건을 떠오르게 합니다.
A large payment company needs to replace the heart of their production system, the code through which all payments travel.
이에 대해 쓰기 전에 먼저 DeepL 번역 결과부터 공유합니다.
대규모 결제 회사는 모든 결제가 이루어지는 생산 시스템의 핵심인 코드를 교체해야 합니다.
2015년 전후로 일에 대한 제 인식에 큰 변화가 있었습니다. 그 중심에는 남들은 실패라고 생각하지 않지만 스스로 큰 실패라고 규정했던 일이 있습니다. 다른 사람들의 평가 기준과 저의 잣대가 달랐던 것이죠. 느낌과 직관에 따른 행동이었는데 이후 제랄드 와인버그의 <대체 뭐가 문제야>를 반복해서 읽으면서 막연한 느낌을 생각으로 바꿀 수 있게 되었습니다. 그 과정은 와인버그의 책을 저에게 인생책으로 만들어 준 계기가 되기도 했습니다. 앞서 쓴 글 <내가 풀려는 문제가 무엇인지 분명히 하자>에 그 시절에 배운 바를 기록했다고 할 수 있습니다.
문제를 어떻게 규정할 것이냐가 중요한 이유는 그 이후에 하는 행동이 바로 나의 삶을 이루기 때문입니다. 문제를 멋지게 해결하느냐로 보지 않고 문제의식 자체를 차분히 정의하는 일입니다. 그 경과는 나에게 의미 있게 시간을 쓰는 관점을 알려줍니다. 달리 말하면 문제 정의는 내 삶에 큰 영향을 끼친다는 사실을 깨달을 수 있습니다.
생산 시스템의 심장인 코드
시행착오를 포함한 배움을 줬던 사건에서 강렬한 인상을 준 장면은 다른 회사가 작성 중인 코드를 본 일에서 시작합니다. 2012년으로 기억하는데 이름만 들으면 아는 회사에서 진행하던 프로젝트의 결과로 만들어진 코드를 보게 되었습니다. 동시에 추진되던 새로운 서비스 모델의 타당성 검증 차원이었는데, 아직 릴리즈 되지 않은 그 코드에 따르면 새로운 서비스에서 기획하는 내용은 모두 실행이 불가능했습니다.
책임자에게 사실을 고했지만, 100억이 넘는 프로젝트가 마무리되는 시점에서 그 문제를 어떻게 다뤄야 하는지 당시에는 알지 못했습니다. 다만, 그 이후에 다년간 그곳에서 일했기 때문에 여러 가지를 배울 수 있었습니다. 그중에 가장 아쉬운 점은 당시 어렵지만 꼭 해야 한다고 느낀 일을 실행하지 못한 일입니다. 결국은 가장 중요한 코드를 수정하는 일에 집중했어야 하는데, 그런 생각을 실천하지 못한 점입니다. 당시 저의 역할이나 외형적으로 혹은 이해관계자들이 가장 중시하는 내용에 끌려서 내면의 강렬한 소리를 받아들여 행동에 옮기지 못한 것이죠.
그때 고치지 못한 코드는 이후 어떠한 노력을 해도 만회할 수 없었다는 느낌을 줍니다. 10년이 지난 일이지만 여전히 제가 기술 부채에 관심을 끄지 못하는 이유도 어쩌면 이 사건과 관련된 일인지도 모릅니다. 제 경험이 알려주는 느낌을 한 마디로 말하면, '코드는 생산 시스템의 심장이다'입니다.
가장 중요한 변수는 무엇인가?
앞서 언급한 사건에 이어 최근에도 비슷한 교훈을 주는 아쉬운 일이 또 있었습니다. 코드의 문제는 다음과 같은 식으로 와전되기 쉽습니다.
코드에 문제가 있다. (설명하기 어렵고, 의사결정권자는 이해하기 어렵다.)
누가 짠 거야? (사람 문제, 업체 문제)
다음에는 누가 짜게 할 거야? (관계 문제, 계약 문제, 이권 문제)
정말 중요한 것이 생산 시스템(Kent Beck의 표현)이라면 사람 문제는 당장의 문제가 아니라 지속 가능성의 문제입니다. <행동 가능한 문제 정의와 함수>는 이런 인식을 담아 쓴 글입니다. 한 가지 가장 중요한 변수(요인)부터 고려해서 풀자는 생각을 강렬하게 새겼지만, 평소 실행할 때도 그렇게 하고 있는지는 자신이 없습니다.
또한, 함께 일하는 동료나 카운터파트가 가장 중요한 변수에 대한 입장이 나와 다른 부분을 수용할 수 있어야 합니다. 저도 과거에는 시시비비를 가리는데 급급해 서로 다른 가치관 하에서 문제를 정의하고 푸는 법에 서툴렀습니다. <어떻게 원하는 것을 얻는가>는 지금의 제가 곁에 두고 실천법의 도움을 받는 일종의 바이블입니다.
개념의 정의 혹은 진짜의 판단 근거
모처럼 동료들과 XP 책을 주제로 토론을 하는 자리가 있었습니다.
그중에 '진짜 고객'이란 표현에 대해 제가 한 발언은 기록으로 남겨둘 만합니다. 저는 소프트웨어 개발을 다룬 XP에서 고객을 두고 '진짜'를 판단하는 방식보다는 다른 대안을 제시했습니다. 개념을 인수분해하듯이 나누면 '고객'을 이루는 역할적인 요소는 셋으로 나눌 수 있습니다.
대리자(외주 개발에서 프로젝트 관리자, 서비스 개발할 때 기획자), 스폰서(물주, 돈 집행을 결정하는 사람), 사용자로 나눌 수 있습니다. 물론, 실제 사람을 뜻하는 것이 아니라 앞서 말한 대로 역할에 대한 정의입니다. 그래서, 내 앞에서 고객 역할을 하거나 고객의 입장을 설명하는 사람이 말하는 고객이 셋 중에 무언인가를 묻는다면 서로 관심사나 고객 정의가 달라 소통이 안 되는 일을 줄일 수 있다고 봅니다.
지난 월요안영회 연재
1. 경계와 활용(Boundaries & Leverage)
7. 점에서 선분 그리고 꾸불꾸불한 인생의 길(道)로 바꾸기
9. 협상하는 삶을 위해 거절당함과 듣기 인내를 배우기
