안녕하세요. 뱅크샐러드에서 Tech Lead를 맡고 있는 류성두입니다.

뱅크샐러드에서 자랑하는 문화 중에 가장 핵심적이고 독보적이라고 생각하는 문화 중 하나로, 저는 늘 코드 작성 전 테크스펙을 작성하는 문화를 꼽습니다. 그런데 제가 어디 가서 이 이야기를 하면 늘 마주하는 오해가 있습니다. 바로, 개발 전에 문서를 작성하는 일은 애자일에 반하는, 심지어는 관료적인 개발 문화가 아니냐는 것입니다.

그리고 경험상 이런 오해의 배경엔 거의 언제나 애자일 선언문이 있었습니다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서
소프트웨어 개발의 더 나은 방법들을 찾아가고있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만,
본 고지와 함께 전문으로서만 가능하다.

— 애자일 선언문

위 관점을 테크스펙 문화에 기계적으로 적용한다면, 다음과 같은 생각이 가능합니다.

• 테크스펙은 문서다.
• 애자일 선언에선 문서보다 작동하는 소프트웨어를 가치있게 여긴다.
• 뱅크샐러드는 코드작성보다 테크스펙이라는 문서를 먼저 작성한다.
• 따라서 뱅크샐러드의 테크스펙 문화는 애자일에 반(反)한다.

물론 이런 오해는 애자일 선언을 다시 한 번 찬찬히 읽어보는 것만으로 어느 정도 해소될 수 있습니다. 애자일 선언에서 경계한 것은 문서 작성 자체가 아니라, 작동하는 소프트웨어보다 문서 작성을 더 중요시하는 관행이기 때문입니다.
한 편 어떤 종류의 문서는 개인 간의 상호작용을 촉진하고 고객과의 협력을 활발하게 하여, 애자일의 취지를 극대화시키기도 합니다. 그리고 테크스펙이 바로 그런 문서입니다.

특히 여기서 ’문서’라는 것을 바라보는, 애자일 선언을 작성했던 2001년도의 인간과 오늘을 살아가는 21세기 직장인의 관점의 차이를 짚고 넘어갈 필요가 있습니다. 애자일 선언의 저자 중 한 명이자, 애자일의 프로그래머로서의 실천법인 XP(Extreme Programming)를 소개한 Kent Beck은, 그의 저서 『Extreme Programming Explained』 에서 다음과 같이 말합니다.

문서기반의 소통엔 태생적인 비효율이 있다. 문서는 더 많은 사람들에게 도달할 수 있긴 하지만, 결국 일방적인 소통방식이다. 반면 대화를 통해서는 질의, 즉각적인 피드백, 브레인스토밍과 그 밖에 문서로서는 불가능한 다양한 일들이 가능하다. 문서에 적힌 내용은 이미 정해진 사실처럼 받아들여지거나 즉각적으로 거부되는 경우가 많은데, 둘 중 어느 경우도 팀 내의 소통을 늘리는 일에 도움이 되지 않는다.
— 『Extreme Programming Explained』 Chapter 5 Principle

그렇습니다. 일반적으로 애자일 선언의 저자들이 이야기하는 ’문서’는 종이나 정적 HTML 파일 같은 일방향 소통 수단으로서의 문서입니다. 그 당시의 그들에겐 실시간으로 함께 작업하고 댓글을 달고 멘션을 걸어 채팅할 수 있는 오늘날의 노션, 구글문서, 슬랙의 캔버스와 같은 문서 도구들이 없었으니까요.

테크스펙은 오히려 Kent Beck이 (당시의) 문서로는 불가능하다고 말했던, 질의응답과 즉각적인 피드백, 그리고 브레인스토밍 등을 가능하게 하는 것이 본질적인 목적입니다. 단적인 예로, 토론 및 피드백이 필요 없는, 무엇을 어떻게 해야 할지가 명확한 작업을 할 때에 저희는 테크스펙을 작성하지 않습니다. 그런 건 그냥 하면 되고, PR을 올릴 때 PR 본문 정도만 잘 기록하면 됩니다. 테크스펙이 작성되어야 하는 경우는,

• 2명 이상의 협업이 필요한 프로젝트
• 창의력이 필요한 작업

을 진행하는 경우입니다.

협업을 하게 된다면 프로젝트의 범위나 일정, 담당 컴포넌트 간 통신 인터페이스부터 시작해 당연히 함께 토론해야 할 주제들이 있기 마련입니다. 또 창의력이 필요한 작업의 경우, 하나의 관점을 가진 개인보다 다양한 관점을 가진 팀원으로 구성된 팀이 보통 더 창의적이기 마련이므로 팀원의 피드백을 받는 일이 이득입니다. 특히 이런 피드백을 코드로 구현한 뒤에 받는다면, 그 피드백이 아무리 훌륭해도 이미 코드 작성에 들인 비용이 많아 현실적으로 반영하기 어려운 경우들이 생깁니다. 이런 상황을 방지하기 위해 더 이른 시점에 피드백을 주고받을 수 있는 매개체가 바로 테크스펙입니다.

이런 관점에서 봤을 때, 테크스펙은 문서라기 보다는, 사실상 “토론방”에 더 가깝습니다. 그리고 테크스펙을 잘 쓴다는 것은, 생산적인 토론이 잘 일어나는 토론방을 가꾸는 일이라고 할 수 있습니다.

“토론방”으로서의 테크스펙의 성격을 이해하고 난다면, 자연스럽게 테크스펙에 대한 두번째 오해를 풀 수 있을 것 같습니다. 바로 테크스펙이 “최신화 되어야 한다”는 오해입니다. 많은 분들이 뱅샐에서 테크스펙을 작성한다고 하면, “그러면 그 많은 문서를 어떻게 최신화 하느냐”고 궁금해하십니다. 이에 대한 답변은 최신화하지 않는다입니다.

마치 새로운 회의에서 기존 결론이 뒤집혔다고 기존 회의록을 수정하지 않는 것과 같은 이치입니다. 기존 의사결정을 바꾸는 회의가 새로 생기면 새로운 회의록이 나오듯, 스펙이 바뀌면 기존 테크스펙을 고치는 것이 아니고, 새로운 테크스펙을 작성합니다. 즉, 테크스펙은 그 스펙이 실제로 배포됨과 동시에 그 수명을 다 합니다. 테크스펙은 디테일을 다루는 문서이고, 그 디테일은 시시각각 변하기 때문입니다. 만약 어떤 명세가 계속해서 참조되기 위해 최신화되어야 한다면, 뱅샐에서는 이런 경우 테크스펙이 아니라, IDL (Interface Design Language) 및 그 주석이나 테스트코드, 또는 README 등을 사용합니다.

테크스펙은 짧은 수명의 문서인 만큼, 그리고 그 본질이 토론방인 만큼, 가독성 높은 아름다운 문서일 필요도 없고 심지어 오타투성이여도 상관없습니다. 그저 고민할 주제, 그 고민의 과정에서 조사한 내용, 이를 바탕으로 피드백이 오가야 하는 포인트가 명확하기만 하면 됩니다. 보통은 자료 조사까지 포함해 1~2일 안에 초안이 작성되는 경우가 대부분이고, 길어도 일주일 안에는 대부분 핵심 주제에 대한 토론과 피드백이 마무리됩니다. 스펙에 따라 다소간의 차이가 있을 순 있지만, 적어도 자간・장평이 안 맞는다고 상관에게 열두 번씩 문서가 반려되거나 하는 일은 없습니다.

’작업 전에 문서를 쓰는 일’은 최종 납품 일자를 늦추는, 불필요한 관료적 관행처럼 보일 수 있습니다. 하지만 ’작업 전에 토론을 하고 피드백을 주고받는 일’은 어찌 보면 모든 지적생산활동의 본질이라고 할 수 있습니다. 영화를 찍기 전에는 시나리오를 바탕으로 피드백이 오가고, 만화를 그리기 전에는 콘티를 바탕으로 피드백을 주고받습니다. 개인의 창의력엔 한계가 있고, 제품이 생산된 이후에는 팀이 피드백을 주기 너무 늦어버리는 경우가 많기 때문입니다. 영화가 다 만들어졌는데, “아 저 장면에서 저건 어땠으면 좋았을걸”이라고 아무리 창의력 가득한 피드백을 줘본들, 영화감독이 그 피드백을 반영하기는 어려우니까요.

---

모쪼록 이 글을 통해 뱅크샐러드의 테크스펙 문화에 대한 막연한 오해가 다소나마 풀렸기를 바랍니다. 나아가 아마도 각자의 조직에서 다른 형태와 이름으로 존재하고 있을 각자만의 테크스펙 문화가 이 글을 통해 재발견되기를 바랍니다.

아 물론, 뱅크샐러드에서 테크스펙 문화를 제대로 경험해보고, 또 함께 성장하고 싶으신 분이 계시다면, 언제나 환영입니다!