개인 프로젝트에서 BMAD 프레임워크를 사용한 나의 경험 (인내 필요)

Source: Dev.to

위의 링크에 있는 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 기술 용어는 그대로 유지됩니다.)

나의 초기 기대

시작할 때, 나의 기대는 꽤 간단했습니다:

• 내 아이디어를 넣었을 것이다.
• 워크플로우가 나를 안내하도록 두었다.
• 더 나은 방향성과 적은 막다른 길로 코드를 빠르게 작성하고 있을 것이다.

그것은… 부분적으로는 사실이다. 하지만 큰 전제가 있다.

실제 상황

BMAD는 20분 안에 코딩을 시작하는 설정이 아닙니다. 더 가까운 표현은:

“코딩 부분이 가장 어려운 부분이 되지 않도록 사전에 작업을 수행한다.”

프로토타입을 먼저 급하게 만들고 나중에 제품을 고민하는 것이 익숙하다면, 이것은 느리게 느껴질 것입니다—때로는 고통스럽게 느릴 수도 있습니다.

BMAD가 먼저 하도록 강요하는 것

일반적인 엔지니어링 관점(코드 배포)에서 “생산적”이라고 느끼기 전에, BMAD는 여러분을 광범위한 워크플로우로 이끕니다:

1. 문제 정의 – 단순히 “X를 만들고 싶다”가 아니라 “어떤 고통이 존재하고, 누구를 위한 것인가?”
2. 사용자 페르소나 정의
3. 접근 방식 브레인스토밍
4. 시장·분야 조사
5. 제약 조건 명확화 (시간, 비용, 인프라, 팀, 목표 플랫폼)
6. 이를 에픽, 스토리, 실행 계획으로 전환

이 모든 것이 유용하지만, 공짜는 아닙니다.

시간 투자

저에게는 첫 번째 코드를 작성하기까지 대략 12~16시간이 걸렸습니다. “주말 프로젝트” 모드로 생각하면 터무니없는 숫자처럼 들리지만, 시간을 두고 생각해볼수록 의미가 명확해졌습니다:

• BMAD는 프로젝트가 이미 뒤죽박죽이 될 때까지 회피하던 사고를 미리 하도록 강요합니다.
• 저는 반대로 너무 많이 해봤습니다:
  • 빠르게 무언가를 만들고 → 그것이 잘못된 것임을 깨닫고 → 다시 작성하고 → 동기 상실 → 포기.

그래서 네, 이 사전 투자는 실제이며—바로 그게 핵심 포인트입니다.

비즈니스 측면에 대한 새로운 관점

제가 진심으로 좋았던 점 중 하나는 BMAD에서 제시하는 프레임워크가 특히 여러분이 만들고 있는 것의 비즈니스 측면에 대해 다른 시각을 제공한다는 것입니다.

전형적인 엔지니어‑우선 질문

• “어떤 스택을 사용하고 싶지?”
• “어떤 아키텍처가 깔끔해 보일까?”
• “어떤 클라우드 서비스가 가장 저렴할까?”

BMAD‑주도 질문

• 이것은 구체적으로 누구를 위한 것인가?
• 그들이 달성하려는 목표는 무엇인가?
• 현재 그들은 무엇을 하고 있는가?
• 왜 전환해야 할까?
• 가치를 입증할 수 있는 가장 작은 것은 무엇인가?

이 답변들을 이미 알고 있다고 생각하더라도, 글로 적어보는 과정은 명확성을 강제합니다. 가치가 마법 같은 새로운 정보를 제공하는 데 있는 것이 아니라, 결정을 확정하게 만든다는 점에 있습니다.

하지만 다시 말해, 그 명확성을 얻기 위해서는 시간을 투자해야 합니다—코딩을 하는 것이 아니라 생각하고 문서화하는 데 시간을 쓰는 것이죠.

파티 모드: 재미있고 (고통스러운)

만약 아직 사용해 보지 않았다면, 파티 모드는 기본적으로 “다양한 관점을 얻고 빠르게 많은 자료를 생성하는” 모드입니다. 폭넓은 아이디어가 필요할 때 매우 유용합니다:

• 다양한 솔루션
• 다양한 트레이드오프
• 다양한 제품 관점
• 위험 목록
• 아키텍처 옵션

나의 실수

나는 LangSearch와 Gemini를 동시에 사용하도록 파티 모드를 실행하도록 지시했습니다. 그 조합은 내 컨텍스트 창과 사용 크레딧을 완전히 소진시켰습니다.

무슨 일이 일어났는지 (뒤돌아보면 예측 가능):

• 파티 모드는 읽고, 소스를 가져오고, 통합하고, 마지막으로 생성하려고 합니다.
• → 많은 토큰 입력
• → 많은 토큰 출력
• → 도구에 따라 많은 유료 호출이 발생합니다

나는 영리하게 “모든 것을 읽지 말고, 파일에 넣고 요약해라”라고 말했지만, 실제로는 기대한 대로 작동하지 않았습니다. 워크플로우에 깊은 조사를 지시하면, 결론을 정당화할 자료를 모으기 위해 그 과정을 끝까지 수행하는 경향이 있습니다. 이는 품질에는 좋지만, 비용 관리를 소홀히 하면 비용이 크게 늘어날 수 있습니다.

파티 모드 사용 팁

1. 의도적으로 사용하세요.
2. 경계를 설정하세요 (범위, 소스, 최대 깊이).
3. 제어 없이 실행하면 비용이 많이 들 것이라고 가정하세요.

아키텍처 실수

모든 설정과 워크플로우를 마친 뒤, 드디어 코드를 작성하기 시작했습니다. 거의 즉시 저는 아키텍처 실수를 저질렀다는 것을 깨달았습니다.

이 부분은 중요한데, 보조 도구가 주도하도록 내버려 두고 “감독”만 하는 상황에서 쉽게 저지를 수 있는 실수이기 때문입니다.

무엇이 잘못됐는가

• 저는 설계자에게 저비용에 집중하라고 했고, 그래서 서버리스 환경—특히 AWS Lambda 스타일 컴퓨팅—을 택했습니다.
• 그리고 NestJS를 사용하라고 했습니다.

문서상으로는 괜찮아 보이지만 실제로는 까다롭습니다.

• NestJS는 서버리스 환경에서도 실행될 수 있지만, 올바르게 설정하지 않으면 “NestJS를 그대로 넣고 Lambda에 배포”하는 식으로 바로 동작하지 않습니다.
• 일반적으로 어댑터 레이어(예: @vendia/serverless-express 등)나 서버리스 요청 처리를 보다 직접적으로 지원하는 프레임워크가 필요합니다.

그렇지 않으면 서로 맞지 않는 가정들이 뒤섞인 혼란이 발생합니다.

• 장기 실행 서버 패턴 vs. 콜드 스타트
• 프레임워크 부트스트래핑 시간 vs. 지연 시간 기대치
• 요청 라이프사이클 차이
• 배포 패키징 및 핸들러 연결

결과

• 곳곳에서 오류가 발생했습니다.
• 시스템이 스스로를 고치려는 루프에 빠져 실제 진전이 없었습니다.

저는 엄청 많은 시간(약 6시간)을 들여 이를 고치려 애썼습니다.

가장 답답했던 점은 그 순간에 정확히 무엇이 잘못됐는지 바로 알 수 없었다는 것입니다. “잘못된 import를 사용했다”는 식의 명확한 오류가 아니라, 다음과 같은 흐름이었습니다.

1. 무언가가 실패한다.
2. 증상을 고친다.
3. 또 다른 것이 실패한다.
4. 고친 내용이 또 다른 문제를 만든다.
5. 결국 루프에 빠진다.

프로젝트 초기에 맞지 않는 아키텍처 결정을 경험해 본 적이 있다면 그 느낌을 알 것입니다. 코드 자체는 “정상”이지만, 실행 환경과 가정이 잘못된 것이죠.

교훈

AI‑보조 워크플로우는 로컬에서는 그럴듯해 보이는 변경을 계속 제안할 수 있지만, 프레임워크와 배포 모델 사이의 근본적인 불일치를 해결하지는 못합니다.

TL;DR

• BMAD는 많은 사전 사고와 문서화를 요구합니다—첫 번째 코드 라인 전에 12‑16 시간을 예상하세요.
• 그 대가로 더 명확한 결정, 더 나은 제품‑시장 적합성, 그리고 나중에 발생하는 막다른 길이 줄어듭니다.
• Party mode는 강력하지만 토큰을 많이 소모합니다; 명확한 한계를 두고 사용하세요.
• 저비용 서버리스 목표와 NestJS 같은 무거운 프레임워크를 결합할 때는 주의하세요—적절한 어댑터가 있거나 더 적합한 스택을 선택해야 합니다.

시간을 사전에 투자할 의향이 있다면 BMAD는 나중에 큰 고통을 줄일 수 있습니다. “그냥 뭔가 해보자”는 마음가짐이라면 시작이 느릴 수 있음을 준비하세요.

상황

AI가 결코 수렴하지 못하고 합리적인 편집을 계속 “승인”하는 루프에 갇혔습니다. 무한히 돌아가면서 왜 멈춰 있는지 계속 궁금했습니다.

돌파구를 만든 계기

1. 프로세스가 수렴 없이 너무 오래 걸리는 것을 발견했습니다.
2. BMAD 워크플로를 시작하고 회고(retrospective) 를 진행했습니다.

회고는 일시 중지를 강제하고 다음 질문에 대한 답을 요구했습니다:

• 우리가 하려는 일은 무엇인가?
• 무엇이 우리를 가로막고 있는가?
• 어떤 가정을 했는가?
• 무엇이 변했는가?
• 어떤 결정이 반복적인 실패를 일으키고 있는가?

통찰

회고를 통해 설정이 잘못되었다는 것이 밝혀졌습니다 – 아키텍처가 런타임 모델과 맞지 않았습니다.

확인된 옵션

• NestJS 설정을 서버리스 핸들러 모델에 맞게 올바르게 조정한다.
• 목표에 따라 컴퓨트 모델을 변경한다(예: ECS/Fargate의 컨테이너화 서비스 또는 단순 VM).
• 서버리스와 보다 자연스럽게 맞는 프레임워크를 선택한다.

핵심 포인트: 회고가 끝없는 임시 수정 작업을 멈추게 하고 실제 진단을 시작하게 했습니다.

구조화된 워크플로우(BMAD 등)가 중요한 이유

대부분의 엔지니어는 개인 프로젝트에서 문제가 생겨도 회고를 하지 않고 그냥 더 열심히 일합니다.
그렇게 열심히 일해도 별 도움이 되지 않습니다.

수정 후 달라진 점

• 스토리가 생김 – 모호한 “백엔드 구축” 항목 대신 실제로 범위가 정해지고 테스트 가능한 작업이 나타났습니다.
• 시스템에 정확히 구현할 내용을 전달할 수 있게 되었고, 아이디어를 엔지니어링 작업으로 변환하는 과정이 이미 완료되었습니다.

나의 새로운 역할

• 감독
• 결정 검토
• 코드에 대한 상식 체크
• 요청 및 변경에 대해 가끔 예/아니오 클릭
• 작업이 목표와 일치하도록 유지

이것은 “내가 모든 것을 다 한다”는 느낌과는 매우 다릅니다. 병목 현상이 “얼마나 빨리 타이핑할 수 있느냐”에서 “얼마나 잘 검토하고 방향을 잡아줄 수 있느냐”로 옮겨갑니다.

팀을 이끌어 본 적이 있다면 이 방식을 익히게 될 것입니다: 모든 코드를 직접 작성하는 것이 아니라, 올바른 작업이 수행되도록 보장하는 역할입니다.

트레이드‑오프

BMAD를 마법 코드 생성기로 취급하면 좌절감을 초래합니다.
이를 사고를 앞서 로드하는 프로세스로 취급하는 것이 타당하며, 초기 경사 이후에는 간단해집니다.

Resume‑ability: A Big Win

모든 것이 기록되어 있기 때문에 기억이나 불안정한 채팅 컨텍스트에 의존하지 않습니다. 구체적인 산출물이 있습니다:

• 페르소나
• 문제 진술
• 아키텍처 노트
• 에픽
• 스토리
• 결정 및 트레이드오프

하루 혹은 일주일 후에 다시 돌아와서 간단히 말할 수 있습니다:

• “이 에픽을 실행하세요.”
• “이 스토리를 계속하세요.”
• “다음 작업을 구현하세요.”
• “마지막 변경에 대한 회고를 진행하세요.”

시작을 처음부터 하는 느낌이 아닙니다. 개인 프로젝트의 경우, 모멘텀을 죽이는 컨텍스트 재구성 비용을 줄여줍니다.

BMAD가 적절한 경우와 그렇지 않은 경우

• 비추천: 빠른 스크립트나 일회성 API 테스트에는 너무 무겁습니다.
• 추천: 실제로 배포하고 싶은 모든 경우, 심지어 혼자 개발할 때도 적합합니다.

내 실행에서 얻은 실용적인 교훈

1. 설정에 시간을 할당하세요.

   • 첫 시간에 코드를 작성하려고 기대하면 워크플로와 충돌합니다.

2. “파티 모드”에 주의하세요.

   • 유용하지만 컨텍스트와 크레딧을 빠르게 소모할 수 있습니다.

3. 아키텍처 프롬프트를 가볍게 여기지 마세요.

   • “저비용”은 서버리스 패턴으로 유도하지만, 이는 좋을 수 있지만 프레임워크 선택과 배포 형태를 제한할 수도 있습니다.

4. 막히면 회고를 활용하세요.

   • 본능적으로 앞으로 나아가려 하지만, 더 현명한 방법은 멈추고 진단하는 것입니다.

5. 스토리는 결과가 나오는 곳입니다.

   • 좋은 스토리는 실행을 기계적이고 반복 가능한 프로세스로 전환합니다.

6. 초기의 마찰을 받아들이세요.

   • 첫 단계는 마찰처럼 느껴지지만, 그 마찰이 바로 목적입니다: 속도를 늦추고, 무엇을 하는지 정의하며, 결정을 명확히 하게 합니다.

7. 시간과 크레딧을 추적하세요.

   • 저는 몇 군데에서, 특히 파티 모드로 인해 시간(및 크레딧)을 소모했고, 초기 단계에서 발견될 수 있었던 아키텍처 불일치 때문에 6시간을 잃었습니다.

8. 문서와 워크플로가 갖춰지면 프로세스가 원활해집니다.

   • 에픽과 스토리에서 재개하고, 요구사항을 계속 다시 쓰지 않으면서 구현을 이끄는 것이 실제 생산성 변화를 가져옵니다.

최종 생각

BMAD를 시도한다면 다음을 준비하세요:

• 인내 – 설정 단계는 의도적인 사전 로드입니다.
• 규율 – 문서화와 검토 루프를 철저히 유지하세요.
• 마인드셋 – 코딩에 들어가기 전에 생각하는 데 더 많은 시간을 투자한다는 점을 기억하세요.

당신 차례

이 내용이 공감된다면, 구조화된 AI‑지원 워크플로우에 대한 여러분의 경험은 어떠했나요? 여러분의 생각을 듣고 싶습니다.