🗂️ AI 기반 소프트웨어의 품질은 작업 단위(unit of work) 관리에 달려있다

AI 기반 소프트웨어 개발이라는 기술은 본질적으로 작업 단위를 올바르게 관리하는 것입니다.

제가 AI 기반 코딩이라는 새로운 기술에 익숙하지 않았을 때, 모델 자체는 상당히 지능적이었음에도 불구하고 형편없는 결과물을 얻곤 했습니다. 알고 보니 가장 큰 병목 현상은 지능이 아니라, 올바른 컨텍스트를 제공하는 것이었습니다.

Andrej Karpathy는 이 주제에 대한 제 이전 글을 언급하며, AI 기반 엔지니어링 작업을 "AI를 짧은 목줄에 묶어두는 것"이라고 표현했습니다. AI 에이전트가 그 어느 때보다 독립적으로 코드에 관여하는 프로세스에서 '짧은 목줄'은 어떤 모습일까요? 그는 힌트를 남겼습니다. "하나의 구체적인 작업에 대해 작은 단위로 작업하라"는 것입니다.

적절한 크기의 작업 단위는 컨텍스트를 존중합니다

저는 '컨텍스트 엔지니어링'이라는 용어를 좋아합니다. 이 용어는 왜 작업 단위 관리가 AI 도구로부터 더 나은 결과를 얻기 위한 가장 중요한 기술인지를 더 잘 설명할 수 있는 어휘의 폭을 넓혀주었기 때문입니다. 이는 AI가 코드를 생성하는 '캔버스'를 중심으로 논의를 이끌어 갑니다.

저는 Anthropic의 문서에 있는 시각 자료를 좋아합니다.

LLM이 생성하는 결과물은 다음 토큰 확률의 샘플입니다. 토큰을 생성할 때마다 이전 반복에서 이미 생성된 내용이 컨텍스트 창에 추가됩니다. 이 컨텍스트 창이 어떤 모습인지가 생성된 결과물의 품질에 막대한 영향을 미칩니다.

Drew Breunig는 컨텍스트에 발생할 수 있는 온갖 문제점과 이를 해결하기 위한 다양한 기술에 대해 훌륭한 글을 썼습니다.

최고의 AI 기반 개발 장인들은 AI가 한 번에(one-shot) 솔루션을 내놓도록 하기 위해 컨텍스트의 설계와 배열에 대해 자주 고민합니다. 이는 AI 코딩에 대한 과장된 광고와는 달리, 까다롭고 노력이 필요한 일입니다.

만약 좋은 결과물을 만드는 데 필요한 정보를 컨텍스트에 제공하지 않으면, AI는 환각(hallucination)을 일으키거나 여러분의 코드베이스 관행과 일치하지 않는 코드를 생성할 것입니다. 특히 소프트웨어 시스템의 통합 지점(integration points)에서 매우 취약합니다.

반면에, 컨텍스트를 너무 많은 정보로 채우면 집중력이 떨어져 결과물의 품질이 저하됩니다.

작업을 '적절한 크기(right-sized)'의 작업 단위로 나누는 것, 즉 딱 적당한 양의 세부 사항을 설명하는 것이 컨텍스트 창을 개선하고, 결과적으로 생성된 코드의 정확성과 품질을 높이는 가장 강력한 수단일 것입니다.

적절한 크기의 작업 단위는 오류 전파를 제어합니다

간단한 냅킨 계산(napkin maths)을 해볼 시간입니다.

AI 에이전트가 5%의 확률로 실수를 한다고 가정해 봅시다. 여기서 말하는 실수는 단순히 환각 현상만을 의미하는 것이 아닙니다. 문서를 찾아보는 것을 잊었거나 명세서의 세부 사항을 놓쳐서 발생하는 미묘한 실수일 수도 있습니다.

모든 코딩 워크플로우가 수렴하고 있는 에이전트 기반 다중 턴(agentic multi-turn) 워크플로우에서는 이 오류가 복리처럼 쌓입니다. 만약 어떤 작업을 구현하는 데 10턴이 걸린다면, 성공 확률은 (1 – 0.95)^10 = 59.9%에 불과합니다. 그다지 높지 않죠.

Utkarsh Kanwat도 그의 블로그 글에서 같은 주장을 했습니다. 그의 결론은 어떤 AI 에이전트라도 장기적인 작업을 수행하기 위해서는 각 단계마다 잠시 멈춰서 검증하는(pause-and-verify) 게이팅 메커니즘이 필요하다는 것이었습니다.

그렇다면 다중 턴 오류율에 대한 최신 기술 수준은 어떨까요? METR은 최근 AI 모델이 장기적인 작업에서 얼마나 발전하고 있는지를 보여주는 유명한 차트를 발표했습니다. 현재 GPT-5가 리더보드 최상위에 있으며, 약 2시간 길이의 작업을 70% 정도의 성공률로 수행할 수 있습니다. 이를 역산해보면 (2시간짜리 작업을 50턴 이상이라고 가정) 액션당 오류율이 1% 미만이라는 계산이 나옵니다.

액션당 1% 미만의 오류율이 좀 의심스럽지 않나요? 에이전트 기반 코딩 도구(제가 현재 사용하는 것은 Codex CLI입니다)를 자주 사용하는 사람으로서, 만약 GPT-5가 제 작업을 99.9%의 확률로 완벽하게 처리하기 시작한다면 제 신발이라도 먹겠습니다.

제 경험에서 비롯된 직관에 따르면, 현재 최고의 AI조차도 95%의 정확도를 보장하지 못합니다. 그렇다면 이 차이는 어디서 오는 걸까요? 실제 논문을 자세히 들여다볼 필요가 있습니다.

우리 과제는 일반적으로 에이전트에 의해 직접적인 영향을 받지 않는 한 크게 변하지 않는 환경을 사용합니다. 반면, 실제 과제는 종종 변화하는 환경의 맥락에서 발생합니다.

[…]

마찬가지로, 단 한 번의 실수에 대해 큰 페널티를 주는 과제는 거의 없습니다. 이는 부분적으로 인간 기준선 수집에 드는 예상 비용을 줄이기 위함입니다.

이것은 제가 수행하는 작업들과는 전혀 다릅니다.

METR은 현실 세계의 복잡함을 인정합니다. 그들은 자신들의 과제에 대해 '복잡도 등급(messiness rating)'을 만들었고, 과제들의 '평균 복잡도'는 16점 만점에 3.2점입니다.

METR의 정의에 따르면, 제가 주로 접하는 종류의 소프트웨어 엔지니어링 작업은 최소 7-8점 정도의 점수를 받을 것입니다. 소프트웨어 엔지니어링 프로젝트는 경로 의존적이고, 동적이며, 명확한 반사실적 상황이 없기 때문입니다. 저는 복잡도 13/16 수준에 달하는 문제들을 다뤄본 적도 있습니다.

과제 복잡도가 1점 증가하면 평균 성공률이 약 8.1% 감소합니다.

METR이 측정한 복잡도의 영향을 바탕으로 추정해보면, GPT-5는 2시간짜리 작업에 대한 성공률이 70%에서 약 40%로 떨어질 것입니다. 이것이 제가 경험한 현실과 더 부합합니다.

저는 순수한 지능만으로 이 복잡성을 해결할 수 있을지 확신할 수 없습니다. 환경의 혼란과 현실의 모호함에 대한 강건함은 근본적으로 컨텍스트를 잘 관리하는 것에 달려 있습니다. 이 문제를 해결할 마법 같은 비법을 찾기 전까지는, 오류의 복리 효과를 관리하기 위해 문제를 작업 단위로 나누고 검증 가능한 체크포인트를 두는 워크플로우가 필요하다는 것이 분명합니다.

이러한 검증 가능한 체크포인트는 인간이 이해할 수 있어야(legible) 합니다.

그렇다면, '적절한 크기'의 작업 단위란 무엇일까요?

적절한 크기의 작업 단위는 작아야 하고, 원하는 결과를 간결하게 설명해야 합니다.

작업 단위가 완료되었을 때의 원하는 결과는 인간이 이해할 수 있어야(human-legible) 합니다. 저는 그것이 이해 가능한 비즈니스 가치를 제공해야 한다고 주장합니다. 궁극적으로 소프트웨어의 사용자는 인간(또는 인간의 개념을 모델링한 시스템)이 될 것이기 때문입니다. 따라서 프로젝트를 분해하는 우아한 방법은 각 체크포인트에서 이해 가능한 비즈니스 가치를 제공하는 작은 작업 단위로 모델링하는 것입니다. 이는 LLM의 컨텍스트 창을 존중하고 오류 전파를 관리하는 데 도움이 될 것입니다.

소프트웨어 엔지니어들은 이미 비즈니스 가치를 제공하고 모든 컨텍스트와 범위 협상의 기준점 역할을 하는 작업 단위인 User Stories를 정의했습니다. 저는 이것이 큰 문제를 LLM이 한 번에 해결할 수 있는 작은 문제들로 나누는 데 좋은 출발점이라고 생각합니다. User Stories는 '작업'과 달리 소프트웨어 개발의 복잡하고 동적인 환경에서도 견고한 사용자 결과물에 집중합니다. Srihari는 소프트웨어 개발 프로세스에서 User Stories의 가치에 대해 우아하게 글을 썼으며, 복잡한 소프트웨어 구축 작업에 적합한 속성을 더 잘 이해하기 위해 그의 글을 읽어보시길 추천합니다.

제공 가능한 비즈니스 가치는 모든 이해관계자가 이해하고 협력할 수 있는 것이기도 합니다. 소프트웨어는 개발자 혼자 진공 상태에서 만드는 것이 아닙니다. 팀, 제품 소유자, 비즈니스 담당자, 사용자의 협력이 필요합니다. AI 에이전트가 다른 이해관계자들과 분리된 자체 컨텍스트 환경에서 작동한다는 사실은 효율성과 그 이점의 전달을 저해합니다. 저는 이것이 반드시 메워져야 할 중요한 격차라고 생각합니다.

오늘날 대부분의 AI 에이전트는 잘 작동하는 '계획(planning)' 모드를 가지고 있습니다. 이것은 에이전트가 궤도를 벗어나지 않도록 하는 데는 좋지만, 대부분 기술적 가치를 제공할 뿐 반드시 이해 가능한 비즈니스 결과물을 제공하지는 않습니다. 저는 계획 기능이 프로젝트를 작은 비즈니스 가치 단위로 나누는 우리의 아이디어와 상호 보완적이라고 믿습니다. 제가 제안하는 작업 단위는 기존의 계획 도구로 계획할 수 있습니다. 그리고 저는 이것이 앞서 설명한 컨텍스트 부패(context rot) 문제 때문에 큰 작업 단위를 계획하는 것보다 우수하다고 생각합니다.

물론, Agile 방법론에서 설명하는 평범한 User Stories만으로는 충분하지 않습니다. 에이전트가 스토리의 비즈니스 가치 결과물에 부합하는 올바른 컨텍스트를 수집하도록 유도할 수 있는 '그 이상의 무언가'가 동반되어야 합니다.

The quality of AI-assisted software depends on unit of work management - nilenso blog

…

nilenso blogNilenso