시니어 개발자의 조건

누군가의 이력서를 읽다가 멈칫한 적이 있다. 꽤 큰 규모의 기술적 변화를 여러 조직이 엮어서 시도했으나 매번 실패했고, 그 원인을 ‘문제를 함께 정의하지 못한 협업 방식’으로 진단한 내용이었는데, 그 문단에서 시선이 한참이나 머물렀다.

와, 진짜 시니어는 이 문제를 이렇게 풀어내는구나.

그동안 내가 시니어라는 단어를 떠올릴 때 먼저 생각나던 것은 기술적 깊이였다. 복잡한 문제를 풀어내는 능력, 남들이 못 보는 아키텍처 결함을 찾아내는 눈, 위기 상황에서 시스템을 안정화시키는 손놀림 같은 것들. 물론 그런 것들도 중요하겠지만, 조직의 규모가 커질수록 진짜 시니어의 실력은 서로 다른 이해관계를 가진 조직들 사이에 인터페이스를 설계하는 능력이지 않을까 하는 생각이 들었다.

오더로 해결할 수 없는 일들

회사 규모가 커지고 연관된 조직이 많아질수록 일을 끌고 나가는 것은 정말 어려워진다. 우리 팀에게는 중요한 일이 그들에게는 중요하지 않을 수도 있고, 모두가 각자의 사정과 KPI 지표를 가지고 있기 때문에 공통된 목표를 제시하고 협업하는 분위기를 만드는 것은 쉽지 않다.

제일 쉬운 해결책은 그 조직들을 모두 아우르는 상위 직책자의 오더일 것이다. 하지만 모든 일을 그렇게 할 수 있는 것도 아니고, 그렇게 해서 더 어렵게 가게 되는 일들도 많다. 오더로 움직이는 일은 대개 다양한 의견을 적절한 가중치로 수렴하기가 어렵고, 필요한 일 외에 “일을 위한 일"이 만들어질 공산도 크다.

결국 가장 이상적으로는 이해 관계에 있는 모든 플레이어의 동의와 협조를 아름답게 구하는 일이겠지만 역시 쉽지 않다. 특히 기술적 변화 같은 것들은 기존 작업 방식의 파괴를 동반하기 때문에 거부감을 일으키기 쉽다. 새로운 제안에 “이래서 현실적으로 어렵다"라는 딴지를 걸기는 너무나 쉽다. 반대로 서로가 빠듯한 리소스를 나누어가며 협업하기는 너무나 어렵다. No 는 무료이고 Yes 는 유료다.

콘웨이의 법칙이 말하는 것

이 문제는 콘웨이의 법칙과도 유관해 보인다.

Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

소프트웨어 구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게 된다는 것. 결국 우리가 만들어내는 결과물은 소프트웨어이지만 그것은 조직의 구조와 사람의 심리 위에 세워진다.

같은 협업이라도 책상 옆에 앉은 동료와 하는 것과, 층만 다른 팀원과 하는 것, 그리고 이름도 얼굴도 모르는 다른 조직 사람과 하는 것은 완전히 다른 결을 가진다. 같은 팀에 소속된 사람들과는 자연스럽게 자주 이야기하게 되고, 그 결과 그들이 담당하는 모듈끼리는 긴밀하게 결합된다. 반면 업무적으로 거리가 먼 팀과는 소통 자체가 드물어지니, 자연스럽게 모듈 사이의 경계도 도드라지고 결합은 느슨해지거나 아예 단절되곤 한다.

조직 구조가 사람 사이의 거리를 정하고, 그 거리가 다시 소프트웨어의 모듈 구조를 결정한다. 말하자면 코드는 조직도를 따라 흐른다.

이 법칙이 시사하는 바는 단순하지 않다. 기술적인 해법 (How) 을 먼저 완성해서 가져가면 안 된다는 것이다. 우리가 만든 완벽한 설계도는 상대 조직에게 ‘이미 결정된 사항’으로 읽히고, 이는 사람 심리 상 자연스럽게 방어 기제를 불러일으킨다. 관성이란 게 그러하다.

왜 함께 고민해야 하는가

어느 시니어의 이력서를 통해 나는 이 문제를 풀기 위한 하나의 접근 방법을 배웠다. 결국은 Why 에 대한 합의를 먼저 이뤄야 한다는 것이다. 어떻게 (How) 가 아니라 왜 (Why) 이 일을 해야 하는지를 함께 고민하는 과정이 선행되어야 한다.

일의 필요성에 대한 합의를 이끌어내려면, 먼저 눈에 띄지 않게 숨어있는 우리의 pain point 를 수면 위로 끌어내어 주목하게 만드는 것이 방법 중 하나일 수 있다.

가령 그동안 입 밖으로 꺼내지 않았던 침묵의 비용을 시각화하는 것이다. 사람들은 추상적인 위험에는 잘 움직이지 않지만, 일단 수치화가 되면 더 눈길이 갈 수 있다. 우리가 이걸 하지 않고 있는 동안 지불하고 있었던 유무형의 비용을 보여주어야 한다.

이미 완성된 계획을 “통보” 받으면 비판적으로 반응하기 쉽지만 설계 과정에 “참여"하면 동료 의식을 가지게 할 수 있다. 이러한 태도의 전환을 유도하기 위한 장치 중 하나로 자주 쓰이는 기법 중 하나는 설계에 의도적으로 빈 칸을 넣는 것이다. 사람이란게 완벽한 계획 앞에서는 자연스레 안되는 이유를 찾게 되지만, 대놓고 채우기 쉽게 마련된 빈칸 앞에서는 완성시키기 위한 마지막 조각을 찾게 된다. 전자는 계획을 부정하는 방향으로, 후자는 계획을 긍정하는 방향으로 사고하게 된다.

시니어의 역할 재정의

돌아보면 조직 내 시니어들은 이런 일을 잘해야 하는 사람들이겠구나 하는 깨달음이 든다. 기술적 깊이는 기본이고, 그 위에서 각 조직의 특성과 사정을 꿰뚫고 있는 상태에서 이해 관계를 조정하고, 모두가 납득할 수 있는 문제 정의를 함께 만들어나가는 능력.

그것이 결국 조직 사이의 인터페이스를 설계하는 일이 아닌가 싶다. 다른 말로 하면 영향력이라고 할 수도 있을 것이다.

이력서에 적힌 그 문장을 읽고 나는 한참을 생각했다. 내가 지금까지 시니어라는 단어를 너무 좁게 해석하고 있었던 것은 아닐까. 기술만 잘하면 된다는 생각은 어쩌면 조직이 작을 때나 통하는 발상일지도 모르겠다.

함께 정의되지 못한 문제는 함께 해결되지 않는다. 이 문장이 오랫동안 머리에 남았다.