나는 팀원 총원이 5명인 초기 스타트업에서 일하고 있다. 2023년부터 이 회사에서 일하기 시작했으니, 이제 만 1년이 된 셈이다.

‘초기 스타트업’을 여러 관점에서 정의할 수 있지만 그 중 가장 핵심이 되는 특징을 꼽자면 아직 시장 반응이 검증된 프로덕트가 없다는 점일 것이다. 우리 회사의 이름을 사람들이 모르고, 우리가 만들고 있는 제품을 사람들이 모르고, 내가 1년 간 열심히 짠 코드가 하루 아침에 버려질 수도 있다는 뜻이다.

그래서 더더욱 기록의 필요성을 느낀다. 이 글을 통해 지난 1년 간 내가 이 팀에서 해온 일들에 대해 돌아보려 한다.

팀이 일하는 방식

1년 간 내가 무엇을 했는지를 말하려고 보니, 팀이 일하는 방식을 기술해야만 내가 무얼하며 1년을 보냈는지를 말할 수 있겠다는 생각이 들었다. 나는 다른 회사에서 개발자로 일해본 적이 없기 때문에 우리 팀의 업무 방식에 대한 메타 인지가 없다. 단지 내가 경험해온 것들을 기술해본다.

팀이 가진 특징 / 상황

일하는 방식을 소개하기에 앞서, 업무 방식의 기반이 되는 몇 가지 팀 특징(혹은 현실적 상황)이 있다.

첫번째, 기획자와 개발자의 명시적 구분을 지양한다.

개발자의 도메인/프로덕트 이해, 기획자의 개발 지식 이해를 장려한다. 도메인과 프로덕트에 대한 팀 전반의 이해도를 높이는데에 많은 시간을 쓴다. 기획자, 개발자라는 표현보다는 기획부와 구현부라는 표현을 주로 사용한다.

VoC 미팅에 직접 참여하기도 한다.

둘째, 개발자 총원이 두 명이다.

처음에 팀에 합류했을 땐 총 4명이었는데, 줄었다. 5월 중순부터 CTO님과 나 둘이서 일해왔다. CTO님은 10년차 개발자로, 내게는 사수님이기도 하다. 원래는 프론트엔드 개발자셨지만 여기선 백엔드와 인프라를 주로 맡고 계시다. 결과적으로 프론트엔드의 경우 대부분 내가 개발한다.

셋째, TestFlight를 통해 서비스를 사용 중인 실유저들이 있다.

이건 명확한 시장 신호가 없었음에도 불구하고 1년 간 동일한 프로덕트를 빌드해가고 있다는 사실에 대한 약간의 설명(혹은 변명…😇)인데

우리 팀은 현재 중소상인들을 위한 사업관리 솔루션을 개발하고 있다. 타투이스트, 주문제작 케이크, 네일 아티스트 등이 우리의 타깃이다. UT에서 서비스를 소개 받은 사업자 중 실제 자신의 사업을 우리 앱으로 관리하고 계신 분들이 있다. 이 분들을 통해 새로운 사업자를 소개 받기도 하고, 지속적인 UT를 통해 피드백과 인풋을 구하고 있다.

그래서 우리 팀이 일하는 방식

기본적으로 스프린트 단위로 작업을 진행한다. 순서대로 기술해보자면 이렇다.

1. 스프린트 주제가 정해진다.

   주제를 정하는 과정은 그때마다 달랐다. 팀 전체가 VoC를 바탕으로 주제의 후보를 도출해 투표했던 적도 있고, PO/PM님의 선두로 미리 결정된 적도 있었다.

2. 주제에 대한 그림을 각자 구체화한다. 이를 바탕으로 큼지막한 Todo를 작성한다. (팀 내에서는 이를 Imagined Todo라고 부른다.)

   이때부터는 기획부와 구현부에서 하는 일들이 달라진다.

   • 기획부 (PM, PO, 디자이너)
     • 도메인 지식을 바탕으로 스프린트 주제와 관련된 모든 유저 플로우를 정리한다.
     • 모든 유저 플로우를 포괄할 수 있는 일반화된 개념을 도출한다.
     • 각종 정책을 구체화한다.
   • 구현부 (개발자)
     • 스프린트 주제를 개발자의 관점으로 바라보고, 어떤 기능을 구현하게 될 지 나열해본다. 도메인 전반에 대한 이해도가 높기 때문에 명세 없이도 대략 어떤 기능들이 포함될지 상상할 수 있다.
     • 해당 기능들을 구현하기 위해 필요한 작업들을 파악한다. 필요 시 관련 라이브러리에 대한 스터디를 진행한다.

3. Todo를 구체화하고 하나씩 태클한다.

   백엔드와 디자인 작업이 완료될 때까지 기다릴 만한 버퍼가 없다. 따라서 프론트엔드 개발자인 나는 백엔드 개발자, 디자이너와 유기적으로 협업해가며 당장 작업을 시작한다.

   백엔드 명세 같은 건 없고, 각 화면에 어떤 데이터가 필요할지 먼저 리스트로 정리해 전달하기도 한다. Dto에 대해 백엔드와 논의한다. 화면의 경우 Low fidelity의 디자인 산출물을 바탕으로 개발을 시작한다. 보통은 와이어프레임 수준인데, 그것보다 더 낮은 fidelity의 산출물을 가지고 시작할 때도 있다.

   필요 시에는 데모라는 이름으로 UI 없이 기능의 동작만이 포함된 중간 구현물을 공유한다. 이 데모를 통해 UX 정책이 변경되거나 구체화되기도 한다.

4. QA를 진행하고 발견된 이슈들을 해결한다.
5. 필요 시 개발한 기능과 추후 스프린트 주제들에 대한 UT를 진행한다.

그래서 1년 간 무엇을 했는가

리스트업

총 15개의 스프린트를 했다. 그 중 내가 한 일들을 보다 구체적으로 나열해보면 다음과 같다.

• 기능별
  • 앱, 웹 채팅 기능 구현
  • 앱 캘린더 기능 구현
  • 웹 영어 번역 기능 구현
  • 알림 시스템 구축 (푸시 알림, 카카오 알림톡)
  • 그 외 숱한 기능 개선들
• 주제별
  • NextJS 마이그레이션
  • 에러 핸들링 시스템 구축 (관련 포스팅)
  • React Query 도입
  • Mixpanel 지표 개선
  • 웹페이지 성능 개션 (관련 포스팅)
  • 기존 코드 정복
    • 이제 나는 이 팀의 모든 레거시를 꿰고 있다고 확신할 수 있다
    • 앱, 웹, 백엔드까지...
  • API 관련 소통 방식 개선
  • 비개발자 팀원들 대상 "데이터 관점 키우기" 세션 진행
  • Node 스크립트로 기기테스트 자동화하기

보통 개발 블로그에 올라오는 업무 회고들의 경우 최적화와 개선에 대한 내용이 대부분인 것 같은데, 나는 아무래도 하나의 기능을 처음부터 끝까지 개발하는 경우가 많았다.

가장 기억에 남는 세 가지

채팅 구현

비교적 최근이라 기억에 남는다. CTO님과 둘이 앱과 웹 채팅을 구현했다. 기억에 남는 이유는 더럽게 힘들었기 때문인데… 보통 기능 개발에는 크게 두 가지 요소가 있다고 생각한다. 목표 결과물과 이를 달성하기 위한 도구. 전자가 불명확하거나 후자에 대한 이해도가 낮을 경우 기능 개발의 난이도가 올라간다. 그리고 채팅 스프린트는 그 두 가지가 모두 해당됐다.

채팅을 개발할 당시에 팀에 디자이너가 없었다. 즉 채팅에 대한 구체적 명세가 없었다. 막연하게 카카오톡의 UX를 목표로 삼았지만 카카오톡 정도로 고도화된 서비스의 UX를 명문화해서 개발에 녹여내기란 여간 쉬운 일이 아니었다. 다른 한편 우리는 Socket.io를 활용해 채팅을 직접 구현했는데, 처음으로 http가 아닌 프로토콜(웹소켓)을 사용해보는 동시에 안정성이 중요한 시스템을 구축해야 한다는 점이 정말 어려웠다.

Socket.IO 의 공식문서를 처음부터 끝까지 모두 다봤다. Socket.IO 자체도 매우 고도화된 라이브러리였기 때문에, 이 라이브러리에서 정확히 무엇을 해주는건지, 무엇을 직접 구현해야 하는지 파악하는데 오랜 시간이 걸렸다.

또한 명세가 없는 상태에서 채팅 화면에서의 여러 가지 상태를 직접 정의하는 것도 어려웠다. 연결 상태, 각 메시지의 발송 상태, 여러 상태 간의 위계 등등…

적다보니 너무 길어져서 이 내용은 기회가 되면 별도의 포스팅으로 적어보겠다

UX 개선을 통한 Mixpanel 지표 개선

개발적으로 크게 유의미한 건 아니지만 Mixpanel을 실제로 사용해본 게 재밌었다. Mixpanel은 늘 마음 한 켠에 짐처럼 들고 다니던 주제였다. 필요성은 인지하고 있었으나 늘 기능 구현에 우선순위가 밀렸었다. 어떤 지표를 추적할지 논의해 코드에 직접 추가하고, 관리하고 트래킹하는 게 여간 번거로운 일이 아니었기 때문이다.

하지만 UX 개선 스프린트의 킥오프 때 문득… 지표 없는 막연한 UX 개선에 신물이 나서 지표 트래킹의 필요성을 강력 주장 했었다.

스프린트가 종료된 후에 우리끼리 수고했다 짝짝짝~ 하고 끝나는 게 아니라 실제 데이터로 개선 효과를 확인할 수 있었던 점이 뿌듯했다.

Mixpanel 들어가보지 않은지 꽤 됐는데 ☺️… 내일 출근하면 다시 들어가봐야겠다.

에러 핸들링 시스템 구축

6개월차 주니어 혼자 에러 핸들링 시스템 구축하기

이 주제에 대해서는 이미 작성해놓은 글을 첨부한다.

가장 많이 성장한 점

가장 많이 달라진 점을 꼽자면 개발에 대한 겁이 많이 사라졌다는 점인 것 같다.

이 팀에서 일하는 방식을 한 문장으로 정리하자면 '큰 자유와 큰 책임'이라고 정리할 수 있다. 위에서도 언급했지만, 개발자가 나와 CTO님 두 명 뿐이다. 오늘 어렵다고 포기해봤자 내일의 내가 해내야 한다… 고로 미룰 수도 회피할 수도 없다. 이런 1년을 보내면서 무엇이든 만들어낼 수는 있다는 믿음이 꽤 강해진 것 같다.

라이브러리 공식문서들을 많이 본 게 큰 도움이 됐다. 기존의 나는 개발을 할 때 온갖 블로그들을 무지성으로 구글링하는 스타일이었다. CTO님 옆에 있으면서 공식 문서만으로 라이브러리의 핵심을 파악하는 능력이 많이 길러진 것 같다. 정해진 시일 내에 빠르게 개발해야 하는 환경이다 보니 당면한 문제 해결을 목표로 빠르게 학습하는 자세가 몸에 익었다.

라이브러리의 실제 코드를 뜯어보는 경험도 큰 도움이 됐다. 공식문서에서 제공하는 사용법으로 문제를 해결할 수 없을 때, 사용법은 나와있으나 해당 방법이 내가 바라는 바를 완벽히 해결하는지에 대한 확신이 없을 때 일일히 코드를 뜯어봤다. 큰 라이브러리가 어떤 식으로 구현되어 있는지를 보는 게 흥미로웠다. 무엇보다 API로 공개되어 있는 것보다 로우 레벨의 라이브러리 코드를 조합해서 내가 원하는 걸 빠르게 구현했을 때 무척 재밌었다. 약간 금기를 깨고 정복한 느낌(?) ㅋㅋㅋ 많은 사람들이 사용하는 라이브러리도 결국 자바스크립트로 작성됐다는 점을 직접 확인했던 게 막연한 두려움을 없애주었다.

---

개발 외적으로는 마무리 짓는 능력이 늘었다. 큰 목표를 달성하기 위해서는 중간 지점을 잘 설정해야 한다. 각 중간 지점을 잘 기록하고 잘 갈무리해야 한다.

중간 중간 진척 상태를 기록하고 공유하는 습관을 들였다. 중간에 멈춰 나의 좌표를 기록하는 일은 여러모로 효용이 크다. 첫째로, 잘 기록해두면 한 번에 다 끝내지 못했더라도 나중에 이어서 할 수 있다. 마감에 맞춰 날림으로 작업한 걸 나중에 고치는 일만큼 고역인 일이 없다. 둘째로, 나와 협업하는 사람들의 가시성을 확보해준다. 이는 팀의 리소스를 효과적으로 사용하는데에 도움이 된다. 셋째로, 도움을 요청하기가 쉬워진다. 혼자서 정신없이 작업하다 보면, 문제를 맞닥뜨리더라도 도움을 요청하기가 어렵다. 나도 내가 무얼 해왔는지 정리가 되지 않기 때문에 타인에게 설명할 수가 없다.

더 많은 사람들과 더 큰 일을 해내기 위한 방법을 배웠다고 생각한다.

---

머릿속 생각을 논리적 틀에 맞춰 정리하고, 이를 명문화하는 능력도 많이 늘은 것 같다. “아 우리 앱 출시하긴 불안한데…” 라는 막연한 감을 아래 같은 문서와 프로젝트로 디벨롭하는 능력 같은 것.

나의 작업을 시간 단위로 예측하는 능력도 많이 늘었다.

아쉬웠던 점 / 마무리

더 나은 방법에 대해 고민할 시간이 없었다는 게 가장 아쉽다. 할 줄 아는 대로 개발한 느낌이랄까? 멈춰서서 고민할 여유가 있었다면 팀이 더 빠르게 많은 것들을 개발할 수 있지 않았을까 싶다. 원래 하던 걸 열심히 하는 건 상대적으로 쉽다. 더 나은 방법을 고안해 시스템화하는 게 어렵지.

나 개인적으로는 또래 개발자들과 소통하지 못했다는 점, 회사 밖에서 개발 공부를 하지 않았다는 점이 아쉽다. 회사에 너무 많은 시간을 있다보니 회사 밖에선 개발 관련된 걸 하기가 싫었다. 여름까지 사이드 프로젝트 동아리를 하긴 했지만 퇴근 후 남는 리소스로 개발하려다 보니 크게 실력 향상에 도움이 되진 않았다. 직접 부딪쳐볼 때 가장 실력이 는다고 하지만, 실력의 벽을 넘기 위해서는 책을 읽는 공부가 반드시 필요한 것 같다.

회사를 무척 좋아했고, 그래서 열심히 일했지만 마지막엔 조금 힘이 빠진 한 해였다. 창업으로 성공하는 게 대표님의 꿈이지 나의 꿈은 아니라는 걸 깨달아버렸기 때문이다. 지금 회사에서 개발자로 일하는 것이 전형적인 개발자와는 다소 거리가 멀겠다는 생각이 든다. 자고로 개발자라면 더 크고 연봉 높은 회사의 개발자로 이직하는 것이 목표여야 할텐데, 내가 그 삶을 원하는지 아직까지 잘 모르겠다. 직업에서 원하는 바를 찾겠다는 게 욕심이라는 생각을 하면서도 작년에 즐겁게 일했던 시간들이 그 희망을 놓지 못하게 만드는 것 같다.

우리 팀이 믿는 개발 철학의 핵심은 개발은 도구일 뿐이다 라는 문장인데, 이 도구를 수준높게 사용하는 사람이 되기 위해선 역설적으로 개발을 도구보다 대단한 무언가로 여기는 마음이 필요한 것 같다. 개발 자체를 좋아하든, 무지와 뒤쳐짐에 대한 불안을 느껴서 공부를 지속하든.. 전자에는 해당되지 않고 후자에서는 벗어난 나는 어떤 원동력으로 실력을 향상시켜야할까? 잘 모르겠다.

다소 울적해져버린 회고를 일단은 이렇게 마무리 해본다 ㅎㅎ (왜냐면 7시간 뒤에 일어나야 함)