아침 루틴이 바뀌었다
나는 오늘도 아침에 일어나서 노트북을 켠다. 밤에 돌려놓은 AI가 처리한 작업의 보고를 확인하기 위해서다. 불과 몇 달 전까지만 해도 일어나면 알고리즘 문제를 풀거나, 사둔 IT 서적을 전자책으로 열어 읽으며 머리를 깨웠을 것이다.
읽는 문서도 바뀌었다. 예전엔 TanStack 공식 문서를 읽고 작업했다면, 요즘은 Claude 문서를 읽는다. 원하는 기술 명세를 내가 작성하고, 기술의 공식 문서는 서브에이전트에게 링크를 걸어두고 검증시키는 방식으로 일한다. 문서를 읽는 주체가 나에서 에이전트로 넘어간 것이다.
프롬프트 엔지니어링에서 하네스 엔지니어링까지
AI 쪽도 많은 변화가 있었다. ChatGPT가 세상에 충격을 주면서 웹 LLM 형식의 시작은 프롬프트 엔지니어링에 불을 지폈다. "어떻게 물어봐야 좋은 답이 나오는가"를 연구하던 시대를 지나, RAG와 컨텍스트 엔지니어링으로 "무엇을 보여주고 물어볼 것인가"의 시대가 왔고, 에이전트가 도구를 쥐고 스스로 작업하기 시작하면서 이제는 하네스 엔지니어링의 시대까지 왔다.
하네스 엔지니어링은 한마디로 문서 정리다. 에이전트가 참조할 규칙, 작업 절차, 검증 기준을 문서로 깔아두는 일. 그런데 이 문서 정리조차 사람이 하는 영역인가? 그것도 아니라고 생각한다. 나는 원하는 내용을 프롬프트로 작성하고, 문서 정리는 다시 AI 에이전트에게 시키고, 그걸 정돈하는 프롬프트만 넣을 뿐이다. AI를 부리기 위한 준비 작업마저 AI가 한다.
공부를 했다는 착각
AI 성능이 올라갈수록 작업의 만족도는 매우 커진다. 그리고 그럴수록 나는 "공부를 했다는 착각"을 하게 된다.
옛날엔 하루를 꼬박 써야 완성했을 작업을 이젠 30분도 채 되지 않아 처리하곤 한다. 몇 달 전만 해도 작업을 완수하긴 해도 그 질이 좋다고 느끼긴 어려웠다. 환각도 많았고, 기능 하나를 만들기 위해 프롬프트를 몇 번이나 다시 넣었는지 모른다. 그 과정에서 나는 적어도 결과물을 의심하고, 뜯어보고, 고치는 일을 했다. 그런데 요새는 알아서 잘 만든다. 일상 작업조차 자동화하다 보니 완성도 높은 결과물이 딸깍 하고 완성되고, 나는 하루를 알차게 보낸 기분이 든다.
하지만 그날 저녁에 스스로에게 물어보면 자괴감?도 들고 정말 개발자가 왜 필요할까?라는 고민을 하게된다. 오늘 내 머리를 통과한 지식이 뭐가 있지? 결과물은 쌓였는데 내 것이 된 게 없다. 작업의 완성도와 나의 성장이 처음으로 분리된 것이다. 예전에는 결과물을 만들려면 반드시 내가 배워야 했는데, 이제는 배우지 않아도 결과물이 나온다.
나는 에이전트 오케스트레이터인가, 개발자인가. 학생인 나는 기업 차원의 유지보수나 고객 대응을 하지 않으니, AI가 일상의 모든 걸 해주는 동료처럼 느껴진다. 문제는 그 동료가 너무 유능해서, 내가 성장할 기회까지 대신 가져가고 있다는 점이다.
그럼 AI 시대에 개발자는 어떻게 해야 하는가
이 불안을 나만 느끼는 건 아닌 것 같아서, GeekNews에서 AI 시대 개발자의 역할에 대한 글들을 찾아 읽어봤다. 정리하면 대략 세 갈래의 이야기가 있었다.
1. 역할은 "코드 작성자"에서 "설계·검증자"로 이동한다
AI 코딩 시대의 개발자 역할 변화는 개발자가 코딩 실행자에서 "문제 정의, 절차 설계, AI 산출물 검증, 제품화를 담당하는 설계자"로 바뀐다고 말한다. 좋은 결과물은 한 번에 나오지 않으니, 부족한 점을 판단해 반복 개선을 주도하는 수렴 과정의 관리자가 되어야 한다는 것이다. 흥미로웠던 건 코드 생산량이 폭증할수록 문서, 테스트, 이슈 기록 같은 "맥락 보존 장치"가 핵심이 된다는 지적이었다. 내가 하고 있는 하네스 엔지니어링이 정확히 이 영역이다.
물이 빠지면 누가 발가벗고 수영했는지 드러난다 이 글은 더 냉정하다. AI는 반복 코드나 문법 오류 같은 "우발적 복잡성"만 해결할 뿐, 비즈니스 요구사항과 설계 트레이드오프라는 "본질적 복잡성"은 여전히 인간의 판단이 필요하다. 그리고 AI는 법적 책임을 질 수 없으므로, 결함이 생기면 그 코드를 리뷰하고 승인한 인간이 책임 주체가 된다. 검증자의 역할은 선택이 아니라 구조적으로 강제된다는 얘기다.
2. 다만, 검증 능력은 직접 코딩에서 나온다는 역설
여기서 뼈아픈 글이 Agentic Coding은 함정이다였다. 생성된 코드와 개발자 사이의 거리가 벌어지면 "인지 부채"가 쌓이고, 직접 작성하고 디버깅하는 마찰이 사라지면 학습 능력 자체가 약해진다는 것이다. 이 글이 말하는 "감독의 역설"이 정확히 내 상황이다 — AI를 효과적으로 감독하려면 코딩 실력이 필요한데, 그 실력은 AI에 과의존하면 약해지는 바로 그 능력이다.
특히 주니어에게 치명적이라는 대목이 찔렸다. 코드 리뷰는 학습의 절반일 뿐이고, 나머지 절반은 직접 쓰고 디버깅하며 겪는 마찰에서 온다. 나는 지금 학습의 절반을 자동화로 지워버린 채, 하루가 생산적이었다는 이유로 공부했다고 착각하고 있었던 것이다.
3. 결국 "장인이면서 빌더"
AI 시대, 가장 가치 있는 개발자는 장인이면서 빌더인 사람이라는 글이 방향을 잡아줬다. 빌더는 AI 도구로 빠르게 대규모로 만들어내는 사람이고, 장인은 축적된 전문성과 취향으로 그 결과물을 검증하고 다듬을 수 있는 사람이다. IKEA 의자가 셀프 조립으로 팔릴 수 있는 건 숙련자가 부품을 설계하고 검증했기 때문이듯, AI가 쏟아내는 코드도 그걸 판별할 수 있는 사람이 있어야 제품이 된다. 코딩 기술이 더 이상 개발자를 정의하지 않지만, 기술적 깊이 없는 빌더는 오래가지 못한다.
착각에서 벗어나기 위해
정리하고 나니 결론은 단순했다. 오케스트레이터가 되는 것 자체는 문제가 아니다. 방향은 이미 그쪽으로 정해졌다. 문제는 검증할 실력이 없는 오케스트레이터는 결국 AI 출력물에 서명만 하는 사람이 된다는 것이다.
그래서 몇 가지를 바꿔보기로 했다.
- 읽고 승인하기 전에, 왜 이렇게 짰는지 설명할 수 있는지 자문한다. 설명할 수 없으면 그건 내 코드가 아니라 내가 서명만 한 코드다.
- 핵심 로직은 처음부터 생각하고 직접 리뷰하자. 전부 직접 보겠다는 비장한 다짐은 어차피 지키지 못한다. 대신 그날 작업에서 가장 본질적인 부분 하나는 서브 에이전트를 대신 내 손으로 통과시킨다.
- 아침 루틴의 절반을 돌려놓는다. AI의 밤샘 보고를 보는 건 그대로 두되, 그 전에 예전처럼 머리를 깨우는 시간을 다시 넣는다. 보고를 읽는 것은 공부가 아니다.
AI가 일을 대신해주는 시대에 결과물은 더 이상 성장의 증거가 아니다. 이제 성장은 결과물과 별개로, 의도적으로 챙겨야 하는 것이 되었다. 오늘도 아침에 노트북을 켜고 밤새 쌓인 보고를 읽겠지만, AI를 다루는 능력만큼 개발자의 기본기 또한 중요하다는것을 다시 한번 새기게되었다.