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

Source: Dev.to

Getting Started: “I’ll just use BMAD to move faster”

지난 몇 주 동안 BMAD 프레임워크를 개인 프로젝트에 적용해 보았고, 아직도 신선한 감각이 남아 있을 때 이 글을 남기고 싶었습니다.

시작할 때 제 기대는 아주 단순했습니다. 아이디어만 넣고 워크플로우가 안내해 주면, 코드를 빠르게 작성하면서 방향성도 더 명확하고 막다른 길도 적을 거라고 생각했죠.

그것은… 어느 정도 맞았습니다. 하지만 큰 전제가 하나 있습니다.

BMAD는 “20분 안에 코딩을 시작한다”는 설정이 아닙니다. 오히려 “코딩이 가장 어려운 부분이 되지 않도록 사전에 작업을 충분히 해두는” 접근에 가깝습니다.
프로토타입을 먼저 대충 만들고 나중에 제품을 정리하는 방식에 익숙하다면, 이 과정은 느리게 느껴질 수 있습니다. 때로는 고통스럽게 느껴질 정도로 말이죠.

첫 번째 현실 점검: 코드를 작성하기 전에 많은 시간이 필요합니다

BMAD를 처음 접하면 엔지니어가 보통 생산성(코드 배포)이라고 정의하는 방식으로 생산성을 느끼기 전에 광범위한 워크플로우를 강요한다는 점을 눈치채게 됩니다.

다음과 같은 여러 단계를 거칩니다:

• 문제 정의 (단순히 “X를 만들고 싶다”가 아니라 “어떤 고통이 존재하고, 누구를 위한 것인가?”)

  • 사용자 페르소나 정의
  • 접근 방식 브레인스토밍
  • 분야 조사

• 제약 조건 명확화 (시간, 비용, 인프라, 팀, 목표 플랫폼)

  • 이를 에픽, 스토리, 실행 계획으로 전환

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

저에게는 12~16시간 정도가 지나야 비로소 첫 번째 코드 라인이 작성되었습니다.

주말 프로젝트 모드로 생각한다면 이 숫자는 터무니없게 들릴 수 있습니다. 하지만 시간을 두고 생각해 보면 이해가 됩니다: BMAD는 프로젝트가 이미 뒤죽박죽이 된 뒤에야 하는 생각을 미리 하게 만들기 때문입니다.

그리고 공정하게 말하자면, 저는 반대로 너무 많이 해왔습니다:

1. 뭔가를 빠르게 만들기
2. 내가 잘못된 것을 만들었다는 것을 깨닫기
3. 다시 작성하기
4. 동기 상실
5. 포기하기

그래서, 이 초기 투자는 실제로 존재합니다. 그리고 바로 그게 핵심이기도 합니다.

Source: …

프레임워크는 실제로 좋다 (특히 비즈니스 사고에)

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

엔지니어가 개인 프로젝트를 만들 때 보통 다음과 같이 시작합니다:

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

BMAD는 여러분을 다음과 같은 질문으로 다시 이끕니다:

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

그 답을 이미 알고 있다고 생각하더라도, 적어보면 명확성을 강제합니다.

여기서의 가치는 마법 같은 무언가를 알려주는 것이 아니라, 여러분이 결정을 확정하도록 만든다는 점입니다.

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

“Party Mode”와 내가 컨텍스트와 크레딧을 소진한 방법

그 다음에 재미있고(그리고 고통스러운) 부분이 나옵니다: party mode.

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

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

저는 LangSearch와 Gemini 모두에 파티 모드를 실행하도록 지시하는 실수를 저질렀고, 그 조합은 제 컨텍스트 창과 사용 크레딧을 완전히 소진했습니다.

돌이켜보면 예측 가능한 일었습니다: 파티 모드는 읽고, 소스를 끌어오고, 합성한 뒤 생성하려 합니다. 즉:

• 토큰 입력이 많음
• 토큰 출력이 많음
• 그리고 도구에 따라 많은 유료 호출이 발생

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

그럼에도 매우 유용했습니다. 여러 각도를 비교할 수 있을 때 결과물이 확실히 더 좋았습니다. 다만 그만큼 비용이 들었습니다.

파티 모드를 사용할 계획이라면, 제 조언은 간단합니다:

• 의도적으로 사용하세요
• 경계(범위, 소스, 최대 깊이)를 설정하세요
• 마음대로 두면 비용이 많이 들 것이라고 가정하세요

12–16 시간 후: 첫 번째 코드 라인… 그리고 아키텍처 벽에 부딪히다

모든 설정과 워크플로우를 마친 뒤, 드디어 코드를 작성하기 시작했습니다.

그리고 거의 바로 아키텍처 실수를 저질렀다는 것을 깨달았습니다.

이 부분이 중요한 이유는, 어시스턴트에게 작업을 맡기고 “감독”만 하는 상황에서 쉽게 저지를 수 있는 실수이기 때문입니다.

저는 아키텍트에게 저비용에 집중하라고 지시했으며, 그래서 서버리스 환경, 특히 AWS Lambda‑형식 컴퓨팅을 선호하도록 했습니다. 그 다음에 NestJS를 사용하라고 했습니다.

이론적으로는 괜찮아 보이지만, 실제로는 까다롭습니다.

NestJS는 서버리스 환경에서도 실행될 수 있지만, 올바르게 설정하지 않으면 “NestJS를 그대로 넣고 Lambda에 배포”하는 식으로 바로 사용할 수 없습니다. 일반적으로 어댑터 레이어가 필요합니다(예: @vendia/serverless-express 사용 또는 유사 패턴) 혹은 서버리스 요청 처리에 더 직접적으로 맞는 프레임워크를 사용해야 합니다.

그것이 없으면 서로 맞지 않는 가정들의 혼란이 발생합니다:

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

그 결과는 예상대로 여러 곳에서 오류가 발생하고, 시스템이 실제 진전 없이 스스로를 고치려는 루프에 빠지는 상황이었습니다.

6시간 디버깅 나선(그리고 왜 그렇게 혼란스러웠는가)

나는 이를 고치기 위해 6시간 정도를 투자했다.

그 순간 가장 답답했던 점은…

증상‑수정 루프

무엇이 잘못됐는지 바로 알 수 없었다. “잘못된 import를 사용했다”와 같은 명확한 오류가 아니었다.

오히려 다음과 같은 느낌이었다:

1. 무언가가 실패한다.
2. 증상을 고친다.
3. 또 다른 무언가가 실패한다.
4. 그 수정이 또 다른 문제를 일으킨다.
5. 루프에 빠진다.

프로젝트 초기에 구조적 결정이 맞지 않아 겪어본 사람이라면 이 느낌을 알 것이다. 코드는 독립적으로는 올바른데, 환경과 가정이 잘못돼 있다.

AI‑지원 워크플로우도 여기서 이상하게 동작할 수 있다. 시스템이 도움이 되려다 보니, 지역적으로는 타당해 보이지만 근본적인 불일치를 해결하지 못하는 변경을 계속 제안한다. “합리적인” 편집을 승인하면서도 결코 수렴하지 않는 데 많은 시간을 허비하게 된다.

그리고 바로 그 일이 일어났다. 나선은 계속 돌았고, 나는 계속 생각했다. “왜 이렇게 막힌 걸까?”

전환점: 내가 해결한 것이 아니라 회고가 해결했다

무슨 일이 있었나요?

프로세스가 너무 많은 시간을 소모하고 수렴하지 못하고 있음을 발견하고 BMAD 워크플로우를 시작해 회고(retrospective) 를 진행했습니다. 그 단계가 바로 돌파구가 되었습니다.

앞으로 나아가는(가짜 진행) 움직임을 계속하기보다, 회고는 일시 정지를 강요하고 다음 질문을 던졌습니다:

• 우리가 하려는 목표는 무엇인가?
• 무엇이 우리를 가로막고 있는가?
• 어떤 가정을 했는가?
• 무엇이 변했는가?
• 어떤 결정이 반복적인 실패를 초래하고 있는가?

그 결과 설정이 올바르지 않다는 것이 명확해졌습니다. 아키텍처를 런타임 모델에 맞게 조정해야 했습니다.

다음 단계

• NestJS 설정을 조정하여 서버리스‑핸들러 모델에서 정상적으로 실행되도록 하거나, 또는
• 컴퓨트 모델을 변경(예: ECS/Fargate 위의 컨테이너 서비스, 혹은 간단한 VM)하여 목표에 맞추거나, 또는
• 서버리스와 보다 자연스럽게 맞는 프레임워크를 선택

핵심은 회고가 시스템에게 패치를 멈추고 진단을 시작하도록 강제했다는 점입니다.

“대부분의 엔지니어는 문제가 생겼을 때 개인 프로젝트에서 회고를 하지 않는다. 그냥 더 열심히 밀어붙인다.”

저도 그런 식으로 많이 밀어붙여 보았습니다. 거의 도움이 되지 않았습니다.

수정 후: 모든 것이 순조롭게 진행됐고 (“Stories”가 슈퍼 파워가 되었다)

환경을 올바르게 설정하자 경험이 완전히 달라졌습니다.

가장 큰 승리: Stories

저는 실제 스토리를 가지고 있었고, “백엔드 구축” 같은 모호한 작업이 아니었습니다.
스토리를 통해 시스템에 구현해야 할 내용을 정확히 전달할 수 있었으며, 범위가 정해지고 테스트 가능한 형태였습니다. 아이디어를 엔지니어링 작업으로 변환하는 과정이 이미 완료된 것이었습니다.

나의 새로운 역할

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

이는 “내가 모든 일을 직접 하는” 느낌과는 매우 다릅니다.

팀을 이끌어 본 적이 있다면 그 방식을 알게 될 것입니다: 모든 코드를 작성하는 것이 아니라, 진행 중인 작업이 올바른 작업인지 확인하는 것입니다.

BMAD가 제대로 하는 점: 모멘텀을 위한 인내

전체적으로 BMAD가 정말 멋지다고 생각하지만 과대평가하고 싶지는 않다. 트레이드‑오프는 명확하다:

• 설정하려면 인내가 필요합니다
• 좋은 답변을 제공해야 합니다
• 모든 것을 검토해야 합니다
• 초기 단계가 느리게 느껴지는 것을 받아들여야 합니다

마법 같은 코드 생성기처럼 다루면 짜증이 날 것이다.
생각, 문서화, 실행 구조를 앞에 두는 프로세스로 다루면 이해가 되기 시작한다.

그 초기 구간을 지나면 꽤 직관적이다.

과소평가된 기능: 모든 것이 문서에 있기 때문에 언제든지 재개할 수 있음

또 한 가지, 내가 깊이 파고들 때까지 제대로 인식하지 못했던 점은 언제든지 재개할 수 있다는 것이 얼마나 좋은가 하는 점이다.

모든 것이 문서화돼 있기 때문에 기억이나 불안정한 채팅 컨텍스트에 의존하지 않는다. 다음과 같은 산출물이 있다:

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

그래서 하루 혹은 일주일 뒤에 다시 돌아와도 다음과 같이 말할 수 있다:

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

그리고 처음부터 시작하는 느낌이 아니다.

개인 프로젝트에서는 이것이 큰 차이를 만든다. 우리 대부분은 코딩을 못해서가 아니라, 휴식 후에 컨텍스트를 재구성하는 데 한 시간을 소비하기 때문에 모멘텀이 끊긴다. BMAD는 그 부담을 줄여준다.

다른 엔지니어에게 시도하기 전에 전하고 싶은 말

저는 이것이 모든 프로젝트에 대한 정답이라고 가장하지 않을 겁니다. 빠른 스크립트를 해킹하거나 API 아이디어를 테스트하고 있다면 BMAD는 아마도 너무 무거울 수 있습니다. 하지만 실제로 배포하고 싶은 무언가를 만들고 있다면—혼자 개발하더라도—고려해 볼 가치가 있습니다.

내가 진행하면서 얻은 실용적인 교훈

• 설정에 시간을 예산으로 잡아라. 첫 시간에 바로 코드를 작성하려고 하면 워크플로와 충돌하게 됩니다.
• “파티 모드”에 주의하라. 유용하지만 컨텍스트와 크레딧을 빠르게 소모할 수 있습니다.
• 아키텍처 프롬프트를 가볍게 여기지 마라. “저비용”은 서버리스 패턴으로 이끌 수 있는데, 이는 좋을 수 있지만 프레임워크 선택과 배포 형태를 제한합니다.
• 막혔을 때 회고를 활용하라. 본능적으로 앞으로 나아가려 하지만, 더 현명한 방법은 멈춰서 원인을 진단하는 것입니다.
• 스토리는 보상이 일어나는 곳이다. 좋은 스토리를 갖추면 실행이 훨씬 기계적으로 진행됩니다.

마무리 생각

BMAD는 처음 단계가 마찰처럼 느껴지지만, 나중에 그 마찰 자체가 핵심이라는 것을 깨닫게 되는 경험 중 하나가 되었습니다.

그는 나에게 속도를 늦추고, 내가 하고 있는 일을 정의하며, 결정을 명확히 하도록 강요했습니다. 특히 파티 모드에서 몇 군데 시간을(그리고 크레딧을) 낭비했으며, 미리 발견했어야 할 아키텍처 불일치 때문에 6시간을 잃었습니다.

하지만 워크플로와 문서가 갖춰지자 놀라울 정도로 원활해졌습니다. 에픽과 스토리에서 작업을 재개하고, 요구사항을 계속 다시 쓰지 않고 구현을 이끌어 갈 수 있다는 것은 실제 생산성의 변화를 의미합니다.

BMAD를 시도한다면 인내심을 가지고 가세요. 규율을 가지고 가세요. 그리고 코딩에 들어가기 전에 생각하는 데 더 많은 시간을 할애할 것이라고 가정하세요.

이 내용이 공감된다면, 구조화된 AI 지원 워크플로에 대한 여러분의 경험은 어떠했나요? 궁금합니다.