기능을 나열한 결과물 제작은 쉬워졌지만, 핵심은 무엇을 남기고 어떻게 재배치할 것인가다.

어떤 팀은 코드를 남기고, 어떤 팀은 의도를 남긴다. 그리고 시간이 지나면 둘 사이의 격차는 기능이 아니라 유지보수 비용에서 폭발한다. AI 시대에 이 차이는 더 극단적으로 드러난다. 누구나 코드를 빠르게 만들어낼 수 있지만, 그 코드가 왜 그렇게 만들어졌는지를 설명할 수 있는 팀은 많지 않다. 결국 문제는 생성 능력이 아니라, 의도를 얼마나 오래 유지하느냐로 이동한다.

지금 대부분의 AI 활용이 실패하는 이유도 여기에 있다. 우리는 빠르게 생성하고, 나중에 검증하는 구조를 선택했다. 처음에는 생산성이 올라간 것처럼 보인다. 코드가 빠르게 나오고 결과가 눈앞에 쌓이기 때문이다. 하지만 시간이 지나면서 이상한 일이 벌어진다. 동작은 하는데 이해가 안 되는 코드, 수정하려고 하면 더 꼬이는 구조, 결국 다시 처음부터 뜯어보는 상황이 반복된다. 생성은 빨랐지만 검증 비용은 뒤로 밀렸고, 그 청구서가 한꺼번에 날아오는 구조다.

이 문제의 중심에는 ‘맥락의 진공 상태’가 있다. 인간의 머릿속에는 왜 그렇게 설계했는지에 대한 복잡한 맥락이 존재하지만, AI는 프롬프트를 통해 전달된 일부 정보만으로 결과를 만들어낸다. 그 결과는 겉으로는 작동하지만, 내부 설계 철학이 제거된 상태다. 그래서 사람은 다시 코드를 해석하고, 의도를 역추적하는 데 시간을 쓴다. 이때부터 생산성은 증가한 것이 아니라, 미래로 미뤄졌던 비용이 현재로 회수되는 과정이 된다.

이 단절을 해결하는 방식이 바로 스케치북 접근이다. 여기서 중요한 것은 AI를 더 잘 쓰는 것이 아니라, AI의 역할을 바꾸는 것이다. 결과를 대신 만들어주는 엔진이 아니라, 사고의 연속성을 유지하는 장치로 사용하는 것이다. 설계 단계에서는 단순히 “이거 만들어줘”가 아니라, 왜 이 방식을 선택했는지, 어떤 대안을 버렸는지까지 함께 쌓는다. 구현 단계에서는 그 상태를 유지한 채 결과를 만들어내도록 제약을 걸고, 검증 단계에서는 같은 상태를 기준으로 결과를 공격하게 만든다. 이 과정에서 AI는 생성자이면서 동시에 비평가가 된다.

여기서 한 단계 더 중요해지는 개념이 있다. 맥락을 유지한다는 것은 단순히 기록하는 것이 아니라, ‘실행 가능한 상태’로 만드는 것이다. 설계를 문서로 남기는 것과, 설계를 작동시키는 것은 완전히 다른 문제다. 예를 들어 “이 버튼은 여러 번 눌러도 결과가 한 번 눌렀을 때와 동일해야 한다”는 조건을 정하는 것은 직관적으로 이해할 수 있다. 개발에서는 이를 멱등성(idempotency)이라고 부른다. 이런 원칙을 문서에 적어두는 것은 누구나 할 수 있다. 하지만 AI에게 매번 그 조건을 기준으로 결과를 생성하게 하고, 동시에 그 조건을 깨는 입력을 만들어 검증하게 만드는 것은 전혀 다른 차원의 작업이다. 전자는 참고 자료에 불과하지만, 후자는 결과를 통제하는 기준이 된다.

이렇게 되면 반복의 성격이 바뀐다. 일반적인 방식에서는 반복할수록 코드가 무너진다. 맥락이 사라진 상태에서 계속 덧붙이기 때문이다. 반대로 상태가 유지되는 구조에서는 반복할수록 정교해진다. 이전의 의도와 제약이 계속 작동하기 때문에, 새로운 결과도 같은 방향으로 수렴한다. 이때의 반복은 단순한 시도가 아니라, 맥락을 유지한 상태에서 실패를 축적하고 정제하는 과정이 된다.

결국 AI 슬롭은 코드의 품질 문제가 아니다. 맥락이 실행되지 않는 구조에서 발생하는 필연적인 결과다. 코드를 잘 만드는 팀은 빠르게 결과를 낼 수 있지만, 의도를 유지하는 팀은 시간이 지날수록 구조를 통제하게 된다. 그리고 그 차이가 쌓이면, 어느 순간부터는 따라잡을 수 없는 격차로 변한다.

AI를 스케치북으로 쓴다는 것은 아이디어를 기록하는 것이 아니다. 의도를 끝까지 작동시키는 시스템을 만드는 일이다.

Creating outputs that simply list features has become easy, but the real question is what to keep and how to reorganize it.

Some teams leave behind code, while others leave behind intent. Over time, the gap between them doesn’t show up in features, but in maintenance costs—and eventually it explodes. In the age of AI, this gap becomes even more extreme. Anyone can now generate code quickly, but far fewer can explain why that code was written the way it was. The real problem is no longer the ability to produce output, but how long intent can be preserved.

This is also why most AI adoption is quietly failing. We chose a structure where generation happens fast and validation happens later. At first, it looks like productivity has increased. Code appears quickly, and results accumulate in front of us. But over time, something strange happens. The code works, yet it’s hard to understand. Trying to modify it makes things worse. Eventually, everything has to be taken apart and rebuilt from scratch. Generation was fast, but the cost of validation was deferred—and now that bill is arriving all at once.

At the center of this problem is a “vacuum of context.” In a human mind, design begins with a dense web of reasons and assumptions. But AI produces output based only on the fragmented information that passes through the narrow channel of a prompt. The result may function on the surface, but its internal design philosophy is stripped away. So humans end up reinterpreting the code, reverse-engineering its intent. At that point, productivity hasn’t increased—it has merely shifted costs into the future, and those costs are now being collected.

The way to close this gap is the sketchbook approach. The key is not using AI more skillfully, but redefining its role. Instead of treating AI as an engine that produces results, it becomes a device that preserves the continuity of thought. In the design phase, it’s not just “build this,” but also sharing why a choice was made and which alternatives were discarded. In the implementation phase, constraints are applied so the output stays aligned with that shared state. In the validation phase, the same state is used as a reference point to attack the result. In this process, AI becomes both a generator and a critic.

At this point, a more critical concept emerges. Preserving context is not about recording it, but about turning it into an “executable state.” There is a fundamental difference between documenting a design and making that design operate. For example, it is easy to state a rule like “pressing this button multiple times should produce the same result as pressing it once.” In software, this is called idempotency. Writing this principle in a document is trivial. But making AI generate outputs that always respect this rule—and simultaneously produce test cases that attempt to break it—is an entirely different level of work. The former is just reference material; the latter becomes a controlling constraint over the outcome.

Once this structure is in place, the nature of iteration changes. In a typical workflow, repetition leads to decay. Without preserved context, each addition drifts further away from the original intent. But in a stateful structure, repetition leads to refinement. Because intent and constraints continue to operate, each new result converges in the same direction. Iteration is no longer just trial and error—it becomes a process of accumulating and refining failure within a consistent context.

Ultimately, AI slop is not a problem of code quality. It is the inevitable result of a system where context is not executable. Teams that are good at producing code can move quickly, but teams that preserve intent gain control over structure as time passes. And once that difference accumulates, it turns into a gap that can no longer be closed.

Using AI as a sketchbook is not about recording ideas. It is about building a system where intent continues to operate.

FROM BUNTGAMES.COM