AI가 코드를 쓰는 시대, 개발자는 무엇을 해야 하는가에 대한 생각

코드 작성에서 작업 설계로

2024년 초 입사했을 당시를 생각한다. GPT-4o가 나오기 직전쯤이었던 것으로 기억된다. 그때도 LLM은 코드 작성에 꽤 유용한 보조 수단이었다. 다만 지금과는 성격이 달랐다.

예를 들어 Spring Boot로 API를 하나 만든다고 하자. controller에서 facade, service, repository로 이어지는 예시 API 하나를 직접 완성한다. 이후 그 코드를 전부 복사해 넣고, 같은 컨벤션과 같은 로직으로 다른 API를 작성해 달라고 요청하는 식이었다. 말하자면 당시의 LLM은 설계자라기보다 재현 장치에 가까웠다. 사람이 이미 길을 닦아두면, 그 궤적을 어느 정도 모사하는 수준이었다.

물론 구현이 교착 상태에 빠질 때 질문을 던지기도 했다. 그러나 환각은 심했고, 과업의 복잡도가 조금만 올라가도 문법 오류와 논리적 결함이 코드 곳곳에서 발견되었다. 그때 개발에서 당연한 절차는 여전히 공식 문서를 뒤지고, 라이브러리 코드를 확인하고, 에러 로그를 읽고, 직접 디버깅하는 것이었다. LLM은 보조적 장치였지, 작업을 위임할 수 있는 독립적 주체는 아니었다.

이후 모델 성능은 계속 상승했다. 어느 순간부터 직접 찾아보는 시간보다 답변에 의존하는 시간이 조금씩 늘어났다. 그리고 coding agent가 등장했다. 처음 제대로 써본 것은 Gemini 계열의 에이전트였는데, 솔직히 말하면 성능은 조악했다. 로컬 파일을 직접 수정할 수 있다는 점은 신기했지만, 내가 직접 작업할 때보다 훨씬 느렸고, 결과물도 안정적이지 않았다. 이때부터 나름의 harness engineering을 시도했다. 작업 단위를 쪼개고, 규칙을 명시하고, 테스트를 강제하고, 수정 범위를 제한했다. 그래도 인간이 직접 작성하는 코드의 완성도를 따라오지 못했다.

특히 이미 컨벤션이 완성된 repository에서조차 문제는 반복되었다. 구조를 이해하지 못한 채 파일을 수정했고, 비슷해 보이는 코드들을 억지로 접합했으며, 컴파일 과정에서는 거의 항상 문제가 터졌다. 결국 개발자가 다시 코드를 읽고 고쳐야 했다. 에이전트가 코드를 작성하긴 했지만, 책임은 여전히 전부 개발자에게 귀속되었다.

그러다 2026년 초 퇴사할 즈음, Codex 계열의 새로운 모델들을 쓰기 시작하면서 체감이 완전히 달라졌다. 코드가 정교해졌고, 작업 후 컴파일 체크까지 직접 수행했으며, 단순 구현뿐 아니라 수정과 검증까지 하나의 흐름으로 처리하기 시작했다. 이제는 하나의 작업을 에이전트에게 맡겨두고, 나는 다른 작업을 진행할 수 있었다. 과장을 조금 보태면 기존 능률의 두세 배까지도 가능했다.

복학 후 여러 프로젝트를 수행하는 동안 이 변화는 더 가속화되었다. 한두 달에 한 번꼴로 새로운 에이전트와 모델이 나오고, 성능과 속도는 눈에 띄게 향상되었다. 작업이 끝난 뒤 개발자가 손봐야 하는 부분은 줄어들었고, 코드는 점점 더 치밀해졌다. 달 단위로, 심하면 주 단위로 따라가지 않으면 도태된다는 감각마저 들었다. 이제는 코딩 에이전트 없이 코드를 작성하는 것이 오히려 부자연스럽다.

작업 방식도 완전히 바뀌었다. 브랜치 컨벤션과 Git flow를 명시해 두고 여러 작업을 병렬로 돌린다. PR 리뷰도 직접 전부 읽기보다, 커스텀 대시보드를 만들어 타인의 코드, 정확히는 타인의 에이전트가 작성한 코드까지 검토한다. MCP가 부상하면서 Notion, Figma, 브라우저, 각종 커넥터를 엮어 기존에는 창을 옮겨 다니며 수행해야 했던 작업들을 하나의 워크플로우로 압축할 수 있게 되었다.

개발자의 격차는 어디에서 생기는가

서버 장애 대응도 마찬가지다. 과거에는 문제가 발생하면 직접 Prometheus 쿼리를 작성하고, Grafana 대시보드를 확인하고, CloudWatch 메트릭을 뒤지고, Datadog APM에서 JVM flame graph나 API trace를 따라가며 원인을 추적했다. 데이터베이스 문제가 생기면 하루 종일 쿼리 콘솔에 붙어 프로세스를 확인하고, 비용이 큰 쿼리를 찾아내고, 실행 계획을 읽고, 인덱스와 쿼리 구조를 수정했다. 이제는 이 과정의 상당 부분을 에이전트에게 위임할 수 있다. MCP 서버를 통해 메트릭을 읽게 하고, 인프라 서버에 터널을 열어 Java profile capture를 수행하게 하고, 그 결과에 대한 분석을 보조하게 만든다. 사람이 감당하던 반복적 탐색과 텍스트 분석의 상당 부분이 압도적으로 짧은 시간 안에 끝난다.

이 발전은 경이로웠다. 그러나 동시에 허무했다.

내가 잘할 수 있었던 작업들을 이제는 모두가 할 수 있게 된 것 같았다. 코드를 읽고, 라이브러리를 뜯어보고, 디버깅에 하루를 쏟고, 공식 문서를 뒤져가며 축적해온 시간이 무용하게 느껴졌다. 예전에는 그것이 경쟁력이었다. 남들이 오래 걸리는 문제를 더 빨리 파악하고, 더 정확하게 고치고, 더 안정적인 구조로 구현할 수 있는 능력. 그런데 AI가 그 능력을 빠르게 모방하기 시작했다. 내가 쌓아온 기술의 희소성이 소멸하는 것처럼 보였다.

하지만 여러 개발자와 협업하며 생각이 조금씩 바뀌었다. AI는 개발자의 격차를 축소하는 것이 아니라, 오히려 그 격차를 더 선명하게 노출하는 방향으로 작동하고 있었다.

많은 사람이 프롬프트의 중요성을 말한다. 나도 뼈저리게 느낀다. 그러나 여기서 말하는 프롬프트는 단순히 문장을 유려하게 쓰는 능력이 아니다. 작업의 본질을 이해하고, 결정해야 할 지점을 식별하고, 코드가 놓일 시스템의 맥락을 파악한 뒤, 에이전트가 임의로 추론하지 못하도록 조건을 정교하게 부여하는 능력이다. 결국 좋은 프롬프트는 좋은 개발 지식에서 나온다.

가령 간단한 로그인 페이지를 만든다고 하자. 프론트엔드와 백엔드를 포함해 “로그인 페이지 뷰와 뒷단 로직을 작성하라”고만 해도, 지금의 AI는 5분 안쪽으로 작동하는 로그인 기능을 만들어낼 수 있다. 문제는 바로 그것이 “작동한다”는 점이다. 너무 그럴듯하게 작동하기 때문에, 무엇이 누락되었는지 모르면 그대로 넘어가게 된다.

그러나 로그인은 단순히 이메일과 비밀번호를 입력받고, 서버에 POST 요청을 보내고, 성공하면 메인 화면으로 보내는 기능이 아니다. 세션을 어떻게 관리할 것인지, JWT를 쓴다면 access token과 refresh token의 생명주기를 어떻게 설정할 것인지, 쿠키를 쓴다면 HttpOnly, Secure, SameSite 정책을 어떻게 가져갈 것인지, 비밀번호는 어떤 방식으로 해싱하고 저장할 것인지, 서버단 인증과 권한 검사는 어디에서 수행할 것인지, credential stuffing과 brute force 공격에 어떻게 대응할 것인지, 로그인 실패 횟수와 rate limit은 어떻게 처리할 것인지, 사용자 역할별 접근 권한은 어떻게 분리할 것인지, 로그아웃과 토큰 폐기는 어떻게 보장할 것인지, 에러 메시지는 보안과 사용성 사이에서 어디까지 노출할 것인지 결정해야 한다.

에이전트와 일하는 방식

이런 것들은 로그인 페이지를 직접 구현해보지 않았다면 쉽게 떠올리기 어렵다. AI는 답을 낼 수 있다. 그러나 무엇을 물어봐야 하는지는 개발자가 알아야 한다. 무엇을 결정해야 하는지 모르는 사람은 AI가 채워 넣은 추론을 그대로 받아들이게 된다. 그 순간 코드는 “완성”된 것이 아니라, 보이지 않는 기술 부채를 품은 채 저장소에 편입된다.

그래서 나는 “AI의 기여도”를 독립적인 값처럼 보는 관점이 부정확하다고 느낀다. 코드 품질의 기여도를 100이라고 할 때, 과거에는 개발자의 역량 90에 LLM의 도움 10이 더해졌고, 이제는 AI가 90을 차지하고 개발자는 10만 담당한다고 말하는 사람들이 있다. 그러나 나는 그렇게 생각하지 않는다. AI가 만들어내는 90의 품질은 여전히 개발자의 역량 위에 성립한다. 사전 지식이 없고, 시스템을 이해하지 못하고, AI 사용 능력이 없으면 그 90을 끌어낼 수 없다.

오히려 격차는 더 확대될 수 있다. 예전에는 뛰어난 개발자와 평범한 개발자의 차이가 코드 작성 속도와 디버깅 능력에서 드러났다. 이제는 그 차이가 에이전트를 다루는 방식에서 드러난다. 어떤 사람은 AI에게 “로그인 만들어줘”라고 말하고, 어떤 사람은 인증 정책, 보안 요구사항, 에러 처리, 테스트 범위, 기존 아키텍처와의 통합 방식까지 정리한 뒤 작업을 맡긴다. 두 사람 모두 AI를 쓴다. 그러나 결과물은 완전히 다르다.

채용 시장 이야기도 비슷하다. 요즘 기존 개발자들의 능률이 올라 신입 개발자가 필요 없어졌고, 그래서 시장이 힘들어졌다는 말을 자주 듣는다. 물론 어느 정도 타당한 말이다. 숙련된 개발자 한 명이 에이전트를 능숙하게 활용하면 예전보다 훨씬 많은 일을 처리할 수 있다. 단순 구현만 담당하던 인력의 필요성은 줄어들 수밖에 없다.

그러나 현업자들의 말을 들어보면, 단순히 “신입을 덜 뽑는다”는 문제만은 아닌 것 같다. 뽑을 사람이 줄었다는 느낌도 강하다. 개발이 너무 쉬워진 것처럼 보이기 때문이다. 코드를 깊게 파고들지 않아도 결과물이 나온다. 직접 구현해본 적이 없어도 프로젝트를 완성할 수 있다. 그러나 그 과정에서 공학적 사고를 제대로 훈련하지 못하면, 코드가 왜 그렇게 작성되었는지 이해하지 못한다. 에러가 발생했을 때 원인을 좁히지 못하고, 구조가 충돌할 때 어디서부터 풀어야 할지 모른다. AI가 없으면 못 짜는 것이 문제가 아니다. AI가 짠 코드조차 제대로 독해하지 못하는 것이 문제다.

물론 코드 공부 자체도 훨씬 어려워졌다. 예전처럼 AI를 쓰지 않고 밑바닥부터 구현하며 로직을 이해하는 방식이 이상적이라고 말할 수는 있다. 나도 그것이 중요하다고 생각한다. 하지만 바로 앞에 내가 하지 못하는 작업을 열 배의 속도로 수행하는 도구가 있는데, 어떻게 그것을 외면할 수 있겠는가. AI를 쓰지 말자는 말은 현실적이지 않다. 이제 중요한 것은 AI를 쓰느냐 마느냐가 아니라, AI를 쓰면서도 사고를 상실하지 않는 방식이다.

내가 그나마 실천하려고 하는 방법이 있다. 작업을 시키기 전, 요구사항을 최대한 상세히 적는다. 그리고 마지막에 반드시 이런 질문을 덧붙인다.

“이 작업을 수행하기 위해 내가 사전에 결정해야 하는 것이 무엇인가? 어떠한 작업 플로우나 로직도 추측하지 말고, 모든 과정을 나에게 상세히 검토받아라.”

책임은 더 위로 올라간다

이 질문 하나만 붙여도 결과가 크게 달라진다. 프롬프트를 아무리 자세히 썼다고 생각해도, 항상 내가 놓치고 있던 부분이 튀어나온다. 아예 생각해보지 못했던 절차가 질문으로 돌아오기도 한다. 그 질문들을 다시 공부하고, 의사결정을 내려야 한다. 그래야 같은 작업을 두 번, 세 번, 열 번 다시 시키지 않는다.

작성된 코드를 이해하는 것도 중요하다. 에이전트가 만든 코드라고 해서 읽지 않아도 되는 것이 아니다. 오히려 더 면밀히 읽어야 한다. 첫 작업의 품질은 언제나 그럴듯하게 시작한다. 새 레포지토리에서 첫 기능은 깔끔하다. 그러나 그 구조를 이해하지 못한 채 후속 작업을 계속 맡기면, 어느 순간부터 스파게티 코드가 축적된다. 로직은 충돌하고, 책임은 뒤섞이고, 예외 처리는 중복되고, 같은 개념이 여러 이름으로 분산된다. 처음에는 빠르게 가는 것처럼 보이지만, 나중에는 걷잡을 수 없이 붕괴한다.

AI 시대의 개발자는 코드를 덜 쓰게 될 수 있다. 그러나 덜 생각해도 되는 것은 아니다. 오히려 더 많이 생각해야 한다. 직접 타이핑하는 시간은 줄어들지만, 무엇을 만들 것인지, 어떤 구조가 적합한지, 어떤 결정을 유예하면 안 되는지, 어떤 추론을 차단해야 하는지 판단해야 한다. 구현 노동은 줄어들지만, 설계와 검토와 책임은 더 선명해진다.

그래서 이제 개발자와 코더의 차이는 더 분명해지는 것 같다.

코더는 AI가 작성한 코드를 받는다. 개발자는 AI가 어떤 코드를 작성해야 하는지 결정한다. 코더는 작동하면 끝났다고 생각한다. 개발자는 왜 작동하는지, 어디서 깨질 수 있는지, 다음 기능이 붙었을 때 어떤 구조가 버틸 수 있는지 본다. 코더는 프롬프트를 명령문으로 쓴다. 개발자는 프롬프트를 설계 문서처럼 쓴다.

AI가 코드를 쓰는 시대가 왔다. 이 말은 더 이상 개발자가 필요 없다는 뜻이 아니다. 오히려 개발자가 무엇을 알고 있는지가 더 중요해졌다는 뜻에 가깝다. 예전에는 모르는 것을 직접 부딪히며 배웠다. 이제는 모르는 것을 AI가 너무 빨리 가려버린다. 그래서 더 의식적으로 파고들어야 한다. AI가 채워준 답을 보는 것이 아니라, AI가 무엇을 추론했는지 확인해야 한다.

결국 경쟁력은 사라진 것이 아니다. 위치가 바뀌었을 뿐이다. 코드를 얼마나 많이 치느냐에서, 어떤 코드를 작성해야 하는지 얼마나 정확히 정의하느냐로 이동했다. 그리고 이 변화는 생각보다 냉정하다. AI는 모두에게 열려 있지만, 모두가 같은 결과물을 얻지는 못한다.