이 글은 개발자 채용 규모를 예측하거나 모델의 순위를 매기는 글이 아닙니다. 최근 프로젝트를 하며 제가 체감한 변화를 기록한 회고입니다. 소프트웨어가 사라진다는 뜻도 아닙니다. 다만 코드를 쓰는 일이 개발의 당연한 중심이라는 생각은 흔들리고 있습니다.
새 모델과 AI 에이전트 소식은 매일 쏟아집니다. 성공 사례도 많고, 과장된 데모와 사기도 섞여 있습니다. 이 소란은 한동안 계속되겠지만, 개발 과정에서 사람과 코드가 놓이는 자리는 전보다 분명하게 바뀌고 있습니다.
수십 년 동안 개발을 해왔지만, 이렇게 직접적으로 체감되는 변화는 처음입니다. 최근에는 제가 직접 쓰는 코드가 예전의 절반쯤으로 느껴집니다. 제가 쓴 코드도 에이전트에게 다시 검수받고, 다른 구현안을 받고, 테스트까지 맡깁니다. 이제는 AI가 전혀 닿지 않는 단계를 찾는 편이 더 어렵습니다.
불편한 변화는 속도만의 문제가 아닙니다. 예전에는 복잡한 코드를 오래 붙들고 이해하는 일이 개발자의 본능에 가까웠습니다. 지금은 먼저 에이전트에게 구조를 설명해 달라고 하고, 위험한 부분을 짚어 달라고 하고, 수정안을 몇 개 내놓으라고 합니다. 그러다 보면 한 가지 질문을 피하기 어렵습니다. 나는 아직도 모든 코드를 예전처럼 이해해야 할까.
코드가 중심이 아닐 때
오랫동안 소프트웨어 공학의 중심에는 사람이 있었습니다. 사람이 요구사항을 해석하고, 논리를 설계하고, 코드를 쓰고, 오류를 잡았습니다. 이제는 순서가 바뀔 수 있습니다. 사람이 목표와 제한을 정하면 에이전트가 구현과 실행의 상당 부분을 맡고, 사람은 결과를 확인하는 쪽으로 밀려날 수 있습니다.
일의 단위도 달라집니다. 예전에는 함수 하나, 커밋 하나, 신중하게 검토한 풀 리퀘스트 하나가 일이었습니다. 이제는 실행 중인 시스템에서 기능이 제대로 동작하는지, 그 결과를 믿을 근거가 남았는지가 더 중요합니다. 코드는 여전히 남아 있지만, 코드만으로 일이 끝났다고 말하기는 어려워졌습니다.
제품의 형태도 바뀔 수 있습니다. 사람이 직접 조작하는 화면보다 AI가 다른 AI를 호출하고, 협상하고, 운영하는 구조가 더 중요해질 수 있습니다. 사람은 대시보드에서 결과를 보고 승인하거나 멈추고, 문제가 생기면 원인을 찾는 쪽으로 이동할지도 모릅니다. 몇 개 프로젝트의 경험만으로 증명할 수 있는 결론은 아니지만, 충분히 현실적인 방향으로 보입니다.
도메인 지식도 영원한 방어막은 아닙니다
도메인 지식이 있는 사람은 안전하다는 말도 자주 나옵니다. 저는 그 말도 확신하기 어렵습니다. 프로젝트 규칙, 자주 나오는 질문, 사소한 예외 처리, 내부 용어는 생각보다 빨리 에이전트가 쓸 수 있는 맥락으로 옮겨갑니다. 팀원 모두가 동료보다 에이전트에게 먼저 묻는 환경에서는 한 사람의 머릿속에 있던 지식이 공동의 작업면이 됩니다.
그렇다고 사람이 쓸모없어진다는 뜻은 아닙니다. 가치가 놓이는 자리가 바뀝니다. 규칙을 가장 많이 외운 사람보다, 서로 충돌하는 규칙을 알아차리는 사람, 고객이 용납하지 않을 일을 아는 사람, 조직이 감수할 손실을 판단하는 사람이 더 중요해질 수 있습니다.
AI가 아직 전체 주도권을 갖지 못한 이유는 충분한 신뢰를 얻지 못했기 때문입니다. 고객 데이터를 잘못 다루거나, 비용을 예상보다 크게 쓰거나, 운영 환경에서 실패했을 때 누군가는 어디서 멈출지 결정하고 피해에 답해야 합니다. 좋은 사례와 긴 운영 기록이 쌓이면 그 장벽은 낮아질 수 있습니다. 하지만 오늘 테스트를 통과한 패치와 운영을 맡길 수 있는 신뢰는 다른 문제입니다.
방금 마무리한 Luthn Team 온보딩 작업에서도 이 차이를 봤습니다. 기본 작업공간은 자동으로 준비하게 했지만, 팀의 Hub를 연결하는 일과 Agent를 연결하는 일은 분리했습니다. 한 번에 끝내면 편했겠지만, 사용자가 원하지 않은 Agent 설정 변경까지 함께 일어날 수 있었습니다. 그래서 자동화는 그 지점에서 멈추게 했습니다.
이 사례에서 중요한 것은 에이전트가 코드를 얼마나 잘 만들었는지가 아니었습니다. 어디까지 자동으로 바꿔도 되는지, 실패했을 때 무엇을 보존해야 하는지를 사람이 정하는 일이었습니다.
개발자에게 남는 일
개발자가 살아남는 방법은 에이전트보다 빨리 코드를 치는 데 있지 않을 겁니다. 그 경쟁은 이미 의미를 잃고 있습니다. 일은 코드 바깥으로 이동합니다. 무엇을 만들지, 무엇은 만들지 말아야 하는지 정하고, 에이전트가 볼 정보와 실행할 권한을 나누고, 결과가 맞다는 기준을 세우는 일입니다.
프롬프트보다 중요한 질문도 생깁니다. 이 에이전트는 무엇을 볼 수 있나. 어디까지 바꿔도 되나. 누가 이 결과를 정상이라고 정했나. 문제가 생겼을 때 멈추고 되돌릴 수 있나. 잘못됐을 때 그 비용은 누가 감당하나.
이 질문에 답하지 못한다면, 아무리 멋진 결과물이 나와도 운 좋게 작동한 데모에 가깝습니다. 책임 있게 운영할 수 있는 제품은 아닙니다.
그래서 개발자의 미래는 더 좋은 자동완성으로 코드를 생성하는 일에만 있지 않다고 봅니다. 역할은 의도, 권한, 검증, 결과에 남는 책임 쪽으로 이동합니다. 모든 줄을 직접 쓰지 않더라도 시스템을 의심하고 증거를 확인할 수 있어야 합니다. 맡기면 안 되는 일을 거절할 수도 있어야 합니다.
소프트웨어가 끝나는 것은 아닐 겁니다. 지금보다 훨씬 많은 소프트웨어가 더 빠르게 만들어질 수도 있습니다. 다만 코드가 가장 중요한 산출물이던 시대와 개발자가 코드를 독점적으로 이해하던 시대는 끝나고 있을지 모릅니다.
앞으로의 질문은 개발자가 살아남을 수 있는가가 아닐 겁니다. AI에게 어디까지 맡길 것인가. 그리고 그 결과에 누가 책임질 것인가.
범위: 이 글은 개인적인 프로젝트 회고이며 벤치마크가 아닙니다. ‘직접 작성하는 코드가 절반쯤 줄었다’는 표현도 업계 전체에 적용할 수 있는 측정치가 아니라, 현재 제 작업 방식에서 느끼는 변화입니다.
