by
May 01. 2023
늦은 회고록-1
이미 늦어버린 1분기 회고와 4월 회고에 대한 기록
인트로
회고가 많이 늦었다. 스스로 합리화를 하면 플랫폼 리뉴얼 QA, 외주 기획 및 개발 PM, 포트폴리오 정리, 인터뷰 등 많은 일이 있었기 때문이다.
사실은 의지가 부족했던 것이 맞다. 애당초 노션에 일상회고 DB를 구성할 때 목표는 주간 회고를 짤막한 문장 단위로 분리하여 애자일하게 작성하고, 월간/분기 회고는 이 문장들을 조합하여 살을 붙이는 정도로 마무리하는 것이었으니까. 근데 주간회고부터 놓치니 그대로 스노우볼이 되어버렸다.
오늘 회고를 작성하는 이유는 오늘을 기점으로 다시 회고에 대한 프로세스와 심적 정비를 하고 하반기 목표의 미세 조정을 진행하기 위해서다. 즉, 일종의 의식인 셈.
따라서 이번 글은 이미 늦어버린 1분기 회고와 4월 회고에 대한 기록이다.
플랫폼 리뉴얼 프로젝트 클로징, 정식 오픈
나를 폭풍 성장하게 해 준 프로젝트플랫폼 리뉴얼 프로젝트는 기존 서버리스 형태로 구축된 플랫폼의 레거시와 백로그를 정리하고, 리액트와 스프링 언어를 사용하여 정책부터 개발까지 A to Z 리뉴얼을 진행한 프로젝트였다.
작년 6월쯤부터 본격적으로 착수한 것이 올해 3월 말에 종료됐으니 거의 9개월을 함께 했다. 내가 이 회사를 다닌 기간이 20개월이면 그중 45%를 함께한 격. 너무 몰아치듯이 프로젝트가 진행되어서 그런지 막상 리뉴얼 버전 서비스가 오픈할 때 실감이 잘 나지 않았다. (3명의 기획자가 함께 시작한 프로젝트의 끝에는 나 혼자만 남아있었다는 슬픈 이야기)
배운 것이 정말 많은 프로젝트였다. 모든 프로젝트를 진행할 때 레슨런이 있긴 하지만, 특히 내 기획 스타일의 방향을 잡거나, 여러 기획과 IT 지식을 빠르게 흡수할 수 있도록 큰 도움을 준 프로젝트라고 생각한다.
이 프로젝트를 진행하며 아래의 경험을 할 수 있었다:
1. 어떻게 고객들의 요구사항을 듣고, 정리할 것인가?
의견 취합 사이클- 외부 고객이 보는 프론트도 중요했지만, 이번 프로젝트에서 가장 집중해서 해결해야 했던 것은 내부 고객들의 업무 프로세스 개선과 시스템화였다.
- 이 때문에 시스템에 얹어지지 못하고 파편화되어 버린 수많은 업무들을 어떻게 파악하고, 분석하고, 표준화할 것인지에 집중했다.
- 이 과정 속에서 이해관계자들과 어떻게 협의하고 대화할지, 어떤 것을 시스템화 하고 어떤 것을 원칙을 세워 사람이 풀어나가게 할 것인지 기초적인 노하우를 배웠다.
의견 취합은 스프레드시트로 진행했다.2. 서비스 정책서를 어떻게 작성할 것인가?
- 처음에 서비스 정책서를 작성할 때는 순도 100%의 '운영 정책서'였다. 개발자가 보기에는 개발을 어떻게 할지 무한정 상상의 나래를 펼치게 만드는.. 그런 매뉴얼이었다. 사실 개발자 출신의 CPO님께서 요구하던 정책서는 더 친개발적인 것이었다.
- 정책서를 처음 작성하던 시기가 22년도 7월쯤이었는데, 이때는 백엔드 기획에 대한 개념이 전무했다. 그러니 CPO님이 말했던 '어떤 속성을 관리할 것인지 생각하라'는 말의 의미를 이해하는데 시간이 걸렸던 것 같다.
- 이 의미는 그들의 업무 중 어떤 항목을 데이터 단위로 관리를 할 것이냐라는 뜻이었다. 속성은 RDB를 모델링할 때 릴레이션 안에 들어갈 속성(컬럼, 필드)을 의미하는 것이었고, 결국 데이터 처리를 위한 정책서를 만들라는 의미였다.
- 이 과정 속에서 DB에서 어떤 데이터를 왜 관리할 것인지 정의하는 능력과 이를 문서로서 정리할 수 있는 능력을 기룰 수 있었다. 정규화, 비정규화를 통해 스키마를 설계하는 것은 백엔드 개발자의 몫이지만, 어떤 데이터를 왜 관리해야 하는지는 기획자 혹은 PM이 정의 내릴 수 있어야 한다고 생각한다. 덕분에 지금은 ERD를 놓고 개발자와 얘기하는 것이 자연스럽다.
3. 화면을 어떻게 설계할 것인가?
- 외부 고객(회원)이 보게 될 프론트 화면의 경우에는 타깃의 나이, 성격, 목적에 맞도록 설계하려고 애썼다. 그럼에도 불구하고 디테일을 챙기지 못한 부분이 더러 나와서 아쉬웠다.
- 이는 페르소나를 보다 명확하게 하지 못한 것도 있지만, 3명이서 시작한 프로젝트의 기획자가 중도에 바뀌기도 하고 나가기도 하며 프로젝트의 볼륨이 혼자 내지 둘이 담당하기에 버겁도록 커졌기 때문이라고 생각한다. 플랫폼에서 모듈화 한 것이 크게 '회원, 멤버십, 마케팅, 데이터제공, 결제, 공통' 정도였는데 이 모든 내용을 커버해야 했으니 말이다. 첫 번째는 능력부족, 두 번째는 인력부족이 디테일이 떨어진 것들의 원인이 아닐까.
- 내부 고객(실무자)이 보는 백오피스의 경우에는 '업무 프로세스에 해당하는 데이터 처리가 자연스러워야 하는 것'과 '그들이 원하는 데이터를 한눈에 쉽게 보는 것' 두 개를 핵심 목표로 설정하고 화면을 설계했다.
- 아쉬웠던 것은 개발 공수를 줄이기 위해 프론트에서 사용한 이쁜 컴포넌트를 백오피스에서 그대로 사용하는 것을 고려해 화면 설계를 하다 보니, 많은 양의 데이터들이 한눈에 들어오지 않는 영역이 부분 존재했다는 것이다.
- 그리고 프로토타입과 함께한 실무자 리뷰 시, 미처 그들로부터 끌어내지 못한 숨겨져 있던 몇몇 업무들이 등장했다. 이는 그들에게 내용과 프로세스에 대해 확실히 싱크를 맞출 수 있도록 내용을 공유 및 푸시하지 못한 것이 원인이 아닐까 생각한다.
- 이 과정 속에서 가장 확실하게 숙련된 것은 두 가지인데, 하나는 피그마다. 프로젝트를 진행하며 Auto Layout과 Component의 제작, 활용에는 도가 터버렸다. 피그마에서 저 두 기능을 알면 생산성이 엄청 올라가게 된다. 이는 나중에 따로 영상을 찍어서 올려볼까 싶다. 그리고 재밌는 것은, HTML, CSS의 원리를 함께 이해할 수 있다는 사실! 그래서 10월에는 고향에서 바를 운영하는 친구의 모바일 웹 메뉴판을 리액트로 만들어주기도 했다.
- 그리고 남은 하나는 RDB, ERD 등 데이터와 데이터 처리에 대한 이해다. 최초에는 부족한 이해를 메꾸기 위해 생활코딩 등에서 공부하기도 했는데, 실무에서 백엔드 개발자와 보다 많이 소통하며 그들의 업무에 익숙해질 수 있었다.
- 예를 들어 "로이님, 멤버십을 구독한 후에 즉시 변경하게 되면 어떻게 되어야 하나요?"라는 질문을 받으면, "기존 멤버십 레코드의 OO 속성을 OO로 업데이트하고, 새로운 레코드를 인서트 해야 해요. 멤버십 변경 시 OO테이블에도 OO작업을 해줘야 합니다."와 같은 대답이 술술 나왔다. 이 기간 동안에는 데이터 테이블을 머릿속에 집어넣고 살았던 것 같다.
- 또한 UX/UI에 대한 레퍼런스를 찾고 연구하며 지식을 평소보다 많이 공부하고 쌓을 수 있었으며 개발자들을 위한 좋은 Description 작성 스타일을 고민할 수 있었다.
많다.4. 프로젝트 관리와 QA는 어떻게 할 것인가?
- 프로젝트 관리는 CPO님과 함께 진행했다. CPO님이 개발자들의 마일스톤을 관리했고, 나는 개발자들과 피드백을 즉각적으로 주고받으며 개발에 몰입할 수 있는 환경을 만들기 위해 노력했다.
- 리뉴얼 프로젝트를 할 때 아쉬웠던 점은 QA가 없었다는 것이었다. 작년 12월 말쯤 기존 QA분이 퇴사를 하셨는데, 이미 개발을 진행하고 QA를 앞두고 있던 상황이어서 새로운 QA를 채용해 기획서를 팔로업 시키고, 테스트 시나리오 등을 작성할 수 있도록 서포트할 자신과 시간이 없어 QA 채용을 진행하지 않았다.
- 그래서 결국 QA를 올 초까지 남아계시던 기획자 분과 나 둘이서 진행을 할 수밖에 없었다. 다행이었던 것은 백엔드 기획을 하며 데이터 모델 설계단부터 관여했기 때문에, 모든 모듈의 기능들이 동작할 때 처리되어야 하는 데이터 흐름이 머릿속에 있었다는 것이다. A 릴레이션의 상태값이 업데이트되면 B, C 릴레이션에 데이터가 어떤 값을 가지고 인서트 되어야 하는지 등을 예시로 들 수 있다.
- 이 과정을 겪으며 공수 산정에 대한 생각을 정리할 수 있었는데, (직접 개발자들에게 업무별 데드라인을 부여하지는 않았지만) 공수를 산정할 때는 룸을 충분히 확보해 둬야 함을 배울 수 있었다. 기존 플랫폼의 유지보수, 급한 건들의 개발 요청 등 예상치 못한 변수들이 끼어들 수 있기 때문이다. 특히 기획단부터 새로운 업무가 끼어들게 되면 기획에서는 하루 밀린 일정이 개발 쪽에서는 3일 정도 밀리게 되는 경험을 했다. 룸을 확보하자, 어떻게든.
이 외 올해 상반기에 진행한 프로젝트가 몇 개 더 있지만, 이 또한 볼륨이 크기 때문에, 이후 브런치에서 프로젝트 단위의 회고 형태로 글을 따로 발행할 생각이다.
이번 회고 글에서 프로젝트에 대한 내용은 여기까지!
포트폴리오 정리 완료
일종의 체크포인트를 만들고자 설정한 목표였다. 목표의 기간은 올해 1분기 내로 완성하는 것이었고, 중간에 어떤 계기가 있어 예상보다 2주 정도 빠르게 완성할 수 있었다.
노션 개인페이지, '다락'의 목적목표 대시보드포트폴리오를 정리하는 것은 일종의 임시저장이라고 생각한다. OKR을 원활하게 진행하기 위해 중간중간 업무에 대한 체크인 시간을 가지듯이, 전사적으로 같은 비전을 공유하기 위해 얼라이먼트를 위한 시간을 가지듯이, 내가 설정한 방향에 맞춰 길을 잘 걸어가고 있는지 되돌아보는 시간이기도 하다.
이번 포트폴리오 정리를 통해 내가 어떤 업무와 프로젝트를 진행했고, 어떤 레슨런을 가졌는지를 정리할 수 있어서 좋았다. 겸사겸사 혹시 모를 상황(?)을 대비할 수 있기도 했고. 사진은 PDF로 따로 만든 포트폴리오인데, 개인적으로 커피챗을 가지거나 보고 싶다고 하는 분들께만 전달하는 용도의 포폴이다. 오픈 포트폴리오는 노션에 만들어놨다.
블러 투성이 포트폴리오직무 인터뷰, 퍼블리 콘텐츠 제안 등 다양한 브런치 제안
브런치를 올해 2월 말쯤부터 운영을 했다. 이때 직무 회고와 ChatGPT에 대한 글들도 종종 올렸는데, 이들을 보고 재밌는 제안들이 많이 들어왔다.
기억에 남는 것은 3개인데, 하나는 PM 직무 준비생들을 위한 직무 인터뷰 영상 촬영이다. 이 또한 좋은 경험이었다고 생각한다. 나중에는 더 좋은 강연을 다니고 싶은 마음도 있고, 내가 어떤 생각을 하는지 정리할 수 있는 기회여서 뜻깊었다. 영상이 궁금하다면? ☞ Go and watch it
두 번째는 헤드라잇이라는 뉴스앱에서 작가 제안이 왔다. 콘텐츠 발행에 대한 규칙이 프리하기도 하고, 작가 분들이 모인 커뮤니티에 참여할 수 있는 기회라서 수락한 제안이었다. 하지만 아직 청자로서 앱을 자주 보지, 실제 콘텐츠는 많이 안 올리고 있다. 조만간은.. 올려야지..
세 번째는 현재도 진행 중인 건인데, 퍼블리 콘텐츠 연재 제안이 왔다. 주제는 ChatGPT를 활용하여 실무자들의 업무 자동화와 관련된 내용. 이전에 브런치에서 작성한 ChatGPT로 크롤러를 만들었던 주제를 보고 제안이 온 것이었다. 나도 겸사겸사 생각하던 효율적인 Prompt를 만드는 법에 대해서 정리할 수 있고, 이 또한 좋은 흔적이 될 것 같아 수락했다. 현재는 원고 수정 단계에 있다. 아마 5월 중에 콘텐츠를 발행할 수 있지 않을까? 콘텐츠의 주제는 누구나 쉽게 Python 설치 없이 ChatGPT를 활용하여 웹 및 API 크롤러를 만드는 것이다. 관심 가져주시면 아주 감사드리겠습니다.
항상 회고 글을 쓰다 보면 길어져서 두 파트로 나눈다. 오늘 말해보카에서 배운 문장이 떠오른다. "such a talker.". 나는 말이 너무 많은 사람이 맞는가 보다. (사실 듣는 것도 잘합니다.)
다음 글은 이번 주 내에 발행할 예정이다. 현재까지 회고를 해오던 방식에 대한 고찰과 어떻게 개선할지에 대해 가볍게 작성하고 늦은 회고를 마치고자 한다.
다들 즐거운 근로자의 날 되시길!
벌써 80일 연속 출석 중 