본문으로 건너뛰기
jcjang의 블로그
· opinion · 3분 읽기

2026년 시니어 개발자는 코드 에디터가 된다

aicareeropinionengineering

AI 에이전트를 매일 쓰기 시작한 지 1년 남짓 됐다. 처음엔 신기했고, 두 달쯤 지나면서는 이게 진짜 생산성을 바꾼다는 감각을 얻었고, 지금은 조금 김이 빠졌다. 편해진 건 분명히 편해졌는데, 내 하루가 생각만큼 가벼워지지는 않았다.

이 글은 그 1년을 정리해본 것이다. 마침 얼마 전에 본 Addy Osmani의 JS Nation US 2026 인터뷰가 내가 느낀 것들을 언어로 잘 정리해둬서, 개념 몇 개만 빌려왔다. 그 외에는 내가 에이전트와 부딪히면서 쌓은 관찰이다.

속도는 느는데 하루는 왜 덜 줄지 않나

처음 에이전트를 쓰기 시작했을 땐 “이제 4시간이면 될 일을 2시간에 끝낸다”는 식으로 기대를 했다. 실제로 특정 구간은 그렇게 된다. 빈 파일에서 CRUD 엔드포인트를 하나 만들거나, 정형화된 데이터 파싱 스크립트를 짜거나, 흔한 리팩토링을 밀어주거나.

그런데 하루 전체를 놓고 보면 줄어든 시간이 기대만큼 크지 않았다. 이유를 짚어보니 이랬다. 빠르게 처리되는 일은 원래도 부담이 크지 않은 일이었고, 하루의 무게는 그 전후 구간, 즉 요구를 해석하고 설계를 잡고 최종 결과를 다듬는 구간에 몰려 있었다. 앞쪽이 짧아진 만큼 뒤쪽이 같이 짧아지지는 않는다.

AI 업계에선 이걸 “70% 문제”라고 부르는 사람이 있었다. AI가 70%까지 깔끔하게 데려다주지만, 나머지 30%는 사람이 메워야 한다는 이야기다. 최근엔 모델이 나아지면서 그 숫자가 80%쯤으로 올라왔다는 얘기도 나온다. 숫자는 움직여도 결론은 같다. 마지막 구간의 사람 시간은 별로 줄지 않는다.

내가 체감한 건 “속도가 늘었다”보다 “속도가 쏠렸다”에 가깝다. 빠른 부분은 아주 빨라졌고, 느린 부분은 예전과 거의 같다. 이게 기대와 결과 사이의 거리를 만든다.

조금 다르게 표현하면, 에이전트가 잘 해주는 영역과 사람이 필요한 영역이 서로 다른 모드의 코드 작성에 대응한다. 한쪽은 “이게 가능은 한가”를 빠르게 확인하는 탐색용 작업이다. 최근 업계에서 바이브 코딩(vibe coding)이라고 부르는 쪽에 가깝다. 어차피 대부분 버려질 코드라 리뷰의 엄격함이 덜해도 된다. 다른 한쪽은 실제 제품에 들어가는 코드다. 아키텍처, 에러 처리, 장애 대응, 성능까지 기존 엔지니어링 원칙이 살아있어야 한다. 에이전트로 체감 속도가 오른 건 주로 전자이고, 후자는 여전히 사람 시간에 묶여 있다.

에이전트가 올린 PR을 읽는 시간

제일 크게 늘어난 작업이 뭐냐고 하면, 나는 PR 리뷰를 꼽겠다. 에이전트에게 적당한 태스크를 맡기면 10분이면 PR을 올려준다. 그런데 그걸 머지하기까지 드는 시간은 30분이 넘어가는 경우가 자주 있다.

가장 흔한 패턴이 이런 거다. 기능은 돌아간다. 테스트도 통과한다. 그런데 브랜치를 받아서 변경 파일을 열어보면, 기존에 이미 있던 formatDate 같은 유틸을 쓰면 됐는데 비슷한 함수를 새로 한 덩어리 만들어뒀다. 혹은 에러 처리가 다른 파일과 패턴이 다르다. 혹은 함수 하나만 고치면 될 일에 설정 파일 세 개가 같이 수정돼 있다.

이런 것들은 명백한 버그가 아니라서 테스트로 잡히지 않는다. 머지 전에 사람이 한 번 더 읽고 정리해줘야 하는 종류의 문제다. 한두 번이면 그냥 고치고 말 텐데, 이게 PR마다 누적된다. 리뷰 시간이 길어지는 이유다.

더 문제는, 시간을 아낀다고 리뷰를 대충 훑고 머지한 코드들이다. 당장은 아무 일도 없다. 그런데 두 달 뒤, 관련 기능을 손볼 일이 생겨서 그 파일을 열면 낯선 코드가 한 뭉치 들어있다. 내가 머지한 건데 누가 왜 이렇게 짰는지 설명할 수 없다. 이 시점에 들어가는 복원 비용은 그때 아꼈던 리뷰 시간보다 훨씬 크다.

이 감각을 “이해도 부채”라고 이름 붙여 설명한 글을 얼마 전에 봤다. 팀에 머지된 코드 분량과 팀이 실제로 이해하고 있는 분량의 간극이 매일 벌어지는 현상. 이자 붙는 부채라는 표현이 꽤 적절하다고 느꼈다. 기술 부채가 “바쁠 때 대충 짠 코드의 청구서”라면, 이해도 부채는 “대충 읽고 넘긴 코드의 청구서”다.

예방책은 특별할 게 없다. 다른 글에서 따로 다룬 것들이 대부분이다.

  • 한 커밋에 한 작업. 무슨 변경이 왜 들어왔는지 히스토리에서 읽을 수 있게
  • 테스트로 동작 고정. 설명이 애매해도 스펙은 남음
  • 워크스페이스 규칙 문서(CLAUDE.md 등)에 “이 프로젝트에서는 이렇게 짠다”를 박아둠
  • 리뷰 때 “왜 이 방식을 골랐는지”를 형식이 아니라 실제로 묻기

이 중 하나라도 빠지면 부채가 빠르게 쌓인다. 몇 달 써보고 나니 리뷰의 질이 개인 생산성보다 팀 생산성에 훨씬 큰 영향을 준다는 게 눈에 들어왔다.

결국 읽고 판단하는 사람이 필요하다

여기까지 관찰을 쌓아놓고 보면, 시니어의 역할이 자연스럽게 재정의된다. 코드를 얼마나 빠르게 쓰느냐보다, 올라온 변경을 얼마나 정확하게 읽고 판단하느냐가 중요해진다.

앞서 언급한 인터뷰에서 이걸 “코드 에디터”라는 이름으로 부른다. 제목 그대로 옮기면 “고연봉 코드 에디터(highly-paid Code Editors)“다. 처음 들었을 땐 어딘가 깎아내리는 것처럼 들렸는데, 곱씹어보니 오히려 반대였다.

편집자라는 역할을 생각해보면 그렇다. 글쓰기에서 편집자는 저자보다 덜 쓴다. 대신 원고 전체의 일관성, 흐름, 사실 관계, 독자와의 거리 같은 걸 지킨다. 저자는 한 문장을 잘 쓸 수 있지만, 책 한 권 단위의 완성도를 책임지는 건 편집자다.

코드도 비슷하다. 에이전트는 한 파일 단위의 구현을 빠르게 뽑아낸다. 그걸 팀 코드베이스의 스타일, 의존성, 장애 대응 패턴과 맞출 수 있는 사람은 결국 그 코드베이스를 오래 들고 있는 개발자다. 에이전트가 만든 결과물을 보고 “이건 기존 것과 같이 가야지”, “이 부분은 우리 제품 방향과 안 맞다”라고 판단할 수 있어야 한다.

이 관점에서 코드 에디터는 폄하가 아니라 정확한 명칭이다. 빠르게 찍어내는 일이 기계 쪽으로 넘어가면, 남는 건 제품과 코드베이스의 정합성을 지키는 일이다. 이건 병목이 좁아진 쪽으로 일이 몰리는 것에 가깝다.

여러 에이전트를 동시에 굴릴 때

최근에 내 작업 방식도 조금씩 바뀌고 있다. 예전엔 에이전트 하나와 대화하듯 일했다면, 요즘은 서너 개 태스크를 동시에 맡겨놓고 내가 돌아가며 들여다본다. 블로그 글 초안을 한쪽에서 쓰게 해두고, 다른 한쪽에서는 간단한 리팩토링을 시키고, 또 다른 창에서는 PR 리뷰를 받는 식이다.

이렇게 하면 한 사람 기준 처리량은 분명히 올라간다. 다만 관리 부담이 함께 올라간다. 각 에이전트가 지금 어디쯤 와 있는지, 서로의 변경이 충돌하지는 않는지, 내가 돌아왔을 때 어떤 걸 먼저 봐야 하는지를 머릿속에 들고 있어야 한다. 혼자 일하는 게 아니라 작은 팀을 이끄는 느낌에 가까워진다.

단, 이 방식이 먹히는 범위는 아직 좁다. 개인 프로젝트, 작은 팀의 실험적 작업, 블로그 같은 저위험 저장소에서는 잘 돈다. 엔터프라이즈 코드베이스처럼 공유 의존성이 많고 배포 책임이 무거운 환경에서는 아직 권하고 싶지 않다. 여러 에이전트가 각자 올린 PR이 서로 미묘하게 맞물리면 사고가 커진다.

태스크 분배가 핵심이다. 에이전트에게 맡기는 단위를 최대한 독립적으로 쪼개고, 서로 의존하지 않는 작업만 병렬로 돌리는 게 낫다. 의존이 있으면 한 줄로 줄을 세우고, 사람이 중간 결과를 확인한 뒤 다음을 시작하게 한다. 이건 소프트웨어 설계에서 모듈 간 느슨한 결합을 유지하는 것과 같은 이야기다.

주니어는 뭘 해야 하고, 시니어는 뭐가 남는가

주변에서 가장 자주 받는 질문이 이거다. “AI가 이렇게 코드를 잘 짜면 주니어는 어떻게 성장하나.” 나도 답이 명확하지는 않지만, 몇 가지는 또렷해졌다.

AI가 잘 대체하는 건 “이미 정리된 문제에 대한 답안”이다. 프레임워크 CRUD, 전형적인 데이터 변환, 반복되는 설정 스크립트. 이 구간은 분명히 압축된다. 예전엔 주니어가 숙련도로 차별화할 수 있었던 영역이 빠르게 평준화되는 중이다.

반면 줄어들지 않는 게 있다. 문제 자체를 정의하는 일, 서비스 경계를 설계하는 일, 장애 상황에서 무엇을 먼저 살릴지 판단하는 일, 낯선 버그의 실마리를 잡는 일. 이 영역은 오히려 에이전트 시대에 더 선명하게 “사람이 해야 하는 일”로 드러난다. 그리고 이 영역의 바탕에 있는 건 결국 기초다. 운영체제, 네트워크, 데이터베이스 내부, 알고리즘의 비용 감각. 화려한 스택보다 몸에 붙어 있는 기본기가 훨씬 오래 간다.

주니어의 길이 좁아진 게 아니라, 성장 경로가 바뀌었다고 보는 쪽이 맞다. 예전엔 프레임워크 튜토리얼을 따라가며 실력을 증명할 수 있었지만, 이제 그 구간은 에이전트와 공유한다. 대신 기본기에 시간을 쓰는 사람의 가치가 올라간다. 몇 년 뒤에 돌아보면 이 시기에 기초를 깔아둔 사람이 눈에 띄게 앞서 있을 거라고 본다.

시니어에게는 일의 결이 조금 바뀐다. 빠르게 만드는 일의 비중이 줄고, 읽고 판단하고 조율하는 일의 비중이 는다. 기술적 코칭과 리뷰의 질이 그 사람 가치의 큰 부분을 차지하는 쪽으로 이동하는 중이다. 쓰는 사람에서 읽는 사람으로 무게 중심이 넘어가는 것에 가깝다.

정리

이 변화를 완전한 격상이라고 보고 싶지는 않다. “속도의 이득”이 과장된 구간도 분명 있고, 앞에서 적은 것처럼 하루의 총량은 생각보다 덜 줄었다. 다만 방향 자체는 맞는 것 같다. 쓰는 속도가 아니라 읽고 판단하는 속도가 병목이 되는 시대.

몇 개 개념을 빌려 준 인터뷰에 감사한 한편, 끝까지 동의하기 어려운 부분도 있다. 나는 여전히 “코드 에디터”라는 이름이 너무 매끄럽다고 느낀다. 실제로 내가 하는 일의 절반은 편집에 가깝지만, 나머지 절반은 여전히 머리를 굴려 설계를 잡는 일이다. 이 둘을 한 단어에 담기는 좀 좁다.

그래서 이름은 계속 고민하되, 관찰은 고정해두려고 한다. 빠르게 만드는 일이 기계 쪽으로 넘어간 만큼, 읽고 판단하는 힘에 대해 각자 더 정직해져야 한다는 것. 이 힘의 크기가 앞으로 개발자의 값을 정할 거라고 생각한다.

참고 자료

관련 글

AI 시대를 살아가는 개발자의 덕목컨텍스트 엔지니어링, 프롬프트 튜닝 다음에 오는 것RAG와 벡터 검색, 그리고 pgvector
다음