Agents write code, but they don't remember
Code generation is solved, but memory isn't. Here's an argument for why the SDLC is inverting with intent becoming the spine and code becoming a layer you drill into, explaining what teams lose every time an agent's reasoning disappears.
개요 #
코드를 빠르게 만들어내는 일은 거의 끝난 문제가 됐다. 이제 발목을 잡는 건 코드 자체가 아니라, 그 코드가 왜 그렇게 만들어졌는지에 대한 기억이다. AI 에이전트는 한 시간 동안 수많은 판단을 내리며 기능을 완성하지만, 세션이 끝나는 순간 그 판단의 근거는 통째로 증발한다. 남는 건 거대한 diff 한 덩어리와 "내가 뭘 시켰더라" 하는 흐릿한 기억뿐이다.
Lizzie Siegle은 Google의 새 SDLC 논문을 다룬 Addy Osmani의 글을 출발점 삼아, 소프트웨어 개발 생명주기(SDLC)가 코드 중심에서 의도(intent) 중심으로 뒤집히고 있다고 주장한다. 핵심은 단순하다. 에이전트는 빨라졌으니, 이제 그 작업에 기억을 붙여줄 차례라는 것이다.
20년짜리 릴레이 경주가 압축됐다 #
지난 20년간 SDLC는 릴레이 경주에 가까웠다. 한 사람이 티켓을 쓰고, 다른 사람이 설계하고, 또 누군가 만들고, 마지막에 리뷰가 붙는다. 단계마다 고유한 도구와 산출물, 회의가 따라붙었다.
AI 에이전트가 등장하면서 이 과정은 고르지 않게 압축됐다. Addy Osmani의 정리가 이 지점을 잘 짚는다. 구현에 걸리던 시간은 몇 주에서 몇 시간으로 줄었지만, 요구사항 정의·아키텍처·검증은 여전히 느리다. 판단이 필요한 일이기 때문이다. 생성은 사실상 풀렸고, 남은 건 명세(specification)와 검증(verification), 그리고 둘을 묶어주는 시스템이다.
80%의 문제는 사실 맥락의 문제다 #
Addy는 이 한계를 "80% 문제"라고 부른다. 에이전트는 기능의 첫 80%를 빠르게 만들지만, 마지막 20%(엣지 케이스, 시스템 사이의 이음새)는 모델이 보통 갖고 있지 않은 맥락을 요구한다.
Siegle은 여기서 조금 다르게 본다. 마지막 20%가 어려운 건 코드가 어려워서만이 아니다. 첫 80%를 만들어낸 추론이 이미 사라졌기 때문이다. 에이전트가 무언가를 만들 때 "왜"는 세션과 함께 날아간다.
상황을 그려보자. 에이전트에게 기능 하나를 함께 출시하자고 부탁한다. 한 달 뒤, 동료가 호출을 받는다. 큰 고객이 throttling에 걸렸다는 것이다. 코드를 열어보지만 커밋이 답해줄 수 없는 질문만 잔뜩 쌓인다. 엣지 케이스 판단은 맞았나? 중간에 계획이 바뀌었나? 그 모든 결정을 내린 에이전트는 — 당신이 옆에서 추론 과정을 지켜봤기에 근거가 있다는 걸 알지만 — 이미 사라지고 없다.
Photo by cottonbro studio on Pexels
그래서 동료는 할 수 있는 유일한 일을 한다. 이미 신중하게 내려진 결정을 거꾸로 추적하는 것이다. 한 시간짜리 에이전트 추론을 diff 하나로 압축하면 결론만 남고 그 논거는 버려진다. 에이전트의 판단은 옳았지만, 그중 무엇도 살아남지 못했다. 우리는 코드를 생성하는 데는 아주 능숙해졌지만, 그 코드가 어떻게 지금에 이르렀는지 기억하는 데는 형편없어졌다.
검증에 필요한 건 결과가 아니라 경로다 #
Addy의 글에서 가장 쓸모 있는 구분은 두 종류의 평가다. 결과 평가(output evaluation)는 최종 결과물이 맞는지를 묻는다. 경로 평가(trajectory evaluation)는 그 결과에 도달한 과정 — 도구 호출과 추론 — 이 타당했는지를 묻는다. 둘 다 필요하다. 검증 단계를 건너뛰고도 맞아 보이는 답은, 차라리 대놓고 망가진 답보다 위험하다.
이건 박스 스코어와 경기 영상의 차이다. 박스 스코어는 결과를 알려주지만, 영상은 그 결과가 실력으로 얻은 것인지 운이었는지를 보여준다. 문제는 대부분의 개발 도구가 박스 스코어만 남긴다는 데 있다.
우리가 여전히 쓰는 PR 큐는 사람 속도의 산출물에 맞춰 설계됐다. diff와 설명, 그리고 승인 한 번. 경로는 버려지고 결과만 표시된다. 그사이 에이전트는 물량을 쏟아낸다. 개발자에게 남는 선택지는 둘 다 신통치 않다. 모든 diff를 일일이 리뷰하며 병목이 되거나, 눈 감고 출시한 뒤 잘되길 비는 것이다. diff는 정작 중요한 질문에 답하지 못한다. 우리가 맞는 것을 맞는 방식으로 만들었는가? 그 답은 에이전트가 밟은 경로에 있고, 지금 대부분의 팀에게 그 경로는 어디에도 저장되지 않는다.
SDLC는 죽지 않는다, 뒤집힌다 #
Siegle은 SDLC가 사라질 거라고 보지 않는다. 뒤집힐 거라고 본다.
지금은 코드가 산출물이고 의도는 아무도 다시 열어보지 않는 티켓이다. 이 관계가 뒤집힌다. 의도가 척추가 되고, 코드는 필요할 때 파고들어 가는 한 겹의 레이어가 된다. 작업의 단위는 더 이상 PR이 아니라, 요청부터 결정·경로·작동 증거까지 이어지는 전체 호(arc)다.
이것이 Siegle이 몸담은 Entire의 베팅이다. 추론 사슬을 포착해 git 안의 코드에 붙이고, 벽처럼 쌓인 diff 대신 바로 그 추론을 리뷰 대상으로 만드는 것이다. 마지막 20%를 닫는 방법도 여기에 있다. 더 똑똑한 모델을 기다리는 게 아니라, 어려운 부분을 어렵게 만드는 그 맥락을 애초에 잃지 않는 것이다.
소프트웨어를 만드는 미래는 "에이전트가 코드를 더 빨리 짠다"가 아니다. 그건 이미 와 있다(글에 인용된 수치로는 새 코드의 41%가 AI 생성물이다). 그리고 그것만으로는 충분하지 않다. 진짜 미래는 세션이 끝난 뒤에도 에이전트가 한 작업을 이해하고, 이어가고, 신뢰할 수 있는 팀이다. 에이전트는 빨라졌다. 이제 그 작업에 기억을 줄 차례는 우리다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.