[카카오테크 캠퍼스] 2025년 회고

한해를 돌아보며

어느덧, 치열했기에 그만큼 더 보람찼던 2025년이 저물어가고 있다. 올해는 내 개발자 인생의 '터닝 포인트'라 불러도 부족함이 없을 만큼 거대한 변화가 있었다. 이번 회고의 중심, 아니 사실 내 2025년의 모든 순간에는 '카카오테크 캠퍼스'가 자리하고 있다. 웹 개발을 시작한 지 1년도 채 되지 않은 시점이었지만, 좋아하던 리그오브레전드 게도 과감히 삭제하고 프로젝트에 온 힘을 쏟아부으며 '성장의 밀도'를 극한으로 높였던 시간들이었기 때문이다. 그 과정에서 감사하게도 훌륭한 멘토님들과 귀한 인연을 맺었고, 수료한 지금까지도 소중한 가르침을 주고받으며 인연을 이어가고 있다.

사실 나는 어릴 적부터 글쓰기를 참 좋아했는데, 이번 부트캠프를 거치며 기록과 회고가 주는 힘을 다시금 체감하게 되었다. 그동안은 부트캠프가 100% Notion 기반으로 운영된 탓에 회고나 테크 문서들을 개인 공간에 묵혀두기만 했었지만, 이제는 블로그를 완성했으니 세상 밖으로 꺼내보려 한다. 비록 지금은 화려한 기술적 깊이보다는 학생 개발자의 치열한 고민이 주를 이루겠지만, 이 2025년 회고를 시작으로 나의 성장 궤적을 꾸준히 기록해 나갈 예정이다.

1. 2025 1분기

1. 블로그 기획

커스텀 블로그 첫번째 포스트에도 언급을 했었는데, 지금 하고 있는 개발이 정말 즐겁고, 즐거운 만큼 많은걸 해보고 싶었다. 내가 처음 프론트엔드를 개발하며 가장 재밌었던 점은 내 생각이 웹 서비스에 그려지는 과정, 결과 모두에 있었다. 물론 지금도 그 이유로 프론트엔드 개발을 사랑하고 있다. 첫 프로젝트도 그렇고 그동안은 모든 개발을 html, css, javascript만을 사용하고 실행도 로컬호스트에서만 실행했었다. 정확히는 24년 12월 쯤에 React와 Nextjs, Rest api에 대해 접하게 되었고, 나만의 커스텀 블로그를 기획하게 되었다.

내가 블로그를 개발하게된 이유는 몇 가지가 있다.

첫째로, 프론트엔드의 핵심을 깊이 있게 경험하고 학습하기엔 '블로그'만 한 프로젝트가 없다고 판단했다. 프론트엔드의 숙명과도 같은 SEO(검색 엔진 최적화)는 블로그의 생존 필수 요소이며, 디자인 시스템(CSS) 구축부터 상황에 맞는 렌더링 전략(CSR, SSR, SSG, ISR) 선택, RDB와 REST API 설계, 그리고 사용자 친화적인 UI/UX와 성능 최적화까지. 블로그는 이 모든 요소를 종합적으로 고려해야 하는 프로젝트이기에, 개발 과정 자체가 나에게 큰 성장을 가져다줄 것이라 확신했다.

Nextjs Caching guides

두번째 이유로는 단순히 내 고유 도메인의 블로그를 갖고 싶었다. 나는 글쓰는 것을 정말 좋아하고, 첫 프로젝트에서 그 프로젝트에 대해 고민하고 개발했던 과정을 회고로 작성하면서 개발에서 얻었던 재미와는 별개의 재미가 있었다. 티스토리나 vlog등에 글을 작성하면 정말 편리하겠지만, 나만의 고유 도메인을 가질 수 없는 것은 물론이고, 정해진 테마 안에서만 디자인해야 하는 답답함, 원하는 기능을 자유롭게 추가할 수 없는 확장성의 한계, 그리고 서비스 정책에 따라 내 데이터가 영향을 받는 점들이 마음에 들지 않았다. 나는 내 마음대로 조정가능하고, 계속 운영하면서 성장할 수 있는 블로그를 갖고 싶었다.

우선 블로그를 운영하기 위해 정말 많은 공부와 시도를 해보게 되었다. 웹 개발을 공부한지 4달도 안된 시점이었기 때문에 전문 지식은 없었지만, 개발에 대한 흥미 덕분이었을까, 하루종일 공부하고 찾아보고 해도 지치지 않았던것 같다. 우선 블로그 운영에 돈이 들어가면 부담스러울 것 같아 최적의 결과를 내기 위해 많은걸 찾아봤던 것 같다. 하나둘 찾아보다 보니 Nextjs, Vercel, AWS 등 여러 기술스텍에 대해 연구하게 되었고, 프로젝트의 ‘배포’에도 자신이 생기게 되었다. 이론상 티스토리,vlog같은 비개발자도 운영가능하면서 zero cost운영이 가능한 블로그에 근접하기 시작했다.

2. 블로그 구현 과정

“어떻게 만들면 깔끔한 디자인을 만들 수 있을까?”를 고민하면서 정말 많은 블로그 디자인들을 참고했고, “내가 개발하기 편한 방법보단 어떻게 만들면 사용자들이 찾아보고 싶은 글을 쾌적하게 사용할 수 있을까?”를 생각하며 설계했다.

솔직히 기획 단계에서도, 구현 단계에서도 정말 재미있었다. 블로그도 구축하면서 그 과정에서 얻은 많은것들을 짧게 기록하기도 했다. 새로 얻게 된 정보나 최적화 및 에러 해결 과정에서 얻은 영감을 스크린샷을 찍고 간단히 그날 그날 기록해 두었다.

블로그를 구축하면서 가장 먼저 도입한 건 역시 카테고리였다. 처음에는 3-depth까지 고려했으나, 깊이가 깊어질수록 데이터를 추출하고 관리하는 과정이 불필요하게 복잡해졌다. 결국 포스트와 카테고리를 1:1 관계로 단순화하고, 부모 카테고리를 통해 자식만 불러오는 2-depth방식으로 테이블을 구성했다.

하지만 카테고리 구조만으로는 포스트를 나누는 기준이 너무 모호했고, 사용자가 원하는 글을 찾으려 해당 카테고리 페이지까지 이동해야 하는 불편함이 있었다.

이 문제를 해결하기 위해 태그(Tag) 시스템을 도입해 포스트와 다중 관계를 맺도록 했고, 페이지 이동 없이 즉각적으로 반응하는 CSR 기반의 검색 기능을 구현했다. 사용자가 '태그'로 접근했는지, 단순 '제목'으로 검색했는지에 따라 UI가 유연하게 바뀌도록 처리했다.

TYPESCRIPT

{/* 검색어(searchQuery)와 검색 타입(tag/title)에 따라 헤더가 동적으로 변경됨 */}
<h1 className="...">
  {searchQuery 
    ? `"${searchQuery}" ${searchType === "tag" ? "Tag" : "제목"} 
    검색 결과 (${posts.length})`: "Archive"}
</h1>

TYPESCRIPT

{/* 태그 모드(isTagsMode)일 때만 전체 태그 목록을 렌더링 */}
{isTagsMode && (
  <>
    <TagsOverview tags={allTags} />
    <div className="..."></div>
  </>
)}

상태에 따라 헤더 텍스트를 분기 처리하여, 사용자가 현재 어떤 맥락에서 리스트를 보고 있는지 직관적으로 알 수 있게 구현했다. 결과적으로 손이 비교적 많이 가는 카테고리 탐색도 유지하며 User가 원하는 방식으로 원하는 글에 빠르게 도달할 수 있는 구조가 완성되었다.

3. 카카오테크 캠퍼스 3기에 지원하다

나는 방학 중 블로그를 만들다 우연히 카카오테크 캠퍼스 3기 모집 공고를 접했고, 웹 개발의 재미 뒤편에 해소되지 않는 갈증을 느끼던 차에 지원하게 되었다.

지원 동기는 크게 두 가지였다. 첫째는 성장을 위한 인맥이었다. 단순한 친목이 아닌, 빅테크 현업에 계신 멘토님들과의 접점, 그리고 대학생 수준에 안주하지 않고 치열하게 고민하는 동료들을 만나고 싶었다. 개발자의 성장은 코딩 실력뿐 아니라 커뮤니케이션과 네트워크에서 비롯된다고 믿었기 때문이다.

둘째는 AI 의존도를 낮추고 '진짜 실력'을 키우기 위해서였다. 사소한 구현조차 AI에 기대고, AI가 제안하는 코드가 적절한지 판단조차 못한 채 "동작만 하면 그만"이라는 식으로 넘어가곤 했다. 겉보기에 번듯한 결과물로 칭찬을 받아도, 정작 속을 들여다보면 "이걸 내가 구현한 게 맞나" 싶은 상실감이 컸다. 빠른 출시보다 유지보수성과 본질적인 코드를 고민하는 개발자가 되고 싶었다.

4. 지원에 사용할 프로젝트 구현

사실 나는 개발을 정말 싫어했었다. 코로나 학번으로 입학해 검은 콘솔 창에 텍스트만 찍히는 프로그래밍을 처음 접했을 때, 흥미는커녕 진지하게 반수까지 고민했을 정도였다.

본격적인 웹 개발을 시작하기 전까지 내 경험이라곤 C++로 콘솔 게임을 만들거나 자료구조를 구현하는 전공 과제가 전부였다. 당연히 누군가에게 내세울 만한 프로젝트도, 포트폴리오에 채워 넣을 이력도 없었다. 그러다 우연히 웹 개발을 접하며 처음으로 재미라는 걸 느꼈다. 흥미가 생기니 자연스레 압도적인 시간을 쏟게 되었고, 싫어하던 프로그래밍의 원리들도 비로소 이해되기 시작했고 모든게 재밌어지기 시작했다. 그렇게 막연하기만 했던 개발자라는 꿈은 점차 선명하고 구체적인 현실이 되었다. 이후 협업 프로젝트에서 프론트엔드 개발을 맡으며 작지만 소중한 노력의 결과물들을 하나둘 쌓아갈 수 있었다.

그러던 중 카카오테크 캠퍼스 지원이라는 기회가 찾아왔다. 간절히 참여하고 싶었지만, 이력서나 포트폴리오를 제대로 갖춰본 적도, 정식으로 어딘가에 지원해본 경험조차 없던 터라 고민이 깊어졌다. 합격을 위해서는 지원하는 곳의 가치관을 파악하는 것이 우선이라 생각했다. 카카오테크 캠퍼스 OT를 지켜보니 1시간 동안 '성실도'와 '마음가짐'을 계속 강조하는 것을 확인할 수 있었다.

나는 전략을 세웠다. 짧은 기간일지라도 내가 얼마나 치열하게 기술 스택을 익혀왔는지 결과물로 증명해 내 진심을 보여주기로 한 것이다. 시간이 촉박했기에 기획은 내 첫 웹 프로젝트에서 영감을 얻었다. 처방전을 AI로 분석해주던 초기 아이디어를 발전시켜, 약 사진을 업로드하면 성분과 특성을 분석해주는 서비스를 기획하게 되었다.

시간이 촉박했기에 기획은 내 첫 웹 프로젝트에서 영감을 얻었다. 처방전을 AI로 분석해주던 초기 아이디어를 발전시켜, 사용자가 약 사진을 업로드하면 성분과 특성을 즉시 분석해주는 'MediScan' 서비스를 기획했다.

이번 프로젝트는 프론트엔드 트랙 지원을 위한 도전이었기에, 백엔드 로직을 직접 구현하는 데 시간을 쏟기보다는 프론트엔드의 숙련도와 클라우드 인프라 활용 능력을 증명하는 데 집중했다.

우선 Next.js 15의 App Router를 도입했다. (marketing)과 (dashboard)로 라우트 그룹을 나누어 구조적인 설계를 진행했고, 미들웨어를 활용해 인증 상태에 따른 페이지 접근 제어를 구현했다. 또한 AWS Cognito와 JWT를 연동하여 배포시에도 동작하는 인증·인가 시스템을 구축했으며, 사용자 프로필 관리에는 API Gateway와 Lambda를 활용해 서버리스 아키텍처를 적용했다.

프론트엔드 지원자로서 특히 신경 쓴 부분은 사용자 경험(UX)이다. 단순히 기능을 구현하는 것에 그치지 않고, 다양한 기기에서 매끄럽게 동작하도록 반응형 디자인을 설계했다. 데스크탑부터 모바일까지 어색함 없는 UI를 제공하기 위해 공을 들였고, 이는 곧 내가 프론트엔드 개발자로서 가진 열정을 보여줄 수 있는 결과물이 되었다.

새로 만든 프로젝트를 포함해서 대략 3개의 프로젝트에 대해 내가 기여한점과 해결한 문제를 정리해서 첫 포트폴리오를 만들었고, 다행히 좋게 봐주셨는지 1차에 합격할 수 있었고, 그 후의 과정도 최선을 다해 참여했고, 다행히 프론트엔드 트렉으로 카카오테크 캠퍼스 3기에 참여할 수 있었다.

2. 1단계 웹 개발 기초 교육

내가 참여한 카카오테크 캠퍼스는 3기였고, 앞선 두 번의 기수를 거치며 커리큘럼이 어느 정도 안정적으로 정착된 상태라는 인상을 받았다. 90분에 걸친 OT에 참여하면서, 그동안 정말 들어오고 싶었던 부트캠프에 내가 실제로 와 있구나 하는 실감이 조금씩 들기 시작했다. 이때부터 2025년 한 해를 이곳에 온전히 집중해보자는 마음을 먹게 되었다.

1년간의 과정을 간략히 정리해보면 총 3단계로 나뉜다. 학기와 병행하는 1단계에서는 매일 온라인 강의를 수강하고, 주기적으로 수업이 끝나는 저녁 7시부터 2~3시간 정도 실시간 강의를 듣는 방식으로 진행된다. 방학 기간에 해당하는 2단계에서는 학기 부담이 없는 만큼, 하루 종일 개발에 몰입해야 하는 과제들이 주어진다. 마지막 3단계에서는 다시 실시간 강의를 병행하며, 같은 학교 팀원들과 함께 하나의 프로젝트를 완성해 나가게 된다.

앞으로의 과정을 무사히 수료하기 위해 필요한 강의와 과제가 중심이 되는 단계가 바로 첫 번째 단계였다. 프론트엔드 트랙에서는 웹의 기초 뼈대라 할 수 있는 HTML, CSS, JavaScript를 깊이 있게 다루고, 이어서 React의 기초·숙련·심화 과정, Git, 그리고 프론트엔드 실무 코딩까지 폭넓게 학습하게 된다. 수료 조건 또한 명확했는데, 모든 온라인 강의와 실시간 강의에 참여해야 했고, 두 차례의 구현 과제와 마지막 수료 성취도 평가를 통과해야만 다음 단계인 2단계로 넘어갈 수 있었다.

사실 카카오테크 캠퍼스에 들어오기 전에는, AI가 코드를 꽤 잘 작성해 주는 시대에 굳이 이론을 깊게 알고 있어야 할까 하는 생각도 가지고 있었다. 하지만 실제로 학습을 진행하면서 느낀 점은 달랐다. 과도한 AI 의존은 오히려 도움이 되지 않았고, 언어와 개념을 어느 정도 이해한 상태에서 프롬프트를 작성했을 때 학습과 작업의 효율이 눈에 띄게 올라갔다. 그리고 25년 회고의 첫 부분에서 언급했듯이, 나는 AI를 어디까지나 보조 도구로 활용하고 싶었기 때문에 과제나 공부 과정에서는 최대한 AI 사용을 자제하려고 했다. 대신 그날 그날 공부한 내용을 TIL(Today I Learned)로 꾸준히 기록하기 시작했고, 이 습관이 이후 학습의 기반이 되어주었다.

첫 번째 과제였던 '순수 JavaScript 기반의 영화 검색 사이트 구현'은 픽셀 단위의 정밀함에 집착하며 프론트엔드의 기본기를 밑바닥부터 다지는 시간이었다. 외부 라이브러리 없이 index.html의 뼈대를 세우고, 요소 간의 간격과 타이포그래피를 1px의 오차 없이 맞추려 노력했다. 특히 card.css에서 미디어 쿼리를 세분화하여 화면 크기에 따라 레이아웃이 유연하게 변하도록 반응형 디자인을 설계했다. 또한 api.js에서는 국문 줄거리가 없을 때 영문 데이터를 가져오는 Fallback 로직을 구현하고, ui.js에 이벤트 위임을 적용해 수많은 영화 카드의 이벤트를 효율적으로 제어하는 등 성능과 UX를 동시에 고민했다.

1단계 과제에서 수행한 기본기는 두 번째 과제인 'React 기반의 포켓몬 도감 구현'에서 더 견고한 설계로 이어졌다. 1단계에서 익힌 정교한 레이아웃 감각을 Dashboard.jsx와 PokemonList.jsx의 Styled-components에 녹여내어, 어떤 해상도에서도 포켓몬 슬롯이 무너지지 않는 반응형 환경을 구축했다. 상태 관리 측면에서는 초기 PokemonContext.jsx를 활용한 방식에서 더 나아가, Redux Toolkit의 createSlice를 도입해 예측 가능한 상태 변화를 설계했다. 특히 PokemonCard.jsx에서는 e.stopPropagation()을 사용하여 이벤트 버블링을 방지하고, addPokemon 리듀서 내에서 중복 선택과 최대 개수 제한 로직을 철저히 검증하는 등, 데이터의 무결성을 지키기 위해 노력했다.

결국 1단계의 모든 과정은 ‘무엇을 만들 수 있는가’를 넘어, ‘얼마나 정확하고 깊이 있게 이해하고 있는가’를 증명하는 시간이었다. 두 번의 과제에서 모두 우수한 성적을 받았고, 난이도 자체는 높지 않았지만 1단계 최종 성취도 평가 역시 만점으로 수료하며 만족스러운 결과를 얻을 수 있었다.

또한 실무진과 프론트엔드 강사, 멘토님의 과제 점수와 성취도 평가 점수, 그리고 전체적인 정성 및 성실도 평가를 종합해 5명의 최우수 수료생을 선발했는데, 그 중 한 명으로 선정되었다.

모든 활동에 정성을 다했고, 코드 한 줄 한 줄을 직접 쌓아 올린 끝에 얻은 최우수 수료라는 결과는 단순한 성과 그 이상이었다. 이는 앞으로 이어질 2단계의 실무적인 코드 리뷰와 더 복잡한 협업 과정을 버텨낼 수 있는, 나에게 꽤 단단한 밑거름이 되어주었다.

3. 2단계 클론 프로젝트

나에게 카카오테크 캠퍼스에서 최고로 의미 있고 즐거웠던 과정을 뽑으라 한다면, 나는 고민 없이 2단계 클론 프로젝트 과정을 말할 것이다. 카카오를 비롯한 현직에 계시는 멘토님들께 직접 코드 리뷰를 받을 수 있는 기회였고, 현업에서 통용되는 클린 코드와 아키텍처에 대해 깊게 파고들 수 있는 시간이었기 때문이다. 사실 2단계 과정은 별도의 상세 회고가 존재할 만큼 나에게 많은 변화를 가져다주었다.

AI를 내려놓고 생각이 담긴 코드 까지

2단계 초반의 나는 여전히 AI에 의존하고 있었다. 개인 프로젝트를 진행하며 가독성보다는 빠른 기능 구현에 매몰되었던 습관이 남아 있었고, Mission 1까지만 해도 AI가 짜준 정교한 코드 뒤에 숨어 과제를 해결하기 급급했다. 하지만 "본인의 생각이 궁금하다"는 멘토님의 피드백이 내 뒷통수를 한대 친 기분이 들었다. AI는 과도하게 방어적인 코드를 제안하며 "이것이 실무적"이라 말해주지만, 정작 그 코드의 적정선을 판단할 '나의 주관'이 없음을 깨달은 것이다.

이후 나는 사소한 스타일 수정부터 비즈니스 로직까지 AI 의존도를 최소화하고, 내가 작성한 코드의 근거를 TIL에 기록하기 시작했다. AI가 제안하는 90%의 자동 완성보다 내가 고민해서 짠 10%의 코드가 내 실력을 만든다는 확신이 들자, 색다른 재미를 느낄 수 있었고 앞으로 만나는 멘토님들께도 “오랜만에 사람이랑 코드리뷰 하는것 같아서 좋네요” 같은 반응을 들을 수 있었다.

디자인 패턴의 확장: Atomic Design에서 FSD까지

컴포넌트 설계에 대한 궁금증은 Atomic Design Pattern 도입으로 이어졌다. 단순히 폴더를 나누는 것을 넘어, 원자(Atoms) 단위부터 페이지(Pages)까지 계층적으로 컴포넌트를 쌓아 올리며 가독성과 재사용성을 고민했다. 특히 Mission 2에서는 기존의 중구난방했던 구조를 완전히 뒤엎고 전체 프로젝트를 Atomic하게 마이그레이션하며 설계의 희열을 느꼈다.

여기서 멈추지 않고, 멘토님의 조언을 통해 FSD(Feature-Sliced Design) 아키텍처라는 새로운 아키텍처를 접했다.

도메인과 기능별로 관심사를 분리하는 FSD 구조를 적용하며, '어디에 파일을 위치시킬 것인가'에 대한 소모적인 고민을 줄이고 비즈니스 로직에 더 집중할 수 있었다. 화이트보드에 의존 관계를 그려가며 복잡한 참조 구조를 풀어냈던 시간은, 단순한 코딩을 넘어 소프트웨어 아키텍처를 이해하는 단단한 밑거름이 되었다.

사용자 경험을 위한 기술적 집요함: API 및 UX 최적화

Mission 4에서는 성능 최적화와 사용자 경험(UX)에 몰입했다. 실제 카카오 선물하기 서비스와 쿠팡 등을 분석하며, 상품 상세 페이지의 초기 로딩 지연을 해결하기 위한 전략을 세웠다. 모든 데이터를 한 번에 가져오는 대신, Suspense와 ErrorBoundary를 전략적으로 배치하여 핵심 UI를 먼저 보여주고, 하단 리뷰나 상세 정보는 백그라운드에서 호출하는 방식을 채택했다.

멘토님께 "이런 방식의 UX 개선을 어떻게 생각하시는지" 등을 질문하고 토론하며, 기술적 구현만큼이나 중요한 것이 사용자의 관점에서 문제를 바라보는 시각임을 배웠다. 또한 생소했던 테스트 코드 작성법을 익히고, Git의 rebase와 cherry-pick을 실습하며 협업의 기본기인 버전 관리 능력까지 한 층 더 끌어올릴 수 있었다.

성장의 증명: 내 코드에 대한 확신

2단계를 마무리하며 멘토님께 나의 단점과 나아갈 방향에 대해 여쭤보았을 때, "스스로를 믿어보라"는 답변을 받았다. AI가 짜준 정답이 아닌, 내가 고민하고 부딪히며 만들어낸 결과물들이 멘토님께도 긍정적인 에너지로 전달되었다는 사실에 큰 자신감을 얻었다.

결국 2단계는 ‘무엇을 만들었는가’보다 ‘왜 이렇게 만들었는가’를 스스로 설명할 수 있게 된 시간이었다. 또한 코드리뷰와 여러 차례의 멘토링을 통해 멘토님들과의 네트워크가 형성되었고, 카카오테크 캠퍼스 내에서도 학교 상관없이 열심히 참여하는 학생들과 알아갈 수 있는 시간이 되었다. 글을 쓰는 재미를 알게 해준 TIL 기록 습관과, 기술적 한계에 부딪혔을 때 도파민을 느끼며 몰입했던 경험들은 앞으로 이어질 3단계 팀 프로젝트에 큰 도움이 되었다.

4. 3단계 신규 서비스 개발 프로젝트

1. 3단계 - 프로젝트의 시작

카카오테크 캠퍼스의 핵심 단계는 뭐니뭐니 해도 3단계라고 생각한다. 기획부터 디자인, 개발까지 전 과정을 담당 멘토님들과 팀원들과 함께 풀어나가는 단계이기 때문이다. 카테캠에 합류하기 전부터 가장 기대하고 있던 단계이기도 했다. 개발에서 협업은 선택이 아니라 필수라고 생각해왔기 때문이다. 학기 병행이라는 특성상 팀은 같은 학교 학생들로 구성되는데, 부트캠프를 진행하다 보면 의도하지 않아도 누가 얼마나 열심히 하고, 또 잘하는지 자연스럽게 알게 된다. 사실 3단계에서 함께하고 싶었던 동료들이 있었지만, 모두 너무 좋은 사람들이어서 팀이 갈라질 수밖에 없다는 것도 알고 있었다. 결국 마음속으로 생각해 두었던 분들 모두 각자의 팀에서 테크 리더를 맡게 되었고, 비록 다른 팀이 되었지만 이후에도 꾸준히 교류를 이어가게 되었다.

하지만 3단계에서 우리 팀은 시작부터 순탄하지만은 않았다. 첫 온라인 만남에서 카테캠 프로젝트를 어느 정도 우선순위로 두고 있냐고 물었을 때, 프로젝트에 뚜렷한 관심을 보인 팀원이 단 한 명도 없었다. 이해하지 못할 일은 아니었다. 나는 3학년이었지만, 팀원 대부분은 4학년이었고 졸업 프로젝트와 취업 준비로 여유가 없었을 것이다. 역할 분담 과정에서도 모두 메이커(기록)나 플래너(계획)를 희망해 테크 리더와 팀장 선정을 두고 고민이 이어졌다.

나는 팀워크를 모든 우선순위 중 가장 위에 두고 프로젝트에 임하는 편이다. 이번 프로젝트에도 진심이었고, 사실 오래전부터 테크 리더로서 멘토님과 소통하며 프로젝트를 관리해보고 싶다는 생각을 가지고 있었다. 한 명이 진심으로 임하면 그 에너지가 팀 전체에 전파될 수 있을 것이라는 믿음도 있었다. 무엇보다 3단계를 포기하지 않고 참여 의지를 밝혀준 팀원들이 고마웠고, 결국 내가 팀을 이끌기로 결심했다.

의지가 부족한 팀원들에게 의지를 주는 방법은 생각보다 단순하다고 생각한다. 프로젝트에 참여하는 과정 자체를 재미있게 만들면 된다는 것이다. 그 핵심은 기획에 있다고 생각했다. 모두가 흥미를 가질 수 있는 참신한 기획을 만들기 위해 밤낮으로 AI를 활용하며 아이디어를 정리했고, 총 12가지의 기획안을 도출했다. 각 아이디어마다 주 고객층(페르소나), 기획 의도, 기존 서비스와의 차별점과 경쟁력을 정리해 기획 회의 전에 팀원들에게 기획안을 공유했다.

결과는 예상한 대로였다. 충분히 준비된 기획안이 압도적인 선택을 받았고, 그중에서도 내가 가장 공을 들였던 관광 보조 서비스를 최종 프로젝트 주제로 선정하게 되었다.

선택된 기획을 간단히 정리하자면 세계적으로 뻗어나가는 한류(K-contents)의 힘에 힘입어 고객층을 확보하고, 지도 서비스나 기타 서비스에서 제공해주지 않는 K-성지 정보를 제공해주는 서비스이다. 여행과 K-Contents에 대한 내용으로 해서 팀원들의 흥미를 끌어주고, 기존 서비스들과의 차별점, 이미 뼈대가 있는 기획은 팀원들의 관심을 끌기에 충분했다.

이후의 상황은 순탄했다. 초반의 걱정과 달리 모두가 열정적으로 참여해주기 시작했다. 사실 기획이라는게 초반엔 정말 막막하고 아이디어가 마음에 안들면 그 무엇보다 재미없는 과정이지만, 실제로 사용하기 위한 프로젝트이거나, 흥미가 가는 주제로 만들어가기 시작하면 정말 재밌는 과정이다. 아이디어톤을 위해 팀원 모두가 열심히 준비하는 과정과 어디서 소문이 났던건지 다른팀 기수들이 우리팀 기획을 참고하러 오면서? 같이 놀던 과정에서 즐거움을 느꼈다. “이게 진짜 카테캠 기획이지”라는 부산대 쿠키의 말이 아직도 기억에 남는다. 아래는 기획의 일부에 해당할 만큼 Figjam 페이지 몇개를 채울 만큼 탄탄히 준비해나갔다.

2. 3단계 - 아이디어톤

아이디어톤은 무박 2일로 밤을 새워가며 기획을 완성하는 날이다. 평소에는 온라인으로만 모여 멘토님과 카카오 기획자분들께 피드백을 받았지만, 이 날만큼은 직접 대면으로 피드백을 받고 기획을 발표하게 된다. 장소는 카카오 AI 캠퍼스였는데, 밤을 새워도 지치지 않도록 준비된 각종 복지(?) 덕분에 환경만큼은 정말 잘 갖춰져 있었다. 가장 힘들었던 건 밤샘 자체가 아니라, 끊임없이 제공되는 음식들을 소화하는 일이었을 정도였다.

다행히 우리 팀은 사전에 준비가 잘 되어 있던 편이라 큰 부담감은 없었다. 다만 우리가 생각하기에 훌륭한 기획이라 하더라도, 다른 사람의 시선에서는 충분히 미흡해 보일 수 있다는 점을 다시 한 번 실감하게 된 자리였다. 이번 아이디어톤의 가장 큰 목적은 서비스의 와이어프레임을 제작하는 것이었고, 이를 위해 기획을 한 번 더 정제하고 다른 팀과 여러 멘토님들로부터 피드백을 받는 시간을 가졌다.

우리 서비스의 MVP는 지도 기반으로 K-콘텐츠 명소의 위치와 촬영 정보를 제공하는 페이지였다. 이를 중심으로 와이어프레임을 설계했고, 홈페이지에서 서비스 소개와 각 페이지로의 라우팅을 구성했다. 이후 K-Drama, K-Movie, K-Pop 카테고리별 데이터 제공 페이지를 시작으로, 작품 상세 페이지, K-콘텐츠 지도 페이지, 장소 상세 페이지, 마이페이지로 구조가 자연스럽게 확장되도록 설계했다. Figma와 대형 화이트보드를 함께 사용하며 서로의 의견을 주고받았고, 팀 내부에서 기획을 정리할 때까지만 해도 큰 문제는 없어 보였다.

하지만 다른 팀원들과 카카오 멘토님들로부터 피드백을 받는 과정에서 예상보다 날카로운 지적들이 쏟아졌고, 솔직히 당황스러운 순간도 많았다. 거의 모든 지적의 핵심은 ‘실현 가능성’에 있었다.

가장 먼저, 그리고 밤새 가장 많이 언급된 문제는 저작권이었다. 카카오 현직자분의 설명에 따르면, 카카오맵에서도 촬영지 정보를 직접적으로 제공하지 않는 이유가 바로 저작권 문제 때문이라고 했다. 카카오에서는 직접 제공하는 방식이 아니라, 유저가 장소 리뷰를 통해 정보를 남기는 형태로 우회하고 있다는 것이다. 상업적 목적이 없고 공공 API를 활용하더라도 이런 문제가 발생할 수 있다는 점은 아직 이해가 잘 가지 않는다.

두 번째는 언어 장벽에 대한 지적이었다. 카카오맵 등 빅테크의 지도가 다국어를 적극적으로 지원하지 않는 이유 역시 정확성과 유지 보수에 있다는 설명이 인상 깊었다. 나도 프로젝트에서 번역을 사용했던 경험이 있어서 그 정확도를 알고있기에 “3개월이라는 프로젝트 기간 안에, 충분히 신뢰할 수 있는 수준의 번역 품질을 만들 수 있겠느냐”라는 질문이 날카롭게 다가왔다.

마지막으로 지도 기능 자체에 대한 현실적인 문제도 지적받았다. 우리는 ‘지도를 사용한다’는 큰 방향까지만 정해두었을 뿐, 지도가 실제로 제공해야 할 기능들에 대해서는 깊이 고민하지 못한 상태였다. 실시간 길찾기나 교통 정보와 같은 기능을 기술적으로 어떻게 구현할 것인지에 대한 질문들이 이어졌고, 그 과정에서 우리가 놓치고 있던 부분들이 분명하게 드러났다.

기획을 수정하고 보강하기에는 하루라는 시간이 결코 넉넉하지 않았지만, 팀원이 여섯 명이라는 점은 큰 힘이 되었다. 역할을 빠르게 나눠 각자 맡은 부분을 정리하다 보니 생각보다 수월하게 보완 작업이 진행되었고, 발표 자료와 예상 질문에 대한 답변까지 어느 정도 정리되었을 즈음 기획 발표 시간이 다가왔다. 아이디어톤은 평균적으로 4~5개 팀이 한 방에 배정되고, 각 방에서 가장 우수한 1팀을 선정한 뒤, 그렇게 선발된 5개 팀이 다시 경쟁해 최종 1등을 가리는 방식으로 진행되었다.

사실 밤새 우리 팀에 쏟아졌던 수많은 피드백과 공격(?) 덕분에 정신이 반쯤 나간 상태이기도 했다. 다행히 회의룸에서 받은 질문들은 전문 기획자 관점의 질문보다는 서비스 전반에 대한 이해를 묻는 수준이었고, 비교적 차분하게 답변할 수 있었다. 특히 개발자로서 구현 방안이나 실현 가능성에 대한 질문들은 내가 맡아 설명했는데, 프론트엔드 관점의 구현 방식이나 모바일 퍼스트 디자인 전략 등을 중심으로 답변했다. 무엇보다 발표를 맡아준 팀원이 끝까지 차분하게 진행해 준 덕분에, 큰 문제 없이 발표를 마칠 수 있었다.

고생한 보람이 있게도 우리는 아이디어톤에서 우수상을 받게 되었다. 최종 발표에서는 앞으로 서비스를 어떻게 발전시켜 나가면 좋을지, 개선 방향에 대한 현실적인 조언들을 들을 수 있었고, 동시에 다른 팀들과 비교했을 때 아이디어의 참신함과 재미 요소에 대해 긍정적인 평가도 받을 수 있었다.

비록 1등은 경북대 팀에게 돌아갔지만, 단순히 순위에 대한 아쉬움보다는 재미있는 기획을 만들어보고자 했던 과정과, 밤을 새워가며 팀원들과 함께 아이디어를 구체화했던 시간이 더 크게 남았다. 그 노력들이 모여 의미 있는 결과로 이어졌다는 사실이, 오히려 앞으로 이어질 3단계 과정을 더 열심히 임해보고 싶다는 다짐을 하게 만들어 주었다.

3. 3단계 - KSPOT

우리 팀에서 팀 프로젝트 협업 경험이 있던 사람은 나뿐이었기 때문에, 프로젝트가 시작되자마자 어깨가 무거워지는 걸 느꼈다. 이전 과정에서 개인상, 협동상, 기획상을 받았던 만큼, 이번 최종 프로젝트에서도 좋은 결과를 내어 모든 활동에 성실히 참여해 왔다는 것을 스스로 증명하고 싶다는 욕심도 있었다. 팀원들이 프로젝트에 충분한 시간을 쏟기 어려운 상황이라면, 그만큼 내가 더 책임지고 움직이면 된다고 생각했다.

프론트엔드에서는 내가 테크 리더를 맡고, 백엔드와의 소통을 포함해 전체적인 개발 흐름을 조율하는 역할을 담당하게 되었다. 특히 1주차에는 테크 스펙을 정의하는 과정이 가장 어려웠는데, 이를 해결하기 위해 내가 먼저 ERD 다이어그램과 REST API 스펙 예시를 정리해 제안했고, 그 위에서 팀원들과 함께 수정·보완해 나가는 방식으로 방향을 잡았다.

PLAINTEXT

CREATE TABLE contents (
    content_id BIGINT AUTO_INCREMENT PRIMARY KEY, -- 콘텐츠 고유 ID (기본 키)
    category ENUM('DRAMA', 'MOVIE', 'KPOP') NOT NULL, -- 카테고리
    title VARCHAR(255) NOT NULL, -- 제목
    poster_image_url VARCHAR(255), -- 포스터 이미지 주소
    release_date DATE, -- 출시일
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 생성 시각
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP -- 수정 시각
);

프론트엔드 쪽에서는 프로젝트 시작 전부터 카테캠 2단계 때부터 꾸준히 연락을 이어오던 멘토님과 티키타카를 하며 FE 테크 설계서를 정리했고, 이를 팀원들에게 공유했다. 이번 부트캠프의 핵심은 ‘성과’보다는 ‘성장’이라고 생각했기 때문에, 기술 스택 선정에도 특히 신중을 기했다. 특별한 이유가 없는 한 2단계에서 학습했던 기술 스택을 최대한 활용하고자 했고, 새로운 기술을 도입해야 할 경우에는 내가 끝까지 책임질 수 있는 범위 내에서만, 팀원들과 충분히 논의한 후 결정했다.

FSD 아키텍처를 사용해 폴더 구조를 설계하고, UI와 로직의 분리, 상수 분리 등에 큰 힘을 주게 되었다. 초기엔 로직 구현에 큰 신경을 두지 않고, 클린 코드와 클린 아키텍처에 집중했다.

TYPESCRIPT

function ContentDetailPage() { // pages에선 컴포넌트 조립을 담당
  const { id } = Route.useParams();
  return (
    <>
      <ContentOverviewHero contentId={id} />
      <LocationImageCarousel contentId={id} />
    </>
  );
}

사실 3단계에서는 생각보다 정말 많은 일들을 벌였다. 그럼에도 별도의 ‘3단계 전체 회고’를 작성하지 않은 이유를 돌아보면, 3단계에서 진행했던 대부분의 과정들을 이미 각각의 주제로 나누어 따로 회고로 남겨두었기 때문인 것 같다. 어쨌든 모두 2025년에 경험한 일들이니, 여기서는 간단하게 어떤 활동들을 했는지만 정리해 보려고 한다.

우선 테크 스펙과 테크 설계서를 작성하는 것과 동시에 프로젝트 세팅을 함께 진행했다. 2단계부터 계속 사용해 오던 Vite를 그대로 활용했고, FSD 아키텍처 기반의 폴더 구조를 미리 구성한 뒤 각 폴더마다 README.md를 작성해 역할과 코드 컨벤션을 정리해 두었다. 또한 멘토님께서 제안해 주신 이슈 템플릿과 PR 템플릿 역시 직접 작성해, 협업 과정에서의 기준을 최대한 명확하게 맞추고자 했다.

두 번째로는 모킹 API가 아닌, AWS Serverless를 활용한 실제 API를 직접 설계했다. 다소 과하다고 느껴질 수 있는 선택이었지만, 나름의 이유가 있었다. 우리 팀은 첫 주차부터 제로 베이스로 시작해, 백지 상태의 프로젝트에 CI/CD를 구축한 뒤 개발을 진행하고 있었는데, 이 과정에서 백엔드 API 지연과 무관하게 프론트엔드가 안정적으로 사용할 수 있는 API가 필요했다. 또한 백엔드에서 제공하기 어려운 기능들은 별도로 서버리스를 통해 서빙하고자 했다. 이 과정에 대한 자세한 내용은 별도의 회고로 정리해 두었다.

<프론트엔드에서 ServerlessAPI 다루기>

세 번째로, 3단계에서 가장 많은 시간을 쏟았던 작업은 백엔드와의 소통이었다. 그중에서도 가장 직접적이고 중요한 영역이 바로 인증·인가였다. 매일 담당 팀원과 모각코를 진행하며, 다양한 상황을 고려한 인증·인가 로직을 함께 구현해 나갔다. Java와 Spring에 대해서는 익숙하지 않았지만, 토큰 관리와 JWT에 대한 지식을 공유하며 지속적으로 논의를 이어갔다. 이 과정에 대한 보다 자세한 내용은 아래 링크의 회고에서 확인할 수 있다.

<인증/인가 모든 UserFlow에 대응해보자!>

네 번째는 다소 개인적인 욕심에서 시작한 작업이었다. 바로 Vite 기반 프로젝트를 Next.js로 마이그레이션하는 일이었다. 시작하게 된 이유는 의외로 단순했다. 백엔드 작업 지연으로 인해 상대적으로 시간이 남기도 했고, 기획 단계에서 제공하고자 했던 기능들이 하나둘씩 사라지고 있다는 점이 아쉬웠다. 그렇다고 백엔드 코드에 직접 관여하는 것은 바람직하지 않다고 판단해, 내가 직접 서버를 띄우고 호스팅까지 책임지는 방향을 선택했다. 그 과정에서 개인적으로 공부해 보고 싶었던 쿠버네티스를 도입해 보았고, 급증하는 트래픽에도 유연하게 대응할 수 있는 아키텍처를 구성하게 되었다.

<Vite to Nextjs migration>

마지막으로는 기능 자체를 직접 만들어 보기로 했다. 몇 년 전이라면 몰라도, AI 시대에 신규 서비스가 AI를 활용하지 않는다면 경쟁력이 없다고 느꼈기 때문이다. 그래서 K-콘텐츠 팬들이 직접 성지순례 코스를 일일이 만들지 않아도, 클릭 몇 번만으로 동선을 생성할 수 있는 기능을 구현하게 되었다. 시간적 여유가 많지 않아 DB 백업 파일을 직접 받아 내 서버에 띄우는 방법도 고민했지만, 보안 그룹에서 AI 서버 IP만 허용한 뒤 쿼리하는 방식이 더 적절하다고 판단했다. 비용을 최소화하기 위해 서버리스 서비스를 활용했는데, IP 할당 문제로 어려움을 겪기도 했다. 이 문제는 Cloud Run과 Cloud NAT를 활용해 해결할 수 있었다.

<Next.js 서버 Kubernetes 배포 환경 구축기1>

최종 발표는 내가 맡게 되었다. 프로젝트 전반에 대해 가장 잘 알고 있었고, 개인적으로 별도로 진행한 기능들도 많았기 때문이다. 나 역시 이 팀의 한 구성원이었고, 팀원들 역시 필요하다고 판단한 기능을 추가로 구현하는 것 자체를 부정적으로 보지는 않았다. 무엇보다 가장 바빴던 시간들조차 누군가의 강요가 아닌, 내가 즐거워서 선택한 일이었기에 문제라고 생각하지 않았다.

발표와 함께 이어진 질문에도 차분히 답변하며, 카카오 관계자분들과 교수님들 앞에서의 무섭고 떨리던 발표는 그렇게 끝이 났다. 같은 충남대 팀들의 발표 역시 각 팀의 테크 리더들이 맡아 진행했는데, 모두가 너무 프로페셔널해서 솔직히 수상은 어렵겠다고 생각하고 있었다.

??? 발표를 또 하게 되었다.

사실 다른 팀들 모두 너무 잘해서 수상은 힘들겠다고 생각했는데, 수상하게 되니 매우 기뻤다.

사실 수상 자체가 목적이었다면 기능을 더 많이, 더 화려하게 만드는 선택도 가능했을 것이다. 하지만 팀원들은 포트폴리오로 남길 수 있는 프로젝트를 원했고, 그에 맞춰 설계 방향 역시 기능의 양보다는 클린 코드와 구조에 초점을 맞추게 되었다. 코드 리뷰 또한 자연스럽게 그 기준에 맞춰 진행되었다.

내 개발에 대한 욕심과 즐거움을 팀원들에게 강요할 수는 없었지만, 욕심 많은 테크 리더 아래에서 쉽지 않았을 과정임에도 끝까지 함께해 준 팀원들에게 고마움을 느꼈다.

3단계에서 엄청난 상금을 주는 상을 모두 받게 되었다. 나는 그저 부트 캠프 과정에 적극적으로 참여하고 더 열심히 공부했을 뿐인데, 전 과정에서 수상을 하게 되었다. 결국 개발이 즐거운 사람은, 언젠가는 반드시 꽃이 피는 것 같다는 생각이 들었다.

5. 느낀점

결과는 기대 이상으로 좋았지만, 아쉬운 점들 역시 분명히 남았다. 그중 가장 크게 느껴졌던 부분은 코드 리뷰였다. 내가 카카오테크 캠퍼스 과정 중에서도 특히 2단계를 좋게 기억하는 이유 역시 서로 간의 코드 리뷰 경험 때문이었다. 이번 3단계에서도 팀원들끼리 자연스럽게 코드 리뷰를 주고받을 수 있었다면 더 좋았을 것이라는 아쉬움이 남는다.

GitHub 레포지토리를 확인해 보면 알 수 있듯이, 코드 리뷰의 90% 이상은 내가 남긴 것이었다. 다른 팀들의 상황 역시 어느 정도 알고 있었기에 크게 문제 삼지는 않았지만, 아쉬운 마음이 남는 건 사실이었다. 나도 제대로 개발을 공부한건 올해가 처음이었고, 실력이 좋다고 말할 순 없다. 하지만 나는 팀원들의 모든 PR에 최소 10개 이상의 리뷰를 남기기 위해 노력했고, 동시에 내 코드에 대한 피드백도 받고 싶었다. 혼자서는 한계가 있을 것 같아 Gemini 기반 리뷰를 도입해 보기도 했지만, 기대만큼의 성능을 보여주지는 못했다. 만약 코드 리뷰가 조금 더 활발하게 이루어졌다면, 결과 역시 더 좋아질 수 있지 않았을까 하는 생각이 든다.

두 번째로는 한 사람의 어깨에 너무 많은 무게가 실려 있었다는 점이다. 회의를 여는 사람도, 정리하는 사람도 늘 나였고, 내가 말을 마치면 자연스럽게 회의가 끝나는 구조였다. 겉으로 보면 팀을 잘 이끈 것처럼 보일 수도 있겠지만, 스스로를 돌아보면 그렇게 훌륭한 리더였다고 말하기는 어렵다. 다른 팀 상황도 비슷했는데, 한 사람이 중심이 되는 팀은 그 사람이 잘 버티면 굴러가지만, 그 사람이 흔들리면 함께 무너질 수밖에 없는 구조이기도 하다. 실력의 높낮이보다도, 조금 더 많은 참여와 주도성이 팀 전체에 고르게 퍼져 있었다면 어땠을까 하는 아쉬움이 남는다.

하지만 이러한 아쉬움들을 충분히 상쇄할 만큼의 성과를, 카카오테크 캠퍼스 3기를 수료하며 얻을 수 있었다. 무엇보다 글의 초반에 언급했던 ‘카카오테크 캠퍼스에 지원했던 목적’을 대부분 이루었다는 점이 가장 컸다. 그중에서도 가장 의미 있게 다가온 성과는 단연코 좋은 네트워크가 만들어졌다는 것이었다.

부트캠프 과정 동안 적어도 열 번 이상의 멘토링을 받을 수 있었고, 2단계에서는 총 네 분의 멘토님께 직접 코드 리뷰를 받아볼 수 있었다. 그 과정에서 감사하게도 지금까지도 연락을 이어가고 있는 멘토님들이 생겼고, 단순한 조언을 넘어 방향성을 고민해 볼 수 있는 관계로 이어지게 되었다. 또한 3단계를 통해 함께 팀을 하고 싶었던 분들과 자연스럽게 교류하게 되었고, 특히 가장 리스펙하던 한 분과는 내년에 프로젝트와 여러 지원 과정을 함께해 보기로 약속하게 되었다.

기술적인 측면에서도 분명한 변화가 있었다. 코드를 리뷰받고, 또 다른 사람의 코드를 리뷰해 주는 과정을 반복하면서 단순히 ‘동작하는 코드’를 넘어서 구조와 의도를 읽는 눈이 생기기 시작했다. 그 결과 이전보다 AI에 대한 의존도 역시 자연스럽게 낮아졌고, 이제는 AI를 대신 코드를 짜주는 도구가 아니라, 내 생각을 검증하고 확장해 주는 보조 도구로 활용하게 되었다는 점도 스스로 느낄 수 있었다.

정말 바빴던 한 해가 지나갔지만, 내년은 올해보다도 더 바쁘지 않을까 한다. 이제는 단순히 기술을 공부하는 단계를 넘어, 마음이 맞는 훌륭한 동료들과 함께 세상에 없던 가치를 만드는 창업의 과정에 본격적으로 뛰어들어 보려 한다.

단순히 코드를 작성하는 개발자에 머무는 것이 아니라, 우리가 만든 서비스로 실제 사용자를 유치하고 그들의 생생한 피드백을 직접 마주하며 서비스를 개선해 나가는 현장을 경험하고 싶다. 실제 유저 트래픽이 몰리는 상황에서 발생하는 기술적 난제들을 해결하고, 비즈니스적인 관점에서 서비스를 확장해 나가는 과정이 벌써 기다려진다. 2025년이 '성장을 위한 기반'을 다진 해였다면, 2026년은 그 기반 위에서 한 단계 더 높이 도약하는 한 해가 되도록 노력할 것이다.