PO와 엔지니어가 분리되어 있으면 문제의 맥락과 성공 기준, 구현 가능성을 서로 전달하고 협상하는 데 비용이 든다. 프로덕트 엔지니어와 FDE는 문제정의부터 구현과 도입까지 한 사람이 이어감으로써 이 얼라인 비용과 맥락 손실을 크게 줄인다. 그러나 비용이 사라지는 것은 아니다. 역할 사이의 충돌이 팀 간 커뮤니케이션에서 한 사람 내부의 판단 전환으로 이동한다.
PO 모드에서는 지금 선택한 문제가 가장 중요한지, 어떤 사업적 결과를 성공으로 볼지 판단해야 한다. 엔지니어 모드에서는 선택한 가설을 기술적 제약 안에서 정확하고 지속가능하게 구현하고, 문제 재정의를 멈추고 실행을 닫아야 한다. FDE·운영자 모드에서는 계약서에서 정한 구현을 끝냈다는 이유로 멈출 수 없고, 결과물이 고객이 원한 사업적 변화로 이어지는 데까지 책임져야 한다(ref1).
따라서 이 역할의 핵심 역량은 단순히 여러 일을 할 수 있다는 폴리매스성보다 상황에 맞춰 성공 기준과 ego의 크기를 전환하는 능력이다. 표면적 요구를 그대로 구현하지 않고 고객이 아직 명료하게 말하지 못한 욕망을 먼저 제안해야 할 때는 PO·컨설턴트의 ego를 키우고 구현자의 ego를 줄여야 한다(ref2) - 이게 매우 어렵다. 반대로 문제를 정한 뒤에는 기술적 제약과 품질을 말하는 엔지니어의 ego를 다시 키워야 한다 - 나한테 이건 쉽다. 유스케이스 하나를 보여주는 수준에서 비즈니스 전체를 바꾸는 수준으로 책임 범위가 넓어질수록 빠른 사업 이해와 실행 권한이 필요하며, 이러한 전환의 빈도와 책임도 커진다(ref3).
프로덕트 엔지니어와 FDE가 줄이는 것은 주로 사람 사이의 요구 전달, 재설명, 실현 가능성 협상 비용이다. 그 대신 “올바른 문제인가”, “올바르게 만들고 있는가”, “실제로 임팩트가 났는가”라는 서로 다른 질문을 혼자 번갈아 판단해야 한다. 전환이 느리면 구현 가능한 솔루션에 너무 일찍 고정되거나, 문제를 계속 재정의하느라 실행을 닫지 못하거나, 구현 완료를 사업 성과로 오인한다. 이 역할의 생산성은 AI나 개발 속도뿐 아니라 각 단계에서 어떤 ego를 줄이고 키워야 하는지를 알아차리는 메타인지에 달려 있다.
언젠가 이 메모에 쓰이면 좋을 것 같은 재료들입니다.
from: 이 메모에 쓰인 생각을 만든 앞의 생각들입니다. 앞의 생각과 연관관계를 설명합니다.
1.
•
AI 덕분에 PO가 구현자까지 될 수 있기에 프로덕트 엔지니어라는 새로운 시장 수요가 생겼다는 생각이 들었다. 앞의 글에서 나는 각종 프로젝트에서 진정한 PO가 되지 못했음을 털어놓았다. 실제로 내가 겪었던, 두 역할을 통합할 때 생기는 정체성 전환 오버헤드를 구체화했다.
2.
•
디어에서 기술부터 사업 기여까지 판단해야 했던 경험을 에고 전환의 문제로 일반화했다.
3.
•
AI가 FDE를 경제적으로 가능하게 만든다는 생각에서, 도구와 실행 통합이 제거하지 못하는 내부 인지 비용으로 발전시켰다.
supplementary: 이 메모에 작성된 생각을 뒷받침하는 생각의 새로운 메모입니다.
opposite: 이 메모에 작성된 생각과 대조되는 생각의 새로운 메모입니다.
to: 이 메모에 작성된 생각으로부터 발전된 생각의 새로운 메모입니다.
ref: 생각에 참고한 자료입니다.
영구메모 템플릿 버전 2026.03.20