현 회사 개발사업부 노션의 첫 번째 페이지는 우리가 일하는 법 이라는 제목의 선언문이다.
공통 원칙, 코드 작성 및 버전 관리 규칙이란 단락으로 구성되어 있고
- Agile Manifesto의 네 가지 가치를 이해하고 따르려고 노력한다.
- 모든 의사 결정은 뒤집을 수 있다.
- 허락을 구하기보다 용서를 구하라.
- 의사소통에서 메시지 전달의 책임은 받는 사람이 아니라 보내는 사람에게 있다.
- 문제가 있을 때 사람을 비난하기보다 문제 자체에 집중할 수 있는 방향으로 소통한다.
- 일정, 사용자 가치, 성능 등의 문제보다도 코드 품질을 최우선으로 한다.
등의 원칙과 규칙이 나열되어 있다.
이렇게 팀원 모두가 추구해야할 원칙을 정해놓지 않은 곳이 많을테고, 원칙이 있어도 명문화하지 않은 곳도 많을테고, 명문화했더라도 거기서 끝인 경우 역시 많으리라 생각한다. 굳이 개발자 집단이 아니라도 말이다.
문화라는 건 자연스럽게 체화되는 것이라고 생각하는데, 우리 팀은 정말로 그랬다.
(당연하게도) 원칙과 규칙들이 전 CTO나 시니어 분들에 의해 이게 좋은 것이니 따르자고 정해진 게 아니었고, 모든 구성원들이 참여한 토론에서 치열한 논의 끝에 선언문에서 어렵게 한 자리씩 차지하게 된 것이었다. 그리고 그렇게 정해진 것도 모든 의사 결정을 뒤집을 수 있다. 란 원칙에 의거해 정제되며 다져졌다.
이후 구성원 하나하나가 (특히 CTO가) 몸소 원칙 기반으로 사고하고 결정하는 모습을 보여주니 나 포함 뒤에 합류한 팀원들도 그런 문화를 자연스레 체화시켰고 선언문이 선언문으로 끝나질 않았다.
원칙을 정하고 모든 판단과 행동에 앞서 그걸 되새기며 결정을 한다고? 업무 문화 뿐 아니라 모든 영역에서 적어도 나는 살면서 처음 겪는, 철학자 혹은 로봇 같은 성실함이었다.
일정보다 코드 품질이 최우선이라고?
선언문의 모든 문장에 대한 인상적인 사례가 있지만, 이 글에선 일정, 사용자 가치, 성능 등의 문제보다도 코드 품질을 최우선으로 한다. 에 대한 이야기를 하고 싶다.
물론 이 규칙은 (실제 경험해보니)코드 품질을 최우선으로 하면 일정, 사용자 가치, 성능을 달성할 수 있다. 라는 말과 대동소이하다.
하지만 후자로 표현하면 타협할 여지가 생긴다는 점에서 크나큰 차이가 있다고 생각한다.
그렇다면 자연스럽게 따라오는 좋은 코드란 어떤 것인가 라는 질문엔 아래와 같이 정했는데,
- 좋은 코드의 조건은 Beck Design Rule(주석까지 읽어볼 것)을 기준으로 삼는다.
- Passes the tests
- Reveals intention
- No duplication
- Fewest elements
여기선 Fewest elements 의 사례 하나를 공유하고 싶다.
Fewest elements == Simplest business logic
간단한 if문 하나라도 왜 필요한지, 불필요하진 않은지, 없앨 수 있는 다른 방법은 없는지 리뷰를 주고 받다보니 비즈니스 로직을 가능한 한 심플하게 만들기 위해 노력할 수 밖에 없었다.
오랜 시간 매달렸던 영역이 셀러에 대한 정산인데, 셀러의 타입이 4가지나 되어 상당히 복잡한 분야였다.
타입별로 같은 용어를 다른 쓰임으로 사용하는 경우도 있었고, 용어 자체가 불분명한 경우도 있었고, 계산식도 다른 경우가 있었다. 당연히 예외 상황도 다 달랐고.
이런 경우 코드적으로는 다형성으로 구현해 복잡성을 분산시키는 게 일반적이겠으나 Fewest elements를 우선하다보니, 사업부와 용어와 쓰임을 통일시키는 노력을 하게 되고 결국엔 계산식마저 하나로 단순하게 만들어 다형성으로 구성할 필요조차 없게 되었다.
추후 정산을 이벤트로 구현하는 리팩토링을 한 것도 무척 재미있는 작업이었지만, 코드 품질을 달성하기 위해 비즈니스 로직부터 심플하게 만들었던 경험과 그에 따라오는 희열은 어지간하면 다시 맛보기 힘들거라 생각이 든다.
사족: 정말 같은가?
일정, 사용자 가치, 성능 등의 문제보다도 코드 품질을 최우선으로 한다.코드 품질을 최우선으로 하면 일정, 사용자 가치, 성능을 달성할 수 있다.
이전 CTO 체제에선 1의 역이 2가 되는 건 당연한 거라 생각했다.
하지만 몇 달간 바뀐 체제를 경험해보니, 조직 구조와 문화가 받쳐주지 않으면 달성하기 힘든 거였다는 걸 알게 되었다.
이전 CTO 체제에선 기획자나 PM이 따로 없었고, 개발자가 기획자 역할을 해야했다. 그러기에 코드 품질을 위해 비즈니스 로직을 단순화시키려는 시도 끝에 양측에서 만족할 만한 합의점을 찾을 수 있었다.
또한 특이하게도 일정을 확정하지 않는 대신 작은 효능을 빨리 맛보게 하는 문화였는데, 일정을 알고자하는 사업부의 욕망에도 불구하고 이 방식이 전체적으로 봤을 때는 일정을 훨씬 단축시켰을 거라는 강한 믿음을 갖고 있다. 그게 아니었다면 아직까지도 정산 자동화에 매달리고 있었지 않을까 싶다.
물론 이전 체제가 무조건 만능이고 좋다는 이야기는 아니다. 조직 규모와 페이즈별로 달성하고자 하는 목표에 따라 맞는 게 있겠지.
