이것은 우리가 2년 10개월 동안 하나의 서비스를 세상에 내놓기까지의 이야기다
현재 회사에 입사한 지도 어느덧 4년이 되어갑니다. 그런데 사실 약 3년 동안은 회사 밖에서 저를 소개할 때마다 어떤 일을 하는지 말하기가 꽤 난감하곤 했습니다. 검색이나 지도, 쇼핑처럼 널리 알려진 국내 서비스였다면 소개가 쉬웠겠지만… 당시 제가 만들고 있던 건 북미 시장을 겨냥한 비공개 신규 서비스였거든요. 대외비 정보가 많아서 설명을 하기도 쉽지 않았습니다.
2023년 4월, 저는 이 프로젝트의 초기 프론트엔드 개발자로 팀에 합류했습니다. 남들이 가보지 않은 길을 간다는 생각에 설레기도 했지만, 한편으로는 정답도 선례도 없다는 사실이 두렵게 느껴지기도 했죠. 이미 방향이 정해진 서비스를 개선하는 것과 달리, 무엇을 만들어야 할지부터 고민하며 서비스의 기반을 하나씩 만들어 나가야 했습니다. 진정한 제로 투 원(0 to 1) 의 길을 걷게 된 것이죠.
그렇게 설계와 개발, 여러 차례의 검증을 거쳐 출시까지는 꼬박 2년 10개월이 걸렸습니다. 그 시간 동안 수많은 결정과 선택, 번복이 있었습니다. 결코 순탄하지는 않았지만, 처음부터 함께 만든 서비스를 직접 세상에 내놓은 경험은 제 개발자 커리어에 큰 의미로 남을 것 같습니다.
회사에서 진행한 프로젝트인 만큼 어디까지 이야기해도 괜찮을지 고민이 많이 되더라구요. 그래서 이 글은 외부에 공개된 자료와 제가 직접 경험한 내용을 중심으로 작성했습니다. 어디까지나 개인적인 회고일 뿐, 회사나 조직의 공식 입장을 대변하지는 않습니다. 공개할 수 있는 범위 안에서 사실은 담백하게 정리하되, 그 과정에서 느낀 감상도 함께 담아보려 합니다.
이번 글에서는 제가 개발한 서비스가 어떤 것인지 간단히 소개하고, 출시를 준비하면서 일과 결과물을 바라보는 제 생각이 어떻게 달라졌는지 돌아보겠습니다. 이 글이 신규 서비스를 처음부터 만들며 여러 불확실성 속에서 고민하고 있는 분들께 작은 공감과 도움이 되었으면 좋겠습니다.
어떤 서비스를 만들었는지
저는 북미 타깃의 SNS 플랫폼인 ThingsBook의 프론트엔드 개발에 참여했습니다. ThingsBook은 책, 영화, 음악, 여행 등 자신의 취향과 일상 경험을 컬렉션 형태로 체계적으로 기록하고 공유하는 UGC 플랫폼으로, 콘셉트를 알기 쉽게 비유하자면 개인 박물관을 지향하는 블로그 라고 설명할 수 있을 것 같네요.
보도 자료
서비스에 대한 자세한 내용은 회사에서 공개한 보도 자료로 대신하겠습니다. 참고로 웹과 앱(iOS/안드로이드)이 모두 지원되는 멀티 플랫폼 서비스입니다. (아쉽게도 서비스 정책상 한국에서 글 작성은 불가능합니다. 😢)
서비스를 만들며 달라진 생각들
돌아보면 지난 2년 10개월은 서비스뿐만 아니라 저의 생각과 감정도 요동치는 시간이었습니다. 지금부터는 어떤 문제를 풀어야 할지 고민하던 초기부터 서비스의 흐름과 기반을 만들고, 여러 변화에 적응하며 출시하기까지 기억에 남은 장면들을 하나씩 정리해보겠습니다.
당시를 돌아보며 주관적으로 그려본 감정의 변화
어떤 문제를 풀어야 할 것인가
무엇을 만들 것인가?
팀에 합류한 2023년은 문제 정의의 시간이었습니다. 해외 시장을 겨냥한 UGC 서비스라는 큰 방향은 있었지만, 어떤 관심사를 중심으로 사람들을 모이게 할 것인지, 무엇을 기록하고 공유하게 만들지는 정해지지 않았거든요.
서비스의 방향이 뚜렷하지 않다는 점이 불안하긴 했지만, 새로운 프로젝트의 시작을 함께한다는 설렘도 있었습니다. 사실 이전 팀이었던 엑스퍼트는 이미 잘 운영되고 있던 서비스라서 정해진 규칙을 학습하고 개선하는 과제를 쳐내느라 정신이 없었거든요. 그래서인지 서두르지 않고 문제를 탐색할 수 있다는 여유가 한편으로는 반갑게(?) 느껴졌습니다.
아이디어의 가능성을 기술로 검증하기
기획과 디자인에서 다양한 아이디어를 제안했고, 개발자들은 그 아이디어를 실제 서비스로 구현할 수 있는지 하나씩 검증했습니다. 저 역시 방향이 정해지기를 기다리기보다 여러 프로토타입을 만들면서, 아이디어를 구체적인 화면과 동작으로 바꾸는 역할을 맡았죠.
처음에는 이런 작업이 실제로 도움이 될지 반신반의했습니다. 하지만 프로토타입이 의사 결정의 참고 자료가 되고, 시도와 판단의 히스토리로 남는 과정을 보며 점차 이러한 시도를 긍정적으로 바라볼 수 있게 됐죠.
개발자가 문제 정의에 참여하는 모습이 꽤 스타트업처럼 느껴져서 좋았지만, 아직까지 서비스의 방향성에 대한 확신이 없었던 만큼 미래에 대한 불안도 여전히 남아 있었습니다.
방향이 바뀌어도 필요한 기반부터 만들기
서비스 콘셉트를 탐색하는 동안에는 회원 체계, 글 작성 등 일반적인 UGC 서비스에 필요한 기반도 미리 구현해보는 시간을 가졌습니다. 앞으로 어떤 방향으로 확장될지 알 수 없는 만큼, 지금 쌓는 기반이 이후의 의사 결정과 서비스의 미래에도 영향을 줄 수 있다고 생각했습니다.
다만 화면 중심의 클라이언트는 백엔드에 비해 범용적인 기반을 미리 만들기가 쉽지 않았고, 구현 비용이 큰 코드가 버려질 수 있다는 불안도 있었습니다. 그래서 당장의 요구사항에만 맞추기보다 앞으로의 선택을 버틸 수 있는 일반적이고 확장 가능한 구조를 만드는 데 더 집중했던 것 같습니다.
기술과 문화의 기준 세우기
마치 게임 문명(Civilization)의 개척자가 된 느낌. 지금 터를 잘 잡는 것이 앞으로의 미래를 좌우한다…!
한편으로 서비스의 방향을 찾는 것만큼, 팀이 앞으로 따를 기술적·문화적 기본 규칙을 정하는 일도 중요했습니다. 이른바 ‘고대의 이름 모를 누군가’가 정해둔 기술 스택과 컨벤션을 그대로 따르는 대신, 우리에게 맞는 베이스 룰을 구성원들의 합의로 처음부터 만들어가는 과정이었죠.
기술적인 측면에서는 빈 저장소에서 시작해 기술 스택과 코딩 컨벤션을 정하고, 당시 막 공개된 Next.js App Router를 비롯한 여러 기술을 꼼꼼하게 검토했습니다. 어떤 기술을 쓸지뿐만 아니라 코드를 어떤 기준으로 작성하고 리뷰할지까지 하나씩 합의해 가며 프로젝트의 기본 구조를 세웠습니다. 문화적인 측면에서는 업무 도구를 사용하는 방식부터 정기 회의와 스크럼 같은 팀 내 규칙까지 함께 정립했습니다.
정답이 없는 문제를 합의로 풀어가는 일은 생각보다 쉽지 않았습니다. 그래도 논의의 근거와 결정 과정을 기록하며 낯선 방식도 조금씩 팀의 익숙한 규칙으로 자리 잡았고, 제가 합의해 만든 규칙인 만큼 더 잘 지키고 싶다는 책임감도 생기더라구요.
사실 대기업에서 기존 서비스의 제품 코드에 의존하지 않고 새로운 코드베이스와 팀의 일하는 방식을 처음부터 만드는 경험이 흔하지는 않거든요. 우리가 일할 방식을 직접 탐색하고 정할 수 있다는 점이 제게는 보람차게 느껴졌습니다.
돌아보면 이 시기를 통해 우리가 풀어야 할 문제와 함께 일할 방식을 먼저 정의하는 일이 얼마나 중요한지 배웠습니다. 이 과정에서 개발팀 역시 프로토타이핑을 통해 막연한 아이디어를 구체화하고, 그 과정에 적극적으로 기여할 수 있다는 점도 알게 되었죠.
서비스의 기본 흐름을 만들기
자 이제 땅은 다졌으니… 다음은 뭘 해볼까?
2024년은 서비스의 기본 흐름을 만드는 시간이었습니다. 회원가입과 로그인, 댓글, 내비게이션, 검색처럼 일반적인 웹 서비스에 필요한 기능을 본격적으로 만들기 시작했습니다.
당연하게 쓰던 기능의 복잡함 이해하기
로그인 페이지와 댓글 페이지
우리가 웹 서비스를 이용하면서 너무나 당연하게 생각하던 기능들이 많죠. 하지만 직접 구현하려니 생각보다 많은 기술적·보안적 고민이 필요하더라구요. 그중에서도 페이스북 소셜 로그인은 많은 공부가 필요했던 기능이었습니다. 화면에 로그인 버튼 하나를 추가하는 단순한 기능처럼 보이지만, 제대로 구현하려면 OAuth와 OIDC 같은 인증 도메인에 대한 이해가 필요했거든요.
저 역시 처음 접하는 개념이 많아 관련 지식을 처음부터 공부해야 했습니다. 그렇게 학습한 내용을 팀에 공유하고, 이후에는 『클라이언트 환경에서 안전한 소셜 로그인을 구현하는 핵심 메커니즘, OIDC와 PKCE 알아보기』라는 글로 정리하기도 했죠. 하나의 기능을 구현하는 데서 그치지 않고, 필요한 지식을 온전히 이해해 다른 사람에게 설명할 수 있게 되었다는 점이 기억에 남습니다.
댓글 입력창의 멘션 기능도 기억에 남습니다. 댓글에는 리치 텍스트 지원이 필요하지 않았고 별도의 마크업 작업이 필요했기 때문에, 에디터 라이브러리 대신 네이티브 contenteditable 요소로 직접 구현했습니다.
DOM 제어 코드를 하나씩 작성하면서 브라우저 호환성 문제까지 겪다 보니, 평범해 보이는 텍스트 입력도 결코 단순하지 않다는 걸 제대로 느꼈죠. (지금 생각해보면 그냥 라이브러리 쓸 걸… 싶기도 하네요.) 이 작업을 하면서 예전에 DEVIEW에서 들었던 스마트에디터 팀의 『중요한 건 꺾이지 않는 마음: 스마트에디터의 도전』 발표가 떠오르기도 했습니다.
이 밖에도 복잡한 회원가입 폼과 웹뷰 대응, 서버 사이드·클라이언트 사이드에서의 오류 처리처럼 서비스의 기본이 되는 기능들을 하나씩 구현해 나갔습니다. 이런 기본기가 하나씩 붙을 때마다 서비스도 조금씩 그럴싸한 모습을 갖춰갔고, 그 과정을 지켜보는 일은 꽤 뿌듯했습니다.
서비스만의 문법 만들기
비표준으로 확장 가능성이 있는 리치 텍스트 구조를 서버에 어떻게 저장할 것인가?
또 하나 기억에 남는 작업은 리치 텍스트를 저장하기 위한 파서와 커스텀 마크다운 포맷을 설계한 일이었습니다. 저장 데이터는 최소화하면서도 서비스의 확장에 대응할 수 있어야 했죠. 그래서 표준 포맷을 그대로 따르기보다, 우리가 직접 통제하며 새로운 요구사항을 수용할 수 있는 형태를 선택했습니다.
입출력이 명확한 파서의 특성을 활용해 처음으로 TDD를 적용해보기도 했습니다. 미리 작성한 테스트는 이후 포맷을 확장하면서 기존 동작을 확인하는 데 도움이 되더라구요. 이 과정에서 데이터 모델링부터 브라우저별 호환성, 단축키와 입력 처리까지 웹 에디터라는 도메인 하나만으로도 고려할 게 끝없이 많다는 걸 새삼 깨달았습니다.
쉽지 않은 영역이었지만, 서비스의 미래를 상상하며 확장 가능한 포맷을 직접 설계하는 과정은 그만큼 재미있었습니다.
돌아보면 이 시기에는 우리가 당연하게 사용하던 기능 뒤에 얼마나 많은 도메인 지식과 의사 결정이 숨어 있는지를 배웠습니다. 낯선 영역이 나오더라도 필요한 지식을 직접 익히고 팀에 공유하면서, 서비스의 기본기를 하나씩 채워가는 과정 자체가 꽤 좋은 경험으로 남았습니다.
도전적 디자인과의 싸움
ThingsBook은 자신의 취향과 일상 경험을 전시하는 공간이었고, 이를 실물에 가깝게 표현하기 위해 스큐어모피즘(Skeuomorphism) 디자인을 적극적으로 활용했습니다. 일반적인 대시보드 형태의 웹사이트와 달리 인터랙티브한 요소가 많아, 클라이언트 개발자에게는 꽤 도전적인 과제였죠.
여기서는 실제 작업 순서보다 성격이 비슷한 작업끼리 묶어, 그중에서도 기억에 남은 인터랙션을 몇 가지 소개해보겠습니다.
첫 번째는 책과 OTT 등의 주제를 실감 나게 진열하기 위한 3D 캐러셀입니다. 포커스와 진행 상태에 따라 회전 각도와 효과가 달라지는 데다, 무한 페이지네이션과 웹뷰·크로스 플랫폼·크로스 브라우저까지 함께 고려해야 했습니다. 구현에 있어서는 캐러셀 라이브러리인 Swiper만 이용했고, 나머지 효과는 모두 네이티브 CSS 또는 JavaScript로 직접 구현했습니다.
처음 디자인을 봤을 때는 솔직히 “와, 이걸 어떻게 구현하지?”라는 걱정부터 들었습니다. 형태가 워낙 독특해 참고할 만한 사례도 찾기 어려웠거든요. 하지만 어떻게든 구현하기 위해 며칠 동안 머리를 쥐어짰고… 덕분에 안 하던 수학 공부도 했네요. 거의 기존 라이브러리를 마개조하는 수준으로 뜯어고친 기억이 납니다.
포트레이트 카드 인터랙션
이외에도 형태는 다르지만, 캐러셀의 진행 상태에 따라 카드가 3D로 전환되는 애니메이션도 만들었구요. 이 작업은 그래도 위 애니메이션보다는 비교적 수월했습니다.
하지만 가장 많은 시간을 투자한 것은 회원가입을 마친 사용자가 관심 주제를 선택하는 온보딩 화면이었습니다.
온보딩 인터랙션
가로·세로형 캐러셀이 한 화면에 겹쳐 돌아가는 동시에 등장과 퇴장, 휠 회전, 드래그 거리에 따른 관성까지 구현해야 했습니다. 거의 모든 버튼과 UI에 개별 애니메이션이 들어가 있었고, 이 모든 동작이 브라우저와 플랫폼에 관계없이 자연스럽게 보여야 했죠.
디자이너와는 1px의 오차까지 함께 짚어가며 다양한 해상도에서도 어색함 없이 동작하는지 확인했습니다. 단순히 디자인을 그대로 옮기는 것보다, 여러 환경에서 같은 인상과 완성도를 전달하기 위해 현미경으로 봐야 보이는 디테일도 신경을 써야 했습니다.
개발자 도구의 레이어 패널에서 회전 애니메이션을 확인하는 모습
가장 어려웠던 부분은 성능 최적화였습니다. 저사양 기기에서는 브라우저가 응답하지 않는 문제가 발생하기도 했기 때문인데요. 화면에 보이지 않는 요소를 DOM에서 제거하고, will-change와 visibility 등의 속성을 활용해 불필요한 렌더링을 줄였습니다. 개발자 도구의 레이어 패널을 열어 애니메이션이 실행되는 동안 각 요소가 어떻게 처리되는지 들여다보며 하나씩 최적화해 나갔습니다.
방망이 깎던 노인이 돼 버린 기분
그래서일까요, 오히려 0%에서 90%까지 구현하는 데 들인 노력보다, 90%를 100%로 끌어올리는 과정이 더 힘들었습니다. 지금 와서 돌아보면 디테일을 놓치고 싶지 않았던 제 성향 때문이었던 것 같지만… 그만큼 애니메이션 구현에 진이 빠졌던 기억도 선명하게 남아 있습니다.
비버 집 부수기
만들고 부수고 만들고 부수고
신규 서비스를 만드는 동안에는 공들여 지은 집을 제 손으로 다시 부숴야 하는 순간이 자주 찾아왔습니다. 서비스의 방향이 바뀌면서 구현을 마친 기능이 폐기되거나, 크게 고쳐서 다시 만들어야 하는 일이 반복됐거든요.
앞서 소개한 포트레이트 카드 인터랙션도 한 번 구현했다가 폐기된 기능이었습니다. 기능 하나를 완성하기까지 적지 않은 시간과 노력이 들어간 만큼, 그렇게 만든 코드가 제가 관여하기 어려운 의사 결정으로 사라질 때면 허무함을 피하기 어려웠습니다.
규모가 큰 기업에서 어느 정도 탑다운 방식의 의사 결정은 불가피하다고 생각합니다. 다만 당시에는 상위에서 결정된 중요 사항이 간접적으로 전파되는 경우가 많아, 실무자로서 그 맥락과 이유를 이해하거나 공감하는 것이 어려운 일이 자주 있었습니다. 그러다 보니 서비스 출시라는 목표도 점점 더 멀게 느껴지더라구요.
명확한 출시일을 알 수 없는 상황에서 완성도에 목매는 것이 지금의 우선순위가 맞는지 의심하기 시작했고, 마라톤의 도착점이 달리는 속도보다 더 빠르게 뒤로 밀려나는 기분이 들었습니다. 그사이 팀의 구성도 여러 차례 바뀌었고, 남아 있는 사람들의 피로도 조금씩 쌓여갔습니다. 조직에 남아 있는 저 역시 “혹시 지금까지 들인 시간이 아까워 떠나지 못하는 건 아닐까?”라는 생각이 들었습니다.
결승점이 무한히 멀어지는 마라톤을 달리는 기분
2025년 초, 새로운 기능을 논의하는 회의를 진행할수록 의욕이 떨어진다는 느낌을 받았습니다. 마치 넘어야 할 산이 끊임없이 나타나는 것 같았고, 가슴이 답답해지면서 무기력감이 몰려왔습니다. 저에게도 번아웃이 찾아온 것이죠. 이때의 감정을 『어느 날, 무기력이 찾아왔다』에서 기록해두기도 했습니다.
그러던 중 글또의 대나무숲에서 저와 비슷한 고민을 담은 글을 발견해 관심 있게 읽어보았습니다. 코드와 자신을 의식적으로 분리해야 한다는 말, 제품의 생명주기를 함께 경험한다는 관점, 그리고 그 과정을 기록해 나만의 자산으로 남기라는 조언이었죠. 당시 질문과 답변을 요약하면 대략 이런 내용이었습니다.
- 질문: 처음부터 공들여 만든 서비스가 회사의 결정에 따라 바뀌거나 다른 곳으로 옮겨진다는 소식을 들으니 마음이 복잡합니다. 내가 만든 코드와 서비스에 애착을 갖는 것이 괜찮은지, 과몰입하지 않으려면 어떻게 해야 할까요?
- 답변: 회사에서 만든 결과물은 결국 회사의 자산이고 언제든 달라질 수 있으므로, 코드와 자신을 의식적으로 분리하는 연습이 필요합니다.
- 답변: 서비스에 애착을 갖는 것은 그 안에 나의 노력과 시간이 담겨 있기 때문에 자연스러운 일입니다. 애정을 억지로 줄이기보다 제품의 생명주기를 함께한 경험을 기록하고, 나만의 자산으로 바꾸어보는 것도 좋습니다.
그렇다고 해서 그 뒤로 구현의 완성도를 낮추거나 일하는 방식을 크게 바꾼 것은 아닙니다. 다만 코드와 서비스는 언제든 달라질 수 있지만, 그 과정에서 얻은 경험만큼은 사라지지 않는다고 생각하며 상황을 받아들이는 마음가짐이 조금 달라졌습니다.
힘들었던 감정을 동료들에게 솔직하게 털어놓고 충분히 쉬었던 것도 회복에 큰 도움이 되었습니다. 함께 일하고 싶은 동료와 맡은 일에 대한 책임감, 그리고 우리가 만든 서비스의 출시를 직접 보고 싶다는 마음이 있었기에 다시 달릴 수 있었습니다.
아이러니하게도 폐기됐던 포트레이트 카드는 이후 다시 살아났습니다. 그때는 그래도 공들인 결과가 빛을 보게 되어 다행이라는 생각이 들더라구요.
돌아보면 제품과 코드에 애착을 갖는 일 자체가 잘못은 아니었습니다. 다만 그 애정을 결과물에만 묶어두지 않고, 서비스의 생명주기를 함께한 경험으로 남기는 방법을 배워가는 과정이었던 것 같습니다. 어쩌면 지금 이 글을 쓰는 일도, 서비스에 쏟은 애정을 제 경험으로 옮겨 담는 과정인지 모르겠네요.
서비스뿐만 아니라 인프라까지
단순히 서비스 로직을 작성하는 것에서 끝나지 않고, 그것을 제공하는 웹 서버의 운영까지 직접.
신규 서비스는 화면과 기능만 구현한다고 끝나는 것이 아니었습니다. 작성한 코드의 품질을 확인하고, 사용자에게 안정적으로 배포하며, 문제가 생겼을 때 빠르게 발견할 수 있는 환경까지 처음부터 마련해야 했습니다.
큰 회사에는 오랜 시간 쌓인 시스템과 절차가 있으니 모든 일이 착착 진행될 거라고 생각하기 쉽습니다. 실제로 전사 차원에서 제공하는 인프라 시스템이 있지만, 개별 서비스의 배포와 운영 환경은 각 개발팀이 직접 관리해야 했습니다.
외부에서 사용하는 일반적인 기술 용어와 사내 도구의 이름이 서로 달랐고, 관련 문서와 정보도 여러 곳에 흩어져 있었습니다. 익숙한 개념을 사내 시스템과 연결하고 필요한 문서와 담당자를 찾아가는 일 자체가 새로운 도메인 학습이더라구요.
저희도 SonarQube를 이용한 정적 분석부터 Docker와 Kubernetes 기반의 배포 환경, GitHub Actions의 Self-hosted Runner를 활용한 CI/CD까지 하나씩 설정해야 했습니다. 여기에 Nginx를 이용한 CDN 구성과 Sentry·Grafana 등의 모니터링, 자체 로그와 이미지·동영상 업로드 도구까지 운영에 필요한 환경을 직접 마련했죠.
저희 팀에는 시니어 실무 개발자가 없었다 보니(…) 초기에는 리더님의 경험에 많이 의지했습니다. 이미 운영 중인 다른 서비스의 설정을 뒤져보며 필요한 지식을 하나씩 익혀나갔습니다.
서비스 출시 이후에는 운영 중인 서비스를 제대로 관찰할 수 있어야 한다는 공감대 아래, 팀원들과 관련 내용을 스터디했습니다. 외부에서 우리 서비스의 도메인을 입력한 순간부터 실제 서비스에 도달하기까지의 흐름을 중심으로 살펴보니, 흩어져 있던 인프라 요소들이 어떻게 연결되는지 이해하는 데 큰 도움이 되더라구요.
모르는 것들이 여전히 많지만, 그래도 이제는 AI와 함께라면…
지금도 인프라가 마냥 친근하지는 않지만, 적어도 한 번의 출시를 끝까지 경험하고 나니 전체 흐름을 바라보는 시야는 생긴 것 같습니다. 아무것도 없던 시절의 막막함을 지나 이제는 서비스가 어느 정도 궤도에 올랐고, 문제가 생겼을 때 어디부터 살펴봐야 할지도 조금씩 알게 되었습니다.
이 경험을 통해 프론트엔드 개발자의 역할을 다시 생각하게 됐습니다. 화면을 구현하는 데서 나아가, 그 화면이 사용자에게 안정적으로 전달되고 문제없이 렌더링되는 환경까지 살피는 것도 프론트엔드 개발자의 역할이겠더라구요.
AI의 발전
그 사이에 AI 없는 업무는 상상하기 힘들게 되어버렸다
프로젝트를 시작한 2023년만 해도 개발 과정에서 AI의 도움을 받았던 기억이 거의 없습니다. 기획을 검토하고 구현 방법을 고민하는 일부터 실제 코드를 작성하고 확인하는 과정까지 대부분 사람이 직접 했죠. 사실 그때는 어느 회사에서 어떤 AI 모델을 만들었는지조차 잘 몰랐습니다.
하지만 2년 10개월이 흐르는 동안, AI가 관여하는 범위는 놀라울 정도로 빠르게 넓어졌습니다. 처음에는 제가 작성한 코드가 적절한지 AI에게 검토받는 정도였지만, 이후에는 테스트 코드 작성은 물론이고 PRD(Product Requirements Document)를 바탕으로 한 실제 기능 구현부터 PR 생성과 리뷰까지 AI가 맡고 사람이 결과를 검토하는 방식으로 역할이 뒤바뀌었습니다.
그렇다고 스펙을 전달하고 결과만 기다리면 항상 좋은 코드가 나오는 것은 아니었습니다. 작업 계획을 작은 단위로 나눠 구체적인 파일로 남기고, 모호한 부분에서는 AI가 임의로 결정하지 않고 사람에게 확인하도록 만드는 과정이 필요했습니다. 코드를 작성하는 일뿐만 아니라 AI가 일을 잘할 수 있는 방식 자체를 설계하게 된 셈이죠.
AI 슬롭도 문제야 문제
때로는 AI가 만든 결과물의 의도를 따라가고 이해하는 일이 직접 작성하는 것보다 더 힘들기도 했습니다. 결국 생성된 결과를 그대로 받아들이는 데서 끝나지 않고, 사람이 다시 읽으며 서비스의 맥락과 기준에 맞게 다듬는 과정도 중요했습니다.
이 과정에서 역설적으로 사람의 도메인 지식이 더 중요하다는 사실도 느꼈습니다. AI가 그럴듯한 답을 내놓더라도 사람이 해당 영역을 모르면 결과를 비판적으로 판단할 수 없고, 결국 그대로 받아들이게 되더라구요. 앞서 인프라 환경을 구성할 때도 AI의 도움으로 기본 설정은 만들 수 있었지만, 그것이 최선인지 확신할 수 없었던 이유가 여기에 있었습니다.
빠른 변화가 반갑기만 했던 것은 아닙니다. 하루가 멀다 하고 새로운 모델과 도구가 등장하다 보니, 흐름을 놓치고 있다는 FOMO를 느끼며 혼란스러웠던 시기도 있었습니다. 업무에서는 회사 내부에서 허용된 AI를 중심으로 사용해야 했기에, 우물 안 개구리가 되지 않으려면 외부의 흐름도 의식적으로 살펴보고 다른 개발자들과 더 많이 이야기해야겠다는 생각이 들었습니다.
결국 AI가 코드를 대신 작성하는 비중이 커질수록, 사람에게는 풀어야 할 문제와 요구사항을 명확히 정의하고 결과를 판단해 다듬으며 그 결과에 책임지는 능력이 더 중요해졌다고 느끼게 되었습니다.
배운 점
결승선 통과!
이번 프로젝트에서 얻은 가장 값진 경험을 하나만 꼽는다면, 힘들고 어려운 순간에도 끝까지 프로젝트에 참여해 서비스를 세상에 내놓은 경험이라고 말하고 싶습니다.
신규 서비스를 만든다는 건 정답이 없는 문제를 계속 풀어나가는 일이고, 그만큼 불확실성이 큽니다. 대기업에는 오랜 시간 쌓인 레퍼런스와 안정적인 프로세스가 많지만, 그렇다고 새로운 서비스의 정답까지 준비되어 있는 건 아니었거든요.
처음에는 주어진 기능을 잘 구현하고 완성도 높은 코드를 만드는 것이 제 역할이라고 생각했습니다. 하지만 여러 차례의 프로토타이핑과 방향 전환을 겪으면서, 요구사항이 모호할 때 필요한 일을 찾고 낯선 도메인을 스스로 학습하며 기술적으로 어려운 기능을 설계부터 구현까지 책임지는 경험을 쌓았습니다. 이제는 필요한 도움을 구하면서도, 맡은 영역에서는 스스로 판단하고 끝까지 책임질 수 있다는 자신감도 생겼구요.
기술적인 성장만큼이나 저 자신에 대해서도 많이 알게 됐습니다. 하나의 어려운 문제를 깊이 파고들어 완성도를 높이는 일은 잘하지만, 목적이 불분명하고 방향이 자주 바뀌는 상황에서는 쉽게 소모된다는 점을 깨달았죠. 비슷한 상황을 다시 만난다면 제가 통제할 수 있는 범위에 집중하고, 회사의 결정과 코드의 운명을 저 자신과 분리하면서 힘들어지기 전에 상황을 적극적으로 공유하려 합니다.
무엇보다 이 시간을 끝까지 버틸 수 있었던 건 함께한 팀원들 덕분이었습니다. 누군가 자리를 비우거나 각자 어려운 시기를 보내는 동안에도, 남은 사람들이 빈자리를 자연스럽게 채우며 해야 할 일을 착착 해내는 모습을 여러 번 보았습니다. 같은 고생길을 오랫동안 걷다 보니 서로를 더 잘 이해하게 되었고, 나중에는 척하면 척이 되는 관계가 되더라구요.
복잡한 화면과 인터랙션을 완성해준 마크업 개발자, 다양한 기기와 환경에서 미처 발견하지 못한 문제를 찾아준 QA 팀과의 협업도 있었는데요. 원하는 기능을 화려한 디자인 안에 자연스럽게 담는 일은 기술 구현만으로 해결되지 않았고, 기획과 디자인, 개발, QA 중 어느 한 역할만으로는 서비스를 출시할 수 없다는 사실을 새삼 느꼈습니다.
큰 규모의 회사에서 팀의 규칙을 정하는 일부터 서비스의 설계와 개발, 배포와 운영까지 경험할 기회는 흔하지 않습니다. 그런 의미에서 이번 프로젝트는 제 개발자 커리어에 오래 남을 중요한 이정표가 되었다고 생각합니다. 기술적으로도 감정적으로도 여러 번 흔들렸지만, 결국 서비스를 세상에 내놓는 순간까지 함께했다는 사실이 뿌듯합니다.
고생해서 나온 서비스인 만큼 잘 되길 바라며
물론 저 혼자 만든 서비스는 아니지만, 오랜 시간 함께 만들고 세상에 내놓은 만큼 어쩐지 제 자식(?)처럼 느껴지기도 합니다. 저의 0 to 1 은 이렇게 마무리됐지만, 이제부터 시작될 1 to 100 의 여정도 오래 지켜보고 싶은 마음입니다.
