누군가의 이력서를 읽다가 멈칫한 적이 있다. 꽤 큰 규모의 기술적 변화를 여러 조직이 엮여서 시도했는데 매번 실패했다고, 그 원인을 “문제를 함께 정의하지 못한 협업 방식"이라고 적어둔 문단이었다. 그냥 한 줄 넘어갈 수도 있는 내용인데, 어쩐지 그 문장에서 한참 눈이 안 떨어졌다.

진짜 시니어는 이걸 이렇게 풀어내는구나 싶었다.

시니어라는 단어를 떠올리면 나는 늘 기술적 깊이를 먼저 생각했다. 복잡한 문제를 풀어내는 능력, 남들이 못 보는 아키텍처 결함을 찾아내는 눈, 장애 상황에서 침착하게 시스템을 되살리는 손놀림 같은 것들. 그런 게 중요하지 않다는 말은 아니다. 다만 조직이 커질수록 진짜 실력은 다른 데 있는 게 아닐까. 가령 서로 이해관계가 다른 조직들 사이에 인터페이스를 설계하는 능력같은 것들.

회사가 커지고 엮인 조직이 많아질수록 일을 끌고 나가는 게 정말 어려워지는 것 같다. 우리 팀에게 중요한 일이 저쪽에는 하나도 안 중요할 수 있고, 다들 각자의 사정과 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를 수면 위로 끌어올려 보이게 만드는 게 한 방법일 수 있다. 가령 그동안 아무도 입 밖에 안 꺼낸 침묵의 비용을 숫자로 보여주는 것. 사람들은 추상적인 위험에는 잘 안 움직이는데, 일단 수치가 찍히면 한 번 더 쳐다보게 되지 않을까. 우리가 이걸 안 하고 버티는 동안 알게 모르게 지불해온 비용을 들이미는 셈이다.

다 완성된 계획을 “통보"받으면 일단 비판부터 하게 되지만, 설계 과정에 “참여"하면 어느새 동료 의식이 생긴다. 그래서 일부러 설계에 빈칸을 남겨두는 기법을 쓰기도 한다. 사람이란 게 완벽해 보이는 계획 앞에서는 안 되는 이유부터 찾는데, 채우기 좋게 비워둔 칸 앞에서는 마지막 한 조각을 끼워 넣고 싶어한다. 똑같은 사람인데 앞에선 계획을 부정하는 쪽으로, 뒤에선 긍정하는 쪽으로 머리가 돈다. 좀 얄팍한가 싶기도 한데, 의외로 잘 먹힌다.

돌아보면 조직의 시니어란 이런 걸 잘해야 하는 사람들이구나 싶다. 기술적 깊이는 기본이고, 그 위에서 각 조직의 사정을 꿰고 있으면서 이해관계를 조정하고, 모두가 납득할 만한 문제 정의를 같이 만들어가는 능력. 그게 결국 조직 사이의 인터페이스를 설계하는 일 아닐까. 다른 말로 하면 영향력이라고 불러도 될 것 같고.

이력서에 적힌 그 한 문장을 읽고 한참을 생각했다. 나는 그동안 시니어라는 말을 너무 좁게 본 게 아닐까. 기술만 잘하면 된다는 생각은 어쩌면 조직이 작을 때나 통하는 얘기였는지도 모르겠다. 함께 정의되지 못한 문제는 함께 해결되지도 않는다. 이 말이 아직도 머리에 남아 있다.