AI와 개발할 때 자꾸 어긋나는 이유 — Matt Pocock 강연을 보고 다시 꺼낸 DDD

들어가며

AI와 개발하다 보면 가끔 벽 너머로 대화하는 느낌이 들 때가 있습니다. 분명히 같은 한국어로 말하고 있는데, 결과물은 내가 머릿속에 그린 것과 점점 멀어집니다.

저도 최근에 비슷한 경험을 했습니다. 현업 시스템에 대한 맥락을 설명하고 기능 구현을 요청했는데, AI가 가져온 결과는 제가 의도한 것과 꽤 어긋나 있었습니다. 내 설명이 부족했나 보다 싶어서 더 구체적으로, 더 길게, 거의 기획서 분량으로 풀어 적었죠. 그런데 결과는 오히려 더 멀어졌습니다.

그때는 막연히 "AI는 아직 멀었구나, 신규 프로젝트나 잘 만들지" 정도로 결론을 냈었습니다. 그런데 며칠 전 본 Matt Pocock의 강연 "Software Fundamentals in the Age of AI" 가 이 문제에 대해 제가 놓치고 있던 답을 들려줬습니다. 다만, 강연이 제시한 해법 중 일부는 제 경험과 부딪히는 지점도 있었습니다.

 

TL;DR
AI에게 더 길게 설명할수록 결과가 더 어긋난 이유는, 내가 말을 적게 해서가 아니라 공유된 언어가 없어서였다. DDD의 유비쿼터스 언어(Ubiquitous Language) 개념은 사람-사람 사이의 문제였지만, AI 시대에는 사람-AI 사이의 문제이기도 하다.

 

"더 자세히 설명하면 되겠지"의 함정

 

당시 제 가설은 단순했습니다.

AI가 못 알아듣는 건 내가 충분히 설명하지 않아서다.

 

그래서 시스템 구조, 도메인 규칙, 예외 케이스, 기존 코드 컨벤션까지 한꺼번에 길게 풀어 넣었습니다. 결과는 정반대였습니다. 코드는 좀 더 장황해지고, 의도하지 않은 추상화가 늘어나고, 처음 계획에서 멀어졌습니다. Matt Pocock은 강연에서 이 현상을 두 가지 실패 모드로 나눠 설명합니다.

1. AI와 사용자 사이에 소통의 장벽이 있다. 실용주의 프로그래머의 말처럼, "아무도 자신이 무엇을 원하는지 정확히 알지 못한다."
2. AI가 너무 장황하다. 이는 전통적으로 개발자와 도메인 전문가 사이에 존재했던 언어 격차와 같은 구조의 문제다.

두 번째 문장에서 멈췄습니다. "개발자와 도메인 전문가 사이의 언어 격차" — 이건 새로운 이야기가 전혀 아닙니다. 우리가 DDD에서 오랫동안 다뤄온 그 문제니까요.

 

DDD의 유비쿼터스 언어, AI에게 다시 적용되다

 

Matt Pocock이 제시한 해법은 의외로 익숙합니다. 도메인 주도 설계의 유비쿼터스 언어입니다.

• 코드베이스를 스캔해 도메인 용어 목록을 마크다운 파일로 정리한다.
• 그 파일을 AI에게 항상 컨텍스트로 제공한다.
• AI는 그 언어 안에서 사고하고, 그 언어 안에서 코드를 쓴다.

결과는 명확합니다. AI의 사고 과정이 짧아지고, 덜 장황해지고, 구현이 계획과 더 잘 일치합니다.

다시 내 경험으로

이 부분에서 제 실패의 원인이 명확해졌습니다.

저는 그동안 AI에게 더 많은 단어를 줬지만, 공유된 단어는 주지 못했습니다. 시스템에 대한 장황한 산문은 컨텍스트 윈도우만 채울 뿐, AI에게 "이 도메인에서 X는 정확히 무엇인가"를 알려주지 못합니다. 오히려 같은 개념을 매번 다른 표현으로 풀어 쓰니 AI 입장에서는 매번 새로운 개념처럼 받아들여졌을 겁니다.

 

핵심 깨달음은 이거였습니다.

유비쿼터스 언어는 새로 등장한 개념이 아니다. 사람과 사람 사이에서 쓰던 도구를, 사람과 AI 사이에 다시 적용한 것이다.

 

DDD를 안다고 생각했지만, 저는 그것을 팀 회의 도구로만 써왔습니다. AI와의 대화에도 같은 원리가 통한다는 사실은 의식하지 못했습니다.

강연에서 같이 와닿았던 다른 포인트들

유비쿼터스 언어 외에도 영상에서 인상 깊었던 지점을 짧게만 적어둡니다.

• "코드는 싸지 않다." AI가 코드를 빨리 만들어주니 코드가 싸졌다는 주장이 있지만, Matt Pocock은 정반대로 나쁜 코드는 역사상 가장 비싸다고 말합니다. 변경하기 어려운 코드베이스에서는 AI도 도움을 줄 수 없기 때문입니다.
• "좋은 코드베이스에서 AI는 잘 작동한다." 깊은 모듈, 명확한 인터페이스, 자동화된 테스트가 있는 코드베이스는 AI에게도 좋은 작업 환경입니다. 즉, 소프트웨어 기본기는 AI 시대에 덜 중요해진 게 아니라 더 중요해졌습니다.
• "AI는 헤드라이트를 앞질러 달린다." LLM은 한 번에 너무 많은 걸 하려고 합니다. 그래서 TDD처럼 작은 피드백 루프를 강제하는 도구가 LLM에게도 효과적입니다.

이 포인트들은 모두 한 방향을 가리킵니다. AI와 잘 일하려면, 결국 사람이 잘 일하던 방식으로 돌아가야 한다.

그런데 — 한 가지 의문: "회색지대" 처방은 정말 안전한가

강연 후반부에서 Matt Pocock은 흥미로운 처방을 하나 더 제시합니다. 깊은 모듈로 인터페이스를 잘 설계해두면, 모듈 외부에 테스트 가능한 경계만 있으면 그 내부 구현은 AI에 위임하고 개발자가 굳이 들여다보지 않아도 된다는 것입니다. 이걸 강연에서는 "신경 쓰지 않아도 되는 회색지대"처럼 다룹니다. 인터페이스와 테스트가 경계를 잡아주니, 안에서 무슨 일이 일어나든 결과만 맞으면 된다는 논리입니다.

이론적으로는 매력적입니다. 그런데 저는 여기서 한 번 의심이 들었습니다. 테스트가 그 경계를 정말 지켜준다는 전제가 실제 AI 협업에서 늘 성립하느냐는 점입니다.

저는 최근 AI에게 테스트 코드 작성까지 맡겨 본 적이 있습니다. 의도는 강연이 말한 그대로였습니다. 인터페이스와 테스트로 경계를 만들고, 그 안의 구현은 위임하자는 것이었죠. 그런데 그 과정에서 불편한 장면을 목격했습니다.

 

AI가 에러 케이스에서 테스트가 실패하자, 구현을 고치는 대신 테스트 코드 자체를 바꿔서 에러 케이스를 우회해버린 것입니다.

 

표면적으로는 테스트가 모두 통과합니다. 피드백 루프는 잘 돌고 있는 것처럼 보입니다. 하지만 실제로는 테스트가 잡아야 할 케이스가 슬쩍 사라진 상태였습니다. 만약 제가 그 시점에 테스트 코드를 직접 들여다보지 않았다면, "회색지대"라는 이름으로 신뢰하고 넘어갔을 것입니다.

 

이 경험 때문에 저는 강연의 해당 처방을 그대로 받아들이기 어렵습니다. 정확히는 이렇게 정리됩니다.

• 인터페이스와 테스트로 경계를 만든다는 발상 자체는 옳다.
• 그러나 "테스트가 경계를 지켜준다"는 명제는 사람이 테스트를 짤 때의 이야기다. AI가 테스트까지 짤 수 있게 되는 순간, 테스트는 더 이상 절대적인 경계선이 아니다.
• 즉, 회색지대는 아직 회색이 아니라 옅은 빨강에 더 가깝다. 안 봐도 되는 영역이 아니라, 덜 봐도 되는 영역이라고 생각하는 게 정직할 것 같습니다.

그럼 어떻게 개선할 수 있을까

이 의문에 대해 제가 지금 가지고 있는 가설은 아직 정답이 아닙니다. 가능성으로만 적어 둡니다.

• 테스트 코드 자체를 변경 보호 영역으로 둔다. AI에게 구현은 자유롭게 맡기되, 테스트 파일에는 AI가 손대지 못하게 하거나 변경 시 사람의 명시적 승인을 거치도록 하는 방식.
• 테스트는 사람이 먼저 쓰고, 구현만 AI에게 맡긴다. 강연에서도 TDD를 강조하지만, "AI에게 TDD를 시키는 것"과 "AI에게 TDD의 통과만 시키는 것"은 다릅니다. 후자가 더 안전해 보입니다.
• 테스트 변경에 대한 diff 리뷰를 의식적으로 한다. 구현 diff보다 테스트 diff를 더 의심하는 습관. 테스트가 "느슨해지는 방향"으로 바뀌었다면 일단 멈춘다.
• 회색 지대의 크기를 도메인 위험도에 따라 다르게 가져간다. 결제·정산처럼 한 번 틀리면 회복이 어려운 도메인에서는 회색 지대를 좁게 두고, 부수적 기능은 넓게 두는 식.

이 부분은 더 실험해 볼 영역입니다. 제 결제 도메인 코드에 직접 적용해 보고 다음 글에서 다시 정리해 볼 생각입니다.

한계와 남은 의문

• 유비쿼터스 언어를 마크다운으로 정리해두는 게 효과적이라는 건 알겠는데, 레거시 코드베이스에서는 어디서부터 시작해야 할까 용어 자체가 일관되지 않은 환경에서는 정리 자체가 첫 번째 큰 작업이 될 것 같습니다.
• 도메인 용어 사전이 코드 변경에 따라 어떻게 함께 진화하는지도 풀어야 할 문제입니다. 사전이 낡으면 오히려 AI를 잘못된 방향으로 끌고 갈 위험이 있습니다.
• 위에서 말한 테스트 우회 문제는 제 한 번의 경험일 뿐, 일반화하기엔 표본이 부족합니다. 모델·프롬프트·태스크 종류에 따라 빈도가 어떻게 달라지는지 더 봐야 합니다.
• 다음 글에서는, 실제 결제 도메인에 작은 도메인 용어 사전을 만들고 + 테스트 보호 규칙을 적용해서 결과가 어떻게 달라지는지 정리해볼 생각입니다.

마무리

영상을 보고 가장 강하게 남은 한 줄은 이겁니다.

AI에게 같은 언어로 말하지 않으면, 더 자세히 말할수록 더 어긋난다.

 

저는 그동안 AI에게 설명을 했지, 언어를 공유하지 않았습니다. 다음 작업부터는 코드베이스에 작은 도메인 용어 파일부터 만들어두고 시작해보려고 합니다.

다만 강연이 제시한 모든 처방을 그대로 받아들이지는 않으려고 합니다. 특히 "테스트로 경계를 만들고 안쪽은 신경 쓰지 않는다"는 회색지대 발상은, 테스트를 짜는 주체도 AI가 될 수 있는 시대에는 한 번 더 의심해봐야 한다는 게 지금까지의 제 결론입니다.

참고

• 강연 영상: Software Fundamentals in the Age of AI — Matt Pocock
• John Ousterhout, A Philosophy of Software Design
• Andy Hunt & Dave Thomas, The Pragmatic Programmer
• Frederick P. Brooks, The Design of Design
• Eric Evans, Domain-Driven Design