개요

이번 글은 2025년을 회고하고, 이를 기록으로 남기기 위한 글이다.

원래는 매년 연 회고 글을 블로그에 게시하려고 했는데, 이것이 점점 더 부담스럽게 느껴졌다. 이제 내 업무의 많은 부분이 개발이 아니라 사람에 대한 것이기 때문이다. 회고를 하려면 평가와 피드백이 반드시 필요하다. IC 개발자로서 회고할 때는 나에 대한 평가와 비판만 하면 되니 공개가 부담스럽지 않았다. 하지만 업무 범위가 넓어지면서 회고를 할 때 내가 아닌 타인에 대한 평가를 완전히 배제하기가 점점 어려워졌다. 옆팀의 삽질이나 다른 팀원과의 충돌에서 비롯된 레슨런이 적지 않으니까. 타인에 대한 평가를 공개적인 장소에 박제해두는 것에 대해 상당한 부담을 느꼈다. 그렇다고 해서 맥락 없이 레슨런이라는 결론만 달랑 올리자니, 개인적으로 글의 가치가 다소 떨어진다고 생각했다. 2023년과 2024년의 연 회고 글을 블로그에 게시하지 않은 것은 이러한 맥락이다.

그러다가 이번 2025년 회고 글을 쓰면서 기존에 쓴 회고 글을 쭉 읽었는데, 그해에 경험하고, 느끼고, 고민한 내용이 그 당시의 언어로 생생하게 남아 있다는 것이 너무나도 다행이라는 생각이 들었다. 이러한 퀄리티는 연 회고를 공개된 장소에 게시하기 위해 내용과 문장을 치열하게 고민했기 때문에 가능한 것이었다. 실제로 2023년과 2024년 회고 글은 애초에 게시할 생각이 없이 작성했기 때문에 훨씬 더 대충 작성되어 있는데, 읽으면서 매우 아쉬웠다.

그래서 앞으로는 다소 추상적이고 맥락이 누락되어 있더라도 연 회고 글을 공개적인 장소, 즉 블로그에 게시해보려고 한다.

일 - 라포랩스

2025년 6월 말, 약 3년 3개월의 여정을 마치고 라포랩스를 퇴사했다. 관련 내용은 블로그에 별도로 게시한 라포 회고록으로 갈음하려고 한다. 내게 많은 배움의 기회, 변화의 계기, 행복한 추억을 제공해준 라포랩스와 함께한 동료분들에게 진심으로 감사하다는 이야기를 남겨두고 싶다.

일 - 계단뿌셔클럽

약 1달 반 정도의 휴식 기간을 가진 뒤, 2025년 8월 중순부터 계단뿌셔클럽(이하 계뿌클) 팀에 합류해서 본격적으로 일을 시작했다. 고작 4개월 정도밖에 일을 하지 않았음에도 불구하고 많은 것을 경험하고, 배우고, 반성하고, 고민하고 있다.

계단뿌셔클럽에 합류한 이유

많은 선택지 중 계뿌클에 합류한다는 선택지를 고른 이유에 대해서는 다른 글에 자세히 적어두었으므로, 여기서는 간단히 요약만 하고 넘어가려고 한다.

돈이 되지 않지만 중요한 문제를 해결하는 데 몰입해보고 싶은 마음
오프라인 측면에서 삶의 질을 개선하는 데 기여하고 싶은 마음
다정하면서 뾰족하고, 긍정적인 에너지를 내뿜고, 더 나은 사회를 만드는 데 관심이 많은 사람들과 인생의 일부를 같이 보내고 싶은 마음
AI 시대에 적응하기 위한 노력

속도를 올리는 것의 어려움

계단뿌셔클럽에 합류한지 4개월 정도가 됐다. 그동안 꽤 밀도 높게 일하면서 많은 업무를 처리했다는 생각이 드는 한편, 4개월을 돌아봤을 때 실제로 내가 만들어낸 가치가 그리 많지 않다는 점에서 실망스럽기도 했다.

희미한 목표

업무량과 만들어낸 가치의 양이 일치하지 않는 주된 이유는 한 가지밖에 없다. 노력의 방향이 잘못된 것이다.

개인적으로 생각했을 때, 지난 4개월간의 성과가 마음에 들지 않는 가장 큰 원인은 목표가 희미했다는 점이다. 더 중요한 목표를 망각한 채 눈앞의 목표에만 집중하고, 목표를 명확히 정의하지 않아 커뮤니케이션 비용이 낭비되고, 목표간 우선순위가 명확하지 않아 덜 중요한 일을 먼저 실행하고, 목표를 측정하는 방법이 정의되지 않아 결과물이 휘발되고, 적절한 사이즈의 목표를 선정하지 않아서 빠른 속도로 가설을 검증하는 것이 어려웠다.

예를 들어, 지금까지 계뿌클의 주된 목표 중 하나는 ‘가게의 접근성 정보를 많이 수집하는 것’이었다. 접근성 정보를 많이 모으면 이동약자에게 유용하게 쓰일 것이라는 가설 때문이었다. 이 가설은 얼핏 보면 참으로 보이고, 이 가설을 참이라고 전제하면 접근성 정보를 많이 수집하는 것이 적절한 목표처럼 보일 수 있다. 하지만 ‘접근성 정보가 이동약자에게 유용할 것이다’라는 가설은 너무 일반적인 가설이라 더 세분화해서 검증할 필요가 있다고 느낀다. 이를테면 관광지, 숙소, 공연장, 맛집 등 다양한 공간 중 어떤 공간의 ‘접근성 정보’가 이동약자에게 가장 절실하게 필요할까? 같은 것이다. 우리는 이 가설을 참이라고 여기고 일반적이고 광범위한 접근성 정보 수집에만 초점을 맞췄기 때문에, 유저가 진짜 필요로 하는 것이 무엇인지에 집중하지 못했다.

이런 문제를 해결하기 위해 두 가지를 하고 있다. 첫 번째는 유저에게 집중하는 목표를 세우는 것이다. 유저 인터뷰를 진행해서 유저의 니즈를 파악하고, 작은 단위로 가설을 세워서 검증한다. 두 번째는 목표를 명확하고, 측정 가능하고, 위계가 분명하고, 적절한 사이즈로 선정하는 것이다. 일단은 효과가 꽤 있다고 느껴지긴 하는데, 실제로 효과가 있을지는 지속적으로 관찰하면서 평가해야 할 것 같다.

그로스의 어색함

지금까지 내가 했던 일은 보통 1. 기획이 나와있는 기능을 개발하거나, 2. 도메인 전문가로부터 요구사항을 수집해서 업무 프로세스를 자동화하는 것이었다. 반면 계뿌클에서는 프로세스 자동화보다는 제품의 그로스를 만들어내는 것이 가장 중요하다.

실제로 그로스 업무를 해보니, 각각의 업무에 필요한 역량이 매우 다르며 내가 후자를 해본 적이 없다는 사실을 절실하게 깨달았다. 업무 프로세스 자동화는 복잡한 로직을 유지보수 가능한 형태로 잘 구현해야 한다는 측면에서 상당히 어렵지만, 결국 이미 존재하는 프로세스를 자동화하는 것이기 때문에 어려움의 수준에 어느 정도 예측 가능성이 있다고 생각한다. 반면 그로스는 예측 가능성 따위가 없다. 넓은 사막에 갑자기 떨어진 뒤 있을지 없을지도 모르는 오아시스(= PMF)를 식량(= 돈)이 다 떨어지기 전에 찾아내야 하는 것이다.

그래서 라포랩스에서 다니면 스쿼드 경험이 없었던 것이 매우 아쉽다. 막막한 상황에서 시장 조사를 하고, 적절한 목표를 세우고, 목표 달성을 측정하는 전략을 고민하고, 목표 달성을 위한 다양한 아이디어를 내서 토의하고, 빠르게 가설 검증을 하는 것이 어색하다. 그리고 이것이 바로 지금 우리 팀이 느린 가장 큰 이유 중 하나라고 생각한다.

한편으로는 이런 WTF zone 경험을 지금이라도 해서 다행이라고 생각한다. 문제가 뭔지는 파악했으니, 결국 어떻게든 익숙해져서 잘 해낼 수 있지 않을까? 하는 근거 없는 자신감이 든다. 주변에 관련 도움을 구할 만한 사람도 많아졌기도 하고.

일하는 방식의 차이

라포랩스를 다닐 때도 라포랩스가 일을 꽤 잘하는 괜찮은 회사라고 생각했다. 이 생각은 라포랩스를 퇴사하고 계뿌클에 합류한 이후에 조금 더 강해졌다.

라포랩스가 잘했다고 사후에 느낀 가장 중요한 포인트는 바로 일하는 문화에 대한 강조이다. 라포랩스에서 핵심 가치를 치열하게 논의해서 정하고, 직무 면접 뿐만 아니라 컬처핏 면접도 빡세게 보고, 온보딩 세션에서 핵심 가치에 대해 소개하고, 올핸즈 미팅에서 주기적으로 각 핵심 가치에 대한 설명 세션을 진행하는 것을 보면서 당시에는 왜 이렇게까지 하지? 싶은 의문이 들었다. 솔직히 말하면 리더 미팅에서 핵심 가치 관련된 논의가 길어질 때 일도 많은데 시간 아깝다는 생각을 종종 했었다.

이러한 의문은 계뿌클에 와서 4개월 정도 일해보니 완전히 해소되었다. 계뿌클은 공동대표 2명만 있다가 올해 8월에 3명이 한꺼번에 입사한 상황이었으므로, 일하는 문화와 방식에 대한 강조가 없는 상태였다. 이런 상태에서 일을 하면 다음과 같은 일을 경험해볼 수 있다.

적절한 피드백을 주고받을 수 없다. 이는 개인의 성장에 치명적인 동시에, 작은 레슨 런을 빠르게 쌓아가야 하는 스타트업에게도 치명적이다.

피드백을 주고받는 적절한 방식에 대한 가이드라인이 없다. 언제 어떻게 피드백을 주고 받을 것인지에 대한 약속이 없으니 사람들은 피드백을 잘 하지 않게 된다.

피드백이 상대방과 팀의 성장을 돕기 위함이라는 합의가 없다. 그러므로 피드백을 주고받을 때 자신에 대한 공격이라고 느껴지기 쉽고, 방어적인 태도를 취하게 된다.

일하는 문화와 방식에 대한 기준이 없으므로 피드백의 객관성이 떨어진다. 피드백의 내용이 잘못되기 쉽고, 누군가가 피드백을 주더라도 ‘난 그렇게 생각 안 하는데?’라고 생각하며 수용하지 않기도 쉽다.
업무 도구와 방식에 대한 싱크가 맞지 않아서 비효율이 발생한다.

구두 논의가 슬랙에 남지 않고 휘발된다. 그러므로 이전에 했던 논의를 다음에 다시 반복하거나, 해야 하는 작업이 누락된다.

슬랙 멘션에 대한 기대치가 다르다. 전달되어야 하는 메세지가 제대로 전달되지 않거나, 멘션을 하더라도 답장이 오지 않는 상황이 발생한다.

일정 estimation이 필요하다는 공감대가 없다. 이로 인해 drop 되어야 하는 일이 제대로 drop 되지 않고 불필요한 컨텍스트 스위칭이 반복되거나, 특정 인원에게 일이 몰려 병목 현상이 발생한다.

이러한 비효율을 경험하다 보니 핵심 가치, 일하는 문화, 일하는 규칙에 대한 강조가 결국 생산성의 하방을 크게 높여준다는 점을 배웠다.

문제를 해결하려면 각자가 생각하는 일 잘하는 방식을 매크로 / 마이크로하게 맞출 필요가 있는데, 가장 쉽고 단순하고 효과적인 방법은 기준을 세워두고 거기에 맞는 사람만 채용하는 것이라고 생각한다. 하지만 계뿌클은 작은 회사라 이것이 불가능하므로, 앞으로 일 잘하는 방식에 대한 토의를 적극적으로 진행해서 컨센서스를 잘 이루고 이를 잘 체화해보려고 한다.

비영리단체의 특수성

계뿌클이 비영리단체이기 때문에 발생하는 특수한 어려움도 있다. 비영리단체는 주로 사회 문제를 해결하는데, 이 과정에서 많은 사람들의 ‘문제에 대한 공감’을 이끌어내는 것이 상당히 중요한 목표이다. 계뿌클도 마찬가지인데, 계뿌클이 가진 가장 큰 자산 중 하나는 오프라인 커뮤니티 활동을 하면서 쌓아온 ‘계뿌클에 대한 사람들의 신뢰’이다.

문제는 이 신뢰가 빠른 가설 검증 사이클과는 잘 맞지 않는다는 점이다. 일반적인 영리 스타트업에서 PMF를 찾기 위해 여러가지 실험을 할 때는 사기를 치는 게 아닌 한 유저의 신뢰가 그렇게까지 중요하지 않다. 가설 검증을 시도해보고, 시장의 반응이 시큰둥하면 제품 접고 다른 가설을 실험해보면 된다. 이는 영리 기업과 유저 사이의 관계가 기본적으로 비즈니스 관계이기 때문에 가능하다. 쿠팡 쓰던 사람이 네이버 쇼핑으로 옮겨가더라도, 쿠팡이 할인을 더 많이 해주면 언제든 쿠팡으로 돌아올 수 있다. 제품에 대한 애정/반감이 없진 않겠지만, 기본적으로 유저의 행동 원리는 브랜드에 대한 애정이나 신뢰보다는 돈을 지불하고 가치를 얻을 때의 가성비에 좀 더 초점이 맞춰져 있다.

하지만 비영리단체는 약간 상황이 다르다. ‘비영리’, 말 그대로 돈이 아닌 가치를 제공하고, 이를 통해 유저를 모아야 하는 단체이다. 그러므로 신뢰가 매우 중요하다. 하지만 신뢰는 잃어버리는 순간 다시 획득하기 어렵다는 문제가 있다. 하물며 비영리단체의 ‘시장’은 그리 크지 않으므로, 새로운 신뢰를 획득하는 것도 어렵다. 그래서 이미 얻은 신뢰를 잃어버리는 것은 ‘사회 문제 해결’이라는 비영리단체의 핵심 목표에 치명적이다. 그러므로 가설 검증 과정에서 신뢰를 잃어버릴 수 있는 과감한 시도를 하기가 어렵다. 예를 들어 오프라인 커뮤니티 활동을 파격적으로 개편하거나, 후원 캠페인의 메세지를 공격적이고 자극적으로 실험하는 것이 제한되는 것이다.

요약 - 간단한 원칙, 어려운 실행

비영리단체의 특수성과 같은 부분을 제외하면, 대부분은 이미 인터넷에 많이 돌아다니는 일 잘하는 원칙이며 많은 사람들이 이미 잘 알고 있는 내용일 것이다.

하지만 인지는 아무런 의미가 없다는 것을 이번 4개월에 걸쳐 배웠다. 어떤 원칙이 왜 얼마만큼 중요한 것인지 경험(이라기보다는 고생)을 통해 이해하고, 이를 바탕으로 강한 의지를 발휘해 원칙을 예외 없이 지키려고 하는 노력이 훨씬 중요하다. 군자오미(부담 없는 배려, 명확한 지시, 탐욕 없는 욕심, 교만하지 않은 자유로움, 사납지 않은 위엄)를 아는 것은 쉽지만, 그걸 안다고 군자가 되는 건 아닌 것처럼 말이다.

역할의 확장

계뿌클은 5명으로 구성되어 있는 팀이고, 우리 팀에 (풀타임) 개발자는 나 한명 뿐이다. 그러므로 내가 팀에서 맡아야 하는 업무 범위가 훨씬 늘어났다. 코드와 데이터를 다루는 모든 일을 처리하고 있다. 여기에 더해 후원이라는 완전히 새로운 도메인의 업무를 맡게 되었다.

서버 개발

서버 개발은 오히려 깊이가 얕아졌으므로 할 이야기가 많지는 않다.

다만 공공데이터의 효용에 대해 언급하고 넘어가고 싶다. 생각보다 세상에 좋은 공공데이터가 많이 공개되어 있다는 점을 배웠다. 예를 들어 계뿌클은 장애인화장실 위치 및 사진 등의 공공데이터를 앱서비스에서 활용하고 있다.

문제는 어떤 데이터가 공공데이터의 형태로 공개되어 있는지 잘 알기가 어렵고, 공공데이터를 가져다 쓰기 위해서는 귀찮은 절차가 필요하며, 이에 따라 좋은 공공데이터의 활용도가 떨어진다는 것이다.

LLM의 발전 과정에서도 느낀 것이지만, 결국 IT 프로덕트가 가치를 제공하는 것은 압도적인 UX라는 생각이 든다. 기술력이 얼마나 뛰어난지가 아니라 UX가 제품의 흥망성쇠를 결정한다.

어떤 데이터를 활용할 수 있는지 조사하고, 유용한 것을 선별하고, 귀찮음을 유저 대신 감수해서 한데 긁어모으고, 데이터 파이프라인을 유지보수하고, 이를 사용자의 실제 쓸모에 맞춰 재가공해서 편하게 볼 수 있는 UX를 제공하는 것이 계뿌클이라는 앱서비스가 나아가야 하는 한 가지 방향성이라는 생각이 들었다.

프론트엔드 개발

프론트엔드 개발, 그중에서 앱서비스 개발을 이렇게 본격적으로 해본 것은 이번 계뿌클 앱서비스 개발이 처음이었다. 지식과 경험의 부족이 걱정됐지만, 사이드 프로젝트로 참여하고 계신 분들과 LLM의 도움을 통해 별 무리없이 적응할 수 있었다. 프론트엔드 개발에 여전히 미숙하지만, 계뿌클 앱을 개발하는 데는 전혀 무리가 없는 수준이다.

특히 놀라웠던 부분은 LLM의 생산성이었다. LLM이 개발을 어찌나 잘해주던지, 프론트엔드 개발을 더 공부해야겠다는 필요성을 전혀 느끼지 못하고 있다. 지금도 별 필요성을 못 느끼겠는데, 앞으로 AI가 더 발전할 일만 남은 상황에서 굳이 왜? 라는 생각이 든다. Figma MCP를 활용한 컴포넌트 디자인 구현, 기획 문서를 기반으로 한 비즈니스 로직 구현, 복잡한 상태 관리 리팩토링, 이슈 디깅 등 다양한 작업을 매우 잘 수행해주고 있다. LLM의 발전으로 인해 올해 가장 이득을 많이 본 부분 중 하나가 아닐까 싶다.

프론트엔드 개발을 직접 해보니, 서버 개발과 프론트엔드 개발이 꽤 비슷해서 서버 개발에서의 노하우를 그대로 활용할 수 있는 부분이 많았다. 이를테면 디버깅 노하우, 코드의 재사용 범위 설정, 코드 아키텍처 구현 등 소프트웨어 엔지니어링의 본질적인 지혜는 동일하게 적용됐다.

하지만 개발을 힘들게 만드는 핵심적인 어려움이 달랐는데, 정리해보면 다음과 같다.

상태 관리

프론트엔드의 경우, 관리해야 하는 상태의 종류가 서버에 비해 많아 상태 관리가 더 어려울 수밖에 없겠다는 생각이 들었다. 서버는 API라는 규격화된 인터페이스에 맞춰 프론트엔드가 정제해서 넘겨준 데이터만 처리하면 되지만, 프론트엔드는 그 데이터를 정제할 때까지의 모든 유저 인터렉션을 상태로 관리해야 한다. 그러므로 비즈니스 로직과 관련된 상태가 훨씬 많아진다. 또한 비즈니스 로직과 관련이 없는 스크롤이나 애니메이션 등 UI와 관련된 상태도 모두 관리해야 한다. 여기에 뷰포트 사이즈나 브라우저별로 UI를 다르게 그려야 하는 경우도 있다. 즉, 애초에 서버보다 다뤄야 하는 상태의 종류 자체가 많은 것이다.

이렇게 다양한 상태를 어디에 저장해야 하는지도 직관적으로 판단하기가 꽤 어렵다고 느껴졌다. 서버의 경우 모르겠으면 일단 외부의 중앙 저장소(보통 RDB)에 때려박으면 기본은 간다. 하지만 프론트엔드에서는 로컬 스토리지, useContext, useState 등 상태를 저장하는 선택지가 조금 더 다양하고, 이들의 라이프사이클도 저마다 다르다. 여기에 더해 렌더링 최적화를 위한 useMemo 등이 들어가면 더 혼란스러워진다.
디버깅

상태 관리랑 이어지는 것인데, 상태 변경에 대한 ‘동시성 이슈’가 서버에 비해 빈번하게 발생하며 이를 디버깅하는 게 고통스러웠다.

서버는 보통 scale out을 위해서 상태 관리를 외부 저장소에 다 때려박는다. 이때 주로 사용하는 외부의 중앙 저장소는 RDB인데, RDB는 트랜잭션이라는 미친 추상화를 제공한다. 트랜잭션만 적절히 사용하고 따닥 이슈만 락으로 막으면 대부분의 동시성 이슈는 방어할 수 있다. 쓰다보니 트랜잭션을 적절히 활용하는 것이 매우 어려울 수 있다는 생각은 들지만… 일단 postgres 같은 경우 대충 isolation level을 repeatable read로 설정해서 쓰면 대부분의 상황에서 별 문제가 없다.

프론트엔드의 상태 관리에서는 트랜잭션과 같은 추상화를 제공하지 않는다. 그래서 서로 의존성이 있는 상태를 동시에 여러 플로우에서 수정할 수 있는 경우 예상치 못한 문제가 많이 발생하는 듯하다. 여기서 상황을 더욱 악화시키는 것은 반응형 패러다임이다. 유저의 행동에 맞춰서 상태를 바꾸는 데 반응형 패러다임이 자연스럽다는 것은 동의가 되지만, 이로 인해 동시에 진행되는 서로 다른 플로우에서 상태 변경이 발생하는 게 문제를 까다롭게 만드는 것 같다. 여러 상태 변경 간의 순서를 강제하기도 어렵고, 어떤 플로우가 어떤 상태를 언제 변경했는지도 알기 어렵다.

예를 들어 계뿌클은 지도 SDK를 쓴 검색 화면을 제공하는데, 지도 SDK의 카메라 영역을 관리하는 것이 고통스러운 상황이다. 카메라 영역은 1. 현재 뷰포트에서 지도 SDK가 차지하는 영역과 2. 검색 결과의 위경도값 목록을 보고 카메라 영역을 fit 한다. 이때 검색이 일어나면 두 가지 일이 동시에 발생한다. 1. 키보드가 내려가면서 뷰포트가 넓어지고 2. 검색 API를 호출한 뒤 검색 결과를 저장한다. 순서가 1번 → 2번이 강제되어야 카메라 영역이 올바르게 잡히는데, 이를 강제할 방법을 찾지 못했다. 그래서 어쩔 수 없이 ‘아직 키보드가 다 내려가지 않았어요’ 등 순서를 맞추기 위한 다른 상태를 도입해야 해서 복잡도가 올라간다. 이때 유저가 검색 취소 등의 다른 행동을 했을 때 카메라 영역이 이상하게 잡히는 버그가 발생하면, 아주 복잡한 상태 관리 코드를 디버깅해야 해서 디버깅이 더 어려워지는 것이다.
자동화 테스트와 QA

서버의 경우, 어떤 기능을 테스트하는 것이 비교적 쉽다. 예를 들어, 결국 서버가 하는 건 중앙 저장소의 데이터를 비즈니스 규칙을 따라 변경하고, 적절한 side effect를 발생시키는 것이다. 그러므로 각 시나리오에 대해 1. 데이터가 잘 변경되었는지와 2. side effect 발생을 잘 시켰는지를 테스트하면 되는데, 이 두 가지는 보통 성공 여부를 코드로 잘 표현할 수 있다.

프론트엔드의 경우, 비즈니스 로직에 대해서는 같은 논리를 적용할 수 있다. 하지만 UI는 다르다. 대충 사람이 봤을 때 ‘이거 버튼 위치가 이상한데?’라고 느끼는 것을 자동화 테스트로 작성할 수 있을까? 뷰포트와 브라우저별로 모든 컴포넌트 하나하나의 사이즈와 위치가 무엇이어야 적절한지를 코드로 정의하는 것은 사실상 불가능하다. 즉, 자동화 테스트로 프론트엔드 소프트웨어의 품질을 측정하는 데 비교적 한계가 있다는 뜻이다.

이러한 자동화 테스트의 부재는 결국 프론트엔드 작업 시 사람이 QA 단계에 끼는 것을 강제하고, QA 작업의 품질을 개인의 능력이나 컨디션에 의존하게 만들고, 배포 사이클을 느리게 한다. 요즘 실리콘밸리에서는 AI를 활용해 QA를 자동화하는 스타트업들이 생기고 있다는 이야기를 듣긴 했지만, 아직 쓸모 있는 단계는 아니라고 한다.

테스트해야 하는 기기가 여러개라는 점도 QA를 힘들게 만드는 부분이다. 서버는 배포 환경을 하나로 통제하는 것이 가능하지만, 프론트엔드는 그렇지 않다. 수많은 디바이스, 브라우저, OS에서 잘 돌아가는 소프트웨어를 만드는 것이 정말 힘들다는 것을 최근 4개월간 여러 번 느꼈다.
가시성 확보

중앙 집중적으로 배포하고 운영하는 서버나 인프라에 비해, 각 유저의 기기에 설치되는 앱에 대해서는 가시성을 확보하기 어렵다고 느꼈다.

서버나 인프라의 경우, 비용이라는 제약이 있긴 하지만 어쨌든 가시성을 확보하는 것이 비교적 자유롭다. 로그, 메트릭, 프로파일링 등 필요한 데이터가 있다면 이를 수집하는 개발을 진행하고 배포하면 된다. 특정 서버 1대만 더 많은 로그를 심어서 잠깐 배포하고 롤백하는 등 일시적으로 더 자세한 가시성을 확보하는 전략도 사용할 수 있다. 반면 프론트엔드의 경우 배포와 네트워크의 제약 등이 있으므로, 원하는 만큼 가시성을 확보하기가 상대적으로 어렵다.

여기에 더해, 아까 자동화 테스트에서 언급한 ‘소프트웨어의 품질을 측정하는 데 한계가 있다’라는 점이 발목을 잡는다. 서버는 5xx 에러의 비율, API latency, APM 등 서버 전체/일부에 문제가 있음을 측정하기 위한 메트릭이 꽤나 명확한 편이다. 하지만 크래시나 에러 외의 이유로 앱이 이상한지 아닌지를 판단하는 것은 매우 어렵다.

데이터 엔지니어링 및 분석

데이터 엔지니어링의 경우, 그냥 빅쿼리에 냅다 꽂기로 해서 크게 어려운 부분은 없었다. 애초에 <데이터 중심 애플리케이션 설계>에서의 내용처럼 데이터 엔지니어링이 서버 개발과 꽤 비슷하기도 하고, 라포랩스에 있던 내내 데이터 엔지니어링 팀과 가깝게 일하면서 데이터 관리 체계 등 엿들은 내용도 꽤 있었다.

정말 어려웠던 부분은 데이터 분석이었다. 데이터 분석 역할은 스쿼드 경험이 없어서 가장 아쉬웠던 부분 중 하나였다. 생각해보니 나는 메트릭을 어떤 식으로 정의하고, 정의를 팀 전체적으로 어떻게 관리하고, 이를 구현한 SQL이 어떤 형태인지 등을 몸소 경험해본 적이 없었다. 그래서 리서치를 해서 계획을 세우고 실행을 하기는 하는데, 관련 도구를 써본 적이 없다 보니 트레이드 오프를 판단하는 것도 어렵고, 도구에 익숙하지 않다 보니 셋업도 느리고, 최종적인 시스템을 사용해본 경험도 없다 보니 확신도 부족했다.

예를 들면, 지금 계뿌클에서는 데이터 웨어하우스로 빅쿼리를 쓰고 있는데, 빅쿼리를 쓴다는 결정을 하는 것은 아주 쉬웠다. 내가 많이 써봐서 얼마나 편한지 잘 알고 있고, 데이터 파이프라인을 어떻게 유지보수할지도 리서치를 조금 해보니 충분히 상상이 갔다. 그래서 비용 계산만 살짝 해보고 바로 도입을 결정했다. 반면 앰플리튜드나 믹스패널 등 제품 분석 도구는 사용하고 있지 않다. 좋다고 좋다고 주변에서 이야기는 하는데, 실제로 우리 정도 스케일에서 이게 정말로 필요한지, 도입한다면 개발 공수가 어느 정도 될지, 비용은 어느 정도 들지 전혀 감이 없다. 내가 직접 써본 적이 없기 때문이다. 그래서 이걸 할지 말지를 빨리 판단하기가 어려워서 결정을 계속 미루게 된다.

이런 의사결정 외에도 데이터 분석과 관련한 업무를 할 때마다 어려움을 느끼고 있다. 메트릭을 정의하고, 이러한 정의를 중앙 집중적으로 관리하고, 정의한 메트릭을 구현하기 위한 SQL을 작성하고, 이에 대한 사용법을 팀에 전파하고, 그렇게 하기 위해 권한 관리를 하는 이 모든 과정이 새로운 동시에 잘 되지 않아 답답함을 느낀다. 분명히 빅쿼리 테이블에 컬럼 설명과 테이블간 관계를 다 적어놨는데도 불구하고 자꾸 잘못된 쿼리를 짜주는 Gemini가 야속하다. 가장 화가 나는 것은 시각화 도구인데, 이것저것 찾아보다가 그냥 지난 회사에서 썼던 looker studio를 선택했는데 UX가 정말 끔찍하기 그지없었다. 왜 구글은 그 뛰어난 기술력으로 이런 구린 제품밖에 만들지 못하는 것일까?

아무튼, 2026년에는 데이터 분석을 체계적으로 공부해봐야 할 것 같다. 위에서 이야기했듯이 목표 기반으로 일하는 팀이 되는 것이 아주 중요하고, 그러려면 팀의 데이터 분석 역량을 끌어올리는 것이 필수적이라고 생각하기 때문이다.

후원 업무

후원 업무는 말 그대로 사람들이 계뿌클에 후원하도록 만드는 것을 말한다. 올해 10월 말부터 후원 업무를 담당하여 PO 역할을 맡게 되었다.

사실 후원이라는 업무를 하게 될 줄은 9월까지만 해도 꿈에도 몰랐다. 나는 내가 계뿌클에 합류하면 제품 쪽에서 그로스를 만드는 데 보다 많은 시간을 쏟게 될 것이라고 예상했다. 계뿌클에서 진행되는 업무 중 내 경험과 지식이 가장 잘 활용될 수 있는 영역이 바로 제품을 개선하는 쪽이었기 때문이다. 나는 서버 개발만 7년 한 사람이다. 뜬금없이 후원 업무라니?

그런데 10월에 전사 워크샵을 대규모로 진행하면서 내년 목표를 세우고, 각 목표의 오너십을 나눠 가지려다 보니, 내가 후원을 맡는 것이 팀 전체적으로는 가장 최적인 상황이 되었다. 내가 봐도 내가 후원 업무를 가져가는 게 가장 좋은 업무 분배였다. 그래서 얼떨떨하고 불안하지만 내색은 안 하면서 내가 하겠다고 말했다.

결론부터 이야기하면, 후원 업무를 맡게 된 것은 긍정적인 의미의 예상치 못한 변화가 되었다.

가장 좋은 점은 계뿌클에 대한 몰입도가 올라갔다는 것이다. 후원 업무를 하다 보니 후원이 우리 팀이 만들어내는 사회적 임팩트를 구독하는 것과 비슷하다고 느꼈다. 넷플릭스를 구독하는 사람과 계뿌클을 기꺼이 후원해주시는 분들의 마음 자체는 당연히 다를 것이다. 하지만 계뿌클 팀이 뛰어난 사회적 임팩트를 내야 하고, 이 ‘계뿌클이 만든 사회적 임팩트’를 훌륭한 스토리텔링과 브랜딩으로 포장하고, 이를 널리 광고해서 정기 후원을 유치해야 한다는 점에서는 서비스 구독과 어느 정도 비슷한 면이 있다고 생각한다.

갑자기 구독 이야기를 왜 하냐면, 후원 업무를 잘하기 위해서는 결국 ‘계뿌클이 만든 사회적 임팩트’라는 상품에 대한 이해도가 높아야 한다는 점을 이야기하고 싶었다. 후원 캠페인을 기획하다 보니 우리가 만든 사회적 임팩트가 어느 수준인지에 대해 더 자세하게 파고들기 시작했고, 그 과정에서 계뿌클 팀이 정말 올바른 방향으로 나아가고 있는지에 대해 몰입해서 고찰하고, 또 챌린지할 수 있었다.

여기에 더해, 제품 쪽은 아니지만 그로스의 재미를 느낄 수 있는 기회가 되었다. 열심히 준비한 후원 캠페인을 통해서 첫 후원이 들어오고, 매일매일 후원금이 올라갈 때 느낀 감정은… 말로 표현하기 참 어려운 것이었다. 기쁘고, 즐겁고, 행복하고, 감사한 그런 감정. 이런 기분을 제대로 느껴본 것은 처음이었다. 타다가 잘 나갔을 때는 뭣도 모르는 신입 개발자였고, 라포랩스에서는 그로스 업무를 하지 않았으니까. 2026년에도 이런 기분을 자주 느낄 수 있으면 참 좋겠다.

후원 업무를 하면서 새롭게 배운 점도 많다.

제대로 된 기획을 처음 해봤는데, 기획자가 작업자가 기획의 의도를 세부적으로 싱크하는 것, 그러기 위해 기획자의 의도를 기획서에 상세하게 표현하는 것이 얼마나 중요한지를 뼈저리게 느꼈다. 기획 의도를 제대로 전달하지 않아 일정이 딜레이 되는 것을 여러 차례 경험했다. 또한 왜 그렇게 기획자들이 레퍼런스에 목을 매는지 알게 되었다. 이미 성공한 기획을 따라해 실패 확률을 최대한 줄이고, 업계 표준을 벗어나서 유저들이 어색함을 느끼는 일을 줄이려면 레퍼런스를 잘 참고하는 것이 필요하다. 레퍼런스 뿐만 아니라 각종 자료를 리서치하는 것도 상당히 어렵지만 중요하다는 점을 배웠다. 기획 방향성을 정하기 위해서는 선택의 근거가 되는 시장 현황 및 각종 수치가 필요하기 때문이다.

기획 외적으로는, 빠른 실행을 위해서는 오너십과 실행 가능 여부를 일치시켜야 한다는 것을 깨달았다. 오너십을 가진 사람에게 직접 실행할 수 있는 환경과 도구를 제공해주거나, 실행할 수 있는 능력을 가진 사람에게 적절한 단위의 오너십을 끊어서 넘겨줘야 한다. 이것이 최상의 퀄리티를 보장해지는 못하겠지만, 결정과 실행 단계에서의 커뮤니케이션 코스트를 대폭 줄일 수 있어서 최상의 속도를 보장해준다. 그리고 계뿌클에는 퀄리티보다는 속도가 더 중요한 시점이라고 생각한다.

후원 업무를 하는 과정에서 라포랩스에서의 업무 경험이 많이 도움이 되었다. 우선 플랫폼 팀의 리더로서 일한 경험 덕분에 후원 목표를 설정하고 관리하는 등 PO 역할을 어렵지 않게 수행할 수 있었다. 또한 의외로 회계팀과 협업한 경험이 쏠쏠하게 도움이 되었는데, 회계팀의 언어에 익숙해진 덕분에 후원과 관련된 개념이나 법 등을 보다 쉽게 이해할 수 있었다. 이런 걸 보면서 정말 인생이 connecting the dots라는 생각이 들었다. 내년에는 경리 업무도 담당하게 될 예정인데, 회계팀 협업 경험이 더더욱 도움이 될 것 같다.

AI의 가치

계뿌클에 온 뒤로 프론트엔드 개발, 데이터 분석, 후원 등 지금까지 해보지 않은 다양한 역할을 수행하게 되었다. 비록 불완전하지만 어찌저찌 틀어막고는 있는데, AI가 없었다면 이러한 역할의 확장이 아예 불가능했을 것이다.

AI는 내가 이미 잘하는 업무를 자동화하는 데도 큰 도움이 되지만, AI의 진정한 가치는 내가 모르는 업무를 어느 정도 수준까지 잘 수행할 수 있도록 보조해주는 데 있다고 느꼈다. AI는 작은 팀에게 환상적인 업무 환경을 제공해준다. 해보지 않았지만 잘 해내야 하는 역할이 너무나도 많은데, AI는 내가 이들을 주니어 수준으로는 수행할 수 있게끔 도와준다.

개인적으로 AI를 가장 많이 활용하고 있는 부분을 정리해보면 다음과 같다.

개발 - 어느 시점부터 figma MCP도 잘 되기 시작해서, 이제 손으로 코드를 짜는 경우는 거의 없다.
리서치 - 기술적인 설계 뿐만 아니라 후원 업무 기획 등 여러 상황에서 관련 자료를 리서치하는 데 많이 활용한다. 매우 강력한 검색 능력을 보여준다.

반면 AI를 아직 잘 활용하고 있지 못하다고 생각하는 부분은 업무를 자동화하는 측면이다. 아직 AI native한 방식으로 사고하고 워크플로우를 고안하는 것이 부자연스럽다. AI로 자동화한 워크플로우에 인간이 맞춰야 한다는 것을 머리로는 이해하고 있는데, 워크플로우를 바꾸는 비용과 초기 시행착오의 불편함을 감내할 자신이 없다. AI로 업무를 자동화하려면 1. 평소에 맥락을 잘 쌓아두다가 2. 이를 AI가 활용할 수 있는 적절한 형태로 가공하는 작업이 필요하다. 하지만 맥락을 잘 쌓기 위해서는 팀 전체가 업무 과정을 보다 더 잘 기록하는 불편함을 감수해야 한다. 이를 활용해서 2번이 잘 되면 그때는 더 편해지겠지만, 그 과도기 기간 동안의 귀찮음을 감내할 인센티브 구조가 충분히 강력하다고 느끼지는 못하고 있다. 더군다나 워크플로우를 충분한 퀄리티로 자동화하는 것이 꽤 어려운 것 같아 보이기도 한다.

그럼에도 불구하고 AI native한 업무 방식이 근시일 내에 꼭 따라잡아야 할 변화일 것 같아서, AI를 보다 적극적으로 활용해야겠다고 생각’은’ 하고 있다. 당장의 개발 업무와 후원 업무 등으로 인해 시행착오를 많이 해보지는 못했지만, 올해 가장 좋았던 것은 작은 AI 해커톤에 참여한 것이었다. 두 가지 목적이 있었는데, 1. AI로 업무를 자동화하는 데 어떤 작업이 필요한지 시간을 벌크로 빼서 직접 구현하면서 느껴보고, 2. 다른 팀의 결과물을 여럿 보면서 AI로 어떤 작업을 어떤 퀄리티로 자동화할 수 있을지에 대한 감을 익히는 것이었다. 아주 만족스러운 시간이었는데, 결국 데이터와 맥락을 긁어모으는 단계가 가장 어려운 동시에 자동화 퀄리티를 높이는 핵심이라는 점을 배울 수 있었다.

소회

Pay it forward, 도움을 주고받는 문화

나는 상당한 내향인이었지만, 시간이 지나면서 점점 외향적으로 바뀌었다. 기존이 8:2 정도의 내향인이었다면, 지금은 한 6:4 정도인 것 같다. 점점 외향성이 강해진 이유에는 여러가지가 있다. 낯선 사람을 만났을 때의 어색함에 익숙해진 부분도 있고, 대인관계 스킬도 늘었다. 하지만 가장 중요한 이유는 인간관계가 인생에 얼마나 중요한지를 다방면으로 잘 체감할 수 있었기 때문이다.

계뿌클에 와서 일을 하다 보니, 느슨한 관계를 맺고 서로 도움을 주고받는 것이 너무나도 중요하다는 것을 다시 한 번 느낀다. 시간은 너무나도 부족한데 내가 해야 할 일은 너무나도 많고, 내가 아는 것은 쥐꼬리만큼이다. 내가 처음부터 배우는 것보다 도움을 주고받는 것이 훨씬 효율적이며, 거기서 새로운 기회와 즐거움이 발생하기도 한다. 후원 업무가 그럭저럭 굴러가고 있는 건 전적으로 팀원들의 도움과 excuse 덕분이다. 이것 외에도 계뿌클 팀 바깥에서 도움을 받는 경우도 너무너무 많다. 이런 개념을 아산나눔재단의 pay it forward 정신이나 계뿌클에서 이야기하는 도움을 주고받는 문화라는 구체적인 문장으로 인식하게 된 것도 소소하게 도움이 되었을 것이다.

앞으로는 더더욱 먼저 도움을 주는 사람이 되기 위해 노력하려고 한다. 나도 필요할 때 도움을 받고 싶다는 계산적인 마음도 있고, 무엇보다 도움을 주는 것 자체가 즐겁기도 하니까. 이 글을 읽은 누군가가 혹시라도 내게 도움을 청해야 할 상황에 처한다면, 언제든 편하게 연락을 하면 좋겠다.

소속감의 소멸

계뿌클에 합류한 이후, 소속감을 가질 만한 인간관계 그룹이 애매해졌다. 그리고 이는 꽤 우울한 기분이 드는 변화였다.

라포랩스를 다닐 적에는 크게 두 가지 소속감을 느끼고 있었다. 첫 번째는 내가 속한 팀(서버 플랫폼 팀, 커머스 플랫폼 팀)과 그룹(백엔드 그룹)에 대한 소속감이고, 두 번째는 크로스핏 파티에 대한 소속감이었다. 계뿌클에 합류한 이후로 이 두 가지 소속감이 모두 희미해졌다.

팀에 대한 소속감의 경우, 당연히 팀 전체와 함께 많은 시간을 보내고 있으며 계뿌클 팀 자체에 대한 소속감과 애정도 느낀다. 하지만 계뿌클에서 개발자는 나 혼자이고, 후원팀도 나 혼자이며, 내 리더는 없다. 생각해보니 VCNC와 라포랩스에서는 항상 1. 동일 직군의 사람들과 팀을 이루고 있었으며, 2. 나랑 1on1을 진행하는 리더가 있었다. 이 두 가지 요소 없이 일을 하니 내가 하는 일을 정확히 이해하는 사람이 나밖에 없는 상태가 되었고, 이게 꽤 외로운 일이라는 사실을 깨달았다. 추가적으로 ‘나중에 합류한 공동창업자’라는 포지션도 애매한데, 창업자는 아니지만 또 직원도 아니어서 묘한 기분을 느낄 때가 왕왕 있다.

크로스핏 파티를 포함한 여러 사적 관계의 경우, 만나는 빈도가 점점 줄어들고 있다. 창업으로 인해 시간적인 부담을 느끼는 것도 크긴 한데, 의외로 재정적인 부담도 꽤 크다. 다른 사람의 소득은 그대로인데 내 소득만 갑자기 줄어들었기 때문이다. 1월 중순에 회사가 분당으로 이사를 가면 아마 더더욱 사람들과 만나는 것이 어려워지지 않을까 싶다.

다른 창업팀과의 관계에서도 비슷한 느낌을 받는다. 계뿌클은 ‘비영리 IT 스타트업’이라는 정체성을 가지고 있는데, 좋게 말하면 비영리단체와도 접점이 있고 IT 스타트업과도 접점이 있는 것이지만 나쁘게 말하면 둘 모두와 조금씩 정체성이 다르다고 볼 수 있다. 그로 인해 관심사를 아주 폭넓게 유지하지 않는 한 관심사와 대화 주제가 약간씩 어긋나는 것 같다. 그리고 나는 기본적으로 관심사가 아주 좁은 사람이라 이런 애매한 정체성이 꽤 고통스럽게 느껴진다.

이런 문제가 있을 것이라고는 예상하지 못해서, 소속감의 소멸로 인한 우울감이 꽤 당황스러웠다. 중요한 문제라는 생각이 들어서, 내년에는 시간과 돈과 에너지를 더 써서 사람들을 잘 만나고 다녀보려고 한다.

에너지 레벨

지금까지 이런저런 회고와 고민을 적었는데, 결국 중요한 것은 실행이다. 그리고 지금 가장 큰 고민은 실행을 위한 에너지 레벨이 잘 안 높아진다는 것이다. 실행, 그것도 안 해본 것을 많이 실행해야 하므로 더더욱 많은 에너지가 필요한데, 퇴근해서 집에 가거나 주말에 일어나면 의욕이 쏙 사라지고 자꾸 휴대폰만 들여다보고 있게 된다.

놀랍게도 예전 일기를 뒤져보니 2024년 3월에 적은 일기에서도 똑같은 고민이 적혀 있었다(노션에 일기를 적었을 때의 장점은 검색이 쉽다는 점이다). 내가 원래 이렇게 에너지 레벨이 낮았나? 하면 아니다. 과고 입시를 위해 매일 4~5시간씩만 자면서 공부했던 중학교 시절. 과제랑 동아리 때문에 일주일에 3~4일씩 밤을 새기 일쑤였던 대학교 시절. 매주 토요일마다 하루종일 서버 개발 공부하던 VCNC 시절.

왜 이전에는 에너지 레벨이 높았는지 고민해보니, 이때까지는 인생에 plan B가 없었다. 인생이 불안정하고 다음 기회가 없다는 생각에 사로잡혀 있었고, 실패하지 않기 위해 악에 받쳐 있었다. 부정적인 에너지 레벨이 높았다고 해야 할 것 같다. 지금은 어느 정도 ‘배부르고 등따신’, 즉 악에 받치지 않은 상황이다. 삶에서 실패가 좀 있더라도 어떻게든 적당히 먹고 살고, 적당히 행복할 수 있겠다는 생각이 든다. 그래서 어느 정도 에너지 레벨이 낮아질 수밖에 없는 것 같다.

이러한 변화는 인생 전체를 놓고 보면 바람직하지만, 인생에서 중요한 도전과 몰입을 하고 있는 지금은 에너지 레벨을 끌어 올려야 한다. 그래서 에너지 레벨을 높일 수 있는 방법이나 환경이 무엇인지를 잘 고민해봐야 할 것 같다. 아무래도 밤에 휴대폰 보는 시간을 줄이는 게 가장 필요할 것 같은데, 일찍 자고 일찍 일어나는 것을 강제해서 아침 시간을 좀 더 활용해보면 좋을 것 같다. 사람들을 잘 모아서 같이 에너지 레벨을 올라는 것도 좋은 방법이라는 것을 배웠다. 내향인이긴 하지만, 다른 사람들과 무언가를 함께 할 때 딴짓을 덜 하고 의지가 더 생긴다는 것을 올해 다양한 경험을 통해 느낄 수 있었다.

(다음 글에서 계속)

← [라포 회고록] 이직 - 계단뿌셔클럽으로 이직한 이유 2025년 회고 - 2 →

2025년 회고 - 1

개요