【SDD×speckit×Azure】 AI 주도 개발의 도박화를 막아라! 신입이 AI의 약점을 AI로 보완하는 앱을 만든 모든 기록

1. 서론: 편리하지만 두려운 「AI 개발의 이면」에 도전하다

최근 AI가 코드를 작성해 주는 「AI 주도 개발 (AI-Driven Development)」이 큰 트렌드가 되고 있습니다.

엔지니어가 아니더라도 폭속으로 무언가를 만들어낼 수 있는, 꿈 같은 시대가 찾아왔습니다.

하지만 실제로 해보면 한 가지 현실에 직면하게 됩니다.

**「AI의 그때그때의 해석에 따라, 나오는 코드의 품질이 달라진다」**는 점입니다.

어떨 때는 완벽하지만, 어떨 때는 보안 대책이 통째로 빠져 있기도 합니다...

이래서는 어렵게 얻은 편리한 개발도 마치 「도박」처럼 되어버리고 맙니다.

「이 품질의 편차를 어떻게든 막아서, 누구나 안심하고 안전하게 개발을 즐길 수 있는 구조를 만들 수 없을까?」

그렇게 생각하여, 이번 해커톤에서 「보안 리뷰 자동화 앱」 개발에 도전했습니다. 하지만 저는 앱 개발 3회차 신입입니다.

1회차: 연수에서 VSCode의 채팅 기능을 더듬더듬 사용해 보았다. -
2회차: 사양서 (spec 파일)로부터 기능을 구현할 수 있는지 시도해 보았다. -
3회차 (이번): 지금까지의 반성을 살려, 진심으로 AI와 병행해 보았다. -

지식도 경험도 부족한 제가 일상 업무를 수행하면서, 단 5일 만에 3가지 주요 기능을 가진 앱을 형태를 갖출 수 있었던 이유는 무엇일까요? 본 블로그에서는 Azure와 AI를 아군으로 삼은 리얼한 개발 기법과 감동을 소개합니다.

2. 배경과 과제: 사양 주도 개발 (SDD)에 잠재된 「품질의 편차」와 「보이지 않는 벽」

제가 이번에 채택한 것은 사양서를 읽게 하여 AI가 코딩하게 하는 **「SDD (사양 주도 개발, Specification-Driven Development)」**라는 기법입니다. 최근에는 프롬프트를 던져 AI에게 코드를 쓰게 하는 **「바이브 코딩 (Vibe Coding)」**이라는 용어도 유행하고 있지만, SDD는 그것과는 다릅니다.

SDD의 최대 강점은 **「사전에 확실한 사양서를 작성함으로써, AI와 인간 사이의 사양 이미지 괴리를 없앨 수 있다는 점」**에 있습니다. 서로의 인식이 어긋나지 않기에 개발의 「재작업 (rework)」이 최소한이 되었고, 덕분에 처음으로 혼자 앱을 만드는 저라도 일주일이 채 되지 않아 형태를 만들 수 있었습니다.

그 문제는 바로, **「자신이 모르는 보안 대책은 애초에 사양서에 어떻게 써야 할지 판단할 수 없다」**는 점입니다. 바이브 코딩보다 정확하게 만들 수 있는 SDD라 할지라도, 사양서에 쓸 수 없는 이상 코드의 안전 측면은 **「AI의 그때그때의 변덕스러운 해석」**에 통째로 맡길 수밖에 없습니다.

그 결과, 보안 기재가 누락됨으로써 AI의 출력에 편차가 생겨, **「어떤 화면에서는 AI가 센스를 발휘해 대책을 세워두었는데, 다른 화면에서는 통째로 빠져 있다」**거나 **「기능을 추가했더니 이전에 있던 보안 코드가 멋대로 다시 쓰여져 사라져 있었다」**와 같은 품질의 편차가 발생하게 되는 것입니다.

게다가 여기에는 AI 개발 특유의 무서운 특징이 두 가지 있습니다.

① 기능은 「돌려보면 알 수 있지만」, 보안은 「보이지 않는다」

기능의 버그는 돌려보면 알아챌 수 있지만, 보안은 뒷면이 텅 비어 있어도 겉보기에는 정상적으로 작동합니다. 그렇기 때문에 지식이 없으면 놓치고 있다는 사실조차 깨닫지 못합니다. -
② 인간의 육안 리뷰가 AI의 물량을 따라가지 못한다

AI는 1초 만에 대량의 코드를 쏟아내지만, 그것을 인간이 한 줄씩 육안으로 리뷰하는 것은 막대한 시간과 노력을 소모하게 되어 현실적이지 않습니다.

「모르니까 사양서에 쓸 수 없다. 하지만 작동하니까 위험을 눈치챌 수 없고, 물량이 너무 많아서 체크도 할 수 없다...」 이래서는 어렵게 얻은 폭속 개발도 도박처럼 되어버리고 맙니다.

3. 해결책: 전문 지식은 AI로 보완한다! 외부 기준 (OWASP)을 가진 AI에게 리뷰를 맡기면 된다

AI의 해석이 흔들리지 않도록 사양서를 아주 꼼꼼하게 만드는 기법도 있지만, 전문 지식이 없는 저에게는 그 사양서를 만드는 것 자체가 높은 장벽이었습니다. 그렇다면, **「부족한 전문 지식은 세계적인 보안 기준 (OWASP)을 망라한 AI로 보완하여, 자동 리뷰를 시키면 된다!」**라고 관점을 바꾸어 보았습니다.

물론 최종적인 판단은 인간이 수행해야 하지만, 개발 초기 단계에서 「명백한 안티 패턴 (anti-pattern)」을 자동 검지해 주는 파트너가 있다면, 보안 전문 지식에 자신이 없는 사람이라도 안심하고 안전하게 개발하는 즐거움을 체감할 수 있습니다. 이 관점이 이번 개발의 큰 원동력이 되었습니다.

앱 사용법은 매우 간단합니다.

작성한 소스 코드의 GitHub 리포지토리 (Repository) URL을 붙여넣기만 하면, OWASP 기준에 따른 리뷰 결과가 친절하게 돌아오는 방식입니다.

🎬 실제 앱의 구동 모습은 이쪽!

🎥

개발한 앱의 소개 영상

※ GitHub 리포지토리 (Repository) URL을 입력하고, AI로부터 OWASP 기준의 리뷰가 돌아오는 일련의 과정을 영상으로 소개합니다.

4. 아키텍처: Azure 미경험자인 저도 배포까지 실현

앱의 전체적인 모습은 다음과 같습니다.

저는 앱 개발 경험은 있었지만, 인프라 구축부터 개발까지를 혼자서 진행하는 것은 처음이었습니다. 게다가 Azure 서비스를 이용하는 것도 처음이었습니다. 이런 저였지만, AI와 지속적으로 대화(Wall-hitting)한 결과, AI를 탑재한 웹 앱을 구축할 수 있었습니다. AI의 답변에 확신이 서지 않을 때는 동기나 선배 등 유식자 분들에게 더블 체크를 요청하여, 확실한 정보임을 확인한 후 채택했습니다.

또한 이번에는 Spec Kit을 채택했습니다. 이는 GitHub 공식 오픈 소스인 사양 주도 개발 (SDD, Specification-Driven Development) 도구입니다. 사양을 정의하는 spec.md와 태스크를 관리하는 task.md를 출력하여, 개발의 확실한 나침반이 되어 주었습니다.

5. 구현의 노하우: 모크(Mock) 선행 절차와 두 가지 AI의 구분 사용

한정된 시간 속에서 최대의 퍼포먼스를 내기 위해, 개발 절차와 도구 사용법을 고안했습니다.

🎨 사양은 글자가 아니라 「화면 모크 (HTML)」로 전달

글자로만 된 사양서에서 완성형을 상상하는 것은 AI에게도 인간에게도 매우 어렵고, 인식이 어긋나기 쉽습니다. 그래서 이번에는 우선 AI와 대화하며 **화면 모크 (HTML)**를 완전히 만들어 두고, 브라우저에서 실제 동작을 확인할 수 있는 접근 방식을 취했습니다.

여기에는 큰 장점이 있었습니다.

• 순식간에 「공통 인식」을 확보: HTML을 직접 AI에게 보여줌으로써 화면 구조를 정확하게 이해하게 되어, 지시의 어긋남이 급격히 줄었습니다.
• 「재작업 (Rework)」이 제로가 되고 통일성 확보: 처음에 AI와 대화하여 화면 모크 (HTML)를 통째로 출력하게 해두었기 때문에, 나중에 파트별 디자인이나 전체적인 통일감을 「어떻게 맞추지…」라며 머리를 싸맬 필요가 처음부터 없었습니다. 백엔드 처리를 만든 후의 수정은 힘들지만, 화면 디자인만이라면 수정은 순식간입니다.

💡 GitHub Copilot과 KnowNarrator의 현명한 구분 사용

이번 개발의 큰 특징은 VS Code의 GitHub Copilot과 사내 AI 도구인 KnowNarrator를 구분해서 사용한 점입니다.

이번에는 **「구상을 다듬고 프롬프트 (Prompt)를 키워나가는 KnowNarrator」**와 **「실제 코드를 거침없이 작성하는 GitHub Copilot」**이라는 형태로 역할을 명확히 나누어 사용했습니다.

• 사양이나 프롬프트를 심도 있게 다듬기 (KnowNarrator)
  구상 단계부터 「계속 하나의 채팅」으로 대화를 이어갔습니다. 모든 문맥을 여기에 쌓아둠으로써, AI가 앱의 배경이나 의도를 세밀하게 파악할 수 있게 되었고, 빗나간 출력이 급격히 줄었습니다. 또한 남은 태스크도 관리하게 하여 함께 병행했습니다.
• 실제 코딩을 맡기기 (GitHub Copilot)
  KnowNarrator에서 다듬은 프롬프트만을 투입했습니다. Copilot 측은 일일이 승인하지 않는 Autopilot 설정으로 해두었기 때문에, 일상적인 업무를 수행하는 이면에 코드 구현이나 에러 해결을 자동으로 진행해 주었습니다.

이러한 구분 사용을 철저히 한 덕분에, Copilot 측에서의 지루한 시행착오가 사라졌고, 불필요한 상호작용과 토큰 (Token) 소비를 최소한으로 억제할 수 있었습니다.

6. 개발을 구한 메커니즘: 채팅 강제 종료로부터의 「순식간에 이어지는 인수인계 극」

사내 환경 덕분에 이용 한도인 토큰 (Token) 소비는 신경 쓰지 않아도 되었지만, 계속 하나의 채팅 화면에서 AI를 너무 혹사시킨 결과, 마침내 그 순간이 찾아왔습니다.

「하나의 채팅 화면이 한 번에 기억할 수 있는 한계 (입력 토큰의 상한)」에 도달하여, 갑자기 그 채팅의 대화를 이어갈 수 없게 된 것입니다.

의지하던 파트너의 기억이 끊겨 당황스러웠지만, 여기서 도움이 된 것이 speckit의 메커니즘이었습니다. 새로운 채팅 화면을 열고, 우선 AI에게 이렇게 물어보았습니다.

💬

나: "speckit으로 앱 개발을 하고 있습니다. 이전 채팅으로부터 현황을 인계받기 위해 필요한 정보가 있을까요?"

🤖 AI: "그렇다면, spec.md(사양서)와 task.md(태스크 관리 파일)를 보여주세요."

수중에 있던 그 파일들을 새로운 채팅창에 툭 던져 공유하는 것만으로, 처음부터 다시 설명하는 듯한 시간과 수고를 들일 필요 없이, 순식간에 개요와 현황을 인계받을 수 있었습니다.

돌이켜보면, 이 인계가 매끄럽게 진행될 수 있었던 이유는 두 가지가 있습니다.

브레인스토밍(Wall-hitting)을 했던 KnowNarrator에게 사양서(spec.md)를 작성하게 했기 때문

하나의 채팅에서 심도 있게 브레인스토밍을 마친 마지막에, KnowNarrator 스스로 사양서(spec.md나 task.md)를 깔끔하게 출력하게 하여, 그것을 그대로 VS Code에 붙여넣었습니다. 그렇기에 제가 의도했던 바와 배경이 처음부터 모두 망라·집약된 완벽한 파일이 수중에 있었고, 최고의 인계 자료가 되었습니다. -
「Spec Kit」이라는 프레임워크를 채택했기 때문

프레임워크를 따르고 있었기에, 실제 코드를 아직 한 줄도 보지 않은 새로운 AI라 할지라도 "어느 파일을 보면 상황을 파악할 수 있을지"를 즉시 이해할 수 있었던 것이라고 생각합니다.

7. 임팩트: 해커톤에서 전달하고 싶은 「3가지 성과」

이번 챌린지를 통해, 해커톤에서 요구되는 평가 기준에 대해 다음과 같은 답을 내놓았다고 생각합니다.

📈 ① 비즈니스 임팩트: 「앱」과 「노하우」라는 두 가지 가치

만든 앱 자체의 실용성과, 개발 프로세스를 통해 축적된 지식(Knowledge)이라는 두 가지 측면에서 조직의 생산성에 기여할 수 있는 가치를 보여주었다고 생각합니다.

작성한 앱 자체의 가치 (리뷰 비용의 절감)

보안 전문 지식이 적은 멤버라도 스스로 초기 단계의 안전한 코드를 작성할 수 있게 됩니다. 지금까지 선배들이 코드를 육안으로 확인하며 리뷰에 할애했던 시간을 대폭 절감할 수 있으며, 팀 전체의 개발 속도를 끌어올릴 수 있습니다. -
개발 과정에서 축적된 노하우·깨달음의 가치 (재현성 있는 수법)

"먼저 화면 목업(Mock)을 만든 뒤 AI와 공유하는 것의 중요성"이나 "두 AI의 용도 구분"과 같은 살아있는 지식이 축적되었습니다. 인프라 구축이 처음인 신입이라도 단 며칠 만에 AI 탑재 앱을 형상화할 수 있다는, 재현성 높은 개발 수법을 실천할 수 있었습니다.

🎯 ② 접근의 유효성: 외부 기준을 결합하여 AI로 보완하기

이번 개발의 가장 큰 핵심은, **「AI 주도 개발(AI-driven development)이 안고 있는 약점(품질의 편차)을 다른 AI를 사용하여 해결·보완한다」**는 메커니즘 그 자체에 있습니다. 다만, 단순히 다른 AI에게 리뷰를 맡기기만 한다면 그 리뷰 자체의 품질도 편차가 생길 수 있습니다.

그래서 이번에는, **「LLM(GPT-4o)에 외부의 명확한 보안 가이드라인인 OWASP를 결합한다」**는 접근 방식을 채택했습니다.

객관적인 기준(OWASP)을 결합하는 유효성

세계적인 보안 표준인 OWASP의 가이드라인을 명확한 판단 축으로 AI에게 의식시킴으로써, 리뷰 결과 자체의 편차를 최소화했습니다. AI 주도 개발의 편리함을 유지하면서도, 신뢰성 높은 세이프티 넷(Safety net)으로서 기능하게 만들 수 있었습니다. -
「왜 위험한가」를 알 수 있는 교육적 효과

너무 엄격해서 에러의 의미를 알기 어려운 기존의 정적 분석 도구와 달리, AI가 자연어로 친절하게 조언해 줍니다. 개발자가 이유를 납득하면서 보안 고려 사항의 누락을 깨닫고, 배우면서 개발을 진행할 수 있다는 교육적인 강점도 있습니다.

🛠️ ③ 완성도·실현성: 초학자의 벽을 넘은 기능 구현과 배포

이번 개발에서는 실제 업무에서도 운용할 수 있는 현실적인 퀄리티와 실제 동작 상태까지 프로덕트를 완성했습니다.

목업의 100% 유용을 통한 프런트엔드의 높은 완성도

처음에 확정한 디자인의 HTML을 본 구현에 그대로 유용할 수 있었기 때문에, 단기간의 개발임에도 불구하고 외관과 조작감이 매우 높은 퀄리티의 결과물로 완성할 수 있었습니다. -
초학자에게 진입 장벽이 높은 기능의 구현과 Azure로의 배포

혼자서 인프라를 구축하는 것은 처음이었지만, 초보자에게는 비교적 진입 장벽이 높은 **"Entra ID를 통한 인증 기능"**을 확실히 포함시켰고, 나아가 **"LLM (GPT-4o)을 탑재한 앱"**으로서 실제 Azure 환경으로 배포 (Deploy) 하여 문제없이 작동하는 상태까지 만들어낼 수 있었습니다.

8. 마치며: AI는 단순한 도구가 아니라, 믿음직한 파트너다

AI는 단순히 명령을 듣고 코드를 작성하는 도구가 아니라, 우리의 구상을 함께 키워나가는 최고의 파트너라고 느꼈습니다. 전문 지식이 부족했던 제가 일상 업무를 병행하며 혼자서 앱 개발을 이 정도까지 완수할 수 있었던 것은, AI의 힘과 그것을 안심하고 테스트할 수 있는 Azure 환경이 있었기 때문입니다.

이 블로그가 앞으로 앱 개발에 도전해보고 싶은 분들이나, AI 주도 개발 (AI-driven development)이 과연 어떨지 고민하고 계신 분들에게 참고가 된다면 기쁘겠습니다.

끝까지 읽어주셔서 감사합니다!

Discussion