이직 후 1년 회고
2025년 9월 이직한 지 1년이 조금 넘었다. 입사 1주년에 맞춰 회고를 쓰고 싶었지만 이래저래 늦어졌다. 어느새 연말도 가까워졌으니, 지금이라도 지난 시간을 돌아보려 한다.
2015년 9월 어렵사리 개발자로 일을 시작한 지도 11년이 지났다. 그동안 여러 변화를 겪었지만, 최근 1년의 변화가 특히 인상 깊었다. 새로운 회사에서 일하기 시작했고, AI와 함께 개발하는 방식도 크게 달라졌다. 결혼을 하고 짝꿍과 함께 살기 시작한 해이기도 하다.
왜 이직을 했을까?
이전에 다니던 회사에서도 팀의 일원으로 역할을 수행하고, 어려운 문제를 풀어나가는 데 하루하루 매진하고 있었다. 그러면서 몇 가지 의문이 머릿속을 맴돌았다.
나는 현재 상태에 만족하고 있는가? 언제나 만족스러운 곳을 찾기는 어렵다. 만족의 기준은 계속 바뀌기 때문이다. 그래서 이 질문만으로 이직을 결정하기는 어려웠다.
오히려 더 마음에 걸린 것은 2년쯤 뒤의 내 모습이었다. 개발자로 계속 일하고 있겠지만, 여러 방면에서 압박을 받으며 많은 스트레스를 받고 있을 것 같았다. 그리고 ‘지금은 내가 프론트엔드 개발자라는 이름을 달고 있지만, AI 시대에 직업시장이 한 번 큰 파도를 맞고 나서, 내 이력서는 이후 어떤 가치가 있을까?’ 라는 걱정도 들었다.
전문성이 점점 희박해지는 느낌이었고, T자형 인재를 어필한다 해도 나의 깊이는 어느 측면에 있는지 스스로 의심이 들기 시작했다.
그러던 중 네이버에서 사우디아라비아에 지도 앱을 내놓는다며 개발 인원을 모으고 있었다. 원래 지도 서비스를 좋아하기도 했고, 더 많은 사용자에게 가치를 전달하는 프로젝트에 참여할 기회라는 생각이 들어 지원했다. 이 글을 쓰는 시점에는 베타 출시도 마쳤다.
이직을 위해 지원할 때 ‘내가 이 조직에 얼마 있지 않았는데’ 같은 생각은 하지 않는 편이다. 그것을 평가하는 것은 나를 채용하는 쪽에서 할 일이라고 생각한다. 지원하지 않아서 나중에 후회할 일을 만들고 싶지도 않았다.
결론부터 이야기하면, 이직하길 잘했다. 언제나 좋은 경험만 있었던 것은 아니지만, 앞으로의 나를 위해 좋은 결정이었다고 생각한다.
갈피를 잡기 어려웠던 초반
프로젝트의 규모가 크고 협업 대상도 많았다. 의사결정에 여러 주체가 얽혀 있었고, 소통에도 많은 비용이 들었다. 여러 요인이 겹치면서 협업 절차가 충분히 정리되지 않았다고 느꼈다. 내가 참여한 프로젝트에서는 제품을 빠르게 쌓아 올리고 피드백을 받아 개선하는 흐름을 만들기가 쉽지 않았다.
기존 지도 조직과 협업할 일이 많으리라 생각했지만, 실제로는 맡은 업무에 따라 달랐다. 나는 주로 사용자에게 제공되는 웹뷰를 밑바닥부터 만들거나, 프론트엔드 플랫폼 관련 작업을 맡고, 장소 정보를 수집하는 도구를 개발했다. 모두 0에서 1을 만드는 일이었다.
합류한 뒤 프론트엔드 업무가 명확히 정의되기까지는 시간이 조금 걸렸다. 이때 프론트엔드 개발자끼리 어떻게 일하면 좋을지 더 진지하게 고민하고 논의하지 않았던 것이 아쉽다.
AI가 바꾼 일하는 방식
LLM이라고 말하는 것이 더 적절할 수 있으나, 편의상 이 글에서는 AI라는 단어를 사용한다.
이전 회사에서는 Windsurf로 AI 기반 개발에 맛을 본 정도였다. 입사 후 Cursor를 잠시 사용했고, 얼마 지나지 않아 Claude Code를 사용할 수 있게 되었다. 이 무렵부터 개발 관련 관심사가 프론트엔드, 웹 플랫폼, 설계 등에서 ‘효과적인 에이전틱 워크플로 구축’으로 크게 이동했다.
어떻게 하면 AI 도구를 활용해 더 빠르고 효과적으로 개발하고, 업무를 더 잘 처리할 수 있을지 조사하고 실험하는 나날을 보냈다. 여러 도구와 방법을 탐색하고, 매일 일정 시간은 전날까지의 방식을 개선하는 데 썼다. 조직 안에서 AI 이야기를 나눌 채널을 만들고, ‘모두의 AI’라는 토론 세션을 열어보기도 했다. AI와 함께 더 탁월하게 일하고 싶어 여러 시도를 하고 있지만, 여전히 부족함을 느낀다.
최근에는 정신없이 밀려 있는 업무를 보며 나만의 대시보드를 만들었다. 다음에 우선적으로 처리할 일을 보기 쉽게 하고 싶었다. 에이전트의 업무를 중앙에서 오케스트레이션하고, 스스로 일하는 방식을 개선하는 나만의 Tech Lead 에이전트도 만들어보고 있다. 이 시도도 한 달 뒤에는 전혀 다른 모습이 되어 있을지 모르겠다.
전문성의 초점이 달라졌다
예전에는 구현의 세부 사항에 초점을 맞춰 개발할 때가 많았다. 브라우저와 React API를 세심하게 다루는 방법, 컴포넌트 구조, 테스팅 전략, 베스트 프랙티스를 팀에 전파하는 방법 등을 고민했다. 읽기 쉬운 코드를 만들고 애플리케이션의 성능을 좋게 만드는 것이 중요했다. 코드가 불필요하게 장황하지 않은지까지 깊이 살폈다.
지금은 구현을 에이전트에게 맡긴다. 구현에 앞서 조사하고, 그 결과를 바탕으로 전략을 세우고, 에이전트의 작업 방향을 잡는 프롬프트는 내가 작성한다. 기능의 크기에 따라 이 과정도 어느 정도 자동화할 수 있지 않을까 생각하고 있다.
애플리케이션의 성능은 여전히 중요하다. 다만 코드를 읽고 고치는 일의 상당 부분을 에이전트가 맡으면서, 코드 표현의 세세한 부분을 다듬는 데 들이는 노력은 줄었다. 대신 테스트가 의도를 제대로 담고 있는지, 구현이 기능 명세와 설계 의도에 맞는지 검증하는 데 훨씬 많은 노력을 기울인다.
요즘은 기술자보다는 제품을 만드는 사람으로 프로젝트에 참여한다는 느낌이 든다. 브라우저나 웹뷰로 접속한 사용자가 최종적으로 데이터를 전달받기까지, 그 사이에 고려해야 할 것들을 프론트엔드에 초점을 맞춰 살핀다. UI와 UX를 어떻게 구성할지, 서버에서 데이터를 어떤 방식으로 받고 소비할지, 모바일 앱과 인터페이스를 맞추는 방법 등, 이런 부분에 프론트엔드 개발자로서 적극적으로 의견을 내고 있다.
전문성이 크게 달라졌다기보다는 기술적 구현에서 제품 자체로 초점이 이동했다고 느낀다. 그래서 지금은 나를 ‘프론트엔드에 특화된 프로덕트 엔지니어’라고 표현하는 것이 더 어울리는 것 같다.
하지만 일은 여전히 많다
많은 기능이 들어 있는 프로젝트를 짧은 시간 안에 출시하려다 보니 모두의 업무가 많았다. 나도 많은 업무를 들고 있던 사람 중 하나였다. AI와 함께 일하면 처리 속도가 빨라지거나, 내가 직접 살펴봐야 할 일이 줄어들 줄 알았다.
하지만 전체적으로 일하는 속도가 얼마나 빨라졌는지는 잘 모르겠다. 협업에는 여전히 다양한 병목이 있었다. AI 사용에 대한 숙련도가 서로 다르다 보니, 소통에 끼어든 불필요하게 길거나 정리되지 않은 AI 결과물이 방해가 되는 경우도 있었다. 결국 나는 올 한 해 많이 일했다.
여러 조사·구현 에이전트를 돌려도, 결과물을 검증하고 다음에 무엇을 할지 판단하는 일은 내 몫이었다. 내가 개발 작업의 병목이 되었다. 여러 업무를 펼쳐놓아도 하나씩 살펴보고 판단하는 속도는 그리 빨라지지 않았다. 작업 사이의 컨텍스트 전환 비용도 컸다. 이 두 가지가 특히 힘들었다.
비슷한 고민을 다룬 글도 있다. 오케스트레이션으로 이 문제를 줄여보고 싶지만, 조율하고 관리하는 일이 늘어나 다시 ‘오케스트레이션 세금’으로 돌아오는 것은 아닐까 걱정도 된다.
팀의 일원으로 더 잘 일하는 방법을 찾는 중
우리 팀의 프론트엔드 엔지니어는 각자 특정 도메인을 맡고, 그 도메인의 오너십을 가지고 일한다. 나 역시 제품의 성공을 위해 백엔드 개발자, 기획자, 디자이너, QA 엔지니어와 활발히 소통하고 협업하고 있다.
반면 프론트엔드 개발자끼리 협업하는 지점은 줄었다. 올해 초 AI 기반 코드 리뷰를 본격적으로 도입하고 담당 도메인의 경계가 명확해지면서, 서로의 코드를 매번 리뷰할 일도 줄었다. 각자가 맡은 도메인을 개발하고 검증할 책임을 지고, 모노레포의 가드레일과 AI 리뷰를 활용하되 놓칠 수 있는 부분을 추가로 챙기는 방식으로 일했다.
나는 커리어 초기부터 프레임워크나 플랫폼처럼 서비스의 밑바탕을 잘 만드는 일에 관심이 많았다. 하지만 여러 조직에서 그런 일을 주도하는 과정에 상처를 입기도 했다. 그래서 이번에는 겁이 났다. 동료와 동료가 사용하는 AI를 신뢰하면서, 공통의 설계나 작업 방식을 함께 논의하는 데는 소극적이었다. 현재 코드베이스에서 발견한 문제를 어떻게 함께 풀지 논의하는 자리를 적극적으로 만들지 못했다.
개별 문제에는 적극적으로 대응했다. AI 코드 리뷰 액션이 그중 하나였다. claude-code-action으로 전체 PR을 리뷰했는데, 주입하는 컨텍스트가 방대해지고 토큰 소모량이 늘면서 리뷰가 너무 느리고 비싸졌다. 업무에 명확히 방해가 되는 상태라고 느꼈다.
이를 개선하기 위해 총대를 메고 조사와 설계, 점진적인 개선을 여러 차례 반복했다. 최종적으로는 꽤 빠르고 비용도 저렴한 코드 리뷰 액션을 새로 만들 수 있었다. 결과도 만족스러웠고, 에이전트 오케스트레이션을 배울 기회도 되었다.
디자인 토큰을 사용하도록 가드레일을 만든 일도 있었다. 모노레포에 디자인 토큰을 패키지로 만들어뒀지만, 에이전트가 이를 사용하지 않고 Figma의 원시 값을 그대로 가져와 스타일시트를 작성하는 경우가 있었다. 그래서 디자인 토큰 조회 CLI를 만들고, 스타일을 작성하기 전에 반드시 토큰을 조회하도록 작업 절차를 정했다.
그런 개선과 별개로, 코드가 생성되는 속도에 맞춰 공통 기반을 단단하게 정비할 시기를 놓쳐 고생하기도 했다. 한참 개발하다 보니 작업 속도가 느려지고 있었다. 동료는 코드와 함께 무분별하게 쌓인 주석이 오히려 작업 속도와 품질을 떨어뜨린다는 의견을 냈다. 이를 받아들여 무분별하게 쌓인 주석을 걷어내고, 정말 필요한 정보는 별도 문서로 정리해 에이전트에게 필요한 시점에 전달하도록 바꿨다. 그 뒤로 개발하기 더 좋은 환경이 되었다.
코드베이스가 커지는 동안 문서화할 여유를 충분히 갖지 못한 것도 아쉽다. 동료가 합류했을 때 프로젝트를 어떻게 설명하고 온보딩해야 할지 어려움을 겪었다.
요즘은 이런 공통 기반을 어떻게 함께 관리하고, AI를 활용하는 숙련도도 같이 높일 수 있을지 고민하고 있다. 부드러우면서도 흡입력 있는 리더십을 가지고, 동료들과 제품뿐 아니라 플랫폼 측면에서도 잘 일하는 방법을 찾는 중이다. 찾고 있던 길 중 하나로 주간 엔지니어링 데이가 만들어져 그 안에서 의미 있는 논의를 하고 있다고 느낀다.
짝꿍과 함께 살며 달라진 생활
결혼을 했다. 2025년 11월, 연애한 지 1년이 조금 넘었을 때 혼인신고를 먼저 했고, 2026년 1월부터 같이 살고 있다.
결혼을 단순히 개인의 신변 변화 정도로 생각했는데, 그보다 훨씬 많은 의미가 있다는 것을 뒤늦게 깨달았다. ‘내 짝꿍이 가족이 되어 같은 집에서 산다’는 것이 삶의 전반을 바꿨다.
일이 힘들었던 날에도 집에 들어가면 서로 맞이해주고, 수고했다며 다독이고, 내일도 힘내자고 격려할 수 있다. 함께 살면서 이전과는 다른 정서적 안정감이 생겼다. 언제나 고맙다.
여가 시간의 소중함도 더 많이 느낀다. 취향과 관심사가 다른 두 사람이 함께 시간을 보내다 보니, 혼자 연구하거나 게임할 시간을 예전처럼 내기는 어렵다. 가족이 한 명 늘어도 이 정도인데, 육아까지 하는 인생 선배 개발자들이 참 존경스럽다.
그럼에도 지금은 개인 시간보다 함께 보내는 시간을 더 중요하게 여긴다. 삶의 무게중심이 바뀌었다. 궁극적인 목표도 ‘나 혼자 어떻게든 버텨보기’에서 ‘짝꿍과 함께 아프지 않고 행복하게 살기’가 되었다. 이 목표를 위해서라면 커리어나 개발자로서의 성장에 대한 고민을 조금 미뤄도 좋다고 생각한다.
조금씩 남는 시간을 어떻게 확보하고 쓸지도 고민이다. 요즘은 그렇게 긁어모은 시간을 수면에 쓰고 있다. 일단 건강부터 챙기고 봐야지.
여전히 소프트웨어 개발은 재밌다
구현을 에이전트에게 맡기고 개발한 지 1년 정도 되었다. 그래도 제품을 만드는 과정에 필요한 깊은 사고와 전략 수립, 커뮤니케이션은 여전히 중요하다. 오히려 더 중요해졌다고 느낀다. 그래서 내가 가진 역량도 앞으로 계속 필요하지 않을까 기대한다.
나와 AI가 함께 만든 소프트웨어가 고객에게 전달되고, 고객에게 만족을 주는 일은 여전히 나에게 동기부여가 된다.
물론 업무량과 컨텍스트 전환, 조직 문화 등 여러 장벽 때문에 힘들 때도 많다. 힘든 부분을 찾아 상담이 필요하면 요청하고, 부족한 점을 발견하면 개선하며 극복하려고 노력 중이다.
앞으로 어떻게 살아갈까
더 탁월한 개발자가 되고 싶은 마음은 여전하다. 소프트웨어 개발의 근본적인 부분을 더 잘 이해하고, 넓은 시야를 갖고 싶다. 특히 주어진 과업에 너무 신중하게 접근하는 태도에서 조금 벗어나, 일단 한 발을 내딛고 빠르게 결과물을 내는 데 신경 쓰고 있다.
어제의 베스트 프랙티스가 오늘의 모델이나 하네스에서는 의미가 없어지는 일이 빈번하다. 그럴수록 사람과 잘 일하고, 소프트웨어 개발 자체를 잘하기 위한 수련을 하고 싶다. 부족한 시간 속에서 빠르게 변하는 것들을 어떻게 잘 학습할지도 계속 고민하게 된다.
이렇게 돌아보면 앞으로의 몇 년도 지금까지 거쳐온 길과 크게 다르지 않게 흘러갈 것이다. 학습하고 발전하고, 부족한 점을 발견하면 다시 개선하고. 조금이나마 나아진 내가 더 좋은 제품과 더 나은 사회를 만드는 데 기여하며, 짝꿍과 건강하고 행복하게 살기. 그게 전부다.