개발자가 기획하고 PM이 개발해요
'타인의삶' 스터디를 하며 배운 것
01. '타인의삶'의 시작
동명의 영화도 있습니다. 영화는 5년 간의 정보요원의 삶을 그리고, 우리 팀의 '타인의삶'은 5주 간의 직무 교환기를 그렸습니다. 사내 스터디 '타인의삶'은 개발자 8명, PM 5명, 디자이너 2명이 함께 시작했습니다. 개발자와 비개발 직군의 팀원이 짝꿍이 되어, 개발자가 기획 및 디자인을 진행하고 상대 직군이 웹개발 기초 강의를 수강한 후 직접 웹사이트를 개발했습니다.
IT 코딩 교육 회사답게, 자사 강의를 수강했습니다.
(참고) 수강한 강의 : http://bit.ly/3S8Vy3j
저에게 '개발자와의 협업'은 업무에 필요한 역량 뿐만 아니라 도메인 지식으로써의 의미도 있었습니다. 협업 및 자기계발을 위해 기초 코딩 강의를 찾으러 오신 비개발 직군의 고객들을 이해하는 토대가 되기 때문입니다. 이번이 기회다, 싶어 저도 바로 신청했습니다.
02. 5주 간의 우여곡절
첫 3주 가량 개발자가 기획을 하는 동안 저를 포함한 PM들은 점심시간을 쪼개 웹개발 강의를 수강했습니다. 바로 시작하면 되는 줄 알았는데 아뿔싸! 개발환경 세팅이 코딩 공부의 장벽이 될 수 있다는 사실을 깨닫기도 했습니다. 구글링, GPT, 개발자 짝꿍과의 질문 타임을 활용해 장난감 삽으로 흙 파듯 아주 조금씩 '알 것 같다'라는 느낌을 받으며 나름의 재미를 느꼈습니다.
아, '서로'의 삶을 체험하며 배우는 스터디이기 때문에 저도 가르쳐드린 것이 있습니다. 한 데 모여 개발자들께서 각자의 기획안을 공유하고 질의응답하는 세션이 있었는데, 그 세션 전에 기획안 설득에 대한 나름의 팁을 드렸습니다. 인터뷰, 로그 데이터, ABT 설계 계획 등으로 기획안에 대한 근거를 보충해나가는 방법부터 의외로(?) 기획서 작성하는 방법을 흥미롭게 들어주셨습니다.
저희 조는 타자 속도 측정 페이지를 만들었습니다. 입사날에 받는 코드북 속 인재상 관련 문장을 보기 문장으로 제시해, 신규 입사자 분들의 온보딩에 재미를 더해보자는 게 기획 목적이었습니다.
급하게 만든 타자 속도 측정 페이지의 진입 화면{이름, 팀명}의 조합으로 사용자를 구분하고, 사용자별 인재상 5개 문장에 대한 타자 입력 평균 속도를 측정하는 것이 주요 개발 사항이었습니다. 참고로 평균 속도가 300타 미만이면 "불명예 전당"에 올리는 무시무시한 기획사항도 반영했습니다.
우여곡절 끝에 스터디원들 앞에서 '그거, 기능이에요'를 기어코 말하며 결과물 시연을 진행했습니다. 문장을 따라 입력함에 따라 실시간으로 올라가는 정확도와 속도를 보며 뿌듯해하던 중 "일부러 오타 내봐요!"라는 실시간 Test Case 제시도 있었습니다. 내부 시연은 잘 마쳤는데 전사 구성원을 대상으로 시연을 진행하자마자 '이거 어디서 나온 거야!' 싶은 오류가 터져 나왔습니다.
"열심히 쳤는데 타자 속도 1 나와서 불명예 전당에 등록되었어요..ㅋㅋㅋ"
"저 타자 속도 무한대 나왔습니다.. infinite 떴어요!!"
저 오류를 해결하려고 ChatGPT를 괴롭히다가, 혹시 옆에 개발자가 있다면 개발자의 조언을 구하기를 권장한다는 답변을 받았답니다. 그 답변을 들고 개발자 짝꿍을 찾아가니, 너털웃음을 지으시며 적극적으로 도와주셨습니다. (아 다행이다)
03. 그리고 배운 것
부담과 체면을 내려놓고 솔직한 마음으로 회고해보면, 스터디를 통해 '개발을 아주 잘 알게 되었다'라고 말하기는 어렵습니다. 분명히 알게 된 것은 개발 자체보다는 개발자의 일하는 방식이었습니다.
첫째, MUST 기능을 정의하자
제가 만든 페이지는 2개 (도전자 정보 입력, 타자 타이핑 및 속도 측정) 였습니다. "스파르타 타자대회"라는 프로그램 이름에서도 알 수 있듯이 가장 중요한 기능은 타자를 입력 받고 속도를 측정하는 것이었습니다. 즉 2번째 페이지가 훨씬 중요했죠. 그런데 저는 도전자 정보 입력 페이지부터 만드느라, 핵심 기능을 만들때 즈음에는 이미 개발 시간의 60% 이상을 사용한 후였습니다. 순서만 생각했지 우선순위를 충분히 고려하지 못했던 것이지요. 타자 속도 측정 페이지를 만들 시간이 턱없이 부족해 뒷 주차에 진땀이 났습니다.
어떤 것이 가장 중요한 기능인지 생각하고, 그걸 기준으로 제작 일정 협의를 제안했다면 도전자 정보 입력 페이지의 개발 스콥을 줄일 수 있었을 것입니다. 어쩌면 페이지 자체를 생략했을 수도 있고요. 그래도 기획서에 작성된 핵심 경험 (인재상 문구를 따라 입력하며 자연스럽고 재미있게 팀 문화를 익힌다) 을 만드는 데에는 유의미한 차이가 없었을 것입니다.
이걸 깨달았던 순간이 PM으로서 이 스터디에 참여한 것이 참 뿌듯했던 Aha 모먼트였습니다. 기획서를 작성할 때 머릿 속으로라도 MUST와 Nice to Have 기능을 구분해, 우선순위에 따른 정보 배열을 시도하는 아주 중요한 계기가 되었습니다.
둘째, 협업 문서는 협업이 이루어지는 공간에 두자
저희 팀은 기획서와 같은 업무 문서를 주로 Notion에 작성합니다. 그래서 FE 개발 요청시에 Figma에서 UI 요청사항 확인, Notion에서 상세 로직 확인이 가능하시게 PRD를 작성합니다. 이번에 개발하면서 뼈저리게 느꼈습니다. 기획 문서 나름의 체계에 대해 PM은 잘 알 수 밖에 없지만 그걸 읽는 사람, 그러니까 개발자는 낯설게 느낄 수도 있다는 사실을요! 이미지 추출이나 화면 변화에 대한 요청 사항을 Figma에서 확인하다보니 Notion까지 띄워두고 기획서를 확인하기가 꽤나 번거로운 일이었습니다.
UI 변경사항이 많은 프로젝트를 진행할 때 한 FE 개발자께 "화면별 요청사항이 많아서 Figma에 PRD 옮겨두려고 하는데 괜찮으세요?"라고 여쭤본 적이 있습니다. 제 업무가 늘어날까봐 걱정해주시는 한편, 제안을 환영해주신 덕분에 Figma를 통해서만 개발요청사항을 전달드릴 수 있었습니다. 한 화면에서 모든 것을 확인하고 소통하니 협업이 더 수월했습니다.
작성 자체의 편리만 생각하면 Notion이 더 좋은 점도 분명히 있습니다. 하지만 결국 협업 문서는 말 그대로 협업을 잘 하기 위한 문서이기 때문에, 협업 대상이 더 쉽게 찾을 수 있는 곳에 위치시키는 것이 효율적이겠다는 배움을 얻었습니다.
셋째, 프롬프트 엔지니어링은 흥미로운 분야다
기본 코드의 뼈대는 모두 ChatGPT가 작성하도록 하고 저는 필요한 부분만 조금씩 수정했습니다.
ChatGPT야 괴롭혀서 미안해예시 링크를 첨부하고, 이 페이지에서 반드시 되어야만 하는 기능을 분명하게 짚고, 영어로 물어보니 GPT의 대답이 점점 더 구체적으로 변했습니다. 신규 입사자께 제품 히스토리를 알려드리며 의견을 구하는 듯한 느낌도 들었습니다.
사람이 하는 자연어를 풍부하게 입력함에 따라 컴퓨터가 더 똑똑해지는 모습을 목도하고 있자니 여러 생각이 들었습니다. 그 중 IT로의 진입 장벽이 더 낮아지고 있다는 희망이 가장 압도적으로 느껴졌습니다. 프로그래밍을 쉽고 재미있게 배울 수 있는 기회가 예전에 비해 더 많아졌지만, 자연어보다 익숙한 수단이 될 날은 아마 오지 않을 것 같습니다. 그래서 자연어로 소프트웨어와 소통할 수 있을지도 모른다는 가능성이 참 반가웠습니다. 더 많은 사람이 현실 세계보다 제약이 적은 IT 세계에서 더 자유롭게 많은 것을 시도해볼 수 있을테니까요.
GPT-4에서는 이미지 첨부도 가능하다 하고 주변에서는 ChatGPT 음성 인식을 통해 영어회화 공부를 한다는 사례도 종종 들립니다. 야무지게 활용하는 방법을 배워봐야겠다는 생각이 듭니다.
만들어낸 결과물이 결코 멋지지도, 많은 기능을 담고 있지도 않지만 그 과정은 꽤나 근사한 기억으로 남을 것 같습니다. 뭐든 처음 배울 때에는 '일단 끝내고 보는' 완주가 중요하다는 것도 새삼 느낍니다.
