.png)
AI가 코드를 쓰는 시대, 개발자는 무엇을 기억해야 하는가
기획연재 1편 : AGI가 당장 개발자를 대체할 것이라는 공포보다 중요한 것은, AI가 아직 갖지 못한 '경험의 축적'과 '판단의 책임'을 개발자가 어떻게 다룰 것인가이다.
📚 연재 안내 | 이 글은 3부작 연재의 1편입니다.
① 왜 개발자의 역할이 바뀌는가(현재 글)
② 바이브 코딩을 넘어 어떻게 일할 것인가
③ 팀에서 어떻게 운영할 것인가
AI 코딩 도구를 쓰다 보면 묘한 감각이 듭니다. 예전에는 사람이 직접 머리를 쥐어짜며 작성하던 코드가 이제는 단 몇 초 만에 화면에 나타납니다. 에러 메시지를 붙여 넣으면 원인을 짚어 주고, 테스트를 요청하면 테스트 코드까지 제안합니다. 복잡한 리팩터링도 자연어로 지시하면 꽤 그럴듯한 결과가 나옵니다.
그래서 많은 사람이 묻습니다.
“이 속도라면 개발자는 결국 대체되는 것 아닐까?”
이 질문은 자연스럽습니다. 하지만 조금 더 정확히 물어야 합니다. 개발자가 사라지는지를 묻기 전에, 먼저 봐야 할 것은 ‘AI가 무엇을 잘하게 되었고, 무엇을 아직 안정적으로 하지 못하는가’입니다.
이번 글에서는 이 근본적인 질문을 다뤄보려 합니다. 결론부터 말씀드리면, AI 시대의 개발자는 타자수에서 벗어나 시스템의 “기억(Memory)”과 “통제(Harness)”를 설계하는 사람으로 진화해야 합니다.
AGI 공포보다 먼저 봐야 할 것
'AGI(범용 인공지능)'라는 단어는 강력합니다. 마치 인간의 지식노동이 한꺼번에 무의미해질 것처럼 들립니다. 특히 코드는 AI가 가장 빠르게 정복해 나가고 있는 영역 중 하나이기에 개발자는 그 공포를 가장 먼저 체감합니다. 하지만 지금 우리가 마주한 변화는 ‘개발자의 전면 대체’라기보다 ‘개발 업무의 하위 단위가 빠르게 자동화되는 현상’에 가깝습니다.
현재의 대형 언어 모델(LLM)은 놀라운 능력을 보여주지만, 사람처럼 경험을 축적하고 실패를 해석하며 장기 목표에 맞춰 스스로 성장하는 체계를 완성한 것은 아닙니다. 2025년 발표된 'Memory-Augmented Transformer' 리뷰 연구 등 최신 학계 동향을 보면, 장기 기억과 계속학습(Continual Learning)은 여전히 AI의 큰 난제로 꼽힙니다.
AI에게 부족한 것은 단순 지식이 아니라, 특정 조직과 제품의 시간 속에서 축적되는 ‘경험’입니다.
- 어떤 구조가 왜 지금의 형태가 되었는지.
- 어떤 장애가 과거에 반복되었는지.
- 어떤 코드나 API는 절대 건드리면 안 되는지.
이런 것들은 구글링으로 얻을 수 없습니다. 숱한 실패와 시간이 쌓이면서 생기는 ‘판단의 기억’입니다.
💡 핵심 요약 · AI가 자동으로 갖지 못하는 3가지
① 조직의 과거 장애 기억 — 무엇이 언제, 왜 무너졌는지
② 건드리면 안 되는 시스템 제약 — 결제·인증처럼 잘못 손대면 위험한 영역
③ 실패 시 책임과 롤백 판단 — 무엇을 되돌리고, 그 결정을 누가 책임질지
→ 이 세 가지가 바로 뒤에서 이야기할 ‘통제(Harness)’ 설계가 필요한 이유입니다.
긴 컨텍스트(Context)가 곧 '기억'은 아니다
AI 모델의 컨텍스트 창(Context Window)이 커지면서 *"코드 저장소 전체를 다 때려 넣으면 해결되는 것 아닌가?"*라고 생각하기 쉽습니다. 하지만 실무는 다릅니다.
Anthropic은 에이전트 설계 시 많은 정보를 무분별하게 넣을수록 모델의 정보 회상 능력이 저하되는 ‘컨텍스트 부패(Context Rot)’ 문제가 나타날 수 있다고 경고합니다. 즉, 중요한 것은 더 많은 토큰을 쏟아붓는 것이 아니라, 어떤 정보를 넣고 덜어낼지 '설계'하는 일입니다.
사람 개발자는 모든 것을 기억하진 못해도 중요한 것을 구분합니다. "이 코드는 결제와 연결되어 있어. 이 테스트는 자주 깨지지만 실제 결함과는 무관해." 이런 진짜 개발자의 경험을 요구사항, 제약, 검증 기준이라는 구조화된 문서로 치환해야 합니다. 즉, 코드를 외우는 사람이 아니라 '맥락을 구조화하는 사람'이 되어야 합니다.
컨텍스트 부패 vs 구조화된 기억
이미 사라지고 있는 것은 개발자가 아니라 ‘훈련용 업무’다
가장 먼저 거센 압박을 받는 곳은 역설적이게도 주니어 개발자의 업무 영역입니다. 작은 버그 수정, 단순 CRUD 같은 반복 작업은 주니어들이 작은 실패를 겪고 시스템 감각을 키우는 필수적인 훈련 과정이었습니다. AI 코딩 도구가 이 영역을 무서운 속도로 흡수하면서, 이 시스템을 책임질 ‘진짜 전문가’로 성장하는 파이프라인도 위협받고 있습니다.
해외 커뮤니티의 화제작 AI Isn’t Replacing Developers. It’s Doing Something Worse는 이 지점을 날카롭게 꼬집습니다. AI는 당장 작동하는 '그럴싸한 코드(Plausible code)'를 뱉어냅니다. 하지만 이해가 결여된 이 코드는 훗날 상용 환경의 가장 취약한 순간에 치명적인 결함으로 터질 수 있습니다. 숱한 디버깅을 거치며 성장한 시니어들이 사라진 미래에, 이 얽힘을 누가 풀어낼 수 있을까요?
그럴싸한 코드(Plausible code)의 위험성
개발자의 역할은 ‘지시’보다 ‘통제(Harness)’에 가깝다
결국 개발자의 핵심 역량은 "프롬프트를 기가 막히게 쓰는 것"이 아닙니다.
- 무엇을 AI에게 맡길지 판단하는 것.
- 어디까지 허용할지 경계(Boundary)를 정하는 것.
- 완료를 어떻게 검증하고 실패 시 롤백할지 설계하는 것.
최근 업계에서는 이를 ‘하네스 엔지니어링(Harness Engineering)’이라 부릅니다. AI 에이전트가 예상치 못한 사고를 치지 않고 정해진 규칙(안전벨트) 내에서 동작하도록 제어하는 환경입니다.
AI에게 *"로그인 기능 개선해 줘"*라고 뭉뚱그려 말하는 대신 *"비밀번호 5회 실패 시 잠금 안내를 추가하되, 인증 API 응답 구조는 절대 변경하지 마라"*라고 지시해야 합니다. 이것이 바로 작업의 경계와 통제 환경(Harness)을 세우는 일입니다.
하네스(Harness) 엔지니어링 아키텍처
마치며: 기억을 설계할 준비가 되었는가?
우리의 일은 코드 에디터에 타이핑하는 것에서 점점 다른 곳으로 이동하고 있습니다. AI가 기억하지 못하는 것을 무엇으로 남기고, 잘못 판단할 지점을 어떻게 통제할 것인지 치열하게 고민하는 사람만이 다가오는 시대를 주도할 것입니다.
🚀 다음 글 예고
우리의 역할이 패러다임 수준에서 '기억'과 '통제(Harness)'를 설계하는 방향으로 진화하고 있다면, 실무 환경에서는 이를 매일의 코딩 프로세스에 구체적으로 어떻게 적용할 수 있을까요?
이어지는 다음 2편에서는 기분 가는 대로 대화하는 '바이브 코딩(Vibe Coding)'의 한계를 짚어보고, AI에게 명확한 기억을 심어주는 실무 방법론인 **'스펙 주도 AI 코딩(Spec-Driven AI Coding)'**에 대해 이야기해 보겠습니다.
