AI는 버그가 있는 코드를 작성하지 않습니다 — 당신의 워크플로우가 작성할 뿐입니다

개발자들로부터 끊임없이 들려오는 불만이 하나 있습니다:

_"AI가 코드를 작성했지만, 나는 그것을 디버깅하는 데 몇 시간을 허비했다."

저는 제 프로젝트에서 AI를 집중적으로 사용해 왔습니다. 그리고 솔직히 말해서 — 저는 이 경험에 공감하지 못합니다. 제가 사용하는 AI가 마법 같아서가 아니라, 버그는 거의 항상 두 가지 중 하나로 거슬러 올라간다는 점을 발견했기 때문입니다. 그 중 어느 것도 AI의 문제는 아닙니다.

문제 1 — 구현 계획 (Implementation Plan)

제가 AI 에이전트(AI agent)에게 모호한 지시를 내리면, 모호한 코드가 돌아옵니다. 그것은 버그가 아닙니다. 수학적인 결과입니다.

만약 제가 이렇게 말한다면:

_"인증 시스템(authentication system)을 만들어줘"

저는 제 데이터베이스 구조, 세션 처리(session handling), 토큰 전략(token strategy), 그리고 에러 응답(error responses)에 대해 임의로 가정하는 일반적인 코드를 받게 될 것입니다. 그 가정들 중 일부는 틀릴 것입니다. 저는 어떤 것이 틀렸는지 파악하는 데 한 시간을 보낼 것입니다.

만약 제가 이렇게 말한다면:

_"Laravel Sanctum을 사용하여 토큰 기반 인증 시스템을 구축해줘. Users 테이블은 이미 존재하며 다음과 같은 컬럼들을 가지고 있어. 토큰은 personal_access_tokens에 저장돼. 로그인은 Bearer 토큰을 반환해. 로그인 실패 시에는 이 JSON 구조와 함께 401을 반환해. 세션 기반 인증(session-based auth)은 필요 없어."

결과물은 정밀합니다. 예외 케이스(edge cases)들이 처리되어 있습니다. 디버깅할 것이 거의 없습니다.

AI가 더 똑똑해진 것이 아닙니다. 제가 더 나은 계획을 제공한 것입니다.

이 부분이 대부분의 개발자가 건너뛰는 지점입니다. 그들은 채팅창을 열고, 대략적인 아이디어를 입력한 다음, 결과물이 머릿속에 그려둔 것(하지만 글로 적지는 않은 것)과 일치하지 않을 때 도구를 탓합니다.

AI 에이전트는 독심술사가 아닙니다. 그것은 당신이 제공하는 컨텍스트(context)를 매우 빠르게 실행하는 도구일 뿐입니다. 출력물의 품질은 거의 전적으로 입력물의 품질에 따른 함수입니다.

문제 2 — 세션 길이 (Session Length)

이 문제는 덜 언급되지만 똑같이 중요합니다.

AI 모델에는 컨텍스트 윈도우(context window)가 있습니다. 대화가 길어질수록, 대화의 초기 부분은 압축되거나 사실상 소실됩니다. 모델은 세션 시작 시점에 확립된 내용에 완전히 접근하지 못한 채 결정을 내리기 시작합니다.

실제로 이는 다음과 같은 모습으로 나타납니다:

• 40개의 메시지 이전에 정의한 제약 조건(constraint)과 모순되는 함수
• 프로젝트 초반의 명명 규칙(naming convention)과 일치하지 않는 변수 이름
• 코드베이스(codebase)의 다른 곳에서 이미 처리된 내용을 재구현하는 로직

코드가 잘못된 것은 AI가 부족해서가 아닙니다. AI가 안정적으로 유지할 수 있는 것보다 더 많은 문맥(context)을 보유하도록 요구했기 때문입니다.

해결책은 간단합니다. 문맥(context)이 무거워지면 새로운 세션(session)을 시작하세요.

새 세션을 시작하기 전에, 지금까지 무엇이 구축되었는지, 어떤 규칙(convention)이 사용되고 있는지, 무엇이 이미 처리되었는지, 그리고 다음 작업이 무엇인지 요약하세요. 그리고 그것을 첫 번째 메시지로 붙여넣으세요. 이는 작업을 잃는 것이 아니라, AI에게 어지러운 기억 대신 깨끗한 작업 기억(working memory)을 제공하는 것입니다.

이렇게 하지 않고 불일치(inconsistency)를 겪는 개발자들은 AI를 탓합니다. 세션을 잘 관리하는 개발자들은 그러한 불일치를 거의 겪지 않습니다.

AI가 실제로 비난받아야 할 지점

솔직히 말씀드리자면, 당신의 계획이 아무리 훌륭하더라도 AI가 진정으로 버그를 유발하는 경우가 있습니다.

복잡하게 상호 의존적인 비즈니스 로직(business logic)이 그중 하나입니다. 서로에게 명확하지 않은 방식으로 영향을 미치는 다섯 개의 시스템이 있다면, AI는 가끔 미묘하게 틀린 확신에 찬 가정을 내릴 것입니다. AI는 자신이 추측하고 있다는 사실을 말해주지 않습니다. 그저 틀릴 뿐입니다.

대규모의 기존 코드베이스(codebase)도 또 다른 사례입니다. AI에게 전체를 다 보지 못한 코드를 확장하도록 요청하면 불일치가 발생합니다. AI는 부분적인 그림을 가지고 작업하고 있는 것이기 때문입니다.

이러한 사례들은 존재하며 실재합니다. 하지만 제 경험상, 이는 개발자들이 제기하는 디버깅(debugging) 불만 사항의 약 10~20% 정도에 불과합니다. 나머지 80%는 계획(planning) 문제이거나 세션 관리(session management) 문제이며, 이 두 가지 모두 전적으로 개발자의 통제 범위 안에 있습니다.

"하지만 실제 개발은 복잡한 작업입니다"

타당한 반론이며, 저도 들어본 적이 있습니다.

그 논거는 이렇습니다. 단순한 작업은 계획하기 쉽지만, 실제 세계의 개발은 복잡하게 상호 의존적인 시스템을 포함한다는 것입니다. 바로 그 지점에서 AI가 무너지는 것이며, 아무리 계획을 잘 세워도 이를 해결할 수 없다는 것이죠.

저는 부분적으로 동의합니다. 하지만 그에 대한 답변은 "그러므로 AI는 복잡한 작업을 처리할 수 없다"가 아닙니다. 정답은 다음과 같습니다: 복잡한 작업은 그저 잘 정의된 여러 개의 작은 작업들이 쌓여 있는 것뿐입니다.

실수는 복잡성을 하나의 거대한 지시사항으로 취급하는 데 있습니다:

"근태, 휴가, 공제 및 법적 준수 사항을 포함하는 멀티 테넌트 (multi-tenant) 급여 엔진을 구축해줘"

이것은 작업 (task)이 아닙니다. 이것은 프로젝트 (project)입니다. 이것을 단 한 번의 세션 (session)에 AI에게 던져주고 깔끔한 결과물을 기대하는 것은 워크플로우 (workflow)의 문제가 아니라, 기대치의 문제입니다.

이를 분해해 보십시오:

세션 1 — 인증 시 테넌트 데이터베이스 전환
세션 2 — 직원 모델 및 관계 설정
세션 3 — 근태 계산 로직
...

각 세션은 새로운 컨텍스트 (context)를 부여받습니다. 각 작업은 구체적입니다. 범위 (scope)가 명확하기 때문에 세션당 AI의 출력물은 깔끔합니다.

복잡성이 사라지는 것이 아니라, 당신이 그것을 관리하는 것입니다. 그것이 실제 기술입니다. 복잡한 시스템을 잘 정의된 범위의 조각들로 분해하고, 적절한 컨텍스트와 함께 AI에게 전달하는 것은 하나의 거대한 프롬프트 (prompt)를 타이핑하는 것보다 더 어렵습니다. 또한 이것이 어떤 개발자는 훌륭한 결과를 얻고, 다른 개발자는 그렇지 못한 이유이기도 합니다.

복잡한 작업은 이 논거를 깨뜨리지 않습니다. 오히려 증명합니다.

내가 실제로 하는 일

사소하지 않은 작업을 수행하기 전에, 나는 다음 사항들을 작성합니다:

• 이미 존재하는 것은 무엇이며 무엇을 하는가
• 내가 무엇을 왜 구축하고 있는가
• 관련된 데이터 구조 (data structures)
• 이미 알고 있는 엣지 케이스 (edge cases)
• 출력물이 어떤 모습이어야 하는가

그런 다음, 이것을 컨텍스트로 사용하여 새로운 세션을 시작합니다.

복잡한 작업에 대해 세션이 길어져서 아마도 20~30번의 대화를 넘어갈 때쯤이면, 요약본과 함께 새로운 세션을 시작합니다.

이 워크플로우는 기본적으로 저에게 있어 "AI가 망가진 코드를 작성했다"는 문제를 제거해 주었습니다. 제가 다른 사람들보다 AI를 더 잘 사용해서가 아니라, AI를 지름길로 취급하는 것을 멈추고 적절한 브리핑 (brief)이 필요한 주니어 개발자 (junior developer)처럼 취급하기 시작했기 때문입니다.

모호한 작업이 주어진 주니어 개발자는 모호한 결과물을 만들어낼 것입니다. 하지만 명확한 사양 (spec), 기존 컨텍스트, 그리고 정의된 제약 조건 (constraints)이 주어진 동일한 주니어 개발자는 사용 가능한 결과물을 만들어낼 것입니다.

AI는 주니어 개발자입니다. 브리프 (brief)를 작성하는 것은 당신의 몫입니다.

저는 실제 프로젝트 이면에 있는 실질적인 결정들에 대해 글을 씁니다. 도움이 된다면 팔로우해 주세요.