2025년 개발자 회고 — 기술을 쌓는 것과, 기준을 만드는 것
2025년 이전: 기술은 늘 문제 뒤에 있었다
개발자로 일해온 시간을 돌아보면, 나는 늘 복잡한 문제 가까이에 있었다. 단순히 화면을 구현하는 일보다, 상태가 많고 조건이 얽힌 문제를 더 자주 맡았다. 그래서 기술을 선택할 때도 “이걸 써보고 싶다”기보다는, “이 문제를 해결하려면 무엇이 필요할까”를 먼저 생각해왔다. 2025년 이전의 나는 그렇게 문제를 따라 기술을 배우는 개발자였다.
React를 쓰면서, 화면보다 렌더링을 먼저 보게 됐다
프론트엔드 개발을 하면서 가장 오래 붙잡고 있었던 도구는 React였지만, 어느 순간부터 React를 “컴포넌트를 그리는 도구”로 보지 않게 됐다. 상태 하나를 어디에 두느냐에 따라, 전혀 상관없어 보이는 화면이 다시 렌더링되는 걸 반복해서 겪으면서부터였다. 그때부터 코드를 짤 때 자연스럽게 이런 질문을 하게 됐다. 이 상태는 왜 여기 있어야 하는지, 이 컴포넌트가 다시 그려지는 이유는 무엇인지.
이 과정에서 React는 편리한 추상화이면서 동시에 굉장히 솔직한 도구라는 생각을 하게 됐다. 구조를 대충 짜면 그 대가는 반드시 렌더링 비용이나 복잡한 props 구조로 돌아왔다. 그래서 점점 “컴포넌트를 쪼갠다”는 말 대신, 책임을 어디까지로 나눌 것인가를 더 많이 고민하게 됐다.
상태 관리 도구를 바꾸며, 도구보다 질문이 중요해졌다
Recoil, Zustand, Context를 오가며 상태 관리를 해본 경험은, 특정 도구에 대한 확신보다는 회의에 가까운 감각을 남겼다. 상태를 전역으로 올리면 편해질 것 같았지만, 시간이 지나면 어느 상태가 왜 바뀌는지 추적하기 어려워졌다. 반대로 상태를 지나치게 쪼개면, 흐름을 이해하는 데 더 많은 비용이 들었다.
이런 경험을 반복하면서, 상태 관리에서 가장 중요한 건 도구가 아니라 상태의 수명과 변경 책임을 먼저 정의하는 일이라는 생각이 굳어졌다. 그 질문을 하지 않으면, 어떤 도구를 써도 복잡함은 그대로 남았다. 이때부터 상태 관리는 기술 선택의 문제가 아니라 설계의 문제로 느껴지기 시작했다.
성능 최적화는 늘 뒤늦게 찾아왔다
성능 문제는 대부분 “기능이 다 만들어진 뒤”에 찾아왔다. 페이지가 느리다는 피드백을 받고 나서야 렌더링 구조를 다시 보게 되고, API 호출을 다시 뜯어보게 됐다. 그 과정에서 깨달은 건, 성능 이슈의 대부분은 특정 코드 한 줄 때문이 아니라 처음에 했던 구조적 선택의 결과라는 점이었다.
CSR 환경에서 SEO를 개선하기 위해 edge 단에서 요청을 분기하고, 빌드 결과물을 압축해 배포하고, 캐시 전략을 다시 짜는 경험들은 모두 사후 대응에 가까웠다. 하지만 이런 경험 덕분에, 이후에는 기능을 만들 때부터 “이 구조는 나중에 어떤 비용을 만들까?”를 자연스럽게 떠올리게 됐다.
프론트엔드를 시스템으로 보기 시작한 계기
프론트엔드에서 겪는 많은 문제들이 실제로는 화면의 문제가 아니라, 상태를 어디에서 관리하고 누가 그 상태를 대표 하느냐의 문제라는 걸 깨닫게 된 계기들이 있었다. 지도 기반 서비스를 만들면서, React 컴포넌트 바깥에서 동작하는 지도 객체의 상태를 UI와 일관되게 유지 하는 일이 생각보다 까다롭다는 걸 경험했다. 단순히 상태를 React 안으로 끌어오는 방식으로는 해결되지 않았고, 결구 렌더링 구조 자체를 이해하고 조정해야 했다.
여러 브라우저 창을 동시에 사용하는 서비스에서도 비슷한 문제를 겪었다. 각 창이 각자의 상태를 들고 있으면 사용자는 같은 계정으로 서로 다른 상태를 보게 됐고, 그 혼란은 UI 수정으로는 해결되지 않았다. 이때 SharedWorker와 WebSocket을 사용해 상태의 중심을 하나로 두고, 각 창은 그 상태를 구독하는 구조로 바꾸면서 문제를 해결했다.
이런 경험들을 거치면서 프론트엔드를 단순히 화면을 그리는 레이어로 보기보다, 상태의 중심을 어디에 둘지 결정하는 시스템의 일부로 인식하게 됐다.
2025년: 같은 기술을, 다른 기준으로 쓰기 시작했다
2025년에 들어서면서 사용하는 기술이 완전히 바뀐 것은 아니다. 여전히 React를 쓰고, 여전히 상태를 관리하고, 여전히 비동기를 다뤘다. 하지만 분명히 달라진 점이 있다면, 기술을 쓰기 전에 질문을 먼저 던지기 시작했다는 것이다.
주문 플로우를 만들며, 상태의 위치를 다시 생각했다
커머스 주문 플로우를 만들면서 가장 많이 고민한 건 상태 그 자체였다. 사용자가 입력하는 데이터, 서버에서 내려오는 데이터, 잠깐만 필요한 UI 상태를 한 덩어리로 관리하면 구현은 쉬워지지만, UX와 안정성은 금방 무너졌다. 그래서 데이터를 서버, 스토리지, 클라이언트 상태로 나누고, 각각의 책임을 명확히 하려고 했다.
이 과정에서 Context를 단순한 전역 상태가 아니라 의존성 주입 수단으로 사용하고, zustand 상태는 optional하게 두는 설계를 시도했다. 타입 수준에서 “이 값이 없으면 안 된다”는 걸 드러내는 것만으로도, 런타임에서 겪던 문제들이 눈에 띄게 줄어들었다.
GraphQL을 쓰게 되면서 바뀐 시선
B2B 어드민 개발에 합류했을 때, 이미 시스템은 GraphQL을 중심으로 설계되어 있었다. 처음에는 쿼리 구조와 데이터 관계가 복잡하게 느껴졌다. REST에 익숙했던 입장에서는, 한 화면을 구성하기 위해 어떤 데이터를 어디까지 가져와야 하는지 판단하는 것 자체가 쉽지 않았다.
하지만 실제로 복잡한 계약과 요금 데이터를 다루기 시작하면서, 이 구조가 왜 선택되었는지 점점 이해하게 됐다. 어드민 도메인에서는 데이터의 양보다 관계와 맥락이 더 중요했도, 화면마다 필요한 데이터의 조합도 제각각이었다. GraphQL은 이런 상황에서, 필요한 데이터를 필요한 형태로 다시 조립하는 데 꽤 유연한 도구였다.
이 경험 이후로 기술을 바라보는 시선도 조금 달라졌다. 새로운 기술을 도입하는 것보다, 이미 주어진 기술이 어떤 문제를 해결하기 위해 선택되었는지를 이해하는 것이 더 중요하다는 걸 실감하게 됐다.
SharedWorker를 다시 쓰며 느낀 변화
2025년에도 SharedWorker를 다시 사용하게 됐지만, 이전과는 접근 방식이 달랐다. 예전에는 “이 문제를 해결할 수 있는 수단”으로 봤다면, 이제는 시스템의 수명을 늘리는 선택지로 보게 됐다. 장시간 유지되는 작업을 브라우저 탭에 맡기지 않고, 공통된 실행 환경으로 옮긴다는 개념 자체가 점점 중요하게 느껴졌다.
에필로그 — 같은 자리에 서서, 다른 질문을 하게 됐다
연말 종무식에서 지난 한 해를 돌아보는 시간을 가졌다. 회사는 분명히 많이 성장해 있었다. 서비스도, 조직도, 숫자도 이전과는 다른 위치에 와 있었다. 그 장면을 보며 자연스럽게 나 자신을 돌아보게 됐다. 회사가 성장하고 있다는 사실과, 내가 성장하고 있다는 감각은 항상 같은 속도로 움직이지는 않는다는 걸 그때 또렷하게 느꼈다.
그 깨달음이 질문 하나를 남겼다. 지금의 나는 환경이 만들어주는 성장에 기대고 있는 건 아닌지, 내가 의식적으로 챙기지 않으면 놓치게 되는 성장은 없는지에 대한 질문이었다. 종무식이 끝난 뒤에도 그 질문은 계속 머릿속에 남아 있었다.
돌이켜보면, 새로운 도구를 많이 쓰게 된 해는 아닐지 모르지만, 같은 도구를 전보다 훨씬 의식적으로 쓰고 있다는 감각은 분명하다. 무엇을 선택했고, 무엇을 선택하지 않았는지, 그 이유를 스스로 설명하려고 하기 시작했다는 점에서 이전과는 다른 시기에 와 있다는 생각이 든다.
2026년을 앞두고 나는 더 많은 기술을 아는 개발자가 되기보다는, 내가 이미 알고 있는 기술을 어떤 기준으로 선택하고 있는지를 설명할 수 있는 개발자가 되고 싶다. 어떤 문제 앞에서 왜 이 구조를 택했고, 왜 다른 선택을 하지 않았는지를 스스로 납득할 수 있는 상태에 가까워지고 싶다.
아마 내년에도 여전히 React를 쓰고, 상태를 고민하고, 성능과 구조 사이에서 흔들릴 것이다. 다만 예전과 다른 점이 있다면, 그 흔들림을 무작정 견디기보다는 기록하고, 질문하고, 나만의 기준으로 남기려 한다는 점이다.
이 회고는 그래서 끝이 아니라, 내가 나의 성장을 조금 더 의식하기 시작한 시점에 남겨두는 기록이다. 2026년의 나는 이 글을 다시 읽고, 지금과는 또 다른 질문을 하고 있기를 바란다.