에이전틱 AI 시대에 개발자로 살아가기
목차
작년 이맘때까지만 해도 저는 AI가 코딩을 대신하는 일은 한참 멀었다고 생각했습니다. 지금은 하루의 대부분을 에이전트와 함께 일합니다. 무엇이 바뀌었는지, 그래서 개발자로서 지금 무슨 일을 하고 있는지 정리해 둡니다.
아직 멀었다고 생각했습니다
작년 중반까지 제 결론은 분명했습니다. 보조 도구 이상은 아니다. 짧은 함수 하나, 정규식 하나, 익숙하지 않은 라이브러리의 사용법 정도는 곧잘 뽑아냈습니다. 하지만 조금이라도 맥락이 필요한 일 앞에서는 어김없이 무너졌습니다. 이 프로젝트의 관례, 다른 모듈과의 관계, 이 코드가 왜 하필 이렇게 생겼는지 — 그런 걸 알아야 답할 수 있는 질문에는 늘 그럴듯한 오답이 돌아왔습니다.
더 큰 문제는 검토 비용이었습니다. 결과물을 읽고, 틀린 곳을 찾고, 고치는 시간을 합치면 그냥 제가 처음부터 쓰는 편이 빨랐습니다. 일을 줄여주지 못하는 도구는 도구가 아닙니다. 그래서 자동완성 이상으로는 기대하지 않기로 하고 한동안 잊고 지냈습니다.
뒤집히는 데는 한 주면 충분했습니다
연말에 Opus 4.5를 접하고 생각이 180도 바뀌었습니다. 과장이 아니라, 한 주 정도 만져보고 작업 방식을 통째로 갈아엎었습니다.
차이는 정확도가 조금 올라간 것이 아니었습니다. 다룰 수 있는 작업의 단위가 달라졌습니다. 파일 하나 안의 함수가 아니라 여러 파일에 걸친 변경을 한 번에 가져왔고, 스스로 빌드와 테스트를 돌려 실패 메시지를 읽고 되짚어 왔습니다. 제가 하던 짜고 → 돌려보고 → 고치는 반복을 안에서 끝내고 결과만 내놓기 시작한 것입니다.
그때부터 제 앞에 오는 것은 고쳐야 할 코드가 아니라 검토할 결과물이 됐습니다. 저에게는 이 차이가 전부였습니다.
흥미로운 건 제가 회의적이었던 이유가 틀리지 않았다는 점입니다. 맥락을 못 잡는다는 지적도, 검토 비용이 더 든다는 계산도 그때는 맞았습니다. 다만 그 전제가 1년도 안 되어 통째로 무효가 됐을 뿐입니다. 판단이 틀린 게 아니라 유통기한이 짧았던 것에 가깝습니다.
지금의 하루
지금 저는 일상 업무를 거의 전부 에이전트로 진행합니다. 하루를 돌아보면 직접 키보드로 코드를 치는 시간은 얼마 되지 않습니다. 대신 이런 일들을 합니다.
- 무엇을 만들지 정합니다. 요구사항을 제 언어로 다시 씁니다. 여기가 흐릿하면 그 뒤가 전부 흐릿해집니다.
- 어떻게 만들지 정합니다. 구조, 경계, 트레이드오프. 에이전트는 선택지를 잘 늘어놓지만 무엇을 고를지는 결국 제 몫입니다.
- 프롬프트를 씁니다. 맥락을 어디까지 줄지, 무엇을 하지 말라고 할지. 결과의 질은 여기서 절반이 결정됩니다.
- 결과를 판단합니다. 동작하는가가 아니라 이게 맞는가를 봅니다. 둘은 전혀 다른 질문입니다.
정리하면 손으로 하던 일에서 정하는 일로 무게중심이 옮겨갔습니다. 하루 중 가장 오래 붙잡고 있는 것도 코드가 아니라 결정입니다.
값이 오른 능력, 값이 내린 능력
이 변화가 개발자에게 무슨 뜻인지 자주 생각합니다. 제 경험으로는 능력의 총량이 줄어든 게 아니라 값이 재조정됐다는 쪽이 정확합니다.
| 값이 내린 것 | 값이 오른 것 |
|---|---|
| 문법과 API를 외우고 있는 것 | 무엇이 문제인지 정확히 말하는 것 |
| 보일러플레이트를 빠르게 치는 것 | 구조와 경계를 정하는 것 |
| 혼자 오래 붙잡고 파고드는 것 | 결과물이 맞는지 짧게 판별하는 것 |
| 구현 자체의 숙련도 | 틀렸을 때 알아채는 감각 |
오른쪽 열은 전부 읽고 판단하는 능력입니다. 그리고 이건 코드를 많이 써본 사람이 유리합니다. 구현을 안 해봤으면 결과물이 그럴듯한지 아닌지 구분이 안 됩니다. 역설적이게도 구현을 대신해 주는 시대에 구현 경험의 값이 오릅니다.
그래도 놓으면 안 되는 것
읽지 않고 넘긴 코드는 제 코드가 아닙니다. 에이전트가 내놓은 결과가 통과했다는 이유로 그대로 흘려보내기 시작하면, 어느 순간 관리할 수 없는 코드베이스 위에 앉아 있게 됩니다. 문제가 터졌을 때 설명할 수 없는 코드는 결국 제 책임으로 돌아옵니다.
실제로 겪은 것들을 적어두면 이렇습니다.
- 테스트가 통과했다는 말은 맞다는 말이 아닙니다. 에이전트는 자기가 만든 전제 위에서 테스트를 씁니다. 전제가 틀리면 초록불도 같이 틀립니다.
- 그럴듯함은 여전히 가장 위험한 실패 모드입니다. 예전보다 훨씬 드물어졌지만, 드물어진 만큼 방심하게 돼서 체감 위험은 크게 줄지 않았습니다.
- 모르는 영역은 여전히 못 맡깁니다. 제가 판별할 수 없는 분야의 결과물은 맞는지 알 방법이 없습니다. 결국 공부는 계속해야 합니다.
남는 생각
1년 전의 저에게 지금 상황을 설명하면 믿지 않을 것 같습니다. 그래서 요즘은 "아직 멀었다"는 판단에 유통기한을 붙여 두는 습관을 들이고 있습니다. 반년 뒤에 다시 보겠다고 적어두는 식입니다.
일은 줄지 않았습니다. 다만 남은 일이 더 어려운 쪽입니다. 무엇을 만들지 정하고, 맞는지 판단하는 일은 위임이 안 됩니다. 개인적으로는 이쪽이 훨씬 재미있습니다.
Table of Contents
- I thought it was still years away
- Changing my mind took about a week
- What a day looks like now
- What went up in value, and what went down
- What you still cannot hand over
- Where that leaves me
This time last year I was convinced that AI writing code for us was still a long way off. Today I spend most of my working hours alongside an agent. Here is what changed, and what my job as a developer actually consists of now.
I thought it was still years away
Through the middle of last year my conclusion was firm: it is an assistant, nothing more. A short function, a regular expression, the calling convention of an unfamiliar library — those it handled well enough. But anything that needed context fell apart. The conventions of this project, how a module relates to its neighbours, why a piece of code is shaped the way it is: for questions that require knowing those things, what came back was reliably a plausible wrong answer.
The bigger problem was the cost of checking. Reading the output, finding the mistakes and correcting them added up to more time than writing it myself. A tool that does not reduce the work is not a tool. So I filed it under autocomplete and stopped paying attention for a while.
Changing my mind took about a week
At the end of the year I tried Opus 4.5 and my view turned completely around. That is not a figure of speech — after roughly a week with it I tore up how I work and rebuilt it.
The difference was not a few points of accuracy. The unit of work it could handle had changed. Not a function inside one file but a change spanning several, delivered in one go, with the model running the build and the tests itself, reading the failures and going back over its own work. The write → run → fix loop I used to run by hand now finished inside, and only the result came out.
From then on what arrived in front of me was no longer code to fix but work to review. For me that difference was the whole thing.
What I find interesting is that my reasons for being sceptical were not wrong. The complaint about context and the arithmetic on review cost were both correct at the time. It is just that the premises behind them were void inside a year. Less a bad judgement than one with a short shelf life.
What a day looks like now
Nearly all of my routine work now goes through an agent. Looking back over a day, very little of it was spent typing code. It goes into these instead.
- Deciding what to build. Restating the requirement in my own words. If that is vague, everything downstream of it is vague.
- Deciding how to build it. Structure, boundaries, trade-offs. An agent is good at laying out the options; which one to take is still mine.
- Writing the prompt. How much context to give, and what to rule out. Half the quality of the result is decided here.
- Judging the result. Not does it work but is it right. Those are entirely different questions.
The centre of gravity moved from doing to deciding. The thing I spend longest on in a day is no longer code; it is a decision.
What went up in value, and what went down
I think often about what this means for a developer. In my experience it is not that the total amount of skill required went down — it is that the prices were reset.
| Worth less | Worth more |
|---|---|
| Having the syntax and the APIs memorised | Saying precisely what the problem is |
| Typing boilerplate quickly | Deciding structure and boundaries |
| Grinding at something alone for hours | Telling quickly whether a result is right |
| Fluency at implementation itself | Noticing when something is off |
The right-hand column is all reading and judging, and it favours people who have written a lot of code. If you have never implemented it, you cannot tell whether the output merely looks right. Paradoxically, in an era that implements for you, implementation experience is worth more.
What you still cannot hand over
Code you waved through without reading is not your code. Start letting output past because it passed, and at some point you are sitting on a codebase you cannot manage. When something breaks, code you cannot explain still comes back to you.
Concretely, this is what I have run into.
- The tests passing does not mean it is correct. An agent writes tests on top of the assumptions it made. If those are wrong, the green tick is wrong with them.
- Plausibility is still the most dangerous failure mode. It happens far less often than it used to, and being rarer is exactly what makes you drop your guard — so the risk in practice has not fallen nearly as much as the frequency.
- You still cannot delegate what you do not understand. In a field I cannot evaluate, I have no way to know whether the output is right. So the studying does not stop.
Where that leaves me
If I described today to myself a year ago, I do not think I would have believed it. So lately I have taken to putting an expiry date on any conclusion that starts "not yet" — a note to look again in six months.
The work has not shrunk. What is left of it is simply the harder part. Deciding what to build, and judging whether it is right, are the things that cannot be handed off. Personally, I find that far more interesting.