3개월 전, 회사에 하나의 제안을 했습니다.

저 혼자 제품의 기획부터 개발, QA, 배포까지 다 해보고 싶습니다.

PM도 없이, 디자이너도 없이, QA도 없이. Back-end engineer였던 제가 제품의 A to Z를 담당하겠다는 것이었습니다. 회사는 이 제안을 받아들였고, 저는 지금 AI Product Engineer라는 새로운 방식으로 일하고 있습니다.

이 글에서는 왜 이런 전환을 했는지, 실제로 어떻게 일하는지, 그리고 무엇이 잘 되었고 무엇이 어려웠는지를 솔직하게 공유합니다.

Why I Made the Switch

Background: 제품 출시 속도에 대한 답답함

저는 항상 어떻게 하면 제품 출시를 더 빠르게 할 수 있을까 고민해왔습니다.

평소에 Back-end Engineer로 일하면서 한가지 한계점을 느꼈던 것이 있는데 내가 Back-end 서버 기능을 아무리 빠르게 만든다 해도 제품 출시가 빨라지지 않다는 것입니다. 소프트웨어 제품의 전체 주기에서 BE는 일부분이기 때문입니다.

그래서 이런 의식의 흐름이 있었습니다:

"제품 출시 속도를 빠르게 할 수 있는 방법은 무엇이 있을까?"
"내가 Back-end를 빠르게 개발하는 것만으로는 출시를 빠르게 할 수 없다"
"그러면 Full-stack engineer로서 FE+BE를 빠르게 만들면 되지 않을까?"

이러한 생각을 해오던 차에 2024년 말부터 새로운 기회가 보이기 시작했습니다.

Discovery: AI Coding Tool이 바꾼 가능성

2024년 말부터 2025년 초, AI Coding Tool(Cursor, Claude Code 등)의 성능이 급격히 발전하는 것을 목격했습니다. 이것은 Anthropic, OpenAI, Google 등의 기업에서 내놓는 LLM에 기인한 것입니다. 체감상 거의 한 주 단위로 성능이 좋아지고 있었습니다.

올해 초(2025년 초) 회사를 잠깐 쉬는 동안 React, Next.js를 공부하면서 개인 사이드 프로젝트와 블로그를 만들었습니다. 처음에는 FE 기술에 대해 공부했던 것은 순전히 내가 Full-stack engineer로 일할 수 있는지 확인해보고 싶었던 것이 컸습니다. 그리고 이 과정에서 AI와 함께 Front-end 코드를 작성해봤는데, AI가 FE 코드를 꽤 잘 작성한다는 것을 확인하게 되었습니다.

기존에도 주로 서버 기능 구현을 위해 Java나 Python 코드를 AI와 함께 개발해왔지만 화면 영역에 대한 기능 구현을 AI와 본격적으로 해본 것은 이번이 처음이었습니다.

여기서 한 가지 생각을 하게 됩니다:

BE는 내가, FE는 AI → Full-stack으로 일할 수 있겠다

비록 개인 블로그와 사이드 프로젝트를 해본 것이었지만 여기서 저는 약간의 자신감을 얻게 되었고 이것을 회사에 적용해볼 수 있을지 고민하게 됩니다.

Experiment: Full-stack Engineer로 첫 시도

회사에 Full-stack engineer 전환을 요청했고, 대표와 팀 리드가 동의했습니다. 쉬운 백로그부터 시작해서 몇 개의 기능을 성공적으로 개발하고 출시했습니다.

이 과정이 꽤 즐거웠고, Production level에서 Full-stack engineer로 일할 수 있다는 자신감도 생겼습니다.

Insight: Product Engineer 개념 발견

동시에 다른 한 줄기의 생각이 있었습니다.

평소에 LLM 기반 AI 기술 발전에 관심이 많아서 관련 커뮤니티를 챙겨보고 있었는데, 거기서 Product Engineer로 일하는 사람들을 발견했습니다. 나와 크게 다르지 않은 사람들이었고, 다른 점은 단순히 Full-stack engineer를 넘어서서 Product 전반에 걸쳐 기여하는 방식이었습니다.

여기에 깊은 감명을 받았습니다. Product Engineer는 AI 기술을 극한으로 활용하기 때문에, 이 분야를 계속 공부하면 AI를 실제 업무에 적용하여 성과를 내는 가장 첨단의 감각을 유지할 수 있다고 생각했습니다.

핵심 통찰은 이것이었습니다:

AI를 극한으로 활용하면 한 사람이 AI Agent 팀을 지휘하며 제품 전체를 만들 수 있다

기존 분업 구조는 유지하되, 지휘자는 한 명. 이것이 가능한 시대가 온 것입니다. 제 고민의 출발점이었던 좀 더 빠른 제품 출시를 위해서도 이 새로운 일하는 방식을 테스트 해보고 싶었습니다.

Decision: AI Product Engineer로 일하기

저는 Full-stack engineer 경험과 Product Engineer 개념을 결합하여, AI Product Engineer라는 방식으로 일하기로 결정했습니다.

회사에 이 방향으로 일하고 싶다고 제안했고, 승인을 받았습니다. 스타트업이라 효율적인 방식에 열려 있었고, Agile 방식으로 작게 시작해서 점진적으로 확대하기로 했습니다.

How I Work as an AI Product Engineer

BMAD-METHOD: AI 중심의 Agile Framework

저는 BMAD-METHOD라는 AI 중심의 Agile 프레임워크를 사용합니다. BMAD-METHOD(Breakthrough Method for Agile AI-Driven Development)는 오픈소스로 공개된 AI 협업 프레임워크입니다.

우리가 챗GPT나 Claude에게 단순히 "이런 앱 만들어줘"라고 말하면 결과물이 엉성한 경우가 많습니다. AI도 사람처럼 구체적인 기획서와 맥락(Context)이 주어져야 제 실력을 발휘하기 때문입니다.

아무것도 없는 상태에서 단순히 AI를 사용하기 보다는 강력한 Instruction을 제공해주는 프레임워크를 사용하면 AI의 성능을 더 극대화 시킬 수 있다고 생각했습니다.

전체 워크플로우는 다음과 같습니다:

Brainstorming → Brief → PRD → UX → Architecture → Epics/Stories → Test Design → Story Development → Code Review → Retrospective

자세한 것은 BMAD-METHOD Github repository에서 확인할 수 있습니다.

Claude Code와 통합되어 있어서, 로컬 환경에 설치하고 Claude Code를 실행하면 바로 작업을 시작할 수 있습니다.

이 프레임워크를 사용하면서 느낀 3가지 핵심 인사이트를 공유합니다.

핵심 1: AI가 질문하고, 사람은 본질에 집중한다

기존 방식에서는 사람이 문서를 작성하고, 검토하고, 수정하는 과정을 반복했습니다. 현재 방식에서는 AI가 구조화된 질문을 하고, 사람은 답변에만 집중합니다.

예를 들어, Brainstorming 단계에서는 이렇게 진행됩니다:

고객이 어떤 어려움을 겪고 있는지, 어떤 가치를 제공하고 싶은지 사람이 입력
BMAD-METHOD가 적절한 Brainstorming 기법을 추천
LLM이 해당 기법에 맞는 질문을 사람에게 함
사람은 고객 입장에서 깊게 생각하고 답변
Iteration을 거쳐 문서 완성

PRD 작성도 마찬가지입니다. PRD를 구성하는 핵심 항목들에 대해 LLM이 어떤 input이 필요한지 사람에게 물어보면, 사람은 해당 input에 대해 깊게 고민하고 답변합니다. 이 과정을 거치다 보면 어느새 PRD가 완성되어 있습니다.

결과: 사람-사람 사이의 커뮤니케이션 비용이 크게 줄어듭니다.

기존에는 PM이 작성한 기획서를 읽고 이해하고, 다시 PM과 논의하여 이해 수준을 높이는 과정이 프로젝트 초반에 매우 중요했습니다. 현재는 이 과정 자체가 없습니다. 온전히 Spec을 확정하고 문서를 작성하는 데 집중할 수 있습니다.

핵심 2: Persona별 Agent가 전문가처럼 협업한다

BMAD-METHOD는 각 단계별로 다른 Agent를 Context에 로드합니다:

PRD 작성 → John (PM Agent)
Architecture 작업 → Winston (Architect Agent)
UX 논의 → UX Agent

(이것 말고도 더 많이 있습니다!)

마치 Agile Master, PM, Architect와 협업하는 느낌입니다. 각 Agent는 해당 분야의 상세한 Instruction을 가지고 있어서, 전문가 수준의 질문과 피드백을 제공합니다.

결과: 혼자 일하지만 팀처럼 일합니다.

즉, 나(사람)는 이 AI 팀의 리더(Lead)가 되어 의사결정을 내리고, 실무는 역할별 AI Agent들에게 위임하는 체계적인 작업 방식입니다.

예를 들어, Architecture 단계에서는 Winston이라는 Architect Agent가 기존 소스코드 모듈을 분석하고, 이 프로젝트를 어떻게 녹여낼지 고민합니다. PRD와 모듈의 경로를 Claude Code에게 input으로 주고 5-10분 정도 소스코드 분석을 시키면, 꽤 괜찮은 분석 결과가 나옵니다.

다만 이 결과를 무조건 수용해서는 안 됩니다. 분석 문서를 읽고 어떤 부분이 잘못되었는지, 어떻게 수정해야 하는지 피드백을 주는 방식으로 문서를 수정해나갑니다.

핵심 3: 코딩 시간 < 기획/설계 시간

코드 작성은 Dev Agent가 담당합니다. 사람은 Spec 확정과 문서 품질에 집중합니다.

PRD, Architecture 문서가 잘 작성되면 Epics/Story 분할이 스무스하게 진행됩니다. 반대로 사전 작업에 빈틈이 있다면, "이게 왜 들어갔지?" 또는 "이거 왜 빠졌지?" 하는 상황이 발생합니다. 그래서 이 과정이 늘어진다면 차라리 PRD 또는 Architecture 단계로 돌아가서 처음부터 다시 시작하는 게 나을 수 있습니다.

결과: 사전 준비에 투자할수록 개발이 빨라집니다.

기획과 UX 디자인에 많은 시간을 쓰고, 코드 작성 시간은 예전보다 많이 줄었습니다. QA 역시 TC 작성을 AI에게 맡기고, 사람은 직접 TC를 수행하는 과정만 담당합니다. 버그 발견 시 문서 정리도 AI가 하고, 버그 수정도 AI가 합니다.

상세 워크플로우

각 단계별로 어떻게 진행되는지 좀 더 구체적으로 설명하겠습니다.

Brainstorming

고객이 어떤 어려움을 겪고 있는지, 이 프로젝트에서 어떤 가치를 제공하고 싶은지에 대한 내용을 입력하면서 프로젝트가 시작됩니다. 여러 Persona별로 어떻게 받아들이게 될지 고민하는 과정을 거칩니다. 이 과정을 통해 LLM도 프로젝트를 깊게 이해하게 되고, 저도 생각을 정리하면서 머릿속에서 구체화하게 됩니다.

Brief

Brainstorming 문서가 생산되고 나서 Overview 성격의 brief.md 문서를 작성하는 단계입니다. 프로젝트가 무엇이고 왜 해야 하는지를 담은 한 장짜리 문서입니다. 이 문서를 여러 번 읽어보면서 내가 이해하고 있는 프로젝트와 LLM이 이해한 프로젝트가 완벽히 일치하는지 확인해야 합니다.

이 문서는 엘리베이터 스피치 문서로 사용할 수 있을 정도로 짧고 핵심만 담겨 있습니다.

PRD

가장 중요한 단계입니다. Story development를 제외하고 가장 많은 시간을 여기에 씁니다. PRD를 구성하는 핵심 항목들에 대해 정의하는 과정을 거치며, LLM이 각 항목별로 필요한 input을 물어보고 사람이 답변하는 방식으로 진행됩니다.

UX

Brief, PRD 기준으로 UX 논의가 필요한 경우 진행됩니다. Front-end 기능 추가나 수정을 요하는 프로젝트의 경우 이 과정을 거치는 것이 좋습니다. 머릿속에서 추상적으로 그려놨던 User flow를 UX 전문가(Agent)와 논의하면서 구체화합니다.

산출물로 'Lo-fi Wireframe'을 그리게 되는데, 제가 일하는 제품이 HR SaaS(B2B)로서 View가 그렇게 복잡하지 않기 때문에 이 Lo-fi Wireframe만으로 디자인 작업을 대신하는 경우가 많았습니다.

Architecture

PRD를 작성하고 나면 곧바로 개발을 시작하는 게 아니라 철저한 사전 준비 단계를 거칩니다. 주요 기술적 의사결정, 시스템 구조를 이 단계에서 결정합니다.

Brownfield 프로젝트인 경우, 기존 소스코드 모듈을 분석하고 어떻게 이 프로젝트를 녹여낼지에 대한 고민도 이 단계에서 수행합니다. 이 프로젝트를 진행하기 위해 어떤 모듈을 참여시켜야 할지 미리 확정해놓는 것이 중요합니다.

Epics/Stories

PRD와 Architecture 문서 기반으로 프로젝트를 실제 개발 가능한 Epic, Story 단위로 분할합니다. 사전 작업이 잘 되었다면 이 과정은 스무스하게 흘러갑니다.

Story Development

개발을 시작할 수 있는 단계입니다. 곧바로 코드 작업을 시작하는 것이 아니라 몇 가지 정해진 절차를 거칩니다:

Epic tech context: 각 Epic별 상세 기술 명세 작성
Create story: 각 Story별 상세 마크다운 파일 작성
Story context: Dev Agent가 참조할 모든 정보를 XML 형식으로 집약
Dev story: 실제 코드 작업 수행
Code review: 구현 완료 여부, 코드 품질, 보안, 테스트 코드 검증

처음에는 왜 이렇게 복잡한 단계를 거쳐야 하는지 좀 답답했지만 막상 이 절차를 거쳐가며 Story를 완성해나가면 이러한 절차의 효과를 체감하게 됩니다.

도구

코딩: Claude Code + BMAD-METHOD 기반으로 PRD, Architecture, Epics 문서 생산. 중간중간 검증을 위해 Anti Gravity(Gemini) 사용
디자인: 기초적인 디자인은 Lo-fi Wireframe 방식으로 작업. 실제 웹 화면 기반 컴포넌트 배치 시 Anti Gravity에서 Nano Banana Pro 모델 사용
QA: TC 문서를 Claude Code에게 읽게 하고, 직접 브라우저를 통해 TC별 Flow 수행. 버그 발견 시 Claude Code가 직접 Jira 티켓 생성

What Worked

구체적으로 어떤 것을 했고 무엇이 잘 되었다고 느꼈는지 설명드리겠습니다.

속도: 프로젝트별 성장 곡선

지금까지 총 3개의 프로젝트를 진행했습니다.

1st Project

Product Engineer로서 처음 진행한 프로젝트
수정 해야 할 모듈도 단 2개 정도였고 범위도 매우 좁았음
- 구체적인 기능 세부사항이 어느 정도 정해져 있었음
기존 방식과 크게 차이 없다고 느낌
- 프로젝트 크기가 작았기 때문

2nd Project

1st보다 크기가 커지고 수정해야 할 부분이 많아짐
- 수정 해야 할 모듈이 5개 정도였고 각각의 수정 난이도는 높지 않았으나 로직이 누락되지 않게끔 신경쓰는 것이 중요했음
PM으로서 UI/UX를 어떻게 구체화할지 고민하는 과정 필요
BMAD Framework에 익숙해져서 PRD, Architecture 문서 작성이 매끄러웠음
실제 소스코드 작업이 일사천리로 진행됨: FE, BE 각각 반나절
핵심: 직군 간 커뮤니케이션 비용이 크게 줄어듦

3rd Project

서비스 특성을 이해하는 것이 핵심
- Back-end side의 스케쥴러 로직을 주로 수정
- 전체 스케줄러 종류와 실행 순서, 계산 방식 등 많은 부분을 고민해야 했음
- Claude Code, Gemini를 활용하여 기존 서비스 스펙 문서와 소스 코드를 분석하게 해서 스케쥴링에 대한 가이드 문서를 만들게 함. 이 문서를 일종의 '암묵지'로 사용함.
프로젝트 규모
- 코드 작업 대상 모듈은 3개 정도였으나 신규 테이블 구조를 도입하고 기존 비즈니스 로직의 중요 부분에 신규 로직을 끼워넣어야 하는 작업이었음.
- Front-end, Back-end 양쪽에 추가된 코드 분량이 꽤 많았음
첫 번째, 두 번째보다 훨씬 더 빠르고 매끄럽게 진행됨
- 노하우와 자신감이 쌓이고 있음

총 3개의 프로젝트를 점진적으로 작은 규모부터 시작해서 중간 정도의 규모까지 키워가면서 진행했습니다. 이 과정의 제일 큰 수확은 무엇보다 노하우와 자신감을 쌓을 수 있었다는 것입니다.

품질: 문서가 코드를 만든다

작성된 문서 품질이 전보다 좋아졌습니다. 하나의 Framework을 사용함으로써 문서의 양식과 생산되는 문서의 종류가 통일되기 때문입니다.

또한 고품질의 PRD, Architecture 문서 기반으로 고품질의 코드가 작성된다는 것을 경험했습니다. 이것은 AI Product Engineer로서 일할 때 필수적입니다. 이것은 고객 요구사항과 Pain point로부터 출발하여 문제를 정의하고 무엇을 어떻게 만들지에 대한 문서를 작성하는데 시간을 많이 쏟은만큼 실질적인 코드 작성 시간이 줄어들고 코드의 품질이 좋아진다는 의미입니다.

버그 발생률도 예전보다 줄어든 것을 체감하고 있습니다. QA 과정에서 발견하는 버그의 숫자가 눈에 띄게 줄어들었습니다. 그리고 발견된 버그도 이미 관련 문서가 풍부하게 존재하기 때문에 수정하는 데 예전보다 시간을 적게 들일 수 있습니다.

성장: BE에서 제품 전체로

단순히 정해진 스펙대로 기능을 구현하는 것 이상으로, 전체 서비스 관점에서 생각해야 하기 때문에 시야가 넓어지고 있습니다.

기존에 BE로서만 일하면서 저에게 다른 직군 영역은 회색 지대였습니다. 지금은 그래도 조금은 그 안개가 걷히고 있는 느낌입니다. 제품이 만들어지는 전체 과정에서 각 직군별로 어떤 고충이 있고, 어떻게 일하면 좋을지 파악하고 있습니다.

제품을 처음부터 끝까지 내가 직접 만들어나가기 때문에 프로젝트를 출시하는 과정에서 높은 자율성과 성취감을 느낍니다. 예전에 비해 더 높은 업무 만족도를 느끼고 있습니다.

What Didn't Work

항상 모든 것이 좋은 것만 있을 수는 없습니다. 생각보다 어려웠던 것을 공유합니다.

새로운 커뮤니케이션의 발견

새로운 커뮤니케이션이 필요하다는 것을 인지하게 됐습니다.

PM의 주요 역할로서 고객, CS, Business 팀과 논의하여 Product roadmap을 그리고, 개별 프로젝트의 디테일한 부분까지도 외부 팀원들과 의사소통하여 방향성과 디테일을 결정하고 이것을 Product team으로 가져옵니다. Product team 내부에서는 제품을 어떻게 만들지만 고민하면 되는 것입니다.

PM의 역할까지도 수행하다보니 프로젝트 시작단계에서 누구와 어떻게 의사소통 해야 할지 조금은 헷갈렸습니다. BE는 주요 대화 채널이 PM이었지만 내가 스스로 PM이 되다보니 이 채널이 전보다 다양해진 것입니다. 프로젝트의 시작 단계에서 Product team을 벗어나서 다른 팀원들과도 충분한 시간을 갖고 이야기 해야 합니다.

AI Product Engineer는 혼자서 제품의 출시 전 과정을 다루기 때문에 상대적으로 다른 팀원들에게 정보 전달이 소홀해질 가능성이 있습니다. 즉, 다른 팀원들 입장에서는 본인도 모르는 신규 기능이 출시되고 있다고 느낄 수 있는 것입니다.

적시에 적절한 사람과 적절한 내용의 논의를 거쳐야 하는 것. 이것을 몰랐던 것은 아니지만 다시 한번 더 체감하게 되었습니다.

AI의 한계: 암묵지 주입

문서, 소스 코드에 담겨 있지 않은 숨어 있는 도메인 지식들이 있습니다. 이것을 AI에게 Context로 제공하는 것은 쉬운 일이 아닙니다. 자칫하면 그 중요성을 간과하고 생략하거나 때로는 해당 사실 자체가 누락될 수도 있습니다.

예를 들어, A라는 기능이 있는데 이것이 사실은 3년 전에 처음 도입되었고, 지금까지 이러이러한 과정을 거쳐서 개선되었다는 히스토리 성격의 정보는 '사람'만 알고 있는 경우가 많습니다.

이러한 암묵지를 AI에게 제대로 주입할 수만 있다면, 훨씬 더 높은 품질의 산출물이 나올 수 있습니다. 이 도메인 지식을 생각해보고 문서화하는 과정을 충분한 시간을 갖고 사전 단계로서 준비해야 합니다.

본인 스킬의 한계: UI/UX

저는 개인적으로 UI/UX 디자인은 사실상 경험이 없기 때문에 많은 고충을 겪고 있습니다.

지금까지 진행했던 프로젝트들도 그래서 일부러 범위도 좁고 UI 파트의 수정 범위가 크지 않은 것을 골랐습니다. 이 분야에 경험도 쌓고 관련 공부도 해야 할 것 같다는 생각이 듭니다.

자율성의 양면: 고립감

아주 높은 자율성과 동시에 약간의 고립감을 느끼는 것도 사실입니다.

다만 저는 개인적으로 혼자 일하는 것을 선호하기 때문에 이것이 오히려 더 큰 장점으로 느껴집니다. 하지만 저와 같지 않은 사람에게는 어쩌면 어려울 수도 있겠다는 생각이 듭니다.

또한 BMAD-METHOD라는 오픈소스 프레임워크에 너무 의존하는 게 아닌가 하는 생각이 들 때도 있습니다.

Lessons & Advice

핵심 교훈: 사전 준비가 전부다

처음에는 실험적인 성격이 강했으나, 몇 번의 프로젝트를 진행하면서 점점 이것이 가능하다는 확신이 들게 됐습니다. 다른 직군의 업무를 조금씩 해보면서 그들의 고충과 어려움을 이해하게 됐습니다.

마인드셋 변화

개발자로서 코드를 곧바로 작성하려는 강한 욕망을 느끼지만, AI Product Engineer로서 제대로 일하기 위해서는 사전 단계를 철저하게 지키는 것이 매우 중요합니다.

또한 Product team 내부 논의를 벗어나서, 회사 전체에 프로젝트의 성격과 서비스가 어떤 방식으로 개선되는지 공유하고 피드백받는 과정이 매우 중요합니다. 실제 작업이 시작되기 전에 사람들에게 충분히 생각할 시간과 피드백을 줄 시간을 줘야 한다는 것을 알게 됐습니다.

트레이드오프: 넓이 vs 깊이

한 명의 사람이 굉장히 넓은 범위를 커버하기 때문에, 모든 범위를 깊게 파고드는 것은 현실적으로 불가능합니다.

다만 AI와 협업하는 방식을 통해 각 직군별로 제품을 만들기에 충분할 정도의 깊이는 도달할 수 있을 것으로 기대하는 것입니다. 애초에 이 방식을 시도하는 주요 전제가 바로 이것입니다.

혼자서 모든 일을 해볼 수 있을 정도로는 AI의 조력을 받을 수 있을 것이다.

과연 이 전제 조건이 만족되었는지 끊임없이 스스로에게 되물어야 합니다.

조언: 작게 시작하고, 실패를 두려워하지 말자

어디서부터 시작해야 하는지

굉장히 작은 프로젝트부터 시작하는 것이 좋다 (2~3일 정도 소요되는)
진행 과정에 잘 안 된다 싶으면 그냥 삭제하고 처음부터 해보는 것에 거부감을 느끼지 않는 것이 중요
- 그래서 중간중간 산출물을 남기고 이력을 관리하는 것이 매우 중요 (BMAD-METHOD를 사용하는 이유 중 하나)

피해야 할 실수

모든 작업을 한 번에 완료해야 한다는 생각
- 하다가 안 되면 그냥 다시 하면 됩니다. 이것이 AI를 사용하는 이유 중의 하나!
큰 덩어리 Commit
- AI가 작업하는 산출물을 평가하여 괜찮다 싶으면 중간 중간 작게 Commit 하는 것이 중요합니다. 큰 덩어리로 Commit 하려다보면 중간에 AI가 길을 잃고 잘못된 방향으로 작업했을 때 이것을 되돌리기 매우 어렵기 때문입니다.

필수 조건

제가 생각했을 때 AI Product Engineer로 일하기 위한 조건은 다음과 같습니다.

스킬

필수 스킬 1: Claude Code 또는 다른 AI Agent 서비스에 대해 기본적으로 알고 있어야 함 (Codex CLI, Cursor CLI, Gemini CLI 등)
필수 스킬 2: Product이 만들어지는 전체 과정에 대해 알고 있어야 하며, 각 과정별로 필수적으로 해야 할 일에 대해 '알고는' 있어야 함
필수 스킬 3: Software 작성 능력. 프로그래밍에 대해 능숙해야 합니다. 나중에 지금보다 더 LLM 성능이 좋아진다면 모를까 아직까지는 비개발자에게는 힘들다고 생각합니다.

사람

고객이 직접 겪고 있는 문제를 푸는 것에 즐거움을 느끼는 사람
- 고객의 문제를 푸는 것보다는 내가 직접 코드를 작성하는 것에 보람을 느끼는 유형의 사람들이라면 맞지 않을 수 있습니다.
제품을 만드는 전 과정에 대해 어느 정도는 알고 있는 사람
- 저연차 또는 회사에 조인한 지 얼마 되지 않았을 때는 이 방식을 사용하지 않는 것이 좋겠다는 생각입니다.

조직

소규모 범위의 Backlog item에 대해 실험적으로 진행할 준비가 된 조직
- 나 혼자 일 하는 것이 오히려 회사 차원과 팀 차원의 지원을 필요로 합니다. 이러한 준비가 이미 되어 있거나 변할 의지가 있는 조직인지 생각해볼 필요가 있습니다.

다음 단계

현재 진행 중인 프로젝트가 출시되고, 2~3번 정도의 적당한 규모의 프로젝트를 더 하면서 좀 더 데이터를 쌓을 예정입니다. 이를 토대로 팀에 공유하여 의사결정을 할 수 있을 것으로 기대합니다.

이 방향으로 갈 것인가
이 방법은 잘못되었고 가서는 안 되는 것인가
또는 제3의 방향?

도전해보고 싶은 것은 소/중규모 프로젝트가 아니라 대규모 프로젝트도 이 방식으로 진행하는 것입니다. 3개월~6개월 이상 되는 규모가 제법 큰 프로젝트도 이 방식으로 해볼 수 있을지 여전히 고민중입니다.

개선하고 싶은 부분은 AI의 산출물(문서, 의사결정, 소스 코드)을 어느 정도 '믿을 수 있는지'에 대해 지금보다 그 수치를 높이는 것입니다. 이 수치를 높여야 자동화 수준을 높일 수 있고, 궁극적으로 생산성을 높일 수 있습니다. LLM의 성능 향상과 더불어 Agent 시스템 개선을 통해 이 수치를 더 높일 수 있을 것으로 기대합니다.

마치며

AI 도구 덕분에 한 사람이 AI Agent 팀을 지휘하며 제품의 A to Z를 담당할 수 있는 시대가 왔습니다.

아직 실험 단계이고, 모든 것이 완벽하지는 않습니다. UI/UX 경험 부족, 암묵지 주입의 어려움, 고립감 같은 어려움들이 있습니다.

하지만 확실한 것은, 이 방식이 작동한다는 것입니다. 3개의 프로젝트를 성공적으로 출시했고, 점점 더 빠르고 매끄럽게 진행되고 있습니다.

이 글이 비슷한 고민을 하고 있는 개발자들에게 도움이 되길 바랍니다.

Comments (0)

Checking login status...

No comments yet. Be the first to comment!

AI Product Engineer: 기획부터 배포까지 혼자서 제품을 만드는 법

Comments (0)