PO와 엔지니어가 분리되어 있으면 문제의 맥락과 성공 기준, 구현 가능성을 서로 전달하고 협상하는 데 비용이 든다. 프로덕트 엔지니어와 FDE는 문제정의부터 구현과 도입까지 한 사람이 이어감으로써 이 얼라인 비용과 맥락 손실을 크게 줄인다. 그러나 비용이 사라지는 것은 아니다. 역할 사이의 충돌이 팀 간 커뮤니케이션에서 한 사람 내부의 판단 전환으로 이동한다.
PO 모드에서는 지금 선택한 문제가 가장 중요한지, 어떤 사업적 결과를 성공으로 볼지 판단해야 한다. 엔지니어 모드에서는 선택한 가설을 기술적 제약 안에서 정확하고 지속가능하게 구현하고, 문제 재정의를 멈추고 실행을 닫아야 한다. FDE·운영자 모드에서는 계약서에서 정한 구현을 끝냈다는 이유로 멈출 수 없고, 결과물이 고객이 원한 사업적 변화로 이어지는 데까지 책임져야 한다(ref1).
따라서 이 역할의 핵심 역량은 단순히 여러 일을 할 수 있다는 폴리매스성보다 상황에 맞춰 성공 기준과 ego의 크기를 전환하는 능력이다. 표면적 요구를 그대로 구현하지 않고 고객이 아직 명료하게 말하지 못한 욕망을 먼저 제안해야 할 때는 PO·컨설턴트의 ego를 키우고 구현자의 ego를 줄여야 한다(ref2) - 이게 매우 어렵다. 반대로 문제를 정한 뒤에는 기술적 제약과 품질을 말하는 엔지니어의 ego를 다시 키워야 한다 - 나한테 이건 쉽다. 유스케이스 하나를 보여주는 수준에서 비즈니스 전체를 바꾸는 수준으로 책임 범위가 넓어질수록 빠른 사업 이해와 실행 권한이 필요하며, 이러한 전환의 빈도와 책임도 커진다(ref3).
프로덕트 엔지니어와 FDE가 줄이는 것은 주로 사람 사이의 요구 전달, 재설명, 실현 가능성 협상 비용이다. 그 대신 “올바른 문제인가”, “올바르게 만들고 있는가”, “실제로 임팩트가 났는가”라는 서로 다른 질문을 혼자 번갈아 판단해야 한다. 전환이 느리면 구현 가능한 솔루션에 너무 일찍 고정되거나, 문제를 계속 재정의하느라 실행을 닫지 못하거나, 구현 완료를 사업 성과로 오인한다. 이 역할의 생산성은 AI나 개발 속도뿐 아니라 각 단계에서 어떤 ego를 줄이고 키워야 하는지를 알아차리는 메타인지에 달려 있다.
<aside>
언젠가 이 메모에 쓰이면 좋을 것 같은 재료들입니다.
</aside>
<aside>
from: 이 메모에 쓰인 생각을 만든 앞의 생각들입니다. 앞의 생각과 연관관계를 설명합니다.
- 나는 시스템을 수직적으로 쌓아올리는 것, 사용 데이터로 해자를 쌓는 것에 쾌감을 느낀다. 하지만 그것이 어떤 포지션과 어떤 도메인에서 최대의 GRIT과 생존력을 보이는지는 증명하지 못했다.
- AI 덕분에 PO가 구현자까지 될 수 있기에 프로덕트 엔지니어라는 새로운 시장 수요가 생겼다는 생각이 들었다. 앞의 글에서 나는 각종 프로젝트에서 진정한 PO가 되지 못했음을 털어놓았다. 실제로 내가 겪었던, 두 역할을 통합할 때 생기는 정체성 전환 오버헤드를 구체화했다.
- ‣
- 디어에서 기술부터 사업 기여까지 판단해야 했던 경험을 에고 전환의 문제로 일반화했다.
- AI의 발전으로 컨시어지 MVP로 해결 가능한 문제가 확장됐다. 과거에 수동으로 처리해야 했던 문제도 높은 수준의 자동화가 가능하다. 절약한 시간은 더 많은 롱테일 비즈니스를 만나고, 수다쟁이 고객을 만나는 데 투자가 가능하다. FDE 포지션의 등장도 이 흐름과 닿아 있다.
- AI가 FDE를 경제적으로 가능하게 만든다는 생각에서, 도구와 실행 통합이 제거하지 못하는 내부 인지 비용으로 발전시켰다.
</aside>
<aside>
supplementary: 이 메모에 작성된 생각을 뒷받침하는 생각의 새로운 메모입니다.
</aside>
<aside>
opposite: 이 메모에 작성된 생각과 대조되는 생각의 새로운 메모입니다.
</aside>
<aside>
to: 이 메모에 작성된 생각으로부터 발전된 생각의 새로운 메모입니다.
</aside>
<aside>
ref: 생각에 참고한 자료입니다.
- “여기서 계약 안하셔도 괜찮은데, 이건 꼭 명심하셔라. 무엇을 구현하는데 얼마 안에 가능하다고 확신하거나, 어떤 기술 중심으로 화려하게 이야기하는 곳은 꼭 피해라. 원하지 않는 결과물이 만들어졌지만 계약서에서 하기로 한 것 다 했으니까 땡이라는 태도를 취할 수 있다.”라고 이야기하며 설득했습니다. … 그 가치를 알아보는 사람들은 분명히 존재하고, 사람들은 거기에 돈을 지불했습니다. 레퍼럴도 많았고 연락을 준 사람들 중 전환율은 50%, 객단가는 월에 수천~1억 수준이었습니다. 하지만 동시에 굉장히 실력이 요구되는 접근이기도 합니다.
- 무당 모드로 접근을 해야 한다. 대표들은 Needs를 말하라고 해도 술술 털어놓지 않는다. Needs의 대부분은 가짜 Needs이다. … “만약 나라면 이렇게 하고 난다음에는 자연스럽게 이런쪽으로 나아가고 싶을것 같은데 너는 그렇지 않니?” 라고 먼저 제안을 해야 한다. 그 적중률이 높으면 그 사람이 나의 문제를 풀어 줄 수 있을 것이라고 기대를 하게 된다.
- 그냥 Usecase 하나를 구현하거나 보여 주는 것을 레벨 1 AX, 프로덕트 하나를 구현해주는 것을 레벨 2 AX, 비즈니스 요구사항에 딱 맞는 것을 구현해주는 것을 레벨 3 AX, 그 비즈니스를 송두리째 갈아엎는 것을 레벨 4 AX라고 하자. 나는 레벨 4 AX가 아니면 진짜 AX라고 생각하지 않는다. AX 전환을 업무 자동화가 아닌 비즈니스 모델 변화까지 포함한 접근으로 보아야 한다. … 왜냐하면 AI 시대에 회사의 핵심 업무 정의 자체 변경 가능성이 높기 때문이다. (그럼 팀도 바꿔야 한다.) 팀을 그대로 두고, 바뀔 업무를 자동화하는 레벨 3 접근의 효용한계는 명확하다. 아무리 으쌰으쌰 하고 컨설팅을 받아도 구성원은 잘 변하지 않는다. … 기존 팀원들을 교육하는 방식보다, 완전히 새로운 팀을 새로운 브랜치로 만들고 버전업을 한 뒤, 기존 팀을 새로운 브랜치로 마이그레이션하고 구조조정하는 편이 더 현실적이다. … 이런 AX 레벨 4를 하려면 사업체를 온전히 위임받는 입장이 되어야 한다. … 그리고 빠른 비즈니스 이해와 큰소리칠 수 있는 배짱도 필요하다. … 대표자가 AI의 저력을 잘 아는 사람이어야 한다. … AX 팀을 온전히 믿어서, AX팀에 사업을 진행할 권한이 있어야 한다. (나: 대표의 두 가지 원형이 있는 것 같다. AI에 대한 힘과 AX 전환자를 믿는 사람과 그렇지 않아서 레벨2, 레벨3으로 WOW를 줘야 하는 사람)
</aside>
영구메모 템플릿 버전 2026.03.20