프론트엔드 인턴 1년 회고

2023년 8월부터 2024년 8월까지 1년 동안 프론트엔드 인턴으로 일했다. (학교 현장실습 + 휴학 후 인턴 생활) 1년 동안 무슨 일을 했고, 잘한 점, 개선해야 할 점, 배운 점, 아쉬웠던 점 등을 간단하게 정리해 보려 한다.

입사하기 전에 기대했던 것들

• 현업에서 진행하는 개발 프로세스 경험하기
• 현업 백엔드 개발자와 디자이너분들과 소통하면서 프로덕트 개발하기
• 사용자들의 피드백을 받으며 프로덕트 유지보수하기

첫 인턴(회사)이라서 실무 경험을 해보는 것이 가장 기대가 되었다. 👀

1년간 무슨 일을 했는지

• 알파 버전 출시를 위한 여러 프론트엔드 작업 (UI implementation, API integration, etc.)
• 고객 피드백으로부터 나온 Feature 구현 작업에 FE 개발자로 참여하기 (고객 피드백 반영)
• 프론트엔드 유지보수 작업
  • Migration from Next.js to Remix
  • Migration from vanilla-extract to tailwind
  • Remix: Vite Migration
  • KTLO: 3번 이상 반복되는 중복 스타일 및 로직 추상화하기
• 프론트엔드 테스트
  • 테스트 코드 많이 작성해보기
  • 테스트 코드 개선 및 유지보수
  • Vitest browser mode 도입
• 랜딩페이지 성능 개선 작업
• 제품 및 경쟁사 공부 등등

가장 기억에 남는 일 3가지

알파 버전 출시

인턴 생활 중에 가장 스트레스를 많이 받은 일이었지만, 가장 행복한 일이기도 했다. 알파 버전 출시 직전까지 버그 및 QA 티켓들을 해결하고, 짧은 시간 안에 많은 일들을 처리해야 한다는 압박감을 느꼈지만, 성공적으로 알파 버전을 출시했다. 이를 계기로 어떠한 압박감에도 일을 처리해 낼 수 있다는 자신감이 생겼다.

큰 규모의 Migration 작업

기술 스택을 바꾸는 마이그레이션 작업을 총 2번 했다. Next.js에서 Remix로 바꾸는 작업과 CSS 관련 라이브러리를 vanilla-extract에서 tailwind로 바꾸는 작업이다.

Remix 마이그레이션은 FE 리드분이 먼저 제안했고, 자신의 경험을 바탕으로 이유를 설명하며 Remix를 사용한 적 없는 팀원들을 설득하셨다. 덕분에 Next.js의 단점들과 Remix를 알게 되었다.

참고 아티클: (번역) 내가 Next.js를 사용하지 않는 이유
가장 인상적인 문장: Remix에 익숙해지면 웹에 대해서도 더 잘 알게 되고, 그 반대의 경우도 마찬가지입니다.

Tailwind 마이그레이션은 모두가 인정하는 vanilla-extract의 문제들이 있어 쉽게 결정했다. 규모가 매우 커 마이그레이션 작업이 오래 걸려서 기억에 남는다.

Vitest browser mode 도입

라이브러리 없이 구현한 Image cropper 컴포넌트 테스트를 작성했을 때 이미지 크기 속성과 getBoundingClientRect 함수를 모킹하는 것이 정말 마음에 안 들었다. 실제 브라우저 환경에서 실행되는 것과 다른 결과가 나올 것 같은 우려가 있었다. 하지만 happy-dom 테스트 환경에서는 다른 방법이 없었다. 몇 개월 뒤, vitest browser mode가 베타 버전에서 나왔고, 모킹이 덕지덕지 붙어 있는 컴포넌트 테스트를 개선할 수 있겠다는 생각에 행복했던 기억이 있다.

잘한 점

팀원들이 평가한 내용이다.

• 업무 delay가 없다. 딱 8시간만 일하면서 할 일을 다 한다.
• 백엔드 및 디자이너와 전반적인 업무 관련 소통을 잘한다.
• 문서화를 잘하니까 이걸 레버리지 삼으면 좋을 것 같다.
• 분야 안 가리고 능동적으로 도와주는 모습이 인상적이다. (디자이너 리소스 부족으로 피그마 디자인, 백엔드 API 작업)
• 연차 이상의 퍼포먼스를 보여준다. (퇴사해도 지금의 포텐셜을 유지하거나 높였으면 좋겠다.)

개선해야 할 점

팀원들이 평가한 내용이다.

• 병목에 발생한 상황에서는 적극적으로 문제상황을 공유해야 한다. 업무 병목 사항 판단이 느리지만, 연차가 쌓이면 해결될 문제일 것 같다.

  입사 초반에는 병목 사항(다른 사람과 소통이 필요한 부분 등)을 파악하기 어려웠는데, 일을 하다 보니 병목 사항들이 눈에 보이고 해결하는 방법을 터득했다.

• 복잡한 컨텍스트를 가진 코드를 작성할 때 주석을 잘 활용하면 좋을 것 같다.

  스펙이 복잡한 필터 UI를 구현한 적이 있는데 이때 주석을 잘 활용했다면 팀원들이 코드 리뷰하기 편했을 것 같다. 혹은 여러 복잡한 케이스 및 시나리오를 정의하고 테스트를 작성했다면 팀원들을 안심시킬 수 있었을 것이다.

배운 점

FE 개발자의 태도

• 브라우저단 개발만이 FE 개발의 전부가 아니다. SSR을 이용한 페이지 렌더링, BFF 구현, 디자이너와 협력해 디자인 시스템 구축하는 것까지 확장할 수 있다.
• 개발자의 시야에 매몰되어서는 안 된다. 고객이 원하는, 그들의 Pain point를 해결해주는 프로덕트를 만들어야 한다. 커뮤니케이션 방향이 PM이 아니라 고객/프로덕트를 향해야 한다. (지금은 아니지만, 초반에 개발자로만 이루어진 팀이라서 더더욱 이 내용을 상기시켰다.)

참고 아티클: 나는 생각하는 사람💁, 너는 만드는 사람👨‍💻

업무 전반

• 스토리 포인트에 따라 어떤 업무를 할지 스스로 산정하는 방법
  • 예를 들어, 스토리 포인트가 3인 태스크를 1개 했다면, 다음은 스토리포인트가 1인 태스크 5개 치기
• 백엔드 개발자와 효율적으로 협업하는 방법
  • 프론트엔드가 PRD 기준으로 API 스펙 작성 -> 백엔드가 API 스펙 리뷰 및 결정 -> FE/BE 개발 진행 (FE가 BE의 API 구현 PR 리뷰해 스펙 잘 지켰는지 확인하기)
  • 위 방식대로 진행하면 FE는 Mock API를 사용해 Pre-Integration을 진행할 수 있어 BE 개발 완료 여부가 FE 개발에 병목 사항이 되지 않는다.
  • 개발할 때는 Mock server 실행하면 되고, 백엔드 API 배포되면 잘 동작하는지 확인하면 된다.
• 1 on 1 시간 잘 활용하기
  • 좋은 리드분을 만나서 1 on 1 회의를 주기적으로 진행했고, 개발적인 고민과 업무 애로사항들을 쉽게 해결할 수 있었다.

Tech

• 컴포넌트와 도메인 분리
  • 컴포넌트와 도메인의 의존성을 줄이는 방식의 디자인에 집중하기
  • 컴포넌트는 일반적인 인터페이스로 설계하고, 사용하는 쪽에서 가공해서 사용하도록 설계하기
• 프론트엔드 테스트의 중요성
  • 입사하기 전에 프론트엔드가 테스트를 작성해야 하는 이유에 대해 크게 공감하지 못했고, 테스트를 짠 적이 한 번도 없었다.
  • 하지만 복잡한 스펙(경우의 수)을 가진 필터 UI를 구현해 보니 테스트가 있어야 팀원들을 안심시킬 수 있고, 테스트가 있으니 자신 있게 리팩토링할 수 있다는 것을 알게 되었다.
  • 회사 다닐 때는 경험하지 못했지만, TDD를 경험해보고 싶다는 생각을 했다.

프론트엔드 테스트 관련 아티클 추천

• 코드와 함께 살펴보는 프론트엔드 단위 테스트 – Part 1. 이론 편
• 코드와 함께 살펴보는 프론트엔드 단위 테스트 – Part 2. 실전 편
• 테스트와 함께 프론트엔드 개발하기 (turing-frontend-test 깃헙 저장소)
• 스토리북 / 테스트와 함께하는 컴포넌트 주도 프론트엔드 개발

기대했던 것들이 충족되었는지

• 현업에서 진행하는 개발 프로세스 경험하기 ⭐⭐⭐⭐⭐
  • 스프린트 사이클이 어떻게 굴러가는지 경험하고, 린(Lean)하게 일하는 방식도 새롭게 경험했다.
• 현업 백엔드 개발자와 디자이너분들과 소통하면서 프로덕트 개발하기 ⭐⭐⭐
  • 팀 내 백엔드 개발자와 긴밀하게 소통하며 협업했지만, 팀에 디자이너가 없어 다른 팀의 디자이너 리소스를 빌려와야 했다. 디자이너분들이 우리 팀에 쓸 수 있는 리소스의 한계가 있어서 디자인 시스템 유지보수, UX 등에 관한 적극적인 소통이 부족했다.
• 사용자들의 피드백을 받으며 프로덕트 유지보수하기 ⭐⭐⭐⭐⭐
  • 정말 많은 고객 피드백 중에서도 선택과 집중이 필요하다는 것을 알게 되었다. 모든 피드백을 반영할 수 없고, 우선순위를 매겨야 한다.

아쉬웠던 점

아쉬웠던 점은 다른 팀의 개발자와의 공유 문화가 부족했다. 우리 팀 내에서는 "Frontend Dev Playbook"이라는 페이지를 만들어 트러블슈팅 경험 등과 같이 개발하면서 겪은 내용을 공유하는 문화를 만들어 갔는데, 회사 차원에서 이러한 문화가 활성화되지 않다고 느꼈다. 팀 각자 사용하는 기술 스택이 다르고, 개발자가 메인인 회사가 아니라서 그런 것 같다. 사람도 업무도 너무너무x100 좋았지만, 성숙한 개발 조직을 갖고 있고, 개발자가 메인인 회사에서 일하고 싶다.

마무리

지금은 퇴사 후 남은 대학 생활을 보내고 있다. 내년 2월에는 꼭 졸업할 것이고, 취업 준비는 졸업 후에 천천히 할 것 같다. (여행 다니면서 더 놀고 싶달까...)

리드분의 조언대로 취준하지 않는다고 개발 씬과 동떨어져 있지 않을 것이다. 학교 동아리 스꾸딩에서 프론트엔드 개발 활동을 다시 하고 있다. 2년 뒤에 아무도 리액트를 사용하지 않을 수도 있으니(?) 프론트엔드 생태계 동향을 계속 파악할 것이고, 졸업 후에는 다양한 사이드 프로젝트를 진행하고 싶다. 인턴 경험을 자양분으로 삼아 앞으로 더 성장해야지~~~