개발이 다시 재밌어진 이유와 근황 (feat. 스타트업 제품 개발)

사진출처: https://parkhyojungstudio.tistory.com/23

재작년에 바카티오 창업팀에 있을 때부터, 중요한 글을 쓸 때마다 GABBY’S COFFEE에 오곤 했다. 자전거를 타고 원하는 카페를 가는 것은 서울에 자취하기 시작했을 때부터 스스로에게 주도성의 상징이 되어주었다. 무기력할 때, 막막할 때, 바쁠 때 내가 늘 오던 그리고 무언가 해결되었던 그 카페들에 가면 마음이 항상 정돈되었다.

서론이 길었다. 즉, 오늘도 중요한 글을 쓰는 날이라는 것이다! 써야 한다고 미뤄오던 글인데 이제 쓰는 것이 참 … 😤

어떤 글인가요?

올해 여름부터 DATAIZE 팀에 합류하여 일하기 시작했다. 6월 중순에 이력서를 보내 커피챗을 하고 6월말부터 본격적인 업무가 시작되었다. 우리팀은 암/데이터 기술을 ‘연구하는 것’에 그동안 집중했지만 이제 제품을 만들기 시작했고 그 타이밍에 합류하게 되었다.

어쩌다보니 부족한 내가 제품개발의 전반적인 것부터 프론트엔드 개발의 모든 것을 생각해볼 수 있게 되었다. 이 글을 작성하여 얻고 싶은 것은 2가지다.

1. ‘업무 관점’에서의 회고: 새로운 환경, 더 넓은 권한을 갖고 개발하는 환경에서 느끼고 배운 것들을 정리하는 것.
2. ‘개발자 또는 인간 문지후 관점’에서의 회고: 일을 통해 성장하기 위해서는 어떻게 해야 하는가? 그리고 그 성장을 어떻게 팀의 발전에 녹여낼 것인가.

업무 관점에서의 회고

해당 부분은 작성하기 조심스러운 부분도 있다. 팀에서 공개하고 싶지 않은 부분까지 의도치 않게 담을 수 있기에. 맥락 설명이 부족해질 수는 있어도, 팀과 관련된 내용은 최대한 축소하여 작성하겠다.

⚡️ 그동안 해온 것들

제품 런칭을 앞두고 있다. 업무를 시작한 이후로 기능개발 공장처럼 일하였다. 스타트업 특성 상, 개발 외적으로 기여해야 할 부분이 있어서 더 정신이 없었다. 핵심 Feature는 4개 정도였지만, 그 4개 안에도 하위 기능이 최소 2개 이상씩 있으며, 그 안에 새로운 디자인 반영까지 해야 할일이 많았다.

하지만 내가 선택한 일이었다. 그동안 순수 구현의 경험 자체가 부족하다고 느낀 것이 내 갈증이고 스스로 생각한 약점이었다. 그랬기에 행복했다. 피그마 속 화면이 처음 실체가 되었을 때, 팀의 상상이 제품의 모습으로 완성되어갈 때의 그 순간들이 짜릿하고 즐거웠다.

⚙️ 어떻게 기여해야 하는가? 내 앞에 놓인 수많은 의사결정들

팀의 문화와 기여 방식에 대한 고민도 컸다. 미리캔버스에서 인턴을 하던 시절에는 이미 개발 인프라가 잘 갖춰져 있었지만 우리팀은 이제 막 그 뼈대를 구축하는 단계다. PR을 남기는 방식, 커밋의 단위 등 개발과 관련하여 내가 하는 사소한 행동도 팀의 정체성과 업무 방식에 큰 영향을 미칠 수 있다는 생각에 더 신중해졌다. 동시에 이에 대한 과도한 몰입으로 행동의 속도가 느려지는 것을 경계하기도 했다.

내가 합류하던 당시 실제 동작하는 모습으로 기능이 구현되어있지는 않았지만 전체적인 코드의 구조는 잡혀있었다. 하지만 웹 개발 경험이 적은 비개발자 팀원이 바이브코딩으로 진행한 방식이었다. 사실 그 짧은 시간 안에 이만큼까지 해내셨다는 것 자체도 대단하고 존경스러웠지만 한편으로는 리팩토링과 기술부채에 대한 우려도 컸다. 그리고 그 이슈들이 ‘현재 정말 우리팀에 필요한가?’에 부딪혔다. 기술과 개발도 결국 어떠한 목표를 달성하는 방식이기에, ‘치명적인가? 치명적이라면 그 기준은 무엇인가? 해결했을 때의 임팩트는 어떠한가? 더 중요한 이슈는 없을까?’와 관련된 의사결정의 늪에서 혼자 헤매곤 했다. 7월에는 재택, 8월부터는 세브란스 디지털헬스센터로 출퇴근하며 팀과 대면회의를 하는 일이 많아졌는데 이때 우리팀의 마일스톤, 비전 등의 큰그림에 대한 이해가 깊어지며 큰 부분이 해결되었다.

팀과 소통할 때, 사용하는 나만의 분류체계 또는 태스크의 층위는 다음과 같다.

(1) MVP에 포함되어야 하는 필수적인 기능인가

(2) 해당 기능의 핵심 특징을 해치는 이슈인가

→ (2-1) 치명적, 고치지 않으면 제품을 데모할 수 없는 이슈

→ (2-2) 치명적이진 않지만 UX, 즉 고객 경험이 불편해지는 이슈

(3) 동작의 문제는 없지만, 잠재적인 문제를 가진 이슈

(2)번과 (3)번은 모호한데, (3)번의 경우 잠재적인 문제의 가능성이 특정 버그로 드러나면 결국 바로 (2)번으로 분류되기 때문이다. 그럼에도 따로 나눠둔 이유는 대부분 DX 또는 유지보수와 관련이 높은 이슈들이기 때문이다. (3)번은 팀원들에게 더 자세한 설명과 설득이 필요하다. 제품을 집중적으로 개발하는 사람이 거의 나 혼자이기 때문에, 내 리소스를 어디에 쏟느냐가 팀의 타임라인과 직결된다. 더 세분화할 수는 있겠지만, 고객 검증이 중요한 시점에서 위의 분류는 유용하다!

🏃‍♀️ 효율적인 태스크 관리를 위해

효율적인 태스크 관리는 내가 생각하는 ‘좋은 개발자’의 역량 중 하나다. “무엇을” 하는지는 팀 단위에서 결정되고 또 하향식으로 전달될 수 있으나, 그것을 “어떻게” 하는지는 천차만별이다. 사수가 있으면 좋겠고, 배울 수 있는 좋은 동료 개발자를 원하는 것도 이때문이다.

기존에는 Confluence, Jira와 같은 툴을 사용하여 회사의 정해진 프레임워크를 따랐다. 우리팀은 특정 툴을 사용한 태스크 관리가 아직 도입되지 않았다. 초반에 노션을 제안하기도 했지만, 팀은 아직 프레임워크의 도입에 대해 조심스러운 입장이었다. 그 이유에 200% 공감했기에 존중하고 있다. 현 시점에서 어떤 툴을 도입하느냐가 팀의 문화 및 정체성을 결정할 수 있기에 이는 더 중요한 어젠다로 해결하기로 했다.

그래도 여전히 하나의 개발 태스크를 해결하며 고려해야 하는 것들이 복잡했다. 새로운 라이브러리에 대한 이해와 스터디도 필요하고, 특히! 가장 큰 문제는 TypeScript가 아닌 JavaScript를 쓰고 있기 때문에 … 데이터 타입에 대한 정의에 대한 문서화도 중요했다.

전체 태스크 관리는 팀이 원래 활용하던 방식대로 플랫폼 내에서 하고, 내 개인적으로 더 자세하게 작성해야 하는 내용들은 아래와 같이 관리하였다. 중요도, 관련 하위 이슈들, 세부 계획 및 마일스톤을 노션 데이터베이스 각 하위 페이지에 정리했다.

• 기능구현 / FIX / 미팅 등의 카테고리에 맞는 템플릿을 따로 활용하였다.
  • 예를 들어, 기능구현의 경우: 기존 로직 분석 / 세부계획 및 공수 산정 / 관련 이슈 메모
  • FIX의 경우: 재현조건 / 긴급도 / 관련 PR 링크 등의 항목으로 구성하였다.

이렇게 하니 몇 가지 문제가 있었다.

• 누적 및 기록 용도의 이슈들과 당장 처리해야 하는 것들이 제대로 구분되지 않았다.
• 팀 차원에서 공유되어야 하는 이슈들이 개인 노션에만 기록되었다.
• 관련된 PR 및 코드와의 연동이 불편하다.

DX를 강조하는 팀의 마음을 알 것 같다. 혼자서 할 때도 히스토리와 개발과 관련된 중요한 정보의 관리가 어려운데 … 효율적이면서도 체계적인 관리는 어떻게 해야 할까?

현재는 노션 대쉬보드를 다시 개편하여, 이슈 목록은 독립적인 데이터베이스로 분리하고, FE뿐만 아니라 다른 범위의 일들도 관리될 수 있도록 변경했다. 다만, 역시 이 방식 또한 팀과의 동기화 이슈가 있기에 … 앞으로 계속해서 고민해봐야 할 문제다.

개발자 관점에서의 회고

😆 개발이 재밌어요

사실 올해 초 인턴을 하며 잠깐 개인적인 개발 슬럼프가 왔었다. 부스트캠프에서 큰 욕심을 부리며 버텨오던 것이 무너지면서, 개발권태기(?)가 왔던 것이다. 내가 맡았던 모듈의 기본적인 개발이 생각보다 빨리 끝나며 방향을 잡지 못했던 것도 있었다. 코드리뷰 이후에는 재밌어졌는데, 그전까지는 “오늘은 00을 리팩토링해야지!” 이렇게 혼자만의 계획을 세우며… 늪에 빠졌다. 돌아보면 명확한 나의 잘못이다, 계획되어있던 리뷰보다 내가 더 능동적으로 빨리 요청했다면 어땠을까…

여튼! 그때와 달리 지금은 개발이 너무 재밌다. 먼저, 제품을 초기부터 만들어보니, 인턴 시절 입사할 때부터 이미 당연하게 있던 것들이 하나도 당연하지 않다. 취업준비를 하며 “해야 하니까, 다들 공부하니까”라는 작은 의무감에 공부했던 것들이 ‘필요해서’ 궁금해진다. 특정 경험을 통해 필요성을 느끼고, 궁금해지며 공부하는 개발이 얼마나 재밌는지 … 이런 고민들을 이야기 할 동료 개발자들이 없다는 것이 큰 아쉬움이다. 내가 지금의 지식 수준에서 부스트캠프로 다시 돌아가면 훨씬 더 재밌을 것 같다. 그때는 모르는 키워드가 너무 많아서 이해하는 데 훨씬 더 오랜 시간이 걸렸다면, 지금은 이제 배경을 이해할 수준이 되었고 … 나의 의견을 정리하는 과정 중에 있다고 느낀다. 명확한 의견을 내고, 나만의 기준을 찾고, 또 설득력 있게 논의하기 위해서는 약간의 시간만 더 있으면 될 것 같다.

⛳️ 일하며 성장하려면? 어떻게 학습해야 할까?

패키지 관리는 어떻게 해야 하지? 패키지의 호환성 이슈는 어떻게 해결해야 할까. 리팩토링은 어느 시점에 어느 수준으로 해야 할까. 좋은 디렉토리 구조는 무엇일가. 유지보수하기 좋은 코드는 무엇일까. 유용하게 사용하기 위해 버전의 히스토리 관리는 어떻게 해야 할까?

하루에 이러한 질문이 10개씩 쏟아진다.

문제는 이런 질문들 중 무엇을 어떻게 학습하고 적용할 것인가다. 기능구현↔퀄리티 사이에서의 균형도 문제지만, 개발↔학습 사이에서의 균형도 문제다. 이건 아무래도 개발자의 숙명같다. 부스트캠프 교육과정 중에도 모두의 핵심 문제는 다 이 사이의 균형을 잡는 것이었다.

도입한 방식은,

1. 그때그때 키워드는 자유롭게 리스팅
2. 이중 학습할 것들 선별
3. 학습 목적을 세분화 [참고용(인사이트) / 빠른 적용 / 흥미 / 문제해결]
4. 빠른 적용 → 문제해결 → 참고용(인사이트) → 흥미의 순으로 순차적으로 학습

이렇게 했을 때의 문제점은 … 정말 최최최소한의 기능개발을 위한 사전지식 위주로 공부하게 되고, 개발의 넓은 관점에서 고민해봐야 할 것들이 늘 후순위가 된다는 점이다.

예를 들어,

체계적인 에러 처리는 어떻게 해야 할까? 안전하게 undefined / null을 처리하려면 어떻게 해야 할까?

보다,

IndexedDB 특성 및 관련 api

이런 것들만 … 아주 빠르고 간략하게 공부하게 된다는 점이다.

(적절한 비유인지는 모르겠지만…) 이때문에 근본적인 성장을 한다는 느낌보다, 어떤 하나의 목표를 향해 올라가고 있다기보다 매일 짧게 런닝머신만 타는 느낌이다. 리스팅한 토픽 중에 더 넓은 관점에서의 학습을 하는 시간을 아예 fix해서 루틴화하거나, 다른 현직자 스터디를 통해 토론에 참여하는 방식으로 해결해야 할 것 같다.

런칭 이후에 실천해보자.

🧩 그때그때 메모한 무작위 레슨런

• 데이터 파싱하는 로직을 작성하다가, 하나의 간단한 책임을 가진 함수도 보기가 참 더럽다는 느낌을 받았다. 문득 loadsh가 생각나서 찾아봤는데 … 유레카, 이래서 쓰는구나 … 진짜 가독성도 2배
• 데이터를 다룰 때 생각보다 undefined나 null이 될 때가 많다. 당연히 있을 거라고 생각하고 접근하는 코드를 작성했다가, 예상치 못한 시점에 비어있어서 오류가 발생하고 디버깅한 경우가 많았다. cannot read undefined, map is not a function 등의 오류는 거의 10번 중 9번은 이런 경우였는데 … 이건 내가 팀에 설득하기 위해 정리하고 있는 “타입스크립트를 도입해야 하는 100가지 이유” ㅋㅋㅋㅋ 중 하나처럼, 스스로 정의한 형태가 꼬여서 그런 적도 있고 … 근본적으로는 안전하게 접근하는 코드 작성에 대한 능력도 부족한 것 같다. 옵셔널 체이닝을 마구잡이로 사용하는 것 말고, 더 구조적으로 해결할 수 있는 방법이 없을까.
• 특정 조건이나 액션을 했을 때 상태를 변경하는 것도 중요하지만, 특정의 상태들을 cleanup하는 것도 중요하다. 이때문에 어떤 액션을 했을 때, 어떤 상태들이 변경되어야 하는지 그 플로우를 그리는 능력이 중요한 것 같다. 예를 들어, agent 채팅이 끝나지도 않았는데, 채팅과 관련된 파일선택 내용을 바꾼다면? 작업하고 있는 프로젝트나 워크스페이스 자체를 바꾼다면?
• 에러/로딩 처리가 매우매우 중요하다. 그리고 하나의 액션에 따라 영향을 받는 범위나 방식이 달라진다. 이걸 깨달은 좋은 예시가 있었지만… 일단 팀의 로직에 관련된 내용이 있어서 생략 … 어쨌든 프론트엔드 개발자가 ‘비동기’를 잘 알아야 하는 이유가 다 있다 … 옛날부터 꿈꿔오던 Promise 직접 만들어보기 꼭 해봐야지
• 함수이름이나 변수명, 일관성을 클린 코드를 위해서만 생각했었는데 실전은 다르다. 일관성이 없으면 그 ‘다음’이 어렵다. 규칙이 없으니 같은 범위에서 새로운 기능을 하나 추가할 때 맞춰나갈 기준이 없어진다. 또한 그 위치를 찾기도, 예측하기도, 기억하기도 어렵다. 이래서 특히 디렉토리 구조까지 신경쓰게 된다. 의존성 방향같은 것을 신경쓰지 않으면 심지어는 디버깅도 어렵다. 데이터가 어디서 어디로 어떠한 흐름으로 바뀌는지 그 각각의 단계가 예측되지 않으니 콘솔에 찍혀도, 어느 시점에서 잘못된 건지 모를 뿐더러, 디버깅 도구에서 찾는다고 해도, 근본적인 해결책을 찾기 어렵다
• UX는 생각보다 어렵다. 무엇이 더 사용자에게 이로운지 판단이 안된다. 명확히 불편한 건 알겠는데, 만약에 a,b 데이터로 보여줄 수 있는 테이블이 있을 때 b의 응답에 오류가 나서 a만 보여줄 수 있다면, (1)아예 분석에 실패했다고 할지 (2) a만 보여줄지 (3) a보여주고 b에러에 대해 알려줄지 → 최대한 많은 정보가 좋을지 아니면 다음 행동을 유도할 수 있게 하는 게 좋을지 이런 것들 사이에서 고민이 많다. UX는 “나는 이럴 것 같은데?”라는 뇌피셜 접근보다, 이에 대해 더 많이 고민해본 개발자들, UI/UX 전문가들의 아티클과 서적을 많이 참고하는 것이 필수적임을 느꼈다.
• js의 falsy값 그리고 고유한 특성들을 모르면 의도치 않은 동작을 할 때 “아니 왜?” 하는 상황들이 많다. 이때문에 ?? 연산자에게 참 고맙고 … 타입스크립트가 그립고 그렇다. 다음 프로덕트부터는 스택을 내가 정할 수 있으니… 꼭 ts써야지

작성하다보니 인간 문지후 관점에서의 회고를 빼놨다. 이건 … 런칭 후에 계속 작성해보도록 하겠다 ㅎㅎ. 인간 문지후 관점은 더 많은 것들이 있는데 … 요즘은 고민고민고민 … 회고회고회고…보다 행동이 더 중요한 시기라 이쯤에서 마무리!