코드잇 프론트엔드 단기 심화 과정 11기 수료 회고

들어가며

2025년 9월, 코드잇에서 진행하는 프론트엔드 단기 심화 과정에 참여했습니다. 약 8주 동안 Storybook, GitHub Actions, Husky, 테스트 코드 등 실무에서 자주 접하는 기술들을 다뤄보며, 한 단계 또 성장할 수 있는 시간이였어요.

이 글에서는 그동안 배우고 느낀 점, 그리고 어떤 부분에서 성장할 수 있었는지 차근차근 정리해보려 합니다.

프론트엔드 단기 심화 과정에 참여 이유

제가 이 과정을 선택한 이유는 다음과 같아요:

• 그 동안의 기능 구현 위주의 프로젝트에서 벗어난 개발 경험을 해보며
• 채용 시장에서 요구되는 Next.js·CI/CD·테스트 등 실무 역량을 갖추고
• 같은 목표를 가진 사람들과 네트워킹하며 개발적 견문을 넓히고 싶었어요.

왜 이 과정을 선택했는지 조금 더 이야기해 보면,

학부 마지막 학기를 마치자 마자 6개월간 인턴으로 근무하며 복잡한 IDE 도메인을 경험할 기회가 있었습니다. 규모가 큰 서비스와 체계적인 개발 환경을 직접 겪어보니, 그동안 제가 가진 시야가 다소 좁았다는 점을 체감하게 되더라고요. 특히 단순히 기능을 구현하는 수준을 넘어, 더 나은 설계나 효율적인 프로세스를 고민해 보고 싶다는 생각이 들었습니다.

또한 최근 채용 공고를 보면서 Next.js 활용 능력이나 CI/CD, 테스트 자동화 역량을 중요하게 다루는 경우가 많더라고요. 실무에 바로 적용할 수 있는 이러한 기술들을 직접 다뤄보는 경험이 필요하다고 판단했습니다.

같은 프론트엔드 개발자를 목표로 하는 팀원들과 네트워킹하며 다양한 정보를 나누고, 서로의 관점을 접해보고 싶어 프론트엔드 단기 심화 과정에 참여하게 되었습니다.

2주간 진행된 이론 수업

처음 2주는 커리큘럼에 따라 이론 수업 중심으로 진행되었습니다. Jest를 활용한 테스트 프레임워크부터 React 컴포넌트 테스트, CI/CD까지 그동안 깊이 있게 다뤄보지 못했던 주제들을 폭넓게 접할 수 있었어요. 강사님의 개념 설명 직후에 실습을 병행하는 방식 덕분에 처음 배우는 내용임에도 이해하는 데 큰 어려움이 없었습니다. 이전에 경험해보지 못했던 것들을 새롭게 배우고 직접 적용해보는 시간이였어요.

6주간 진행된 프로젝트

개요

• 주제: 지역 기반 공동구매 및 쉐어링 서비스 ‘소분소분’
• 팀원: 6명 (프론트엔드 4명, 백엔드 2명, 디자이너 1명)
• 작업 기간: 6주 (2025년 9월 19일 ~ 11월 4일)
• 사용한 기술 스택:
  • 코어: TypeScript, Next.js
  • 스타일링: Tailwind CSS
  • 상태 관리: Zustand
  • 테스트: Jest
  • CI/CD: GitHub Actions

팀 구성

코드잇에서 팀을 배정해주었고, 저를 포함해 프론트엔드 4명이 한 팀으로 구성되었어요. 여기에 프로젝트 완성을 위해 백엔드 2명과 디자이너 1명도 함께 배정되었습니다. 주제는 투두 서비스와 모임 서비스 중 하나를 선택하는 방식이었고, 저희 팀은 모임 서비스를 선택했어요. 제한된 일정 안에 프로젝트를 완성해야 했기 때문에 첫 전체 회의는 기획 방향과 전체 일정 조율을 중심으로 이야기를 나누었어요.

이후에도 전체 회의를 진행했는데, 좋았던 점 중 하나는 백엔드 개발자와 디자이너분 모두 이전 기수 경험이 있는 분들이었다는 점이었어요. 프론트엔드팀 내부적으로는 프로젝트를 기한 안에 완성하는 것을 공통 목표로 삼고 있었는데, 그 경험을 바탕으로 제한된 시간 안에서 어느 정도의 기획량이 현실적이고 효율적인지에 대한 조언을 해 주셨어요. 그 덕분에 기획 단계에서도 자연스럽게 프론트엔드 역량을 쌓기 좋은 방향으로 내용을 정리할 수 있었어요.

또, 프로젝트를 진행하는 동안 백엔드와 디자이너분이 모두 현직자이셨다는 점도 큰 도움이 되었어요. 서비스 관점에서 어떤 부분을 고려해야 하는지, 실제 업무에서는 어떻게 문제를 해결하는지 등 다양한 이야기를 들을 수 있었고, 작업 속도도 정말 빨랐어요. 백엔드 개발이 예상보다 훨씬 빠르게 마무리되었고 API 완성도도 높아서 협업 과정에서 막히는 부분이 거의 없었어요. 이슈가 생기더라도 하루 안에 해결해주셔서 프로젝트가 정말 수월하게 진행됐어요.

디자이너분 역시 현직자이셔서 작업 속도가 빠를 뿐 아니라, UI/UX 관점에서 많은 인사이트를 나눠주셨어요. 그런 의견들이 디자인에 자연스럽게 반영되면서 결과물의 완성도도 한층 높아졌어요. 특히 Figma 안에 프론트엔드가 개발하기 좋은 레이아웃과 필요한 값들이 꼼꼼하게 정리되어 있어서 협업 효율이 정말 높았어요.

프로젝트 목표

저희 팀은 기한 안에 완성도 높은 서비스를 만드는 것, 그리고 이론 시간에 배운 내용을 실제 프로젝트에 적용해보는 것을 프로젝트 목표로 삼았어요. 팀원 모두 같은 목표를 공유하고 있었기 때문에 프로젝트 방향을 잡는 데도 큰 어려움이 없었어요.

• 완성도 높은 서비스 구현
• 이론 수업에서 배운 내용을 프로젝트에 반영
  • Tailwind CSS를 활용한 스타일링 적용
  • Storybook 작성 ( + npm 패키지 배포)
  • Jest 및 리액트 테스팅 라이브러리로 기능 단위 테스트 수행
  • GitHub Actions 기반 CI/CD 환경 구축
    • 전체 프로젝트 빌드, 테스트, 타입검사
    • Chromatic을 통한 Storybook 자동 배포
  • 소개 페이지에 CSS 애니메이션 적용

이 프로젝트에서 저는 기능 구현뿐 아니라 디자인 시스템 구축과 Storybook 문서화를 중심으로 맡아 진행했어요. 특히 컴포넌트 설계, 테스트 코드 작성, Chromatic 기반 자동 배포 환경 구성 등을 담당하며 전체적인 프론트엔드 개발 흐름을 개선하는 데에도 기여했어요.

작업 일정

• 0주차: 주제 선정 및 기술 스택 및 컨벤션 논의
• 1주차: Figma를 활용한 와이어프레임 및 API 명세서 작성
• 2주차: 담당 페이지 분배 및 주요 컴포넌트·스토리북·테스트 코드 작성
• 3주차: 와이어프레임을 토대로 담당 페이지 개발 진행
• 4주차: Figma 디자인을 기반으로 한 UI 구현 및 기능 개발 (+ 중간 점검 발표)
• 5주차: UI 구현 및 기능 개발
  • 추가 컴포넌트 UI 구현 및 기능 개발
  • API 연동 및 데이터 검증
  • 예외 처리 및 에러 핸들링 추가
• 6주차: 디자인/기능 QA 및 마무리 (+ 최종 발표)
  • 반응형 및 스켈레톤 UI 디자인 적용
  • 디자인/기능 QA 및 수정사항 반영
  • 기능 통합 테스트 및 버그 수정, SEO 및 번들 사이즈 최적화

협업 관리 방법

1) 일정 관리

중간 발표 시점까지 구현된 페이지가 거의 없을 정도로, 초반에는 일정 관리가 잘 이뤄지지 않았어요. 돌아보면 여러 요소들이 한꺼번에 겹치면서 흐름이 늦어진 부분이 있었던 것 같아요.

• 프론트엔드에서 기획 디테일까지 고민하느라 초반 시간이 많이 소요되고
• 디자인 작업이 예상보다 늦어지며 전체 일정이 밀리고
• npm 패키지 배포에만 약 4일을 온전히 투자하게 되면서

초반 진행 속도가 크게 떨어졌어요.

프론트엔드 과정이어서 자연스럽게 저희가 기획을 주도했는데, 지금은 기억도 안 날 만큼 세세한 요소들까지 논의하며 시간이 꽤 흘렀어요. 여기에 디자이너 작업이 늦어지면서, 그동안에는 먼저 주요 컴포넌트 기능 개발을 작업했지만 페이지 단위의 구현은 계속 뒤로 밀렸습니다. 그러다 보니 페이지가 나오기 시작한 뒤에는 컴포넌트를 다시 UI에 맞게 수정하고, 동시에 페이지도 구현하는 식으로 일정이 압축되었던 기억이 있어요.

이 상황을 해결하기 위해 데일리 스크럼을 매일 진행하며 작업 속도를 끌어올렸고, 피그마에 남은 작업을 정리해 무엇을 누가, 언제까지 할지 명확하게 쪼개어 분담했습니다. 또 디자이너와도 어떤 작업을 언제까지 마무리할지 다시 정리하면서 서로 일정을 맞췄어요. 예를 들어 “우선순위가 급한 파트를 기준으로, 며칠 동안 어떤 작업을 진행하실 수 있는지”를 구체적으로 나누어 확인하며 작업 순서를 조율했어요. 이렇게 우선순위를 다시 정리하고, 그 일정에 맞춰 프론트 작업 계획도 함께 재정비하면서 전체 흐름을 안정적으로 맞춰 갈 수 있었습니다.

이렇게 매일 긴밀하게 소통하며 작업을 이어간 덕분에, 마지막에는 디자인 QA, 번들사이즈 측정, SEO 개선 등 까지 진행할 여유가 생길 정도로 일정이 안정적으로 회복될 수 있었습니다.

2) 작업 관리

기능 개발에 들어가기 전에 기능을 정의하고, 기능 단위로 역할을 나눠서 작업을 시작했어요. 하지만 초반 일정이 늦어지면서 후반부 작업이 크게 늘어났고, 어느 순간엔 특정 팀원에게 업무가 과도하게 몰리는 상황도 생겼습니다.

그래서 이후에는 역할을 고정해서 나누기보다, 어떤 작업이 남아 있고 누가 무엇을 진행 중인지 매일 투명하게 공유하는 방식으로 전환했어요. 디스코드와 피그마로 매일 작업 상황을 확인하고, 필요하면 바로 작업을 재분배하면서 부담을 균형 있게 나누려고 했습니다.

그리고 작업을 진행하면서 느낀 저희 팀의 큰 장점 중 하나는, 어려운 부분이 생기면 막히는 지점이나 고민 포인트를 편하게 이야기하고 함께 해결책을 찾아보는 분위기였어요. 예를 들어 “제가 지금 OOO 작업을 하고 있는데 이 부분이 조금 고민돼요. 혹시 이전 프로젝트에서 비슷한 경험 있으신가요?” 또는 “OOO 작업 중 이 부분이 문제인 것 같은데 해결이 잘 안 돼요. 화면 공유하면서 같이 봐주실 수 있을까요?”처럼 언제든지 편하게 도움을 요청할 수 있었어요. 이런 태도는 팀원 모두가 강점으로 느낀 부분이었고, 앞으로의 협업에서도 꼭 이어가고 싶은 자세였어요.

특히 마지막 2주 동안은 일정이 빠듯했음에도 서로의 작업을 자연스럽게 나눠 맡으며 부담을 덜어줄 수 있었어요. 완성도를 중요하게 생각하는 팀원들이 모이다 보니, 누가 먼저 말하지 않아도 그때그때 필요한 작업을 대신 가져가거나 도와주는 분위기가 자연스럽게 자리 잡았습니다.

3) 커뮤니케이션

프론트엔드 작업을 하면서 백엔드·디자인과 소통해야 하는 일이 많았는데, 그때마다 디스코드 메시지와 피그마의 댓글 기능을 적극적으로 활용했고, 덕분에 원활히 소통했습니다.

백엔드와는 UI 개발을 마치고 API를 연결하는 과정에서 문제가 생기면 바로 전달했는데, 감사하게도 이동 중이 아닐 때는 거의 즉시 수정해주셔서 해결까지 24시간 이상 걸린 적이 거의 없었어요. (경험이 많으신 분들이라 수정해야 할 부분도 많지 않았습니다.)

디자이너 또한 경험 많으셔서 개발 과정에서 큰 기술적인 이슈는 없었고, 기획과 디테일을 다듬는 과정에서 UX적으로 어떤 방향이 좋은지 자주 논의했어요. 특히 후반부에는 작업 속도가 빨라야 했기 때문에 매일 디스코드 음성 채널을 켜두고 실시간으로 의사결정을 했고, 덕분에 고민되는 요소가 생기면 바로 해결할 수 있었어요. 예를 들어, “대댓글 기능이 필요한데 UI/UX가 고민된다”고 말씀드리면, 최근 OOO 서비스에서도 사용하는 패턴이라 직관적이라는 의견을 바로 주셔서 기획을 확정하는 데 큰 도움이 되었습니다.

이렇게 서로 빠르게 소통하면서 작업하다 보니, 개발 도중 기획이 추가되거나 조정될 때도 일정에 부담 없이 진행할 수 있었고 팀 전체의 작업 흐름도 훨씬 매끄럽게 이어졌어요.

또 중간 발표를 앞두고 진행했던 KPT 회고에서도, 이런 소통 방식이 우리의 강점으로 크게 언급되었고 앞으로 어떻게 개선할지에 대한 방향도 함께 잡을 수 있었습니다.

4) 서로에 대한 존중

서로 다른 환경에서, 다른 스타일로 공부하고 프로젝트를 해온 팀원들이 모인 만큼 기본적으로 서로를 존중하는 태도를 유지하려고 했어요. 작업 속도가 느린 팀원이 있더라도 재촉은 할 수 있지만, 탓하거나 압박하는 분위기는 만들고 싶지 않았고 다른 팀원들도 같은 마음이었어요.

실제로 함께 작업해보니 속도는 조금 느릴 수 있어도 그 팀원의 강점은 ‘꼼꼼함’이었고, 기술적으로 복잡한 이슈가 생기면 오히려 그 꼼꼼함 덕분에 큰 도움을 받기도 했습니다. 서로의 강점과 약점을 자연스럽게 인정하면서, 각자 잘할 수 있는 부분을 살려 협업할 수 있었던 점이 팀워크에 큰 힘이 되었어요.

트러블 슈팅

프로젝트를 진행하면서 위에서 세운 목표들을 실제로 어떻게 실행했는지, 진행 과정에서 어떤 고민과 선택들이 있었는지 하나씩 정리해보려고 해요.

1) shadcn/ui 적용 여부에 대한 고민

처음에는 Tailwind CSS만 사용할지, 아니면 shadcn/ui까지 함께 적용할지에 대해 고민이 많았어요.

• shadcn/ui를 적용하면
  • 스타일 라이브러리를 활용한 개발 경험을 쌓을 수 있어요.
  • 이미 만들어진 컴포넌트를 활용해 화면 구현 속도가 빨라지기 때문에, 기능 개발이나 테스트 코드 작성 등 다른 작업에 더 많은 시간을 투자할 수 있어요.
• 적용하지 않는다면
  • 디자인 시스템을 직접 설계하고 Storybook 문서화를 하면서
  • 더 깊은 수준의 컴포넌트 설계 경험을 쌓을 수 있고
  • 나아가 npm 패키지 배포까지 시도해볼 수 있어요.

여러 방향을 두고 논의했지만, 이번 프로젝트에서는 shadcn/ui를 사용하지 않기로 결정했어요.

물론 직접 컴포넌트를 설계하면 시간이 더 걸리고 페이지 구현 일정이 밀릴 수 있다는 걱정도 있었지만, 디자인 시스템을 처음부터 만들어보는 경험 자체가 이번 프로젝트의 중요한 목표라고 생각했기 때문이에요.

2) Storybook 제작과 npm 패키지 배포 과정

중간 발표 전까지는 기획과 기능 명세서를 작성하는 데 시간이 꽤 많이 들어 실제 개발에 쓸 수 있는 시간이 넉넉하지 않았어요. 특히 제가 맡은 역할이 ‘디자인 시스템 패키지화’였기 때문에 초반 일정이 더 빠듯했어요.

이전 인턴십에서는 이미 패키지 형태로 정리된 디자인 시스템을 import해서 사용하는 환경이 잘 갖춰져 있었고, 그때 재사용성과 유지보수 측면에서 큰 편리함을 느꼈어요. 이번 프로젝트에서도 그 경험을 직접 적용해보고 싶었고, 팀원들과 그 장점을 공유하고 싶어 디자인 시스템을 npm 패키지로 배포해보자는 목표를 세웠습니다.

하지만 막상 진행해보니 npm 배포 과정에서 여러 문제가 발생했어요.

• 자동 버전업 스크립트가 중복 실행되면서 버전이 두 단계씩 증가하는 문제가 생기고
• 패키지를 실제 페이지에 적용했을 때는 CSS 빌드·번들링 이슈가 나타나고
• 이를 해결하는 데 예상보다 많은 시간이 필요해 전체 일정에도 영향을 주기 시작했어요.

이런 상황을 고려해 프로젝트 우선순위를 다시 정리했고, 결국 npm 배포는 잠시 보류하기로 결정했어요.

대신 디자인 시스템 레포지토리에서 만들어둔 컴포넌트를 프로젝트 내부로 직접 옮겨 사용하고, Storybook 역시 프로젝트 안에서 다시 구성하는 방식으로 방향을 전환했어요. 옮겨온 컴포넌트를 실제 페이지에 적용해보니 예상과 다르게 동작하는 부분도 있었고, 그 과정에서 “테스트 없이 npm 패키지 배포를 서두르는 건 위험하겠다”는 점을 다시 한 번 실감했어요.

되돌아보면, 프로젝트 내부에서 바로 문제를 확인하고 빠르게 수정할 수 있었기 때문에 결과적으로는 더 안전한 선택이었다고 느껴요. 😅

3) Chromatic 배포 설정

이번 프로젝트에서는 제가 Storybook 제작을 주도적으로 맡았고, 배포는 Storybook 호스팅에 특화된 Chromatic을 사용했어요. Chromatic 배포는 처음이었지만, 공식 문서와 관련 블로그들이 잘 정리되어 있어서 큰 어려움 없이 따라갈 수 있었습니다. 다만 진행 과정에서 몇 가지 예상치 못한 문제가 있었어요.

• 배포된 Storybook 접근 문제

  처음 배포했을 때는 스토리북 링크가 저에게만 열리고, 팀원들은 접근할 수 없다는 문제가 있었어요. 원인을 확인해보니 기본 설정이 private 모드였던 거예요. 프로젝트 특성상 모두가 손쉽게 접근할 수 있어야 했기 때문에, collaborator를 일일이 등록하기보다는 Visibility 옵션을 public으로 전환하는 방식으로 문제를 해결했습니다. (참고 글: Storybook Chromatic 으로 배포해보기! + 번외 Netlify)

• 스토리북 URL이 매번 바뀌는 문제

  Chromatic은 빌드할 때마다 새로운 스냅샷을 생성하기 때문에 빌드가 발생할 때마다 URL이 달라지는 구조예요. 변경 사항이 생길 때마다 노션에 새로운 URL을 업데이트해야 해서 관리가 번거로웠어요.

  이 문제를 해결하기 위해, 이론 시간에 배운 CI/CD를 활용해 스토리북이 업데이트될 때마다 GitHub 봇이 최신 URL을 자동으로 알려주는 파이프라인을 구성했어요. 덕분에 Chromatic 사이트에 들어가 매번 링크를 직접 확인할 필요가 없어져 관리가 편해졌어요.

  

4) Jest를 활용한 컴포넌트 테스트 코드 작성

프로젝트에서는 컴포넌트 단위로 Jest 테스트 코드를 작성했어요.

처음에는 테스트를 하나씩 직접 작성했지만, 작업이 누적되면서 테스트 케이스가 빠지는 상황이 생기기 시작했어요. 그래서 후반부에는 AI를 적극 활용해 누락된 케이스를 보완했고, 반복되는 구조는 describe로 묶어 정리해 가독성을 높였습니다.

리팩터링을 병행하며 작업하다 보니, 테스트 코드가 코드 안정성을 얼마나 크게 높여주는지 직접 체감할 수 있었어요. 코드를 수정하거나 스타일 클래스를 변경해도 테스트로 바로 검증할 수 있어서 작업이 훨씬 안정적이었고, “왜 현업에서 테스트를 중요하게 다루는지”도 이해할 수 있었어요.

사용한 테스트 코드 예시는 다음과 같습니다.

describe('StatusTag 컴포넌트', () => {
  describe('스타일 적용', () => {
    test('RECRUITING 상태일 때 올바른 스타일이 적용되어야 한다', () => {
      render(<StatusTag status="RECRUITING" />);
      const tag = screen.getByRole('status');
 
      expect(tag).toHaveClass('bg-white');
      expect(tag).toHaveClass('border-orange');
      expect(tag).toHaveClass('text-orange');
    });
 
    // ... 중략 ...
 
    test('ReviewOpen 상태일 때 올바른 스타일이 적용되어야 한다', () => {
      render(<StatusTag status="ReviewOpen" />);
      const tag = screen.getByRole('status');
 
      expect(tag).toHaveClass('bg-[var(--GreenScale-Green)]');
      expect(tag).toHaveClass('border-primary');
      expect(tag).toHaveClass('text-primary');
    });
  });
});

5) SEO 및 웹 접근성 개선

프로젝트 전체 품질을 점검하기 위해 Lighthouse로 성능을 확인했는데,이미지와 폰트 렌더링 문제로 성능 점수가 낮게 나오고, 접근성에서도 aria-label 누락, 색 대비 부족, 시맨틱 태그 미사용 등 다양한 이슈가 발견되었어요. 특히 메인 컬러가 초록 계열이라 WCAG 대비 기준을 충족하기가 쉽지 않았습니다.

이 문제들을 해결하기 위해 다음과 같은 개선 작업을 진행했어요.

• 동적 임포트(Dynamic Import) 적용
• 초기 화면 요소 우선 렌더링
• 웹 표준에 맞는 시맨틱 태그 사용
• 고용량 폰트 서브셋(Subsetting)으로 경량화
• Next.js local-font 기능 활용해 폰트 전송량 감소

개선 작업 이후 Lighthouse 기준 점수는 다음과 같이 올라갔어요.

• 성능: 65 → 81
• 접근성: 88 → 96
• SEO: 92 → 100

전반적으로 성능과 품질이 모두 안정적으로 개선되는 결과를 얻을 수 있었습니다.

6) 번들 사이즈 분석 및 최적화

프로젝트 성능을 점검하기 위해 next-bundle-analyzer를 적용해 번들 사이즈를 분석했어요. 이 과정에서 Zod 모듈의 크기가 예상보다 크게 포함되어 있다는 문제를 발견했습니다. 실제 주요 라우트의 First Load JS 평균이 195.5 kB로 꽤 무거운 편이었어요.

프로젝트 특성상 고급 스키마 기능까지는 필요하지 않다고 판단해, 더 가벼운 zod-mini로 교체하고 불필요한 의존성도 함께 정리했습니다. 그 결과 번들 사이즈가 눈에 띄게 줄어들었어요.

• 평균 First Load JS: 195.5 kB → 169.1 kB (-13.5%)
• 최대 First Load JS: 242 kB → 199 kB (-17.8%)
• /mypage는 -25.8%로 가장 큰 개선 효과

이번 경험을 통해 번들 사이즈를 측정하고 → 원인을 분석하고 → 직접 개선하는 성능 최적화 사이클을 처음부터 끝까지 경험해 볼 수 있었습니다.

7) 배포 툴의 리전문제

개인 프로젝트만 Vercel 무료 플랜을 사용할 수 있는 제한이 있었기 때문에, 대안으로 Netlify를 이용해 배포를 진행했어요. 그런데 Next.js(App Router) 기반 SSR을 적용했음에도 렌더링 속도가 CSR과 크게 차이나지 않거나 오히려 더 느리게 느껴지는 문제가 있었습니다.

처음에는 코드 문제라고 생각해 여러 부분을 점검했지만, 특별한 원인을 찾지 못했어요. 이후 강사님과 함께 살펴본 결과, 문제의 원인은 Netlify 배포 리전(region)이었어요. 기본적으로 한국과 거리가 먼 US East (Ohio) 리전에 배포되기 때문에 SSR 요청을 처리하는 속도가 느려지고, 그 결과 화면 렌더링도 지연된 것이었어요.

문제를 확인한 뒤, 레포지토리를 제 GitHub 계정으로 fork해 Vercel에 다시 배포해보았어요. 그 결과 SSR 요청 응답 속도가 눈에 띄게 개선되었고, CSR보다 훨씬 빠르게 렌더링되는 것을 직접 확인할 수 있었습니다. 배포 환경이 성능에 얼마나 큰 영향을 미치는지 체감할 수 있는 경험이었어요.

작업 내용

• 프로젝트 레포지토리: https://github.com/SoboonSoboon
• 서비스 링크: https://soboon-client-seven.vercel.app/

정규 커리큘럼 외 프로그램

1) 멘토링 진행

정규 프로젝트가 진행되는 6주 동안, 정규 커리큘럼 시간 이후에는 일주일에 두 번씩 현직 멘토님과 1시간씩 멘토링을 받을 수 있었어요. 멘토님이 매 회차마다 새로운 내용을 준비해주셔서 다양한 주제로 대화를 나눌 수 있었고, 실무에서는 어떤 방식으로 문제를 해결하는지, 어떤 상황을 경험해왔는지 구체적인 예시를 들어 설명해주셔서 많은 도움이 되었어요.

어떤 회차는 팀원들이 직접 리팩터링한 코드를 가져가 설명하며 진행되기도 했는데, 각자 다른 관점으로 리팩터링해온 점이 흥미로웠고, 다른 팀원의 코드를 보며 팀원들의 성향도 자연스럽게 알게 되었어요. 무엇보다 제가 미처 생각하지 못했던 개선 포인트들을 많이 발견할 수 있었고, 실제 코드 기반으로 피드백을 받으니 학습 효과도 훨씬 크게 느껴졌습니다.

아쉬웠던 점이 있다면, 멘토님이 여러 팀을 동시에 맡고 계셔서 일정이 종종 변경되었다는 점이에요. 하지만 전체적으로는 실무 이야기를 가까이에서 들을 수 있었던 정말 의미 있는 시간이었습니다.

2) 커리어 프로그램 참여

수료 이후 커리어 프로그램은 총 4주간 진행되었고, 이력서를 정비하며 다양한 피드백을 받을 수 있는 좋은 시간이었어요.

• 1주차: 이력서 작성
• 2주차: 1:1 현직자 이력서 멘토링 (1회차)
• 3주차: 1:1 현직자 이력서 멘토링 (2회차)
• 4주차: 1:1 기술/직무 모의 면접

2–3주차에는 정규 과정 때와 같은 멘토님께 1:1 이력서 멘토링을 받았어요. 형식적인 부분에서는 긍정적인 평가를 받았고, 제 블로그까지 꼼꼼히 살펴본 뒤 기술적으로 어떤 점을 보완하면 좋을지 구체적인 조언도 들을 수 있었어요. 궁금한 부분도 편하게 질문할 수 있었고, 이후에는 기술적인 내용을 중심으로 이력서를 어떻게 강화하면 좋을지 고민하며 실제로 여러 부분을 개선해볼 수 있었습니다.

현업에서 AI를 어떻게 활용하는지, 신입 개발자에게 기대하는 역량은 어느 정도인지, 제 이력서 기반으로 어떤 기술 질문이 나올 수 있을지 등 현실적인 이야기를 들으면서 제 강점과 보완할 점을 훨씬 명확하게 이해할 수 있었어요. 멘토링 이후에는 “그럼 나도 프로젝트에서 AI를 어떻게 활용해볼 수 있을까?” 하는 고민을 하며, 실제로 프로젝트 환경에 AI 코드 리뷰 기능을 설정해 적용해보기도 했어요.

4주차에는 1:1 기술/직무 모의 면접이 진행되었고, 10년 이상 경력을 가진 멘토님께 직접 피드백을 받을 수 있었어요. 첫 20분은 기술·이력서를 기반으로 실전처럼 면접을 진행했고, 이후에는 어떤 부분을 보완하면 좋을지, 실제 면접에서 자주 등장하는 질문은 무엇인지 등을 상세히 설명해주셨어요.

당시 제가 두 곳의 면접을 본 직후라, “답이 정해져 있는 질문에 뻔하지 않게 답하는 방법을 모르겠다”고 고민을 털어놓았는데, 멘토님이 “가능한 한 솔직하게 답하는 것이 결국 가장 좋은 방법”이라고 조언해주셨어요. 너무 가고 싶은 회사라고 해서 스스로를 과하게 포장하다 보면, 정작 나와 맞지 않는 환경으로 가게 될 수 있다는 말이 기억에 남았어요. 그 이후로는 면접을 준비할 때 제 생각을 솔직하게 전달하는 것이 더 중요하다는 점을 자연스럽게 깨닫게 되었어요.

정규 프로그램 과정에서도 멘토링을 받을 수 있었고, 이후 커리어 프로그램까지 참여하면서 총 세 분의 현직 프론트엔드 개발자 멘토님을 만나 뵐 수 있었습니다. 덕분에 취업을 위해 어떤 부분을 보완해야 하는지 방향을 잡을 수 있었고, 실제 업무를 기반으로 한 현실적인 조언들을 들으며 제 강점과 부족한 점을 다시 돌아보는 계기가 되었어요.

3) 인턴십 기회

수료생에게 제공되는 인턴십 기회에 2월부터 참여하게 되었어요. 이력서 멘토링에서 받은 피드백을 바탕으로 문서를 다시 정리했고, 관심 있는 도메인과 기술 스택을 사용하는 회사에 지원해 합격 소식을 들을 수 있었습니다.

단순히 기능 구현 경험을 나열하는 것이 아니라, 문제를 발견하고 해결해가는 과정, 그리고 그 과정에서 무엇을 배우고 어떻게 사고했는지를 구체적으로 풀어낸 점이 좋게 평가되지 않았을까 생각해요.

곧 시작될 인턴십에서는 프론트엔드 단기 심화 과정에서 익힌 경험을 실제 실무에 적용해보며 한 단계 더 성장할 수 있을 것 같아 기대되는 마음이에요.

배운 점들을 실제 작업에 적용한 과정

프론트엔드 단기 심화 과정에서 배운 내용을 바탕으로, 현재 사이드 프로젝트로 참여하고 있는 ‘스노로즈’에도 여러 부분을 적극적으로 적용해보고 있어요. 2025년 10월부터는 스노로즈 백오피스 기능 개발에도 참여하고 있는데, 심화 과정에서 익힌 기술들을 실제 프로젝트에 하나씩 반영하면서 서비스 품질과 개발 환경을 함께 개선해 보는 연습을 하고 있습니다. 아래는 프론트엔드 심화 과정에서 배운 내용을 '스노로즈'에 실제로 적용한 사례를 정리한 내용이에요.

• 스노로즈 메인 서비스 적용
  • 기존 Storybook 코드를 최신화해 전체 구조를 정리했어요.
  • Storybook 관련 코드를 컴포넌트 내부로 이동해, 해당 컴포넌트에 스토리북이 있는지 바로 확인할 수 있도록 구조를 개선했어요. 단기 심화 과정 프로젝트에서 이렇게 적용해보니 협업할 때 훨씬 편리해서 스노로즈에도 동일하게 반영했습니다.
  • Chromatic이 빌드마다 URL이 변경되는 문제를 해결하기 위해, 구매한 도메인으로 Storybook을 고정 배포했어요. (관련 링크: 스노로즈 스토리북)
• 스노로즈 백오피스 적용
  • TailwindCSS와 shadcn/ui로 UI 스타일 구조를 통일해 개발 경험의 일관성을 확보했어요.
  • Husky 기반 로컬 검증 자동화
    • 커밋 전에 lint와 포맷 검증이 자동으로 실행되도록 설정해 코드 품질을 강화했어요.
    • 관련 PR: husky 및 lint-staged 설정
  • GitHub Workflow 구축
    • PR Assignee·Label 자동화를 적용해 반복되는 협업 작업을 줄이고 작업 흐름을 안정화했습니다.
    • 관련 블로그 글: PR Assignee와 Label 자동화하기
  • Vitest 기반 기능 테스트 도입
    • 푸시 알림 등 핵심 기능을 테스트 코드로 검증해 안정적인 배포 환경을 구축했어요.
    • 관련 PR: 푸시 알림 기능 테스트 코드 작성

마치며

1) 아쉬웠던 점

초반에 일정 관리를 충분히 하지 못해 후반부에는 늦은 새벽까지 작업하게 된 점이 가장 아쉬웠어요. 철야 작업이 이어지면서 다음날 컨디션에도 영향을 주었고, 전체적인 작업 효율까지 떨어지더라고요. 여기에 디자인 일정이 지연되면서 프론트 작업도 함께 밀리다 보니, 내부적으로도 외부적으로도 일정 관리를 조금 더 단단하게 했더라면 더 많은 결과물을 만들 수 있지 않았을까 하는 생각이 남습니다.

하지만 이런 상황을 함께 겪으면서 팀원들과 훨씬 더 긴밀하게 협업할 수 있었고, 자연스럽게 서로 도와가며 작업하는 분위기가 만들어진 점은 오히려 긍정적인 경험으로 남았어요.

기술적인 측면에서 아쉬운 점은 테스트 코드 부분에서도 있었어요. 이번에는 컴포넌트 단위 테스트에 집중했지만, API 모킹이나 커스텀 훅 테스트, 상태 관리 라이브러리 테스트까지 함께 진행했더라면 더 탄탄한 테스트 구조를 만들 수 있었겠다는 생각이 들어요.

2) 좋았던 점

돌아보면 개인적으로 기대했던 것보다 훨씬 많은 것을 얻어갈 수 있었던 시간이었습니다. 9시부터 오후 7시까지 이어지는 일정이 쉽지는 않았지만, 그만큼 배운 점도 많았어요. 개발 역량뿐 아니라 디자인 시스템, Storybook, GitHub Actions, Husky 등 재사용성과 자동화를 높여주는 도구들을 직접 활용해본 경험이 특히 크게 남았습니다.

기능을 구현하는 것만큼 중요한 건 협업 환경을 효율적으로 만드는 일이라는 걸 이번 과정을 통해 더 깊이 깨달았어요. 팀 전체 흐름을 안정시키고 반복 작업을 줄이는 도구와 자동화에 자연스럽게 관심이 커졌고, 실제로 이런 방식이 개발 생산성과 서비스 품질에 얼마나 큰 영향을 주는지도 몸소 경험했습니다.

프로젝트 흐름을 되돌아보면, 초반에는 기획 시간이 길어지고 디자인도 늦게 나오면서 중간 발표 시점까지 구현된 기능이 거의 없을 정도로 분위기가 조금 무거웠어요. 하지만 마지막 2주 동안 팀원들과 불철주야 집중해서 개발을 몰아치며 최종 발표를 무사히 마칠 수 있었습니다. 정규 수업 이후에도 일정을 맞추기 위해 계속 작업했고, 촉박한 일정 속에서도 기능 검증과 디자인 QA를 거치며 서비스 완성도를 끌어올릴 수 있었어요.

이 과정에서 협업 경험도 자연스럽게 많이 쌓였어요. 프론트엔드뿐 아니라 백엔드, 디자이너분들과도 빠르게 소통하며 각자 맡은 영역을 맞춰 나가다 보니 팀워크가 탄탄해졌고, 프로젝트 이후 대면 회식을 두 번이나 할 만큼 팀 분위기도 정말 좋았습니다. (중식을 좋아하는 취향도 잘 맞았어요🍜🥟)

그리고 여러 프론트엔드 현직자분들을 가까이에서 만나 다양한 시각을 들을 수 있었다는 점도 이 과정의 큰 장점이었어요. 이론 수업을 진행해주신 주강사님뿐 아니라 멘토링을 맡아주신 현직 프론트엔드 개발자분들의 조언 덕분에, 채용 시장에서의 제 위치를 더 객관적으로 바라볼 수 있었고 앞으로 어떤 부분을 보완해야 할지도 정리할 수 있었습니다.

좋은 팀원들과 멘토님들을 만날 수 있었다는 게 정말 큰 행운이었던 것 같아요. 프론트엔드 단기 심화 과정 2개월뿐 아니라 이후 이어진 1개월의 커리어 프로그램까지, 짧다면 짧은 기간 안에 많은 것을 배우고 성장할 수 있는 시간이었습니다.

이제 곧 인턴십을 시작하게 되는데, 새로운 환경에서 다시 개발에 참여하게 된다는 사실이 기대되기도 하고 설레기도 해요.

이번 프론트엔드 단기 심화 경험들을 바탕으로 앞으로도 꾸준히 성장하는 개발자로 나아가고 싶습니다 🚀

에필로그

프로젝트가 끝난 뒤에도 팀원들이랑 계속 연락하면서 지내고 있어요. 가끔 만나서 회식도 하고, 드라마 이야기도 하고, 생일이면 챙겨주고, 맛있는 음식도 서로 추천해주다 보니 디스코드 채널은 지금도 꽤 활발해요. (다음 회식 장소는 하이디라오가 될 것 같아요)

물론 코딩테스트 스터디, 자격증, 면접 스터디도 종종 함께 하고 있어요^^*

#코드잇스프린트 #코드잇스프린트후기