안녕하세요. Yamaichi Information System 비즈니스 디벨롭먼트부의 masuda입니다.

현재 사내에서는 Claude Code를 활용한 시스템 개발(AI 주도 개발)에 임하고 있습니다.

이번에는 그 사례로서, 지금까지 Excel 매크로(VBA)로 관리해 왔던 수주 관리 업무를 Web 애플리케이션으로 재구축한 시도를 소개합니다.

21개 화면의 제조와 단체 테스트를 2명이서 1개월도 채 걸리지 않고 완료했습니다. 기존의 개발에서는 생각할 수 없는 속도입니다. 하지만 실제로 만들어 버린다. 이것이 AI 주도 개발의 현실입니다.

사양 주도 개발 (Spec-Driven Development)은 구현 전에 먼저 사양서를 명확한 문서로 만들어 두고, 그것을 유일한 정답으로서 코드를 생성·검증해 나가는 진행 방식입니다.

AI 주도 개발에서는 이 사양서가 AI에 대한 지시 그 자체가 되기 때문에, 사양의 정밀도가 그대로 결과물의 품질을 결정합니다.

사전에 사양서를 작성하고, 그것을 바탕으로 다음 공정을 AI가 담당하고 있습니다.

• 코드 생성
• 코드 리뷰
• 단체 테스트의 작성·실시
• E2E 테스트의 작성·실시

공정 그 자체는 기존의 개발과 다르지 않습니다. 다른 점은 코드 생성이나 테스트와 같은 실무 작업을 AI라는 우수한 부하 직원이 맡아준다는 점입니다.

매일같이 Claude Code와 대화하며 개발을 진행하는 가운데, AI 주도 개발에서 특히 중요하다고 느끼고 있는 것은 다음의 2가지입니다. (그 외에도 중요한 것은 많이 있지만, 그중에서도 영향이 크다고 느끼는 것입니다)

사양서에 모호한 표현이 있으면, Claude는 그것을 나름대로 해석하여 구현을 진행합니다. 확인을 요청해 오는 경우도 있지만, 아무것도 묻지 않고 끝까지 달려가 버리는 경우도 적지 않습니다. 게다가 완성된 코드는 언뜻 보기에는 그럴싸하게 동작하기 때문에, 리뷰 단계까지 눈치채지 못하는 경우도 있습니다.

예를 들어, 다음과 같은 방식입니다.

| 명확하게 한 지시 |
|---||
| 「등록 실패 시에는 토스트 알림으로 메시지를 표시하고, 입력값은 유지한 채 화면에 머무른다」 |
| ... |
포인트는, 「사람이 읽고 질문할 법한 부분」은 Claude도 반드시 해석이 갈린다는 것입니다. 모호한 부분을 없애는 작업은 그대로 사양서의 품질 향상으로 이어집니다.

완벽한 사양서를 준비해도 Claude가 사양대로 만들지 않을 때가 있습니다. 지시한 항목이 빠져 있거나, 기존 구현과 모순된 코드를 작성하거나, 단순히 틀리는 일도 흔히 발생합니다.

중요한 것은, 「AI는 틀린다」를 전제로 메커니즘을 만드는 것입니다. 사람이 모든 출력을 육안으로 확인하는 것은 현실적이지 않습니다. 실수를 사람의 주의력으로 막는 것이 아니라, 실수가 자동으로 검출되는 상태를 만들어 두는 것. 이것이 시스템의 품질을 좌우합니다.

Yamaichi Information System에서는 이러한 사고방식을 개발 프로세스에 녹여낸 「YIS 메서드」의 구축을 진행하고 있습니다. AI 주도 개발의 진행 방식을 절차로서 표준화하여, 사내에서 사용하며 개선을 거듭하고 있는 단계입니다.

YIS 메서드가 목표로 하는 것은 개발자가 AI 사용법에 헤매지 않고, 누가 담당하더라도 동일한 흐름으로 개발이 진행되는 상태입니다. 품질을 개인의 스킬에 의존시키지 않기 위한 메커니즘이기도 합니다.

그렇다고는 해도, 실제 개발은 AI와의 대화의 연속입니다. 아무리 절차가 잘 갖춰져 있어도, AI에게 정확한 지시를 내릴 수 있는지 여부는 마지막까지 개발자 자신에게 달려 있습니다. 설계의 의도를 언어화하는 능력, 사양의 모호함을 알아차리는 능력, AI의 출력이 올바른지를 판단하는 능력. 이러한 능력이야말로 앞으로의 엔지니어에게 요구되는 것이라고 느끼고 있습니다.

사양서나 코드를 읽히더라도, 실제로는 전체를 훑어보지 않는 경우가 자주 있습니다. 개발을 하면서도 느끼는 부분이며, Claude 자신에게 확인해 보면 "필요하다고 판단한 부분만을 읽고 있다"라는 답변이 돌아옵니다. 즉, 자료를 전달했다 = Claude가 모든 것을 파악하고 있다, 는 뜻이 아닙니다.

이를 고려하면, 정보를 한곳에 집약할수록 읽히지 않는 부분이 늘어나게 됩니다.

흔히 하는 실수가 Rules에 모든 것을 써넣는 것입니다. 규약도, 화면을 만드는 방식도, 테스트를 작성하는 방식도 전부 넣습니다. 결과적으로 분량이 방대해져서, 정작 중요한 지시 사항이 묻혀버리고 맙니다.

그 대신, 항상 지키게 하고 싶은 최소한의 규칙만을 Rules에 남기고, 작업별 절차는 Skills로 분리합니다. 이렇게 함으로써 Claude는 해당 작업에 필요한 정보만을 확실하게 전달받을 수 있습니다.

생각하는 방식은 기존의 개발과 같습니다. 설계·구현·리뷰·테스트로 공정을 나누고, 각 공정에서 필요한 자료와 작업만을 AI에게 전달합니다. 한 번의 지시로 모든 것을 시키려 하지 않는 것이 결과적으로 품질과 속도 모두로 이어집니다.

AI는 실수합니다. AI의 리뷰 지적이 빗나가거나, 문제없는 구현에 대해 수정을 요구하는 일은 실제로 발생합니다.

여기서 중요해지는 것이 바로 역할별로 에이전트(Agent)를 나누는 것입니다.

코드를 작성한 에이전트에게 자신의 코드를 리뷰하게 해도 판단은 느슨해집니다. 자신의 구현을 전제로 생각하기 때문에, 애초의 설계 오류는 알아차리지 못합니다. 사람도 마찬가지로, 자신이 작성한 코드를 스스로 리뷰해도 놓치는 것과 다를 바 없습니다.

이번 개발에서는 다음과 같이 역할을 나누고 있습니다.

포인트는 3번째 줄입니다. 리뷰에서 나온 지적이 정말로 대응해야 할 것인지를 별도의 에이전트에게 판단하게 합니다.

이를 통해 AI의 선입견에 의한 불필요한 수정을 방지하고, 정말로 고쳐야 할 부분만을 남깁니다.

하고 있는 일은 기존의 개발 체제와 같습니다. 구현자가 있고, 리뷰어가 있고, 최종적으로 판단하는 사람이 있습니다. 그 구조를 그대로 AI에 도입했을 뿐입니다.

한 대의 AI를 신뢰하는 것이 아니라, 여러 대의 AI에게 서로 다른 입장에서 판단하게 합니다. "AI는 실수한다"를 전제로 한다는 것은 바로 이런 메커니즘을 만드는 것이라고 생각합니다.

Claude Code의 진화는 정말 빠릅니다.

2026년 7월 24일에 「Claude Opus 5」가 출시되었는데, 명백히 「Claude Opus 4.8」보다 똑똑합니다. 아웃풋(Output)의 질을 보면 알 수 있습니다.

다만 「Claude Opus 5」는 말이 많습니다. 게다가 써 놓은 내용이 어렵습니다. 말투가 빙빙 돌아서 말하네요. 결론을 알기 쉽게 알려줬으면 좋겠는데 말이죠 (땀).

그런 Claude 군과 매일 대화하며 개발을 진행하고 있습니다.