풀스택 그 너머

풀스택 엔지니어는 프론트엔드랑 백엔드를 만들 수 있어요. 프로덕트 엔지니어는 거기에 더해서 — 그 기능이 처음부터 있어야 하는지를 결정합니다.

PostHog 정의가 잘 담고 있어요. 프로덕트 엔지니어는 "사용자랑 대화하고, 뭘 만들지 결정하고, 가격이랑 매출이랑 UX를 소유하고, 고객을 직접 지원한다." 코드 출시 이상이에요. 제품을 성공시키는 전부를 엔지니어링하는 거예요.

PM 코스프레하는 개발자가 아니에요. 코드 칠 줄 아는 PM도 아닙니다. 이런 사람이에요:

1. 현실에서 문제를 봄
2. 소프트웨어가 풀 수 있는지 판단
3. 솔루션 설계
4. 만듦
5. 먹혔는지 확인

이 전체 루프를 소유하는 게 핵심이에요.

왜 지금 이 역할이 중요한가

패턴이 보여요. 구현은 자동화되고 있는데, 문제 정의는 자동화가 안 됩니다.

9,000명 개발자 설문에서 90%가 2026년 채용이 2020년보다 어렵다고 했어요. 특히 주니어 레벨에서. 주니어가 하던 일 — 디버깅, 테스트 코드, 간단한 기능 — 이 정확히 AI가 제일 잘 대체하는 영역이거든요.

수요가 있는 엔지니어는 AI를 워크플로우에 넣고, 제품 수준 결정을 내릴 수 있는 사람이에요. 그게 프로덕트 엔지니어입니다.

직접 배운 것

10년을 풀스택 개발자로 보냈어요. 만드는 건 잘했습니다. 뭘 만들지 정하는 건 항상 잘하지는 않았어요.

전환점은 "이걸 만들 수 있나?" 전에 "이걸 만들어야 하나?"를 묻기 시작했을 때였어요.

동료가 사진 투표 앱에서 사진 없는 사용자한테 Google 이미지를 가져오자고 했어요. 기술적으로 돼요. 근데 핵심 가치 — 내 사진에 대한 피드백 — 를 흐리게 만들 뻔했어요. 안 하기로 했습니다. 몇 주치 일을 아꼈어요.

다른 회사에서 4,000명짜리 기업 고객이 리뷰어를 한꺼번에 삭제하면 504 에러가 났어요. API를 고치려 했는데, 사용 데이터를 보니까 전체 목록을 한꺼번에 지우는 사람이 거의 없었어요. 페이지당 100명으로 제한했습니다. 엔지니어링 오버헤드 제로. 문제 해결.

두 번 다 답은 코드가 아니라 제품 이해에서 나왔어요.

AI 시대

AI가 실행을 싸게 만들었어요. 문제 정의는 안 싸졌습니다.

2026년에 잘 되는 개발자는 시간의 30%를 사용자 이해에, 70%를 만드는 데 쓰는 사람이에요. AI가 만드는 걸 빠르게 해주니까. 생각하는 시간은 그대로입니다.

AI는 이미 이해하고 있는 걸 증폭시켜요. 사용자를 잘 알면 극적으로 생산적이 돼요. 모르면 틀린 걸 더 빠르게 만들 뿐이에요.