서론

어제 진행된 15주차의 데모데이를 끝으로 5월 16일부터 시작했던 16주의 Yapp 활동이 거의 마무리 됐습니다. 마지막 회고 세션이 남아있긴 하지만 데모데이를 마치고 나니 사실 동아리 정규 활동이 모두 끝났다고 느껴지네요. 잊기 전에 Yapp 활동에 대한 기록을 정리하고 싶어서 회고를 작성해보겠습니다.

AI는 하나도 안쓰고 한땀한땀 작성해보겠습니다 ㅎㅅㅎ

Yapp이란?

YAPP은 기획자(PM), 디자이너, 개발자가 협업하여 4개월 동안 하나의 IT 서비스를 제작하는 기업형 IT 연합 커뮤니티입니다.

자세한 내용은 Yapp 홈페이지에서 확인하실 수 있습니다.

지원 동기

다시 한번 사이드 프로젝트를 하고 싶다는 생각을 했습니다. AI의 발전으로 사이드 프로젝트는 혼자서도 할 수 있지만 저는 사이드 프로젝트를 하면서 다음 커리어에 대한 간접 경험들을 쌓고 싶었습니다.

디자이너와 협업을 하는 디자인 엔지니어링, 프론트엔드 인프라를 책임지는 프론트엔드 플랫폼 엔지니어링, 그 외에 재밌고 난이도 있는 프론트엔드 개발과 같은 경험을 하기 위해서는 협업 경험이 필요하다고 생각했습니다.

이를 위해서 연합동아리에 다시 참여하기로 결심하고 여러 동아리 탐색을 시작했습니다.

DND, CMC를 진행한 후 참여하고 싶은 동아리의 조건은 다음과 같았습니다.

1. 활동 기간이 길면 좋겠다.

8주간 진행되는 DND 활동해본 결과 아래와 같은 아쉬움이 있었습니다.

1. 실 개발 시간은 거의 2 ~ 3주안에 모든 개발을 진행해야 했습니다. 이 때문에 구현에 급급하고 기술적 고민을 하기에는 부족했던 것 같습니다.
2. 짧은 기간동안 개발하고 온라인으로 대부분의 세션을 진행하다보니 네트워킹의 기회가 적다고 느꼈습니다.

그래서 이번에는 3, 4개월 이상 활동하는 동아리를 찾아봤습니다.

2. 사람들이 많이 지원하는 동아리 혹은 유명한 동아리

메이저한 동아리일수록 더 인적 자원의 퀄리티가 높을 것 같다고 생각했습니다.

3. 기획자가 있는 동아리에서 하고 싶다.

기획자가 없는 DND에서는 디자이너와 개발자가 기획까지 해야합니다.

0 -> 1의 기획을 해보는 좋은 경험이라고 생각하지만 결정권자가 없어서 기획이 산으로 가거나 이슈가 질질 끌리는 경우가 있다고 느껴서 이왕이면 PM 직군이 있는 동아리를 가고 싶었습니다.

4. OB와 커뮤니케이션이 활발한 커뮤니티가 있으면 좋겠다.

동아리 활동을 하는 이유는 사이드 프로젝트 외에 좋은 개발자와의 네트워킹도 크다고 생각해서 OB와의 커뮤니티가 있는 동아리에 합류하고 싶었습니다.

위에 적은 우선 순위대로 여러 개발동아리를 탐색해본 결과 Yapp이 이 조건에서 모두 부합했습니다.

Yapp에 대한 관심이 깊어진 건 작년 DND 데모데이를 함께 진행했을 때 였습니다. 약 3개월동안 개발한 프로젝트의 퀄리티, 팀끼리 더 친밀해보이는 분위기 등을 보고 나중에 Yapp에 참여하고 싶다는 생각을 하게 됐습니다.

3. 지원 절차

Yapp은 서류 지원 → 면접 → 합격 순으로 진행됩니다.

4. 자기소개서

Yapp의 자기소개서 항목과 작성한 답변을 모두 적어보겠습니다. 정리해놓은 경험과 자기소개서 항목을 조합하면서 어렵지 않게 작성한 것 같습니다.

1. YAPP에 지원하게 된 동기를 작성해주세요. 그리고 YAPP 활동을 통해 이루고 싶은 목표와 이를 실현하기 위한 구체적인 계획을 작성해주세요. (600자)

   새로운 기술적 도전과 서비스 운영 경험을 쌓고자 YAPP에 지원했습니다.

   현재 회사에서는 1인 프론트엔드 개발자로 기능 구현과 성능 최적화에 집중해왔지만 새로운 기술을 팀 프로젝트에 적용하고 사용자 반응을 확인할 기회는 상대적으로 부족했습니다.

   YAPP은 PM, 디자이너, 개발자가 한 팀으로 4개월간 하나의 서비스를 만들고 문제 정의부터 출시와 운영까지 경험할 수 있는 커뮤니티라는 점에서 제가 원하는 성장 방향과 맞았습니다. 활동 중에는 SVG 기반 마이크로인터랙션, Motion과 GSAP을 이용한 애니메이션, 필요하다면 Three.js 기반 3D 표현까지 프로젝트 목적에 맞게 적용해 유저 플로우를 더 직관적이고 즐겁게 만들고 싶습니다.

   또한 GA 커스텀 이벤트와 Clarity로 주요 행동과 실제 사용 흐름을 분석하고 가능하다면 A/B 테스트나 Feature Flag로 기능을 점진적으로 실험하며 데이터 기반으로 서비스를 개선하고 싶습니다. 나아가 Next.js와 AWS를 활용해 배포 환경을 구성하고 롤백이나 Blue-Green 배포처럼 안정적인 운영 방식도 직접 적용해보고 싶습니다.

2. 타 직군과 협업한 프로젝트에서 발생한 이슈 상황을 예시로 구체적으로 어떻게 소통해서 해결하셨는지 작성해주세요. (600자)

   연합동아리 DND에서 독서 기록 서비스를 개발하며 일정 문제에 직면했습니다. 초기 기획에는 개인 독서 기록 외에 서재 초대 및 방문, 캐릭터 자랑과 SNS 공유까지 포함되어 있었는데 개발을 시작하니 주어진 기간 안에 모두 구현하기는 어려운 상황이었습니다.

   저는 기능을 단순히 줄이자고 말하기보다 각 기능이 서비스 목표에 얼마나 직접적으로 기여하는지 기준을 먼저 공유했습니다. 서재 초대나 SNS 공유는 개인 기록이 충분히 쌓인 뒤에야 의미가 커지는 기능이므로 먼저 사용자가 책을 기록하고 캐릭터를 성장시키는 핵심 경험을 완성하자고 제안했습니다. 디자이너에게는 제거할 화면과 유지할 화면을 구분해 리소스를 다시 배분할 수 있도록 설명했고 개발자들과는 남은 기능의 구현 난이도와 일정을 재산정했습니다.

   그 결과 팀은 개인화된 독서 기록 경험에 집중하기로 합의했고 기한 내 프로젝트를 마무리할 수 있었습니다. 이후 데모데이에서 2위 대비 2배 이상의 투표를 받으며 대상을 수상했습니다. 모든 것을 하려다 아무것도 못 끝내는 것보다 과감하게 줄여 핵심을 완성하는 것이 더 좋은 결과를 만든다는 점을 배웠습니다.

3. 관심을 갖고 기술이나 도구를 탐구해본 경험을 소개해주세요. 실제로 프로젝트에 적용해보면서 느낀 좋은 점 혹은 한계나 아쉬운 점을 포함해서 자유롭게 설명해주세요. (700자)

   회사에서 고용량 이미지로 인해 첫 페이지 로딩이 지연되는 문제를 해결하기 위해 이미지 최적화 방식을 탐구했습니다. 초기에는 백엔드 팀에 업로드 시점의 서버 압축을 제안했지만 내부 클라우드 환경의 안정성 이슈로 운영 부담이 크다고 판단했습니다. 이후 오픈소스 이미지 압축 라이브러리를 조사했으나 대부분 1~2년간 유지보수되지 않았고 일부 기능은 CDN에 의존해 폐쇄망 환경에서 안정성이 우려되었습니다.

   이에 관련 오픈소스 코드를 참고해 Canvas API 기반 이미지 압축을 구현했습니다. 이미지를 Canvas에 다시 그리며 크기와 품질을 조정한 뒤 Blob으로 변환하는 방식이었습니다. 압축 작업이 메인 스레드에 부하를 주어 UI 응답성이 떨어지는 문제는 Web Worker로 분리해 해결했습니다. 또한 프리로딩 중 화면 깜빡이는 문제는 useEffect 대신 useLayoutEffect를 사용해 렌더링 전에 이미지를 준비하도록 변경했습니다. 그 결과 2MB 이미지를 200KB로 압축하고 로딩 시간을 730ms에서 70ms로 90% 단축했습니다.

   별도 서버 변경 없이 빠르게 적용하고 폐쇄망에서도 동작을 제어할 수 있었던 점은 좋았지만 클라이언트 압축은 기기 성능과 브라우저 차이에 영향을 받는 한계가 있었습니다. 이 경험을 통해 기술 선택 시 성능뿐 아니라 실행 환경, 유지보수성, 운영 안정성까지 함께 검토해야 한다는 점을 배웠습니다.

4. 개발하면서 배운 것을 어떻게 기록하거나 공유하는지 본인만의 방법을 소개해주세요. 블로그, 팀 내 공유, 코드 리뷰 등 형식은 무엇이든 괜찮습니다. 구체적인 사례와 함께, 그 경험이 본인이나 주변에 어떤 영향을 주었는지 설명해주세요. (700자)

   개발하면서 배운 내용은 기술 블로그에 정리하며 제 것으로 만들고 있습니다. 블로그에는 Vite 마이그레이션 중 겪은 설정 문제나 Emotion 테마 오버라이딩 같은 실무 기록뿐 아니라 웹 애니메이션과 같이 개인적으로 공부한 기술과 사용법도 함께 정리하고 있습니다. 단순히 결과만 남기기보다 문제가 발생한 배경, 시도한 방법, 다음에 참고할 점 등을 함께 적어 다시 비슷한 상황을 만났을 때 활용할 수 있도록 합니다.

   팀원이 기술적 문제를 겪을 때는 이전에 읽어두었던 공식 문서나 아티클을 찾아 공유하고 있습니다. 예를 들어 티맥스 와플에 근무할 때 동적으로 추가 및 삭제되는 폼을 구현해야 했던 팀원에게 React Hook Form의 useFieldArray 관련 자료를 공유한 적이 있습니다. 또 국제화 작업을 맡은 팀원에게는 Google Spreadsheet API를 활용해 번역 데이터를 관리하고 자동화하는 NHN의 블로그를 공유했습니다. 단순히 링크만 전달하기보다 현재 문제와 연결되는 부분을 함께 전달해 구현 방향을 잡는 데 도움이 되도록 했습니다.

   이런 공유를 통해 팀원들이 처음부터 자료를 찾는 시간을 줄일 수 있었고 저 역시 평소 읽고 정리한 내용을 실제 문제 해결에 연결하는 경험을 쌓을 수 있었습니다. 앞으로도 개인 학습에 그치지 않고 팀의 시행착오를 줄이는 방식으로 지식을 공유하고 싶습니다.

5. 가장 열정적으로 참여했던 프로젝트 중 하나를 선택해서 자세히 소개해주세요. 본인의 역할, 배운 점 등 자유롭게 설명해주세요. *최소 700자 이상 작성해주세요. 최대 1000자

   현재 회사에서 React 웹 애플리케이션을 인수인계 받았을 때 빌드 파일이 S3에서 바로 제공되고 있어 로딩 속도가 느린 상태였습니다. Lighthouse로 성능을 측정해 병목 구간을 파악한 뒤 네트워크, 번들, 폰트 세 방향으로 개선을 진행했습니다.

   먼저 S3 직접 제공 방식은 요청마다 오리진에서 응답해야 하므로 응답 속도와 전송 비용 모두 비효율적이었습니다. CloudFront를 도입해 캐시된 응답을 제공하도록 개선하고 Brotli 압축을 적용해 전송 크기를 줄였습니다. 여기에 리소스 특성에 맞는 HTTP 캐싱 전략을 설정했습니다. HTML은 파일명이 같아도 배포마다 내용이 바뀔 수 있으므로 max-age를 0으로 두어 브라우저가 매번 CDN에 재검증하도록 하되 s-maxage는 1년으로 설정해 CDN 자체는 캐시를 유지하고 배포 시에만 invalidation하는 방식을 적용했습니다. 반면 JS와 CSS는 빌드마다 파일명에 해시가 포함되어 내용이 바뀌면 파일명도 바뀌므로 max-age를 1년으로 설정해 브라우저에서도 영구 캐시하도록 했습니다.

   다음으로 TanStack Router의 코드 스플리팅을 활용해 라우트 단위로 번들을 분리하고 페이지별 라이브러리 사용 빈도를 분석해 공통으로 자주 쓰이는 라이브러리는 별도 청크로 묶었습니다. 여러 페이지에서 공유되는 코드를 분리하면 한 번 캐시된 청크를 페이지 이동 시 재활용할 수 있어 앞서 설정한 캐싱 전략과 함께 시너지를 낼 수 있기 때문입니다.

   마지막으로 다양한 굵기를 하나의 파일로 처리할 수 있는 가변 폰트를 적용하고 Python fonttools를 이용해 실제 서비스에서 사용하는 글자만 추출하는 폰트 서브셋팅을 진행해 폰트 용량을 70% 줄였습니다.

   이러한 개선의 결과 FCP를 50% 단축했습니다. 이 경험을 통해 성능 최적화는 단순히 코드를 빠르게 만드는 것이 아니라 각 리소스의 특성을 이해하고 그에 맞는 전략을 선택하는 것이 핵심이라는 점을 배웠습니다.

6. 만약, 활동 중 개인 일정으로 정기 세션 참여가 어려우시다면 어떻게 대처하실지 작성해주세요. - 200자

   개인 일정은 정기 세션과 겹치지 않도록 우선 조정하겠습니다. 불가피하게 참여가 어렵다면 최대한 빨리 팀원에게 공유하고 양해를 구하겠습니다. 이후 회의록과 진행 상황을 확인해 필요한 작업을 맡고 평일 저녁이나 주말에 추가 시간을 투입해 팀 일정에 차질이 없도록 보완하겠습니다.

5. 면접

면접은 Yapp에서 제시한 면접 시간 중에 면접자가 선착순으로 일정을 정했습니다.

면접은 2대 1로 비대면으로 진행됐습니다. 제 면접에 들어오신 면접관 두 분은 모두 현업자 OB셨습니다.

면접은 인성면접이 주를 이뤘습니다. 지원동기, 협업 경험 등 컬쳐핏에 대해 여쭤보셨고 자소서에 적은 경험을 깊게 물어보는 식이었습니다. 자소서 경험에 대해서는 케이스 면접도 일부 있었던 것으로 기억합니다.

GSAP에 대한 지식은 별로 없는 상태에서 동아리에 들어가면 공부하면서 적용하고 싶다고 자소서에 적었는데 질문이 들어와서 가장 어려웠고 나머지는 무난한 질문이라고 생각했습니다. 결국 GSAP은 사용하지 못한 ㅎㅎ..

면접관 분들이 너무 젠틀하게 대해주셔서 Yapp에 들어가고 싶은 마음이 더 간절해졌던 것 같습니다.

면접관 분들에게 반대로 질문 할 수 있는 시간을 주셔서 아래 질문을 여쭤봤습니다.

1. Yapp커톤 진행방식
2. Yapp에서 좋았던 활동 혹은 좋았던 점

나중에 웹 리드 운영진에게 들은 사실인데 면접자가 현업자와 대학생인지에 따라 그리고 면접관과 면접자의 지인 여부에 따라(지인을 면접보게 되면 감정이 들어갈 수 있으므로) 면접관이 달라질 수도 있다고 했습니다.

6. 합격

적다보니 지원 후기만 해도 길어져서 자세한 활동 후기는 다음 글에 이어서 작성하겠습니다. 지금까지 읽어주셔서 감사합니다!