2026년 4월 6일, 디피니트 전원이 모여 다같이 개발방법론에 대해 논의하였습니다.

당시 세션에서는 성민님, 소라님, 작성자 본인까지 3명의 발표가 있었습니다.

각자의 발표내용은 달랐지만, 주제는 기존에 사용하던 Agent를 활용한 개발 방법에 대해 나눌 수 있었던 자리였습니다.

먼저 본문에 들어가기 앞서, 이런 논의가 발의 된 배경과 최근 제안되고 거론된 AI를 활용한 개발방법론에 대해 정리하겠습니다.

배경과 역사

배경

최근 Dfinite에서는 다음과 같은 문제를 직면했습니다.

• 개발자들의 대량 이탈
• 각기 다른 프로젝트들로 인한 인수인계 분량 증가
• AI와 프로덕트 팀의 분리로 인한 소통 비용 증가
• 각자의 역할군으로 인한 경직적인 작업 흐름

위 배경을 해결하기 위해 다음의 변화가 발생했습니다.

• 직무 이동, 연구팀과 프로젝트팀으로 분리
• 1명의 개발자에게 E2E 프로젝트 수행 요구
• 동적으로 프로젝트에 인원 배정 가능

변화된 역할을 현재 구성원들이 수행하기 위해서는 Agent 활용은 필수였습니다. Agent 활용은 개인에게 더 많은 업무 부담이 될 수도 있지만, 한편으로는 한 프로젝트에 대해 더 많은 권한과 역할이 수행 될 수 있습니다.

그렇다고 해서 Agent을 무조건적으로 강제하고, 통일된 규칙 없이 활용만 된다면, 효율 없고 유지보수가 불가능한 코드만 남발하게 됩니다. 프로덕션 레벨의 소프트웨어 유지를 위해서라도 팀 내부의 Agent 개발 방법론에 대한 적립은 필수적이었습니다.

Vibe coding 이라는 단어가 퍼진 이후부터 최근까지 agent를 활용한 개발 방법론에 대해 간단하게 역사를 알아보겠습니다.

역사

Vibe Coding 이라는 단어는 OpenAI 창립 멤버이자 Tesla 자율주행 AI 연구원으로 일한 안드레 카파시가 2025년 2월에 처음 만든 단어 입니다.

처음 Vibe Coding이 나온 이후로 다양한 Agent 활용 방법에 대한 연구가 있었고, 그 개발방법론에 대해서 하나의 표로 아래와 같이 정리하였습니다.

방법론 비교 매트릭스

위 매트릭스에서 Agentic SDLC는 25년도에 일론 머스크의 Macrohard사 창립 헌장 발표 내용에 맞춰 소프트웨어 개발 방법론의 종착지로 꼽힙니다.

SDLC란?

Software Development Life Cycle의 줄임말로, 소프트웨어 개발을 할 때 거치는 전체 과정을 의미합니다.

일반적으로 "요구사항 분석" -> "설계" -> "구현" -> "테스트" -> "배포" -> "운영/유지보수" 의 단계로 구성됩니다.

전통적으로는 널리 알려진 Waterfall이나 Agile, V-model 같은 방법론이 이 사이클을 관리하는데 사용되었던 것에 반해 Agentic SDLC는 Agent를 통해 파이프라인을 전체적으로 자동화 하겠다는 개념입니다.

이러한 역사와 현재 Dfinite의 상황을 배경으로 파악컨데, SDD 도입이 필요하다고 생각했습니다. 다음의 이유로 다른 개발방법론 보다는 더욱 효과적이고 적절하다고 판단했습니다.

왜 SDD인가?

Dfinite의 개별 구성원은 각자의 전문 분야가 있고 작업하는 방식이 다르기 때문에 1명의 개발자가 E2E 개발을 하기위해서는 프로젝트별 처리 방식에 대한 통일이 필요합니다. Front / Back / AI / Infra 모두 자사 소프트웨어에 활용되는 전문분야 이지만, 모두 다른 성격과 전문 지식을 포함하고 있고, 개발자들이 이전에는 해보지 않은 분야의 직무입니다. 프로젝트 처리 방법을 통일하기 위해서는 작업별 기록해야할 결과물, 소통 방식, 업무 단위등을 재정립해야 가능합니다. Agent 주도 개발방법론이 구성원들에개 소프트랜딩(Soft landing) 하고 나아가 해당 개발 방법론이 기반이되어 심화된 기술 발전을 위해서는 공통된 방식을 적립하는 시스템 설계가 필요합니다.

그 중 SDD가 가지는 성격의 장점을 나열하면 아래와 같습니다.

구체적인 목적과 쉬운 난이도

SDD에서는 Agent에게 위임하여 수행할 작업의 단위가 명확합니다. 완수 해야할 개별 기능을 목표로 지시사항과 컨텍스트를 준비하고 입력하면 됩니다.

지시사항과 컨텍스트를 담은 1개의 문서를 Spec Kit 으로 정리합니다. 해당 Spec Kit은 자연어로 작성되어 있어, 인간과 지시받을 Agent의 작업 계약서와 같이 동작합니다.

Spec Kit에는 다음 항목이 들어가야 합니다.

• 구현할 기능의 목표, 최종 모습
• 목표 달성을 위해 훼손되어서는 안되는 부분(weak harness)
• 현재 기준, 최종 목표 달성을 위해 수행할 작업에 대한 순서와 체크리스트

이와 같은 내용을 담은 Spec Kit은 자사 개발 플로우 속 레벨에 맞춰 PRD, TDD, LLD 문서로 작성됩니다. 각 문서의 성격과 목표에 대해서는 아래 "실제 적용법"에서 더 자세하게 설명드리겠습니다.

위 내용을 담은 Spec Kit을 바탕으로 Agent에게 명확하게 지시하고, 개발자간의 소통을 더욱 편하게 만들며, 프로젝트 개발 진행과정을 작업자가 정확하게 진단합니다.

Agent가 할 작업에 대해 자연어로 작성되어지고 개발자도 언제든지 읽을 수 있기에 쉬운 난이도로 판단되어 우선적 도입을 제안했습니다.

Spec Kit을 통한 소통, 결과 확인, 추적이 편함

앞선 난이도 설명 단락에서도 말씀드린 바와 같이, SDD를 수행하면 필연적으로 스펙 설명 문서(Spec Kit)가 남습니다. 스펙 설명문서 내부에는 반드시 배경과 목표가 담기게 되어 있기 때문에, 서비스 개발 이후 운영 및 유지 보수할 때에도 특정 기능이나 결정이 어떤 배경에서 이루어 졌는지 확실하게 파악할 수 있습니다. 개인 개발자가 확실하게 파악하는데 도움을 줄 뿐 아니라, 모두가 같은 양식으로 소통하기에 서로가 서로 지칭하고자 하는 항목에 대해 정확하게 이해할 수 있습니다.

이후 개발 방법론의 토대 마련

SDD보다 상위의 방법론인 ADD, TDAD, Agentic SDLC 에서는 복잡하고 고도화된 구성을 가지고 있어, 즉시 도입과 적용이 어렵습니다. 뿐만 아니라, 해당 방법론들 또한 Spec Kit기반의 결과물들을 활용하고 그 위에 엔지니어링이 가미되어 개발 과정의 일부가 자동화 되는 구조로 이루어져 있습니다.

단기적인 목표로서의 코딩을 agent로 대체한다는 목표를 완수하기위해 SDD가 부합할 뿐 아니라, 해당 방법론을 토대로 확장할 수 있는 전략도 펼칠 수 있어 SDD 도입을 채택했습니다.

실제 적용법

개발자는 프로젝트 및 작업할당을 받을 경우, 프로젝트의 기술 설계를 가장 먼저 수행하여야 합니다. 요구사항을 분석하고, 이전 프로젝트에서 참고하거나 활용할 만한 부분이 있는지, 구현해야할 필수 화면-로직-데이터는 무엇이 있는지, 그 기능을 위한 데이터나 인프라가 준비되어 있는지, 데이터와 화면을 이어주기 위한 동작 기능에 대한 정의 등이 필요합니다.

이러한 설계는 지시 받은이후 개인이 직접 전부 처리하여도 되고, 지시자에게 질문하여 구체화시켜 나가서 Spec Kit 문서에 결정된 항목이 기록되어야 합니다.

위와 같은 사용자 관점에서 정의된 요구사항을 묶어논 문서, Spec Kit를 PRD, Product Requirement Document 라고 부릅니다.

PRD 속 첨부내용을 다시한번 정리하면 아래와 같습니다.

• 프로젝트 완수 목표: ex) ~~버튼 만들어줘, ~~시각화 화면(그래프, 도표 등) 보이게 해줘, etc
• 프로젝트 참고 자료: ex) ~~위치 폴더 참고해줘, ~~원격 저장소 구조 참고해줘, ~~ 파일 코드 수정해줘, etc
• 프로젝트 금지 사항: ex) ~~데이터는 절대 변형하지 마, ~~함수 구조는 바꾸지, etc

추가로 프로젝트 지시자, 작성 일시, 목표랑 항목별 넘버링(PT-001, PR-003, etc) 등의 문서 양식을 잡고 작성해주시면 됩니다.

이렇게 작성된 PRD를 바탕으로 작업 완수를 검증하기 위한 실증적인 단서를 작성하는 문서를 TDD, Test Drive Document 라고 합니다.

가령, 특정 버튼을 클릭하면, 올바른 API 호출을 하는지, 입력값에 대하여 올바른 연산을 하는지 등을 정의하는 문서 입니다.

TDD 속 내용을 다시한번 정리하면 아래와 같습니다.

• 프로젝트 검수 기준: ex) ~~ 함수에서 값이 예상한 값인지 확인해줘, ~~함수와 ~~결과 값이 같은지 비교해줘, etc
• 프로젝트 검수 방법: ex) 너가 직접 웹으로 확인해줘, 터미널에서 로그로 확인해줘, DB 값이 변경되었는지 비교해줘, etc

위 TDD 문서를 바탕으로 테스트 코드도 작성을 권장합니다. E2E 테스트는 Playwright, 그 외의 테스트는 각 언어별 테스트 패키지 활용 권장드립니다.

Js/Ts - Vitest, Python - testing, Pytest, Go - testing, Rust - std::testing

마지막으로 위 내용들을 바탕으로 실제 작업할 사항을 정리한 LLD, Low Level Design 문서를 작성합니다. 해당 문서에는 PRD와 TDD 에서 구현된 내용을 바탕으로 실제 동작하는 프로덕션-배포 코드를 작성합니다. 문서에서는 직접적인 기술과 Sample code, diagram등을 활용해서 실제 동작할 코드를 추상적으로 표현합니다.

• 프로젝트 패키지 및 언어등의 버전별 정보: ex) Python 3.12, FastAPI 1.12, React 1.6, ...etc
• 구현 핵심 코드: ex) chatService.go의 핵심 코드 및 핵심 함수 내용, React의 핵심 Components 구성 코드 등

PRD, TDD, LLD를 CTO님이 설계한 처리 순서로 표현하면 아래와 같습니다.

flowchart LR
    A["1. PRD\n작성"] --> B["2. PRD\n검증"]
    B --> C["3. TEST\n작성"]
    C --> D["4. TEST\n검증"]
    D --> E["5. LLD\n작성"]
    E --> F["6. LLD\n검증"]
    F --> G["7. 개발\nPhase별"]
    G --> H["8. E2E\n검증"]
    H --> I["↩ 9. PRD 재작성 (보완 반영)"]
    I --> A

    style A fill:#d0e8ff,stroke:#4a90d9
    style B fill:#d0e8ff,stroke:#4a90d9
    style C fill:#c8f7c5,stroke:#27ae60
    style D fill:#c8f7c5,stroke:#27ae60
    style E fill#d0e8ff#4a90d9

위와 같은 순서로 Spec Kit 작성하시길 권장드립니다.

마치며

AI 기술의 발달로 가장 극단적인 변화를 맞은 IT 업계에서 위 방법 또한 새로운 방식 중 하나이고, 특히 개발 방법론은 개인의 지시와 주도로 이루어지기 보다는 구성원들 전체의 동의와 합의, 그리고 설계가 녹아들어야 한다고 생각합니다.

위 내용을 중심으로 다들 적극 활용하시고, 추가적으로 보완하거나 수정될 부분에 대해서는 모두 같이 공유하는 세션을 가지고 나눠지시면 감사하겠습니다.

감사합니다~ 자세한 내용은 언제든지 물어봐 주세요~~~ ^*^

발표자료 다운로드