저번 글에서 스타트업 개발팀에 합류했다는 얘기를 살짝 꺼냈는데, 이번에 제대로 풀어보려고 합니다.
겁은 났지만 일단 뛰어들었다
솔직히 처음엔 무서웠습니다.
고등학생이 실제 서비스 만드는 회사에 들어간다는 게 현실적으로 가능한 일인가 싶었습니다. 근데 "어차피 배우면서 하는 거고, 실전보다 빠른 성장은 없다"는 생각으로 그냥 들어갔습니다.
지금 돌아보면 그 선택이 맞았던 것 같습니다.
내가 직접 만든 것들
공식 홈페이지
첫 번째 큰 작업이었습니다. 단순한 소개 페이지가 아니라
채용, 블로그, 뉴스, 팀원 소개, 정책 페이지까지 다 포함된 풀사이즈 웹사이트였습니다.
들어가자마자 회사의 얼굴을 디자인부터 개발, 유지보수까지 다 해야한다 생각하니 앞길이 막막했습니다.
아키텍처는 FSD(Feature-Sliced Design)를 선택했습니다. 팀이 커져도 파일 위치가 명확해야 하기 때문입니다.
src/
├── app/ # Next.js 페이지, 레이아웃
├── shared/ # 공통 UI, 훅, 유틸
├── entities/ # 도메인 데이터 (API, 스키마)
├── features/ # 사용자 액션 (폼, Query, Mutation)
├── widgets/ # 페이지 섹션 UI
└── i18n/ # 다국어 설정실제로 나중에 디버깅 할때도 효율적이었습니다
도메인별로 분류되어 에러가 생겨도 바로바로 캐치할 수 있기 때문입니다
디자인 시스템
디자이너 없이 제품 6개의 UI를 일관성 있게 유지하려면 디자인 시스템이 필수였습니다.
버튼 컬러 하나 바꾸려고 6군데를 다 고쳐야 하는 삽질만 계속 하다 보니 걍 다 때려치고 싶은 마음이 컸기 때문입니다.
가장 어려운 건 컴포넌트 API 설계였습니다.
variant, size, disabled 같은 기본 props는 쉬운데, 합성 가능한 복합 컴포넌트를 설계하는 건 진짜 머리 아팠습니다.
처음엔 너무 유연하게 만들려다 복잡도만 올라갔고, 결국 핵심은 하나였습니다.
"이 컴포넌트를 쓰는 나의 입장에서 생각하기"
CI/CD 파이프라인
수동 배포는 실수도 실수지만 가장 귀찮고 비효율적인 작업이라 생각했습니다.
그래서 GitHub Actions + Semantic Release 기반 자동 배포를 직접 구성했습니다.
Git 태그 push (1.x.x 형식)
-> ubuntu로 가상 환경 설계
-> Test Coverage로 이 컴포넌트가 웹 접근성에 맞는지 체크
-> Semantic Release 봇이 npm 라이브러리로 배포개발 때려치우고 싶은 순간 3가지
1. Next 이거 React랑 비슷한데 안비슷하다
기존에 React로만 개발했지만, SEO나 다국어 처리 면에서 Next가 낫다고 판단해서
기존 React 프로젝트를 Next로 마이그레이션 할 때 React는 없던 Server / Client Component 구분이 굉장히 어려웠습니다.
use client를 어디까지 내려야 하는지 수십 번 리팩터링했고, 그러다 세운 원칙 하나가 생겼습니다.
"인터랙션이 없으면 서버, 상태가 필요하면 클라이언트"
단순하지만 이 원칙 하나로 판단 속도가 확 빨라졌습니다.
2. i18n을 나중에 붙이는 판단이 에바였다
"다국어는 나중에 붙이면 되지"라고 생각하고 절반쯤 만들었을 때 next-intl을 붙이려니까, 하드코딩된 한국어 문자열이 수백 개였습니다.
그렇게 모든 메시지를 다시 설계하면서 매일 저녁 10시에 퇴근하는 삶이 반복되었습니다.
그 이후로 국제화는 무조건 처음부터 설계하게 됐습니다.
이 삽질 덕분에 지금은 프로젝트 시작 전에 i18n 구조부터 잡습니다.
3. FSD를 학습하는 것
FSD가 좋다는 건 알았는데,
기존에 components/, pages/, hooks/ 구조에 익숙한 저에게
entities, features, widgets 개념을 이해하는게 굉장히 힘들었습니다.
당장 시간은 없는데 서비스는 개발해야 하니, 맨날 야근하면서 개발자 커뮤니티도 둘러보고, Claude, Codex에게 이게 맞는지 방향성을 잡아가면서 개발하였습니다.
고등학생으로 일하면서 깨달은 것
기술적인 문제에서 나이가 걸림돌이 된 적은 한 번도 없었습니다.
코드 앞에서 나이는 숫자에 불과하니까요
저에게 힘들었던 건 커뮤니케이션이었습니다.
대형 I인 저에겐 상사에겐커녕, 동료들에게도 이걸 말하기가 굉장히 어려웠습니다.
기획이 바뀌었을 때 어떻게 피드백할지, 일정이 빡빡할 때 어떻게 협상할지,
모르는 걸 어떻게 물어볼지. 이게 코드보다 훨씬 어려웠습니다.
이제 곧 1년차 개발자..
초반엔 공식 홈페이지까지 버거웠던 제가, 현재는 테스트 커버리지 작성, BFF 방식 도입,
a11y에 맞춘 컴포넌트까지 설계하며, 회사에서 총 8+의 레포를 총괄하며
현재 신입 -> 1년차 개발자로 성장해 나가고 있습니다.
긴 글 읽어주셔서 감사하며, 댓글은 언제나 환영입니다.
우와 많이 컸네여 상만 어린이