Page history of 내가 개발팀을 운영하는 원칙

블로그를 복구한 기념으로, 내가 그동안 개발팀을 운영해왔던 원칙들을 좀 정리해보기로 했다. 예전에는 이런 원칙들을 이미 내재화한 동료들과 많이 일했었기 때문에 이런 원칙들을 문서화해보지 않았는데, 최근 직장인 메디쿼터스에서는 처음부터 개발팀을 새로 빌드업해야 했기 때문에 원칙들에 대해 자주 반복적으로 설명해야 해서 자연스럽게 글로 적어보게 되었고, 이 원칙들을 내 스스로 돌이켜볼 계기가 되었다. 그 원칙들을 여기서 다시 한 번 정리하고 해설을 덧붙여보고자 한다.

애자일 선언과 eXtremeProgramming의 가치를 이해하고 따르려고 노력한다.

팀에서 공식적으로 애자일과 XP를 선언하고 시작했다. 애자일에 대해서는 수많은 논란이 있고, 또 애자일이라는 걸 너무 드러내지 말고 조금씩 도입해야 진짜 애자일이라는 둥 다양한 전략들이 거론되지만, 나는 직진을 택했다. 다만, 애자일이라는 용어가 이미 국내외를 막론하고 정반대의 의미로 많이 오염이 되어서, 애자일이라는 표현을 직접 쓰기보다는 애자일 선언을 거론하거나, 구체적인 방법론으로 XP를 들어 소통하는 방식을 취했다. 

애자일 선언은 단어 하나하나가 정말 세심하게 선택된 명문이다. 주의 깊게 읽는다면 잘못 해석할 여지도 적고, 추상적이면서도 모호하지 않다. 그러나, 쉬운 문장은 아니기 때문에 어느 정도 해설이 필요하다. 그래서 애자일 선언 다시보기 같은 글을 쓰다 말기도 했었다. 이 글에서 애자일 선언을 깊이 해설하다가는 끝이 안 날 수 있어서, 일단 애자일 선언을 깊이 있게 읽어보라는 이야기만 해두고 싶다. 지난 번 팀에서는 애자일 선언의 네 가지 가치, 그리고 12가지 원칙을 여러 차례 리뷰하고 토론하는 시간을 가졌었다. 12가지 원칙도 어느 하나 버릴 게 없는 좋은 원칙들인데, 이 중에 특히 많은 팀이 어려워하는 거 몇 가지만 꼽아본다.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

경력이 적은 주니어들은 요구사항이 자주 바뀌는 것을 보고 팀이 체계 없이 일해서 그렇다고 생각하는 경우가 많다. 하지만, 요구사항이 바뀌는 것은 소프트웨어 개발에서 필연적인 것이며, 안 바뀌는 것이 훨씬 위험하다. 요구사항이 중간에 안 바뀐다는 것은 개발하는 과정에서 개발에 참여한 사람들이 아무 것도 배우지 못했다는 뜻이기 때문이다. 물론, 보통의 회사에서는 합리적인 이유로 요구사항이 바뀌기보다는 의사결정자의 갈대 같은 마음으로 바뀌기 때문에 요구사항 변화에 거부감을 갖기 쉽다. 하지만, 그런 의사결정자라면 더더욱 요구사항이 안 바뀔 때의 리스크가 더 클 것이다. 개발자는 언제든지 자기가 작업한 코드를 버릴 준비가 되어 있어야 한다. 

Business people and developers must work together daily throughout the project

PO라는 포지션의 등장으로 이게 점점 더 어려워져 가고 있다. PO가 다리 역할을 한다는 명분으로 비즈니스 피플과 개발자 사이의 직접적인 소통을 끊고 중간에 정리해서 따로따로 소통하게 하고는 시간을 절약해준다고 말한다. 도대체 누구의 시간을 절약하는 걸까? 아무리 뛰어난 PO라도 소통 과정에서 정보의 유실이 발생하지 않을 수는 없다. 담당자끼리 직접 소통하면 금방 될 일을 여러 단계로 핑퐁하면서 10분 만에 결정할 수 있는 일이 며칠 씩 걸리기도 한다. 그래서 나는 늘 비즈니스 피플과 개발자가 직접 소통하기를 권하고, 개발자가 자신이 맡은 작업의 비즈니스 가치에 대해 이해하기를 요구한다. 개발자에 따라 이걸 싫어하고 그냥 기획서만 쳐다보고 일하고 싶어하는 경우도 많다고 하는데, 적어도 내 팀에서는 대개 비즈니스랑 맞닿아 있는 것을 좋아하는 사람들이 대부분이었다. 자신의 일의 결과로 돈을 얼마 버는지, 혹은 비용을 얼마나 아끼는지 이해할 때 개발자는 더 보람을 느끼고 일에 매진할 수 있다. 

Working software is the primary measure of progress.

애자일이 잘못 전파된 사례 중 하나가 스크럼 보드다. 스크럼 보드, 칸반, 또는 백로그 등의 시스템에서 ToDo가 무슨 상태로 바뀌었냐를 가지고 프로젝트 관리를 하려는 조직들이 많다. 하지만, 이건 진짜 진척도가 아니다. 개발 진척 상황을 100% 작업관리 시스템과 싱크시키려면 많은 시간이 든다. 예전에 JIRA를 열심히 썼던 팀들은 JIRA를 쓰는 시간이 코드를 작성하는 시간보다 더 많을 정도로 시간을 많이 썼다. 팀장 한 명 상황 파악 편하게 하고 싶다고 이렇게 하나? 이건 체계적인 것도 뭣도 아니고, 칸반의 목적도 이해 못하는 것이다. 

정말 중요한 것은 지금 동작하는 소프트웨어가 어떤 상태에 있냐는 것이다. 외주를 하다보면 일 잘한다 싶은 갑을 만날 때가 가끔 있다. 자기가 원하는 것이 뭔지 잘 식별하고 불필요한 일은 잘라내고 다음 해야 할 일을 잘 짚어주는 사람들. 이런 사람들을 보면 공통적으로 백로그 따위는 잘 쳐다보지 않고 현재 디플로이된 제품을 끊임 없이 써보고 이리저리 테스트해보면서 현재 상태에서 다음으로 해야 할 중요한 일이 뭔지 찾는다. 이런 사람들이랑 일하면 적어도 그 사람들이 원하는 바를 달성해주기는 쉽다. 근데, 요구사항은 산더미처럼 많은데 자기가 의뢰해서 개발한 제품을 거의 써보지도 않는 갑들이 많다. 이런 갑들은 프로젝트 끝날 때가 되어서야 이게 아니라는 걸 깨닫는데, 또 희한하게 그런 갑들은 별로 수정 요구도 많이 안하고 처음 해달라는 대로 해준 상태에서 그냥 종결해버린다. 그리고 그 프로젝트는 시장에 나가지 못하거나 나간 후에 얼마 안되서 접는다.

Simplicity--the art of maximizing the amount of work not done--is essential.

이건 개발자들이 심리적으로 잘 못하는 부분이다. 개발자는 요청 받은 일이 뭐든 다 빨리 해주는 게 능력이라고 생각하기 때문에 일을 거절하거나 더 쉬운 방법을 찾기보다 그냥 해달라는 대로 해주는 경우가 많다. 그런데 비즈니스 피플은 소프트웨어 전문가가 아니라서 어떤 대안들이 있는지 잘 모른다. 코드 한 줄 변경 없이 목적을 달성할 수 있는 방법이 있는데도 개발해 달라고 하는 경우가 많다. 매우 어려운 길로 개발하는 대신 손쉽게 조금만 고쳐서 원래 목적을 달성할 수 있는 경우도 많다. 이런 건 개발자가 이야기해줄 수 있어야 한다. 

모든 의사결정은 뒤집을 수 있다.

애자일 선언 다음으로 중요하게 이야기한 원칙이 이것이다. 사실 이것도 embrace change를 내세우는 애자일의 연장선이기는 하지만, 좀더 구체적으로 선언해둘 필요가 있었다. 의사결정은 당연히 바뀔 수 있는데 굳이 선언해둘 필요가 있나 싶을 수 있지만 대부분의 조직은 한 번 의사결정한 것을 바꾸는데 대단한 거부감을 느낀다. 특히 가장 나쁜 것이 "우리 이거 전에 이야기해서 결정한 거잖아?" 같은 말이 나오는 것이다. 이런 말은 우리가 이전에 했던 나쁜 의사결정을 뒤집는 것도 가로막게 된다. 또 이런 말이 반복적으로 나오게 되면 그 팀은 중요한 의사결정을 내리기 어려워진다. 되돌릴 수 없는 결정이라는 걸 알고 결정한다면 사람들이 어떻게 행동할까? 절대 실패하지 않는 결정으로 만들기 위해 더 많은 검토를 해야 하고 반대 의견을 쉽게 수용하기 어려워진다. 그래서, 나는 팀에서 저런 말이 나오는 것을 극도로 경계한다.

법정에서도 증거나 진술 등에 허위가 있었을 때는 일사부재리의 원칙의 예외로 재심이 가능하지만, 회사는 그런 제약도 필요 없다. 이전에 의사결정했을 때보다 팀이 더 발전했고 그에 따라 생각이 바뀌었다면 의사결정을 뒤집지 못할 이유가 없다. 그래서, 실제로 다른 팀에서는 거의 바꾸지 않는 것들을 우리 팀에서는 많이 바꾸었다. js와 ts 사이를 왔다갔다 하기도 하고, 구현 상의 원칙도 여러 번 변경되었다.

나중에 더 좋은 결정을 내리는 게 가능해졌을 때 이전의 의사결정을 뒤집을 수 있다는 확신이 있으면 거꾸로 가벼운 의사결정이 가능해지기도 한다. 반대 의견을 주장했던 사람들도 일단 해보고 안 좋은 점이 발견되면 다시 바꾸자고 할 수 있기 때문이다. 

업무에 대한 의사소통은 가능하면 사적인 채널보다 공적인 채널을 우선한다.

오래된 팀들에서 주로 일해오다가 신세대(?) 회사를 경험하면서 느끼는 것 중 하나는 개인적인 소통을 상당히 많이 한다는 것이다. 당연히 팀 차원에서 논의해야 할 일인데 DM으로 보낸다든지, 둘이서만 미팅 잡는다든지 하는 일이 많았다. 이건 팀 전체에 흘러야 할 정보가 흐르지 않게 만든다. 설령 나 혼자만 하면 되는 일이라 하더라도 그 정보가 팀에 흘러야 한다. 그래서, 대체로 다음과 같은 우선순위로 소통하기를 권장한다.

• 오프라인 미팅은 되도록 모든 관련자들에게 참석을 요구하고, 온라인으로도 중계(허들 등)해서 원하는 사람이 참관할 수 있게 한다.
• DM보다는 팀원들이 모두 소속된 채널에서 소통하는 것을 우선한다.
• 쓰레드보다는 탑 레벨 메시지를 우선한다.
• 채널은 되도록 비공개보다는 공개로 만든다.

이것만으로도 의사소통의 투명성도 높아지고 정보가 좀더 잘 흐르게 된다.

의사소통에서 메시지 전달의 책임은 받는 사람이 아니라 보내는 사람에게 있다.

회사에서 또 분쟁이 많이 생기는 포인트 중 하나가, "전에 말씀드렸잖아요." 같은 것이다. 그런데, 직원들이 성과를 내려면 집중이 필요하고, 머리 속에 집중해야 할 일이 있을 때 들은 이야기는 놓치기 쉽다. 개발자만 그런 게 아니라 거의 모든 직군이 그럴 것이다. 그런 것들을 꼼꼼하게 챙기도록 요구할 수도 있겠고, 그게 프로페셔널의 자세라고 말할 수도 있겠지만, 나는 그렇게 생각하지 않는다. 꼼꼼하게 챙기는 것은 공짜가 아니다. 많은 비용이 들고, 때때로 집중하는데 써야 할 에너지를 소모시키는데, 이것은 회사에 더 큰 손해다. 하지만, 메시지를 보내는 사람은 보통 자신에게 필요해서 보내는 것이기 때문에 컨텍스트를 끊지 않아 전환 비용이 적게 발생한다. 그래서, 나는 메시지 전달의 책임을 송신자에게 부여한다. 이 문제에 관해 여러 가지 다양한 방법을 시도해봤지만, 효율성 측면에서도, 분쟁의 최소화 측면에서도 이게 가장 좋은 방법이었다.

이 원칙은 여러 가지로 파생된다. 이를테면 질문할 때 답변자가 놓치고 답을 안했다고 해서 답변자를 나무랄 수 없다. 그냥 질문자가 다시 한 번 질문해야 한다. 슬랙으로 공개 채널에서 질문했는데 답을 안 주면 멘션을 걸고, 그래도 안되면 DM을 보내고, 그래도 안되면 전화를 해야 한다. 물론 보통은 멘션 수준에서 끝나지만. 코드 리뷰를 받는 것도 리뷰어의 책임이 아니라 커미터의 책임이다. 리뷰가 지연되면 커미터가 계속 리뷰어들을 재촉해야 하는 의무를 진다. 대신 리뷰어는 재촉을 귀찮아해선 안되고.

다만 개발팀 바깥과의 소통에서는 튜닝이 좀 필요하다. 전사적으로 이런 원칙을 적용하는 것은 아니었기에, 외부의 요청에 대해서는 좀더 꼼꼼하게 대응하기를 요구하되, 개발팀이 타 부서나 다른 회사에 요청할 때는 응답이 안 오면 상대를 질책하지 않고 그냥 우리가 요청을 반복하도록 했다.

개발팀 내에서의 의사소통은 비동기가 원칙이었기 때문에 이 원칙과 더 시너지가 나는 부분도 있었다. 메시지 송신자는 언제든지 자기가 급할 때 메시지를 보내도 되고, 수신자도 자신이 가능할 때 답을 하면 된다. 일하는 시간대가 다른 사람도 많았기 때문에 더더욱 이 원칙이 잘 동작했던 것 같다.

이 원칙을 명시하고 여러 번 강조한 이후로는 이런 종류의 분쟁도 사라졌고, 그러면서 의사소통을 꼼꼼하게 챙기기 위한 부담도 줄어서, 상당히 유익한 정책이었다고 보고 있다.

허락을 구하기보다 용서를 구하라.

이건 아마도 설명이 필요 없는 원칙이지만, 이게 좋은 원칙이냐 아니냐는 아마 팀마다 다를 것이다. 내가 이 원칙을 세운 이유는 애자일 선언의 첫번째 가치, "Individuals and interactions over processes and tools"와도 연관이 있다. 개인이 프로세스보다 중요하다는 것은 팀에서 합의하는 과정을 생략하고 개인의 판단으로 움직일 수도 있다는 뜻이다. 상황에 따라 완전한 합의를 구해가면서 하기에는 발이 느린 경우도 많고, 의사결정자가 빨리 응답해줄 수 없는 경우도 많다. 그럴 때 개인의 판단으로 일단 밀고 나갈 수 있어야 좀더 기민하게 움직일 수 있고, 또 그런 개인의 판단을 존중할 때 개인의 능력과 창의성을 최대한 이끌어낼 수 있다. 그래서, 공식적으로 허락을 구하기보다 용서를 구하는 것을 권장한다.

단, 이게 가능하려면 위에서 언급한 의사결정과 의사소통의 원칙도 같이 맞물려야 한다. 개인이 잘못된 판단으로 추진한 일을 다시 되돌릴 수도 있다. 그래서 더더욱 부담 없이 용서를 구하는 모드로 일단 밀어붙여 볼 수 있는 것이다. 물론 이렇게 추진하는 개인도 자신이 작업한 내용이 한 순간에 다 날아갈 수 있다는 각오가 필요하다. 

이 원칙이 잘 동작하기 위해서는 개인이 팀, 그리고 리더를 믿을 수 있어야 한다. 이 원칙을 믿고 자기 생각대로 했는데 왜 너는 허락도 안 받고 이랬냐고 질책을 받는다면 이 원칙은 동작할 수 없다. 설령 개인의 판단이 틀렸더라도 질책하지 않고 바꾸어야 한다. 또, 이런 신뢰를 얻기 위해서는 때때로 최선이 아닌 판단을 보더라도 그대로 끝까지 가도록 내버려 두어야 할 필요가 있다. 자신의 결정이 매번 뒤집어진다면 이 원칙이 진짜인지 믿기 어렵기 때문이다. 그래서 나는 팀원들이 다소 잘못된 길로 가더라도 바로 잡지 않고 놔둘 때가 종종 있다. 단, 이런 선택을 하려면 그 잘못된 선택의 결과를 감당할 수 있는 기술적 역량도 필요하다. 

이 원칙은 코드 레벨에도 많이 스며든다. 파이썬에서는 EAFP 같은 원칙을 이야기하기도 하는데, 발생할 법한 에러를 미리 검사해서 방지하는 코드보다는 에러가 발생하면 끝까지 에러가 던져지게 하되, 잘 기록해서 추적할 수 있게 하고, 적절한 레벨의 알림으로 인지할 수 있게 하는 것을 중시한다. 

불완전한 코드와 생각, 업무 현황을 자주 팀에 공유하라.

문제가 있을 때 사람을 비난하기보다 문제 자체에 집중할 수 있는 방향으로 소통한다. 피치 못하게 사람을 비난할 때는 구체적이고 입증 가능한 근거를 제시해야 한다.

블로그 / 소프트웨어 개발