들어가며​

오픈닥터에서의 '첫 3개월' 수습 기간을 공식적으로 마무리하고 다음 단계를 준비하는 의미 있는 한 달이었다. 3개월간의 수습 기간을 마치고 PO님, 그리고 개발팀 동료들과 함께 'CSS (Continue, Stop, Start)' 방식의 회고를 진행했다.

각 개인 성장을 위해 이렇게 함께 시간을 내어 고민해준다는 것 자체만으로도 정말 감사한 경험이었다. 이 피드백을 통해 지난 3개월간의 내 모습을 객관적으로 돌아보고, 앞으로 나아갈 방향을 설정할 수 있게 되었다.

10월 액션 포인트를 돌아보며 10월 회고를 작성해보려고 한다.

• 10월의 액션 포인트

• 기존 사내 코드 SSR 전환을 위해 Next.js 학습 (2주 집중 학습)

• 기본적인 SQL문 학습

• 오픈 닥터 웹/앱 마이그레이션을 위해 Flutter-web 공부하기

지난 회고에서 위의 3가지의 액션 포인트를 작성했는데, 이렇다할 결과가 없어 체는크 하지 못했다. 보다 명확한 월간 회고별 액션 포인트를 작성하도록 노력해야겠다. 10월 회고를 11월의 액션 포인트는 보다 구체적이고 우선순위가 높은 것들을 선별해서 작성해보려고 한다.

3개월 수습 통과 후, PO와 개발팀과 함께 회고​

CSS 회고는

• Continue (계속 잘하고 있는 점)
• Stop (개선이 필요한 점)
• Start (새롭게 시도하면 좋을 점)

순서로 진행되었다. 동료분들의 이름을 가리고 공유해주신 피드백을 이미지로 첨부해본다.

피드백을 정리하며 파악한 나의 모습은 다음과 같았다.

발전시키면 좋을 나의 강점

• 문서 기반의 소통: 히스토리 파악과 공유를 위해 문서를 적극적으로 활용한 점
• 적극적인 QA와 오너십: 맡은 작업에 대해 책임감을 가지고 주도적으로 QA를 진행한 점
• 수용적이고 주도적인 태도: 피드백을 긍정적으로 수용하고, 업무를 주도적으로 찾아서 하려는 태도

함께 하고 싶은 동료가 되기 위한 개선할 부분

• 디버깅 스킬: 문제 발생 시 버그 지점을 빠르게 파악하는 능력을 키울 필요가 있음
• 기술 리서치 역량: 기술 스택 선정이나 리서치 시, 근거를 더 꼼꼼하게 수집하고 명확하게 전달하는 노력
• 완벽주의보다 완수: '너무 잘하려는' 태도에서 조금 힘을 빼고, '일단 완수하고 개선하는' 사이클을 만드는 연습

장점은 계속 갈고 닦고 부족한 점은 원인을 파악해서 남은 2개월간 집중적으로 개선해나갈 계획이다.

기술적인 고민, "Vercel 이전, 지금 꼭 필요한가?"​

10월의 큰 기술적 고민 중 하나는 오픈닥터 웹 SEO 최적화를 위한 Next.js SSR 도입과 배포 환경이었다.

팀 내에서는 "SEO 최적화를 위해 Vercel 이전이 필수적이다"라는 의견이 있었지만, AWS Amplify 공식 문서를 다시 검토하며 이 전제에 질문을 던지게 되었다. "Amplify는 Next.js의 핵심 기능은 대부분 지원하는데, Vercel에서 제공해주는 기능이 없다면 현시점 우리 목표인 SEO 최적화에 치명적인 문제가 있을까 싶었다.

그래서 우선 각 밴더가 지원 여부 및 비용을 찾아보고 동료들에게 공유했다.

Amplify의 지원 현황 (되는 것 vs 안 되는 것)

Amplify는 Next.js의 핵심 기능을 대부분 지원한다.

• 되는 것: SSR, SSG, 시간 기반 ISR, 이미지 최적화.
• 안 되는 것:
  • On-demand ISR (주문형 갱신): 이벤트 기반 즉시 갱신이 불가능하고 시간 기반갱신만 가능합니다.
  • Next.js Streaming: UI 뼈대를 먼저 보여주는 스트리밍을 지원하지 않아, Core Web Vitals 의 LCP 개선에 Vercel 보다 불리할 수 있다.
  • 미들웨어 성능: 기능은 동작하지만, AWS의 lambda 엣지 기반이라 Vercel의 Edge 성능 대비 심각한 콜드 스타트 위험이 있다.

Vercel 이전의 비용과 리스크

단순히 기능만 보고 Vercel로 이전하기에는 명확한 비용이 존재합니다.

1. 기술적 종속성: Vercel은 Next.js의 모든 기능을 지원하지만, 이는 Next.js가 Vercel 인프라에 강하게 묶여있음을 의미한다. 반골 기질이 있는... 우리에겐
2. 운영 비용 및 복잡성 증가: 인프라 벤더가 분산되면 관리 포인트와 비용이 증가한다.

결론은 먼저 Amplify에서 Next.js SSR을 구축하고 최적화를 진행하는 것

Amplify의 한계가 현재 우리 서비스의 Core Web Vitals 점수에 치명적인 영향을 주는지 혹은 On-demand ISR의 실시간성이 우리 비즈니스에 필수적인지 검토한 결과, "아직은 아니다"라는 결론을 내렸다.

따라서 먼저 Amplify 내에서 SEO를 극대화, 예를 들어 이미지 최적화 점검, 불필요한 동적 렌더링 최소화와 같은 작업을 시도하고, Core Web Vitals 점수가 목표치에 미달하거나 콘텐츠의 실시간성이 중요해지는 시점에 Vercel 이전을 재검토하는 것으로 제안했다.

또한 amplify 환경에선 모노레포 빌드 스크립트 작성에 애를 먹는다는 의견들이 많았는데 현재 오픈닥터는 모노레포 구성도 아니기에 더욱이 amplify에서 할 수 있는 것들을 진행해보기로 했다.

겪어보면 알겠지 싶었다... 미래의 우리 파이팅

OPN 디자인 시스템 구축 시작​

입사 3개월 차가 되면서, 당장의 기능 개발 외에 장기적으로 기여할 먹거리들이 보이기 시작했다. PO이자 디자이너이신 성욱님이 피그마에 OPN 디자인 시스템 파일을 따로 관리하시는 것을 보고 든 생각이 었다.

하지만 해야할 것들이 많은 상황에서,중요하지만 급하지 않은 디자인 시스템 구축은 선뜻 시작하기 어려운 프로젝트처럼 보였다.

그래서 무작정 '제가 할게요!'가 아닌 이 프로젝트를 현실적으로 시작할 기반을 먼저 마련해야겠다고 생각했다. 그래서 스프린트 회의에서 공식적으로 논의를 제안하기에 앞서, 다음과 같은 사전 작업을 진행해보았다.

1. 디자인 시스템 리서치: (토스, 라인 등 국내외 디자인 시스템 사례 분석)
2. OPN 디자인 시스템 분석: (디자이너가 설계 중인 피그마 파일 분석)
3. 디자인 시스템 구축 청사진: (컴포넌트별 예상 개발 공수 측정)
4. 개발 환경 구축: react 기반 Storybook 초기 세팅 및 환경 구성

이러한 준비를 바탕으로 스프린트 회의에서 '디자인 시스템 구축'을 안건으로 올렸습니다.

물론 이 프로젝트는 당장의 우선순위가 높지 않을 수 있다고 생각한다. 그래서 디자이너와 논의하여, 기존 스프린트 업무에 부담을 주지 않으면서도 꾸준히 진행할 수 있는 '의도적인 프로세스'를 함께 제안해보았다.

우리의 경량 프로세스(일이 되도록 먼저 작게라도 하자)

• 주기적인 디자인 시스템 컴포넌트 QA 미팅: 매주 목요일 3시, 1시간 동안 디자인 시스템 QA 및 싱크업을 진행합니다.
• 스프린트 최소 목표 설정: 스프린트마다 최소 2개 이상의 컴포넌트를 구현하고, 이를 Storybook으로 함께 QA하는 것을 목표로 합니다.

이렇게 작은 사이클을 돌리며 시스템을 점진적으로 완성해나갈 계획입니다.

25년 10월 말, 시작은 작지만 아마 내년에 흐뭇하게 바라볼 것 같다. 시작은 했다. 잘했다!

디자인 시스템 구축해본 경험이 있는 프론트엔드 개발자분이 있다면 댓글 혹은 링크드인으로 연락주세요.. 도와주세요.

마치며​

10월은 작은 성공의 기쁨과 동료들의 따뜻한 피드백으로 가득 찬 한 달이었다. 3개월 전의 나와 지금의 나를 돌아보며 이 성장의 동력을 주신 분들께 다시 한번 깊이 감사했다.

• 11월의 액션 포인트

• Next.js 뉴 오픈 닥터 POC(Proof of Concept) 완료 및 공유

• 오픈닥터용 네이버 지도 API 가이드

  • 핵심 기능 3~5가지(e.g., 마커 찍기, 거리 계산)의 코드 스니펫.
  • 우리가 겪었던(or 겪을) '주요 문제와 해결책' (e.g., 좌표계 오류, 마커 로딩 최적화).
  • 신규 입사자를 위한 초기 세팅 방법 및 인증 키 관리 방안.

• 코드 에디터 디버깅 툴 학습 및 실무에 적용