벌써 2월 중순이니까 늦어도 한참 늦은 후기지만 지난 1월 열린 다노 제 1회 프로콘에서 발표를 했다. 재밌었다~! 부트캠프에서 처음으로 개발자들의 문화에 대해 듣게 되었을 때부터 학습과 공유가 활발한 개발자 커뮤니티의 특성들이 신기하고 근사하게 느껴졌다. 특히나 사내 컨퍼런스가 있는 회사를 보면 그 문화와 분위기가 부럽고 신기했는데 그게 우리 회사라니~. 언젠가 어딘가의 컨퍼런스에서 꼭 한 번 발표를 해보고 싶었는데 얼렁뚱땅 포문을 여는 경험을 하게 되어 영광이고 좋았다.
다만 프로덕션 유닛 전체의, 1회차 행사이다보니 주제를 선정하는 게 퍽 까다로웠다. 개발자뿐만 아니라 PM, 디자이너, 데이터분석 등 참여하는 이들의 직무가 다양하다보니 욕심처럼 모든 사람들이 들을만한 주제를 고르는게 어렵기도 했고, 내게 딱 짚어 다룰만한 기술적인 주제가 없기도 해서 입사 이후로 프론트엔드 팀이 시도해왔던 다노's 테크스펙을 주제로 발표했다.
발표한 내용을 조금 정리해 적어둔다.
테크스펙이 누구세요
어 느 날 팀장님이 뱅샐 블로그에 게시된 테크스펙 포스트를 공유하면서 처음으로 테크스펙에 대해 알게 되었다. 코딩을 처음 배우던 때부터 사전에 의사코드를 충분히 고민하고 정리한 후에 실제 소스코드를 작성하라는 당부를 단단히 들었지만, 참을성이 지지리도 없는 나는 선인들의 지혜를 자주 잊어버린다.
1초 뒤의 나도 알아보지 못하는 지렁이 글씨로 성긴 의식의 흐름을 아이패드 메모장에 휘갈긴 다음 충격과 공포의 아노미 상태로 코딩에 착수하는 오만을 깨끗이 청산하지 못한 죄로 스스로 초래하는 재난과 고초에 곧잘 뛰어드니 TDD 실천에 있어서도 극악무도한 캐릭터임에 틀림없다.
그러하니 개발 착수 전에 모든 물음표를 소거하겠다는 패기와 비전이 느껴지는 테크스펙이라는 것이 대단히 근사하고 타당해 보였고, 아노미 코더로 정체성이 굳어질까 두려움이 쑥쑥 자라나는 시기에 운명처럼 하늘에서 내려준 동아줄처럼 느껴져서 온 마음을 열어 ㅇㅋ를 외쳤다. 그러나 너무나 논리적이어서 금세 쓰일줄 알았던 그 문서를 실제로 작성하는 일은 생각보다 녹록치 않았다.
꽈당 포인트
이 문서를 받을 이가 누구요
문서의 전반적인 컨셉과 목적은 알겠으나 막상 작성하려고 하면 세부 항목과 다뤄야 할 범위가 뚜렷하지 않은 점이 어려웠다. 테크스펙 도입 초기 러프하게 정리된 우리팀의 컨셉은 "개발 착수 전에 모든 모호한 지점에 대한 고민을 끝내버리겠다." 였다. 그리고 작성된 테크스펙에 대해 목적 조직인 유닛의 리뷰를 받는 것을 예상하고 있었다.
그런데 이 문서를 검토할 메인 리뷰어는 누구인가. PM? 디자이너? QA? 누가 읽을 것이며 누구의 입장에서 검토할 문서인지 모른다는 건 어떤 내용을 얼마나, 어떤 방식으로 쓸지 고민되는 순간마다 판단 기준을 가늠하기 어렵게 만들었다. 그렇다고 당시에 리뷰어는 바로 여러분 얼오뷰 라고 명쾌하게 선언하기도 쉽지 않았는데, 유닛 구성원 모두를 위한 내용이 포함되는 문서인지 혹은 포함되어야 하는지, 어떻게 포함시켜야 하는지 답하지 못하는 상태였기 때문이다.
아니 제가 이미 정리 다 해놨잖아요
프론트엔드 팀에서 정의한 테크스펙 기본 템플릿은 개발 목표, what에 해당하는 Goal 과 구체적인 개발 과정, 설계 등 How에 해당하는 Plan 그 외 Questions 등의 항목으로 구성되어 있다.
개발 목표 Goal이란 너무나도 당연하게 들리지만 막상 쓰자고 보면 썩 당연하지 않았다. 어찌보면 PM이 이미 빽빽하고 꼼꼼하게 정리해놓은 기획서를 다시 쓰는 것과 다름 없다는 생각이 들 때가 있었고 밀도면에서도 PM의 기획 문서보다 빈틈이 많은 이 구멍난 복사본을 도대체 왜 쓰는 것이며 이것을 다시 리뷰해달라고 하는건 PM분에게 아니 제가 이미 정리 다 해놨잖아요, 라는 대사 참기 챌린지를 부여하는 것이 아닌가 싶은 기분도 들었다.
제 테스트가 왜 그래요
이상적으로 대충 그린 꿈의 시나리오에 따르면 테크스펙을 작성한 시점의 나는 무엇을 어떻게 개발할지 아주 그냥 명료하게 알고 있는 상태임에 틀림없었다. 테스트 껌이죠? TDD 호로록 해버리면 뚝딱인것이다. 마침 내 입사와 함께 2021 하반기 다노 프론트팀은 테크스펙과 TDD 적용하기 챌린지 중이었고 나는 뚝딱거리며 TDD를 시도하고 있었는데 종종 찜찜한 기분에 사로잡히고는 했다. 나의 테스트 케이스 자체가 틀려먹거나 빠진 케이스가 많았기 때문이다. 분명 테스트를 먼저 쓰고 개발을 시작했는데 결국엔 뒤늦게 너무나 많은 테스트를 고치고 추가하는 이게 최선인가? 이게 맞느냐고. 그렇다 나의 테스트 케이스는 상호 검증없이 부족한 한 사람의 뇌절만으로 작성된 테스트였던 것이다.
테크스펙 들어갑니다
개발 착수 전에 개발자가 작성하는 테크스펙은 일견 개발자에게 속한 개발 문서다. 테크스펙을 처음으로 시도했던 유닛은 테크스펙의 도입에 앞서 이를 주창한 팀장님과 당시 PM 간에 이에 대한 사전 논의가 있었다. 당시의 상황은 너무나 아름다워서 마침 개발해야 할 피처의 사이즈도 적당하고, 일정도 편-안 무-탈 하였으며 테크스펙 리뷰에 적극적으로 참여하는 유닛 멤버들의 협조로 인해 나는 마치 개쩌는 시계의 기름칠된 톱니바퀴가 된 것만 같은 기분이 들었다.
나 테크스펙 쓸 줄 아네...라는 섣부른 감상에 고양되어서 다음 유닛에 "이번에도 모두들 알아서, 어련히 테크스펙을 사랑하겠지" 라고 생각했다가 무참히 실망하고 말았는데. 이 문서에 어떤 내용을 기대하고 무엇을 리뷰해야할지 유닛멤버들에게 여전히 낯선 상황에서 충분한 사전 동의와 협조를 구하지 않고 문서만 던져놓으니 언젠가 우려했던 바빠죽겠는데 개발자가 쓴 개발 문서도 한 번 검토해주기 와 매우 닮은 상황이 되어버린것만 같았다.
그래서 이런 것을 쓰려고 합니다
두 번의 서로 다른 유닛과 테크스펙을 체험했다. 올해도 역시나 시행착오를 겪으며 테크스펙 길들이기를 이어나가겠지만, 지난 경험과 고민으로 조금이나마 정리해본 내용을 써보자면 아래와 같다.
의도한 바와 이해한 바
개발자는 기획자의 기획 의도를 자체를 구현하지 않는다, 결국은 개발자가 이해한 바를 구현한다. 꼼꼼하고 충분한 디테일로 채워진 기획 문서도 개발자의 작업 의도를 보장하지 않으므로 테크스펙은 기획 의도와 개발자의 작업 의도 사이의 간극을 확인하고 이를 최소화 하기 위한 장이다. 기획자가 원하는 것을 개발자가 어떻게 이해했는지 명시하고 결과적으로 무엇을 구현할지 정의하며 재확인한다. 이 과정은 차후에 개발 진행 혹은 QA 단계에서 분절되어 발생할 여러 번의 커뮤니케이션을 앞당겨 압축하기 위함이다.
인수 기준은 곧 테스트 케이스
문서의 피드백을 통해 합치된 기획 의도와 작업 계획은 테스트를 통해 개발 단계에서 보장하자. TDD의 효용과 의미는 반쪽짜리 개발 방법론 대신 유닛 차원의 생산성을 위한 도구가 될 수 있다.
동료들에게 충분히 협조를 구하자
이 문서의 작성 과정에서 무엇을 얻으려 하는지. 어떤 목적과 목표로 이 문서를 도입하고자 하는지. 유닛의 구성원들에게 무엇을 필요로 하고 어떤 피드백을 원하는지.
PLUS!
스타트업 각개전투중인 바쁘다 바빠 서로에게 부담스러운 코드 리뷰의 고통을 줄여보자. 서로 맥락을 알지 못하는 거대한 양의 코드를 훗날 들이밀기 전에 Plan에 작성한 의사코드, 구조 설계 등을 통해 개발 착수 전 리뷰, 피드백을 얻을 수 있다.
- 내가 무엇을 어떤 구조로 어떻게 할 것이지 함 보아라
- 이 로직 혹은 이 요청을 어디서 수행할 것이며 왜 할 것인지 보아라
끝
테크스펙을 더 잘 쓰고 싶었고, 유닛 단위의 업무에 있어 꼭 필요한 단계 혹은 생산성에 도움이 되는 작업 단위로 인식시키고 협조를 얻고 싶었기 때문에 능동적으로 선택한 주제가 분명함에도 불구하고, 개발자로서 선택지에 좀 더 기술적인 주제가 없었다는 점에서는 비겁한 기분이 든다. 다음에 또 다시 이런 기회가 온다면 보다 기술적인 주제로 발표를 하고 싶다는 생각이 드는 게 아쉬우니까 올해는 구체적이고 기술적인 고민을 좀 더 해보자구.
그치만 벌써 2월이고 넘나 무사와..
자고 일어나면 12월이 되지 않도록 주의하기 ^^7!
