들어가며
2025년도 마무리가 되었습니다.
작년에는 올해도 기존과 같이 모바일웹을 운영하면서 조금씩 고도화해나가는 한 해가 될 거라고 생각했었는데요, 실제로는 그 예상과는 꽤 다른 방향으로 흘러갔어요. 계획했던 것들을 하나씩 해나가기도 전에, 예상치 못한 큰 프로젝트가 저를 기다리고 있었거든요.
기획자도 디자이너도 없이, 프론트엔드 혼자서 판매자센터를 처음부터 만들어야 하는 상황을 맞닥드리게 되었어요. 코드를 짜는 것뿐만 아니라 일정을 잡고, 요구사항을 스스로 도출하고, 오픈 계획까지 주도해야 했죠. 개발자로서 해본 적 없는 역할들이었는데, 돌이켜보니 그 과정이 올해 가장 큰 성장의 이유가 된 것 같습니다.
한편으로는 Claude Code를 실무에 본격적으로 도입하면서 "내가 정말 개발을 하고 있는 건가?"라는 낯선 감정도 처음 느꼈어요. 개발자로서의 정체성을 다시 생각해보게 된 한 해이기도 했습니다.
그래서 올해 회고는 단순히 "이런 걸 했다"는 기록보다는, 이 과정에서 제가 무엇을 배우고 무엇을 발견했는지에 초점을 맞춰서 써보려고 해요.
올해의 핵심: 판매자센터를 만들다
어떻게 시작됐냐면
시작은 쿠팡의 상품등록 API 스펙 변경이었어요.
당시 타이밍이 정말 안좋았는데, 저희 회사가 티메프 사태로 직격탄을 맞은 상황이었거든요. 당시에 티메프사태 대금문제와 함께 티몬, 위메프, 인터파크몰 등 큐텐 계열 제휴사들을 한꺼번에 잃으면서 회사 전체가 어수선한 시기였는데, 설상가상으로 쿠팡이 상품등록 API 스펙을 변경한다는 공지가 떴어요. 새 스펙대로 옵션 구조를 바꾸지 않으면 상품 연동 자체가 안 되거나 판매자 제재를 받을 수 있다는 내용이었어요. 제휴사들을 잃은 상황에서 쿠팡과의 원활한 연동은 선택이 아니라 필수였기 때문에, 빠르게 대응해야 했습니다.
저희 서비스는 React 기반의 모바일웹과 PHP로 된 PC 버전이 따로 있는데요, 쿠팡 대응 작업은 제가 담당하는 React 쪽에서 먼저 진행했어요. PHP 쪽은 구조상 손을 대기가 워낙 까다로웠기 때문이예요. PHP 개발자분께서 "이건 건드리기 힘들다"는 입장이셨고, 결국 PHP의 상품등록 단을 닫는 방향으로 결론이 났습니다.
다행히 시간이 흐르며 구옵션에 대한 쿠팡의 제재 수위가 예상보다 낮아졌어요. 처음엔 연동 차단이나 패널티까지 우려했는데, 실제로는 노출이 조금 불리해지는 수준으로 정리됐거든요. 그 덕분에 백엔드팀이 20여 개 제휴사 연동 작업을 진행할 시간을 벌 수 있었고, 저도 백엔드의 개입을 최소화하면서 판매자센터를 만들 수 있는 여건이 생겼어요.
갑자기 일정을 내가 짜고 있었다
프로젝트를 진행하면서 예상치 못한 일이 생겼어요. 어느 순간부터 제가 일정을 잡고 있더라고요.
오픈 계획을 세워야 할 시점에, 개발자 회의에서 오전 내내 이야기해도 구체적인 결론이 나지않고, 회의가 헛도는 느낌이 들었어요. 이대로 오후 회의에 들어가면 또 같은 상황이 반복될 것 같아서, 그 날 점심도 거르고 오전 회의에서 나왔던 내용을 기반으로 테스트 범위와 일정을 정리해갔어요.
1차 내부 테스트, 2차 베타 유저 테스트, 1차 오픈, 2차 오픈, 구·신 시스템 병행 기간까지 단계별로 쪼개서 일정을 잡았고, 오후 회의에 그걸 들고 갔더니, 적어도 제가 작성한 초안을 기준으로 두고 이야기할 수 있어서 의견이 빠르게 좁혀졌어요.
원래 일정 산정이나 리스크 관리는 제 일이 아니라고 생각했는데, 막상 해보니 "내가 가장 잘 알고 있는 사람이니까 내가 해야 하는 일"이었더라고요. 그 경험이 꽤 묵직하게 남았어요.
기술적으로 고민했던 것들
아키텍처 결정 중 가장 컸던 건 "새 프로젝트를 만들 것이냐, 기존 모바일웹 코드베이스에 얹을 것이냐"였어요. 사실 마음같아서는 정석대로 새로 프로젝트를 구성하고 싶었지만, API 재연동에 도메인 작업까지 백엔드 리소스가 또 필요해지고, 회원 인증부터 다시 개발해야 하니 범위가 커져서 공수를 줄이는게 가장 중요했던 당시의 급박한 상황에서는 맞지 않았어요. 그래서 결국 기존 코드베이스에 판매자 기능을 통합하는 방향을 선택했고, 일반 유저와 판매자 유저의 라우트를 분리해서 권한별 접근 제어를 구현했습니다.
백엔드 협업에서도 예상 밖의 상황이 많았어요. 쿠팡·네이버 옵션 스펙을 제가 직접 분석해서 API 스펙을 문서로 공유했고, 그걸 기반으로 Mock 데이터로 프론트 개발을 먼저 시작했는데요. 막상 실제 백엔드 작업이 나왔을 때 제가 제안했던 스펙과 달라진 부분들이 꽤 있었어요.
돌이켜보면 저는 한 번 명확하게 전달하면 된다고 생각했던 것 같아요. 이미 이야기된 사항을 또 꺼내면 독촉하는 것처럼 느껴질 수 있다는 생각에, 나름 배려한다고 했던 거였는데요. 근데 이 경험을 겪고 나서 생각이 바뀌었어요. 중요한 부분일수록 자주 소통하고 팔로우업하는 게 오히려 서로에게 더 편한 방식이더라고요. 그 이후로는 백엔드와 더 자주, 더 자연스럽게 소통하는 걸 의식적으로 챙기게 됐습니다.
오픈하고 나서야 진짜 시작이었다
오픈일에는 솔직히 많이 긴장했어요. 1년 가까이 거의 혼자 만든 프로젝트였으니까요. 괜히 큰 오류가 터질 것 같고, 뭔가 준비가 덜 된 것 같은 기분이 계속 들었어요. 하지만 제 우려와는 달리 다행히 큰 장애 없이 오픈했고, 쿠팡 연동 상품 수도 2개월 만에 7만 건에서 8만 5천 건을 넘길 수 있었어요.
하지만 진짜 싸움은 오픈 후에 시작됐어요. 내부 테스트에서는 괜찮았던 것들이 실제 유저 피드백으로 돌아오면 완전히 달랐거든요. 사실 테스트를 하면서 "이거 조금 불편할 수도 있겠는데?" 싶었지만 오픈일을 지키기 위해 넘어갔던 부분들은 어김없이 개선 요청이 들어왔어요.
그래도 이런 메시지를 받았을 때는 진짜 뿌듯했어요.
새로 도입된 파트너스를 통해 리스팅을 진행하고 있습니다.
어려운 시기에 판매 프로그램을 개선해 주신 점 진심으로 감사드립니다.
한 가지 수정 요청 사항이 있어 전달드립니다. 현재 왼손 아이언세트를 입력할 경우, ..(후략)...
이렇게 피드백과 함께 감사 인사를 해주시는 분들이 계셨는데, 그 메시지들 덕분에 힘이 많이 났습니다. 완성도를 높이고 싶은 마음과 빨리 내보내야 한다는 현실 사이에서 계속 타협해야 하는 건 여전히 어려웠지만, 유저의 불편을 직접 해소하는 과정이 생각보다 재미있었어요. 코드를 짜는 것과는 다른 종류의 보람이었습니다.
이 프로젝트로 내가 발견한 것
요청의 행간을 읽는 것
판매자센터를 운영하면서 유저 피드백을 직접 받다 보니, 요청을 해석하는 게 생각보다 중요한 일이라는 걸 알게 됐어요.
한번은 이런 피드백이 들어왔어요.
상품 리스트에서 가격을 바로 수정할 수 있는 기능이 있었으면 합니다.
2번에 추가하여 재고가 다량인 제품의 재고 수정도 편하게 되었으면 합니다.
팀에서는 "재고가 다량인 제품의 재고수정을 원하시니, 기존에 있는 엑셀 대량 수정 기능을 안내드립시다"라는 의견이 나왔는데, 저는 다르게 읽혔어요. '2번에 추가하여' 라는 표현을 쓴 걸 보니, 엑셀이 아니라 상품 리스트 화면에서 가격과 재고를 함께 바로 수정하고 싶다는 거구나 싶었거든요.
기획자 없이 유저 피드백을 직접 분석하다 보니 자연스럽게 생긴 감각인 것 같아요. 요청을 그대로 받아들이기보다, 이 사람이 실제로 불편한 게 뭔지를 먼저 생각하는 습관이 생겼습니다.
UX를 먼저 생각하는 개발
기획자도 디자이너도 없는 환경이었지만, 오히려 그래서 사용자 경험을 더 많이 고민하게 됐어요.
가장 기억에 남는 건 브랜드 선택 UI예요. 브랜드가 많다 보니 검색 기능도 추가하고, 자주 쓰는 브랜드를 모아놓은 "주요 브랜드" 탭도 만들었어요. 나름 잘 만들었다고 생각했는데, 막상 유저 반응은 달랐어요. 주요 브랜드를 디폴트 탭으로 뒀더니, 정작 유저들은 알파벳순으로 전체를 보는 전체 탭이 더 편하다고 하더라고요. 제가 편하다고 생각한 것과 유저가 편한 게 달랐던 순간이었어요.
임시저장 기능도 반응이 좋았어요. 상품등록 페이지는 입력 필드가 많아서 이탈하거나 새로고침하면 데이터가 전부 날아가거든요. 기존 PHP에는 없던 기능이었는데, 추가하고 나서 유저의 반응이 좋았던 기능 중 하나입니다.
제가 편하다고 생각하는 것과 유저가 편하다고 느끼는 것이 다를 수 있다는 걸 계속 의식하면서 개발했던 것 같아요. 요청이 들어오면 그것만 구현하는 게 아니라, 한 발짝 더 나아가서 생각하는 습관이 이때 생겼습니다.
나서야 할 때 나서는 것
저는 사실 처음부터 앞에 나서는 스타일은 아니었어요. 하지만 이 프로젝트를 하면서 "누군가 해야 한다면 내가 하자"는 순간들이 꽤 있었어요. 일정 초안을 점심시간에 혼자 짜서 들고 간 것도 그렇고, 백엔드 API 스펙을 제가 먼저 분석해서 제안한 것도 그랬던 것 같아요. 반장보다는 부반장 같은 느낌으로, 막혀있는 부분에서 물꼬를 트는 역할이 저한테 맞는 방식인 것 같다고 생각하고 있습니다.
AI 도구와 함께 일한 한 해
올해 개발 방식에서 가장 큰 변화를 꼽으라면 단연 Claude Code 도입이에요.
작년까지는 ChatGPT를 보조 수단 정도로만 썼는데, Claude Code는 결이 달랐어요. Claude Code를 사용하니 개발에 있어서 확실히 속도가 붙었고, 그만큼 더 중요한 문제에 집중할 수 있는 시간이 생겼어요.
근데 솔직히 처음엔 묘한 감정이 들었어요. AI가 코드를 척척 써주는 걸 보면서 "내가 지금 개발을 하고 있는 건가?"라는 생각이 드는 거예요. 주변 개발자들도 비슷한 이야기를 많이 하더라고요. "AI 가 다 해주니까 공부 의욕이 떨어진다", "몇 년 후엔 개발자가 필요할까?" 같은 고민들이요.
그런데 판매자센터를 만들면서 생각이 조금 바뀌었어요. 그 프로젝트에서 정말 어려웠던 건 코드를 짜는 게 아니었거든요. 요구사항을 스스로 도출하고, 유저 피드백을 해석하고, 일정을 잡고, 백엔드와 조율하는 것들이었어요. AI가 대신해줄 수 없는 영역들이었죠.
결국 AI를 잘 쓰려면 오히려 기본기가 더 중요하다는 걸 느꼈어요. 무엇을 만들어야 하는지, 왜 이 구조가 맞는지를 알아야 AI한테 제대로 된 걸 요청할 수 있으니까요.
그리고 쓰다 보니 또 다른 걸 깨달았어요. AI를 잘 활용하는 것 자체도 아무나 하는 게 아니더라고요. Claude Code의 commands를 활용해서 커밋 메시지나 PR 작성을 자동화하고, GitHub Copilot이 PR에 남긴 리뷰를 Claude Code가 재검토해서 코멘트를 달도록 온디맨드 방식으로 워크플로우를 만들기도 했는데, 이런 걸 세팅하고 나니까 "그냥 쓰는 것"과 "잘 쓰는 것" 사이의 간격이 꽤 크다는 걸 실감했어요.
마침 Claude Code를 활용한 예측 가능한 바이브 코딩 전략이라는 글을 읽었는데, LLM의 인지적 한계를 시스템으로 보완한다는 관점이 인상적이었어요. Todo로 누락을 방지하고, Plan 모드로 방향을 먼저 검증하고, CLAUDE.md로 컨텍스트를 관리하는 방식들이요. AI를 두려워하기보다 어떻게 하면 더 잘 쓸 수 있을지를 고민하는 게 지금 시점에서 훨씬 생산적인 것 같아요.
올해의 아쉬움과 앞으로의 다짐
판매자센터 오픈이라는 큰 성과가 있었던 만큼, 반대로 소홀해진 부분들도 있었어요.
작년에는 재직자 부트캠프까지 신청하면서 나름 열심히 공부했던 것들이, 올해는 프로젝트가 바쁘면 바쁜 대로 한숨 돌리면 돌리는 대로 조금씩 흐지부지됐어요. 블로그도 마찬가지였고요. 쓰고 싶은 주제는 많았는데 막상 글로 옮기는 게 생각보다 잘 안되더라구요..
그래서 내년에는 두 가지를 챙겨보려고 해요.
하나는 아웃풋이에요. 기술 아티클도 읽고, 실무에서 몸으로 익힌 것들도 꽤 있었는데, 어딘가에 남겨지지 않으면 흔적이 안 남더라고요. 완벽하게 써야 한다는 생각을 내려놓고, 일단 쓰는 것부터 해보려고 합니다.
다른 하나는 AI 활용이에요. Claude Code를 쓰면서 단순히 코드를 생성하는 것 이상으로 활용할 수 있다는 걸 올해 조금씩 느꼈거든요. 잘 쓰는 것과 그냥 쓰는 것 사이의 간격이 생각보다 크더라고요. 내년에는 더 깊이 파고들어보고 싶어요.
2025년은 예상치 못한 방향으로 흘러갔지만, 그 덕분에 제가 어떤 개발자인지를 조금 더 알게 된 한 해였어요. 2026년에는 그걸 바탕으로 더 단단해지는 한 해가 되었으면 좋겠습니다.