지난 20년 동안 소프트웨어 개발 생명주기 (SDLC)는 계주 경기와 같았습니다 (저는 계주를 정말 좋아합니다!). 팀이 참여하여, 한 사람이 티켓을 작성하면 다른 사람이 설계하고, 누군가는 빌드하며, 또 다른 사람이 리뷰를 진행했습니다. 각 인수인계 단계마다 고유한 도구, 산출물, 그리고 회의가 존재했습니다.

AI 에이전트의 부상과 함께, 그 프로세스는 불균형하게 압축되었습니다.

Addy Osmani는 Google의 새로운 SDLC 논문에 대한 그의 글(제 생각에는 전문을 읽어볼 가치가 있습니다)에서 이 점을 매우 잘 지적했습니다. 구현 시간은 몇 주에서 몇 시간으로 단축되지만, 요구사항, 아키텍처, 그리고 검증은 판단(judgment)이 필요한 작업이기 때문에 여전히 느립니다.

생성(Generation)은 거의 해결되었으며, 남은 것은 사양 정의(specification), 검증(verification), 그리고 이들을 하나로 묶어주는 시스템들입니다.

이 블로그 포스트에서는 이러한 시스템들이 어떻게 컨텍스트(context)를 계속 놓치고 있는지 살펴보겠습니다.

80% 문제는 컨텍스트 문제이다

Addy는 이 한계를 "80% 문제"라고 부릅니다. 에이전트는 기능의 첫 80%를 빠르게 처리하지만, 마지막 20%(즉, 엣지 케이스(edge cases)와 시스템 간의 경계)는 모델이 통상적으로 가지고 있지 않은 컨텍스트를 여전히 필요로 합니다.

저는 이를 약간 다르게 표현하고 싶습니다. 그 마지막 20%가 어려운 이유는 단순히 코드가 어렵기 때문만이 아니라, 첫 80%를 만들어낸 추론(reasoning)이 이미 사라져 버렸기 때문입니다. 에이전트가 무언가를 구축할 때, 세션이 종료되면 **이유(why)**가 증발해 버리며, 개발자/빌더들에게는 거대한 디프(diff)와 자신이 무엇을 요청했는지에 대한 모호한 기억만을 남깁니다. 에이전트가 엣지 케이스에 대해 올바른 결정을 내렸을까요? 중간에 계획이 바뀌었을까요?

우리는 코드를 생성하는 데는 매우 능숙해졌지만, 코드가 어떻게 그 상태에 도달했는지 기억하는 데는 매우 서툴러졌습니다. 이로 인해 가장 어려운 마지막 20%는, 코드를 생성한 컨텍스트도 전혀 모르는 채 자신이 작성하지 않은 코드를 디버깅하는 누군가에 의해 처리되고 있습니다.

검증에는 출력물뿐만 아니라 궤적(trajectory)이 필요하다

Addy의 포스트에서 가장 유용한 구분은 두 가지 종류의 평가(evaluation) 사이의 차이입니다. 출력 평가(Output evaluation)는 최종 결과가 올바른지를 묻습니다. 궤적 평가(Trajectory evaluation)는 그것이 거쳐온 경로(즉, 도구 호출(tool calls) 및 추론(reasoning))가 타당했는지를 묻습니다. 당신은 이 두 가지를 모두 가져야 합니다. 올바르게 보이지만 검증 과정을 건너뛴 답변은 명백히 망가진 답변보다 더 위험합니다.

이는 박스 스코어(box score)와 경기 영상(game film)의 차이와 같습니다. 박스 스코어는 결과만을 알려주지만, 영상은 그 결과가 실력으로 얻은 것인지 아니면 운이었는지를 알려줍니다. 우리가 사용하는 대부분의 개발자 도구는 박스 스코어만을 유지합니다. 우리 모두가 여전히 사용하는 PR(Pull Request) 큐는 diff, 설명, 그리고 승인(thumbs-up)을 포함하여 인간의 속도에 맞춘 출력을 위해 구축되었습니다. 경로를 버린 채 출력만을 보여주는 동시에, 에이전트들은 엄청난 양을 배포합니다. 이는 개발자들에게 그리 좋지 않은 두 가지 선택지를 제공합니다: 모든 diff를 검토하여 병목 현상(bottleneck)이 되거나, 눈을 감고 배포하며 요행을 바라는 것입니다.

diff는 정말 중요한 질문에 답할 수 없습니다: 우리가 옳은 것을 옳은 방식으로 만들었는가?
그 답은 에이전트가 거쳐온 경로에 존재하지만, 현재 대부분의 팀에게 그 경로는 어디에도 존재하지 않습니다.

다음 단계는 어디로 향하는가

저는 소프트웨어 개발 생명주기(SDLC)가 사라질 것이라고 믿지 않습니다. 대신 역전될 것이라고 생각합니다.

오늘날 코드는 결과물(artifact)이며, 의도(intent)는 아무도 다시 열어보지 않는 티켓입니다. 의도가 중추(spine)가 되고 코드가 그 안을 파고들어 확인하는 하나의 계층으로 변함에 따라 이 구조는 뒤집힐 것입니다. 작업 단위는 더 이상 PR이 아닙니다. 요청, 결정, 경로, 그리고 그것이 작동한다는 증거를 포함한 전체 아크(arc)입니다.

그것이 바로 우리가 Entire에서 걸고 있는 도박입니다. 추론 체인(reasoning chain)을 캡처하여 git의 코드에 부착하고, 거대한 diff의 벽이 아닌 그것을 검토하게 만드는 것입니다. 또한 이것이 마지막 20%를 해결하는 방법이기도 합니다. 더 똑똑한 모델을 기다리는 것이 아니라, 어려운 부분을 어렵게 만드는 그 맥락(context)을 결코 놓치지 않음으로써 말입니다.

소프트웨어를 구축하는 미래는 "에이전트가 코드를 더 빠르게 작성한다"가 아닙니다. 그것은 이미 실현되었습니다 (본문 수치에 따르면 새로운 코드의 41%가 AI에 의해 생성되었습니다). 그리고 그것만으로는 충분하지 않습니다. 미래는 세션이 종료된 후에도 에이전트가 수행한 작업을 이해하고, 이어서 진행하며, 신뢰할 수 있는 팀의 모습입니다.

에이전트의 속도는 빨라졌습니다. 이제는 우리가 그 작업에 기억(memory)을 부여할 차례입니다.