POSTABOUT

3년차 프론트엔드 개발자로 일하며 배운 것들

2026-05-07

3년차 프론트엔드 개발자로 일하며 배운 것들

2026년 4월, 퇴사 후 지난 3년간의 실무 경험을 돌아보며 느낀 점들을 정리한 글입니다.

운영 어드민, 모바일 PWA, WebView 기반 서비스 등을 개발하며 다양한 기능을 구현하고 유지보수하는 경험을 했다.
빠르게 요구사항을 구현하고 운영 이슈에 대응하는 과정에서 실무적인 문제 해결 경험을 쌓을 수 있었다.

다만 퇴사 후 지난 3년의 흔적을 돌아보니, 내가 잘해온 부분만큼이나 부족했던 부분도 분명하게 보였다.
이 글은 지난 3년 동안 프론트엔드 개발자로 일하며 배운 것들과, 그 과정에서 느낀 아쉬움을 정리하기 위해 작성했다.

🚀 개요 (Overview)

  • 기간: 2023.03 ~ 2026.04
  • 업무: React / TypeScript 기반 운영 어드민 및 모바일 웹 개발
  • 주요 역할: 운영 서비스 유지보수, 신규 기능 개발, 공통 컴포넌트 및 공통 로직 관리

🏃‍♂️ 회사에서 얻은 것 (What I Learned)

기술적 성장 (Hard Skills)

1. 운영 환경에서의 문제 해결 경험

  • 서버 응답 불일치 대응
  • API 명세 및 개발 지연 상황 대응
  • 느린 API의 중복 호출 방지

처음에는 서버 응답의 모든 예외 상황을 프론트에서 방어하는 것이 과한 처리라고 생각했다.
명세가 지켜진다는 전제에서 개발하는 편이 더 자연스럽다고 느꼈기 때문이다.

하지만 운영 환경에서는 예상하지 못한 API 오류나 응답 불일치가 간헐적으로 발생했고, 그때마다 사용자가 서비스를 정상적으로 이용하지 못하는 문제가 발생했다.
이후 팀 내에서 예외 처리를 일괄 추가하고, 서버 응답 불일치 상황을 개발 환경에서 확인할 수 있도록 처리했다. 결과적으로 사용자 피드백이 줄었고, 이슈를 파악하고 수정하는 데도 조금의 여유가 생겼다.

이 경험을 통해 운영 서비스에서는 비정상 케이스에 대한 설계도 중요하다는 것을 배웠다.

2. 공통화와 구조화의 중요성

  • 공통 API Layer 분리
  • 공통 Hook 및 상태 관리 구조화
  • 모노레포 기반 패키지 관리

사내 어드민 특성상 목록, 상세, 수정 화면이 반복적으로 존재했고, 디자인 시스템을 기반으로 개발하다 보니 유사한 컴포넌트도 계속 늘어났다.
초기에는 화면 단위로 구현했지만, 유사한 서비스가 늘어나면서 공통 컴포넌트와 공통 로직을 분리하며 구조를 정리하게 되었다.
또한 기능은 동일하나 서비스에 따라 UI만 다른 경우가 발생했다.
이 케이스를 커버하기 위해 Headless 컴포넌트를 제안했고, 기능만 가진 컴포넌트와 디자인 요소를 가진 컴포넌트를 분리해 관리하는 구조를 만들었다.

이를 통해 동일한 기능을 여러 서비스에서 재사용하면서도, 각 서비스의 UI 차이는 별도로 관리할 수 있었다.

3. 프론트엔드도 데이터 흐름 이해가 중요하다는 점

  • React Query 캐시 관리
  • 서버와 클라이언트 상태 분리
  • 폼 상태 동기화(Funnel)

입사 초기에는 화면 단위로 기능을 구현하는 데 집중했지만, 시간이 지나면서 하나의 흐름 안에서 상태를 관리해야 하는 경우가 많다는 것을 느꼈다.

대표적인 예시가 Funnel 구조였다.
기존에는 회원가입이나 비밀번호 변경 플로우를 각각의 Form으로 관리했지만, 실제로는 이전 단계의 동작이 완료되어야 다음 단계로 넘어갈 수 있는 하나의 흐름에 가까웠다.
이후 하나의 데이터 구조로 관리하는 것이 적절하다고 판단되는 화면들은 Funnel 구조로 변경했다.

서버 상태와 클라이언트 상태를 분리한 것도 비슷한 맥락이었다.
API 명세가 늦게 확정되는 상황에서 프론트 코드가 서버 명세에 과하게 종속되지 않도록, 먼저 클라이언트 상태를 구성하고 이후 서버 상태와 연결하는 방식으로 구조를 정리했다.

이 과정을 통해 프론트엔드에서도 데이터 흐름을 판단하고, 각 역할에 맞는 구조로 설계하는 것이 중요하다는 것을 배웠다.

업무 및 협업 방식

문서화와 공유의 중요성

업무를 하면서 기능 구현만큼 중요한 것이 히스토리를 남기는 일이라는 것을 느꼈다.
입사 초에는 문서화를 하기보다는 코드 작성에 급급하다보니, 타 팀에서 들어오는 요청이나 중요하다고 판단한 내용들만 문서화를 해왔었다. 하지만 일정에 맞춰 개발한 뒤 여유가 있는 시점에 마이그레이션이나 리팩토링을 진행하려고 보면 어떤 것을 작업해야할지, 누가 어떤 부분에 대한 리팩토링을 진행해야할지에 대한 기록이 부재하여 작업을 누락하는 경우가 간헐적으로 발생했다.
이후 Git 이슈에 스크럼에서 논의한 마이그레이션, 리팩토링 사항을 남기기 시작했다.
또 사내 노션에는 변경 과정과 결과를 정리해두었다.
덕분에 과거에 발생했던 이슈의 맥락을 다시 파악하기 쉬워졌고, 신규 인력이 들어왔을 때도 팀 내 코드를 이해하는 데 도움이 되었다.

💡 마주했던 한계와 아쉬움 (What I Lacked)

기술적인 아쉬움

1. 기존 코드에 대한 이해 부족

기존 코드의 의도를 충분히 이해하지 못한 상태로 기능 개발을 이어간 점이 아쉬움으로 남는다.
당시에는 일정에 맞춰 기능을 구현하는 데 집중하다 보니, 기존 구조가 왜 그렇게 작성되었는지 깊게 질문하거나 추적하는 데 소극적이었다.
이후 여유가 생겼을 때는 해당 코드를 작성했던 구성원들이 이미 퇴사한 뒤였고, 기존 로직을 변경했을 때 발생할 수 있는 영향 범위가 부담되어 적극적으로 개선하지 못했다.

2. 테스트 코드 경험 부족

운영 일정과 빠른 대응 중심의 개발을 반복하면서 테스트 코드 작성 경험은 상대적으로 부족했다.
특히 복잡한 상태 흐름이나 예외 처리 로직을 다루면서도 테스트 없이 운영되는 경우가 많았고, 유지보수 과정에서 불안함을 느끼는 순간들이 있었다.
추후 Vitest를 적용하기는 했지만, 운영 일정상 테스트 범위를 직접 설계하고 충분히 검증하는 경험은 부족했다. 어디까지 테스트해야 안정적인 리팩토링이 가능한지 판단하는 기준을 세우지 못한 점이 아쉬움으로 남았다.

3. CS 및 브라우저 동작 이해 부족

이슈가 발생했을 때 증상은 해결할 수 있었지만, “왜 이런 문제가 발생했는지”를 깊게 이해하지 못하는 경우도 있었다.
실무 중 필요성을 계속 느꼈지만 제대로 정리하지 못하고 어렴풋이만 인지하고 넘어갔기 때문에 항상 코드를 작성하면서 "이게 맞나?"라는 생각을 했던 것 같다.

개인적/태도적 아쉬움

이유를 더 깊게 묻지 못했던 점

문제가 발생하면 빠르게 해결하는 데 집중하고 근본적인 원인을 깊게 분석하거나 구조적인 이유를 끝까지 추적하지 못한 경우가 잦았다.

입사 초중반에는 실력에 대한 자신감 부족으로 의견을 적극적으로 내기보다 수동적으로 받아들이는 경우가 많았고
퇴사 전에는 코드나 구조에 대한 제안을 하기도 했지만, 더 이른 시점부터 모르는 것을 질문하고 의견을 냈다면 더 많이 성장할 수 있었을 것 같다는 아쉬움이 남는다.

앞으로는 내가 작성한 코드뿐만 아니라 타인이 작성한 코드도 그냥 넘기지 않고, 그 의도와 영향 범위를 이해하고 싶다.

🎯 앞으로의 계획 (Next Action)

1. CS 및 브라우저 동작 정리

단순 사용이 아니라 동작 자체를 이해하는 방향으로 공부하려고 한다.
비전공자로 개발자 업무를 진행하면서 개념에 대한 이해 없이 단순 개발만 반복했고, 다른 개발자들과 코드에 대해 논의할 때 내 지식이 부족하다는 것을 자주 느꼈다.
좀 더 좋은 품질의 코드를 작성하기 위해서는 기본 개념을 이해하고 이를 바탕으로 판단할 수 있어야 한다고 생각한다.

2. 테스트 코드 학습

Vitest, Testing Library 등을 활용해 복잡한 상태 흐름과 UI 동작을 검증하는 연습을 진행하려고 한다.
기존과 같이 단순히 테스트 코드를 작성하는 것이 아니라 어디까지 테스트를 하는 것이 적절한지 스스로 판단할 수 있도록 변하고 싶다.

3. 서버 및 데이터 흐름 이해 확장

실무를 경험할수록 프론트엔드도 단순히 화면만 구현해서는 부족하다는 것을 느끼게 되었다.
실제로 React Query를 사용하며 서버 상태와 클라이언트 상태를 구분하게 되었고, WebView 환경에서는 토큰 재발급이나 앱과의 데이터 흐름까지 고려해야 했다.
이 경험을 통해 프론트엔드 역시 UI 구현뿐만 아니라 데이터 흐름 전체를 이해하는 것이 중요하다는 것을 많이 느꼈다.

아직은 어떤 개발자가 되어야 할지 찾아가는 중이지만, 그 과정에서 내가 작성한 코드의 구조와 선택 이유를 더 깊이 이해하는 개발자가 되고 싶다.

📚 마무리

기본적인 메소드도 잘 모르던 상태로 시작했던 프론트엔드 개발자 직무였지만 많은 경험을 할 수 있었던 3년이었다.
회고를 작성하면서 스스로에 대해 되돌아보고 내가 어떻게 직무를 이행해왔는지, 이제 어떻게 준비를 해야할지 생각할 수 있는 기회가 되었다.
이번 기회에 잠깐 쉬어가면서 기본 개념에 대한 공부도 하고 어떤 개발자가 되어야할지 스스로 생각할 수 있는 시간을 갖고자 한다.