brunch

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 안영회 습작 Oct 18. 2022

소프트웨어 기능과 구조에 대한 이야기

도메인 모델링 세미나 23

<이벤트는 변경을 알리는 표준 프로그래밍 단위> 편을 쓴 계기가 대화에서 나는 이런 말을 했다.

상태를 이벤트 정의로 검증하는 일은, 구조를 행위로 검증하는 일과 같다

그에 대한 부연은 말로 하기 너무 길어서 미루려고(혹은 포기) 했는데, 우연하게 구독하는 Kent Beck의 글 에서 마침 <Structure & Behavior>라는 제목이 눈에 띄어 읽었다. 막상 읽어보니 내가 하려던 말과는 다른 방향으로 쓰인 글이지만, 흥미 있는 포인트가 있었다.

소프트웨어가 가치를 창출하는 두 가지 방식

먼저 사이다 같은 느낌의 이분법 제시가 짜릿했다.

아쉽게도 글에서 이에 대한 설명이 충분하지 않다. 그래서 그냥 어떤 의도인지 분명하지 않은 상태에서 추정을 하고 내 생각을 쓰기로 마음먹었다.

당장 오늘에 무엇을 하는가?

평소 파파고를 쓰는데 번역이 조금 어색한 듯해서

구글 번역도 해보았다.

경제성(?)을 중시하는 프로그래머라면 당장 쓰는 프로그램을 개발해야 한다. 당연한 일이라 느껴지지만 현장에서는 전혀 그렇지 않고, 뻔해 보이는 사실을 실현하는 문제는 그리 단순하지 않다. 그리고, (여러 사람이 각자) 필요하다고 느끼는 기능에 비해 개발자는 항상 부족하다.[1] 나는 이에 대한 명확한 기준을 만들기 위해 2015년부터 '릴리즈 우선'을 강조해왔다. 이는 경제학자들이나 정치인들이 '시장에 맡기자'고 말하는 논리와 본질적으로 같다.

자원이 부족한 스타트업 맥락으로 문제를 보면 더 예민하게 볼 필요가 있다는 점을 책을 통해 배웠다. <아이디어 불패의 법칙>은 '될 놈' 개념을 익히면서 뼈 때리는 교훈을 2020년 이후에 얻고 있다.

내일을 위한 일에 대처하기

아쉽게도 두 번째 가치 창출 방법에 대한 설명은 부족하다.

어쩌면 아쉬움을 채우려고 내가 글을 쓰는 것인지도 모르겠다. 나는 <오늘의 문제만 우아하게 해결하기>와 같은 식의 경제적인 방법을 좋아한다.

그런데 필드에서 그런 식의 태도('애자일'이라고 대충 부르자)를 견지하려고 할 때 저항에 부딪히면서 배운 것이 있다. 2가지 정도로 요약할 수 있다. 하나는 새로운 일을 대하는 두려움에 대한 대책이고, 두 번째는 자발성은 조직 관점에서는 창발적 현상이 되기에 사후에 정렬이나 정돈이 필요하다는 점이다.

첫 번째는 함께 일하는 사람이 예측이 되지 않으면 두려움을 느끼거나 나아가 비판적이 되는 현상이다. <월말김어준>과 박문호 박사님 덕분에 뇌과학에 대해 1년 정도 듣는 정도로도 왜 그런지 알 수 있게 되었다. 우리는 생명을 지키기 위해 불안을 피하는 방향으로 진화되었다. 그래서, 환경이 아무리 안전하게 바뀌어도 새로운 일을 대할 때 무조건적으로 상당한 위협을 뇌에서 느끼는 듯하다.

동료가 영화 인디아나 존스의 장면으로 비유한 이미지를 자주 써왔다.

출처: https://brunch.co.kr/@graypool/219

전혀 맞지 않는 계획 방식

근데 이러한 터무니없는 두려움의 문제는 프로그래밍 세계에 국한된 일이 아니다. 10여 년 전에 대기업에서 프로젝트를 할 때 임원 방에서 임원과 둘이서 회의를 하던 적이 있었다. 팀장님 한분이 찾아와 나와 논의하던 임원에게 내년도 사업계획 확인을 부탁했다. 임원은 화를 내셨다. 중요한 논의를 하는데, 맞지도 않는 계획은 알아서 쓰면 되지, 왜 자꾸 들고 오냐는 것이다.

합리적인 말씀이지만, 대기업의 표준화된 행동 양식에 너무나도 벗어나는 일이라 깜짝 놀랐다. 구독하는 HBR 기사 중에 <격동의 시대, 어떻게 전략을 세울 것인가>에도 소수의 혁신적인 기업만이 (조직적으로 용기를 내서) 전략적 유연성을 받아들인 점을 알려준다.

나는 조직이 커지고 적극적인 위임을 하는 문화가 아니라면 소통 부하 때문에 효과가 없음을 알면서도 이런 방식을 취한다고 생각한다.

변화를 수행할 때 필요한 리더의 필수 덕목

그리고 해보려고 마음을 낼 수 있는 어떤 장치가 필요하다. 지난주에 CTO와 대화를 하는데 등대지기라는 표현을 썼다.

그는 개발리더를 특정하는 말이었지만, 내 생각에 변화를 수행할 때 필요한 리더의 필수 덕목이라고 해도 틀리지 않는다. 귓가에 이런 소리가 들려오는 듯하다.

나를 따르라~

당장 필요하지 않은 것은 결정하지 말고 내버려 두라

나는 순전히 Optionality라는 표현 때문에 <Economics: Time Value & Optionality>라는 글을 읽은 일이 있다. 글에 내가 원하는 식의 설명은 없었지만, Frozen Desire에 대한 설명은 마음에 들었다.

나는 의사결정에 대한 많은 글을 썼는데, 일을 하면서 리더가 의사결정해야 할 일은 미루고 할 필요가 없는 일은 너무 빨리 해서 유연성을 떨어트리는 일을 자주 겪은 탓이다.

꼭 필요한 것만 의사결정을 하려면 내 경험으로는 위임을 잘해야 한다. 실무자로 성장한 내 경험에서 권한과 책임을 모두 맡기기 위해서는 용기가 필요했고, 진행 스타일(개취인정)까지 용인하는 과정에서 상당한 인내심도 요구했다.

그러고 보니 거리를 두고 필수적인 신호를 보내고 멈춰서 지켜본다는 점에서 등대의 비유는 적절한 듯도 하다.

정원관리, 리팩토링 혹은 닦조기

그러나 이렇게 자유도를 주다 보면 정렬이 필요하다. 나에게는 작은 조직과 내 일상에 적용해본 OKR 경험도 꿈같은 비전과 현실 사이에서 어떻게 정렬하느냐를 가르쳐주었다. 그리고, 아기 발걸음 같은 기법(혹은 태도)으로 변화라는 섭리에 적응하며 계획을 세우는 혹은 변화한 세상을 배우는 방법도 필요하다. 또한, 조직원이 커지면 아무도 관심을 두지 않는 정원관리 같은 궂은일도 해야 한다.

소프트웨어 시스템에 국한하여 정원관리를 방치하면 벌어지는 일을 흔히 기술부채(technical debt)라고 한다. Chris Richardson이 링크드인에 올린 글에 따르면 42%에 해당하는 시간이 기술부채에 따른 비용으로 들어가고 있다. 앞서 Kent Beck이 말한 가치 창출과 무관한 시간 말이다.

맺음말

쓰고 나니 최초 생각과 전혀 다른 행위와 구조의 관계에 대한 글이 되었다. 우리는 고정된 세상을 살고 있지 않다. 변화는 섭리다. 그래서 가치 창출하는 행위에 대한 판단을 삶에서 찾아야 한다. 시장과 이해관계자를 두루 고려한 오늘의 결정만 내려야 한다. 그리고, 내일에 대한 결정은 방향성(혹은 비전)만 명확하게 하고 변화를 수용한 이후에 결정해야 한다.

그리고 조바심이나 두려움은 미래를 대비하는 정원관리에 투자해야 한다. 나도 생각은 그렇지만, 경험은 그렇지 않은 삶이긴 하다. <계획은 개나 주자>라는 구호를 떠올리기 전인 2015년까지는 일종의 계획 중독자의 삶을 살았음을 인정하지 않을 수 없다.