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

운영 어드민, 모바일 PWA, WebView 기반 서비스 등을 개발하며 여러 기능을 만들고 유지보수했다.
요구사항을 빠르게 구현해야 하는 일도 많았고, 운영 중 발생한 이슈에 대응해야 하는 일도 적지 않았다.

일할 때는 하루하루 주어진 일을 처리하는 데 집중했는데, 퇴사 후 지난 시간을 돌아보니 잘해온 부분만큼이나 아쉬운 부분도 분명하게 보였다.
이 글은 지난 3년 동안 프론트엔드 개발자로 일하며 배운 것들과, 그 과정에서 느낀 부족함을 정리하기 위해 작성했다.

지난 3년

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

운영 환경에서의 예외 처리

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

하지만 운영 환경은 생각보다 자주 예상을 벗어났다.
응답 형식이 미묘하게 다르거나, 특정 상황에서만 값이 비어 있거나, 느린 API가 중복 호출되면서 사용자가 실제로 불편을 겪는 일이 있었다.

그때부터는 프론트에서 어디까지 방어해야 하는지에 대한 생각이 조금 달라졌다.
모든 문제를 프론트에서 떠안아야 한다는 뜻은 아니지만, 적어도 사용자가 깨진 화면을 마주하지 않도록 막는 일도 운영 서비스에서는 중요한 일이라는 것을 알게 되었다.

이후 팀 내에서 예외 처리를 일괄 추가했고, 서버 응답이 예상과 다를 때 개발 환경에서 확인할 수 있도록 처리했다.
결과적으로 사용자 피드백이 줄었고, 이슈를 파악하고 수정하는 데도 조금의 여유가 생겼다.

공통화와 구조화

사내 어드민은 목록, 상세, 수정 화면이 반복적으로 등장했다.
디자인 시스템을 기반으로 개발하다 보니 비슷한 컴포넌트도 계속 늘어났다.

처음에는 화면 단위로 구현하는 것이 가장 빠르고 단순했다.
그런데 유사한 서비스가 늘어날수록 같은 형태의 코드가 반복되었고, 수정이 필요할 때 여러 화면을 함께 확인해야 하는 일이 많아졌다.
그때부터 공통 컴포넌트와 공통 로직을 분리하며 구조를 조금씩 정리하게 되었다.

특히 기능은 거의 같지만 서비스마다 UI만 다른 경우가 있었다.
이 케이스를 처리하기 위해 Headless 컴포넌트를 제안했고, 동작만 가진 컴포넌트와 화면을 그리는 컴포넌트를 분리해 관리하는 구조를 만들었다.

덕분에 동일한 기능을 여러 서비스에서 재사용하면서도, 각 서비스의 UI 차이는 따로 가져갈 수 있었다.
공통화가 늘 정답은 아니지만, 반복되는 기능의 기준을 잘 잡아두면 이후 개발과 유지보수가 훨씬 편해진다는 것을 느꼈다.

데이터 흐름

입사 초기에는 화면을 만드는 일에 더 집중했다.
버튼을 누르면 요청이 가고, 응답을 받아 화면에 보여주면 된다고 생각했던 것 같다.

하지만 시간이 지나면서 하나의 화면보다 하나의 흐름을 봐야 하는 경우가 많아졌다.
대표적인 예시가 Funnel 구조였다.

기존에는 회원가입이나 비밀번호 변경 플로우를 각각의 Form으로 관리했다.
그런데 실제로는 이전 단계가 완료되어야 다음 단계로 넘어갈 수 있고, 여러 단계의 값이 하나의 흐름 안에서 이어져야 했다.
이후 하나의 데이터 구조로 관리하는 것이 더 적절하다고 판단되는 화면들은 Funnel 구조로 변경했다.

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

이 경험을 하면서 프론트엔드도 단순히 화면을 구현하는 역할에만 머물지 않는다는 것을 느꼈다.
데이터가 어디서 오고, 어디에 머물고, 어떤 시점에 다음 흐름으로 넘어가야 하는지 판단하는 일이 생각보다 중요했다.

문서화와 공유

업무를 하면서 기능 구현만큼 중요한 것이 히스토리를 남기는 일이라는 것을 느꼈다.

입사 초에는 문서화보다 코드 작성에 더 급급했다.
타 팀에서 들어오는 요청이나 당장 중요하다고 판단한 내용만 간단히 남겼고, 그 외의 맥락은 대부분 머릿속에만 두고 넘어갔다.

그런데 일정에 맞춰 개발을 끝낸 뒤, 여유가 생겼을 때 마이그레이션이나 리팩토링을 다시 보려고 하면 문제가 생겼다.
무엇을 작업해야 했는지, 누가 어떤 부분을 맡기로 했는지, 왜 그 작업이 필요했는지에 대한 기록이 부족해서 놓치는 일이 생겼다.

이후에는 Git 이슈에 스크럼에서 논의한 마이그레이션, 리팩토링 사항을 남기기 시작했다.
사내 노션에는 변경 과정과 결과를 정리해두었다.

기록이 쌓이니 과거 이슈의 맥락을 다시 파악하기가 훨씬 쉬워졌다.
신규 인력이 들어왔을 때도 팀 내 코드를 이해하는 데 도움이 되었고, 나 역시 “왜 이렇게 했지?”라는 질문 앞에서 조금 덜 헤매게 되었다.

기존 코드에 대한 이해

가장 아쉬운 부분 중 하나는 기존 코드의 의도를 충분히 이해하지 못한 상태로 기능 개발을 이어간 점이다.

당시에는 일정에 맞춰 기능을 구현하는 데 집중하다 보니, 기존 구조가 왜 그렇게 작성되었는지 깊게 질문하거나 추적하는 데 소극적이었다.
일단 동작하게 만들고, 문제가 없으면 넘어가는 경우도 많았다.

이후 여유가 생겼을 때는 해당 코드를 작성했던 구성원들이 이미 퇴사한 뒤였다.
기존 로직을 바꿨을 때 어디까지 영향을 줄지 확신하기 어려웠고, 그 부담 때문에 적극적으로 개선하지 못한 부분도 있었다.

지금 돌아보면 코드를 이해한다는 것은 단순히 “어떻게 동작하는지”를 아는 것만은 아니었던 것 같다.
왜 이런 구조가 되었는지, 어떤 제약이 있었는지, 바꾸려면 무엇을 함께 봐야 하는지를 아는 것까지 포함되는 일이었다.

테스트 코드

운영 일정과 빠른 대응 중심의 개발을 반복하면서 테스트 코드 작성 경험은 상대적으로 부족했다.

특히 복잡한 상태 흐름이나 예외 처리 로직을 다루면서도 테스트 없이 운영되는 경우가 많았다.
당장 기능은 동작했지만, 이후 수정이 필요할 때마다 “이걸 바꿔도 괜찮을까?”라는 불안함이 있었다.

추후 Vitest를 적용하기는 했지만, 운영 일정상 테스트 범위를 직접 설계하고 충분히 검증하는 경험은 부족했다.
단순히 테스트 코드를 작성해봤다는 것보다, 어떤 부분을 테스트해야 안정적으로 리팩토링할 수 있는지 판단하는 기준이 더 필요하다는 생각이 들었다.

앞으로는 테스트를 별도의 과제처럼 보기보다, 내가 만든 흐름을 설명하고 지키는 방법으로 익혀보고 싶다.

기본 개념과 브라우저 동작

이슈가 발생했을 때 증상은 해결할 수 있었지만, 왜 그런 문제가 발생했는지 깊게 이해하지 못한 경우도 있었다.

실무 중 필요성은 계속 느꼈다.
그런데 바쁘다는 이유로 제대로 정리하지 못하고, 어렴풋이만 이해한 채 넘어간 개념들이 많았다.
그래서 코드를 작성하면서도 종종 “이게 맞나?”라는 생각을 했다.

비전공자로 개발을 시작한 만큼, 기본 개념의 빈자리를 더 자주 느꼈던 것 같다.
브라우저가 어떻게 렌더링하는지, 네트워크 요청은 어떤 흐름으로 처리되는지, 자바스크립트는 어떤 방식으로 실행되는지 같은 것들을 더 단단하게 정리해야겠다고 생각했다.

좋은 코드를 작성하려면 도구를 잘 쓰는 것만으로는 부족했다.
그 도구가 어떤 원리 위에서 동작하는지 이해해야 더 나은 판단을 할 수 있다는 것을 지난 3년 동안 많이 느꼈다.

질문과 의견

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

입사 초중반에는 실력에 대한 자신감이 부족해서 의견을 적극적으로 내기보다 받아들이는 쪽에 가까웠다.
모르는 것을 물어보는 일도 괜히 조심스러웠고, 내가 낸 의견이 틀릴까 봐 망설인 적도 많았다.

퇴사 전에는 코드나 구조에 대한 제안을 조금씩 하게 되었지만, 더 이른 시점부터 질문하고 의견을 냈다면 더 많이 성장할 수 있었을 것 같다는 아쉬움이 남는다.

앞으로는 내가 작성한 코드뿐만 아니라 타인이 작성한 코드도 그냥 넘기지 않고 싶다.
그 코드가 어떤 의도로 작성되었는지, 어떤 영향을 갖는지 더 자주 묻고 확인하는 개발자가 되고 싶다.

앞으로의 방향

아직은 어떤 개발자가 되어야 할지 찾아가는 중이다.
다만 이번 회고를 쓰면서 한 가지는 조금 분명해졌다.

앞으로는 내가 작성한 코드의 구조와 선택 이유를 더 깊이 이해하는 개발자가 되고 싶다.
기능을 빠르게 만드는 것도 중요하지만, 왜 이렇게 만들었는지 설명할 수 있는 사람이 되고 싶다.

이를 위해 CS와 브라우저 동작을 다시 정리하고, Vitest와 Testing Library를 활용해 복잡한 상태 흐름과 UI 동작을 검증하는 연습을 해보려고 한다.
서버 상태와 클라이언트 상태, WebView 환경에서의 토큰 흐름처럼 실무에서 마주했던 데이터 흐름도 더 넓게 이해해보고 싶다.

잠깐 쉬어가는 이 시간을 그냥 비워두기보다, 지난 3년 동안 느꼈던 부족함을 천천히 메워가는 시간으로 써보려고 한다.

마무리

기본적인 메서드도 잘 모르던 상태로 시작했지만, 지난 3년 동안 정말 많은 경험을 했다.
운영 서비스를 만들고 고치면서 실무에서만 배울 수 있는 것들을 배웠고, 동시에 내가 아직 모르는 것도 많이 확인했다.

회고를 쓰면서 내가 어떻게 일해왔는지, 앞으로 무엇을 더 준비해야 하는지 생각해볼 수 있었다.
아직 완전히 선명한 답이 있는 것은 아니지만, 적어도 이제는 내가 만든 코드의 이유를 더 오래 들여다보는 개발자가 되고 싶다.