제품과 엔지니어링이 함께 일하는 법

"우리는 정말 같은 팀인가요?"

이 글은 Pragmatic Engineer 팟캐스트〈How to Work Better with Product, as an Engineer – with Ebi Atawodi〉편을 바탕으로 작성되었습니다.
기술보다 사람과 구조, 그리고 팀 안에서 우리가 함께 설계해야 할 '신뢰'에 대해, 다양한 사례를 통해 실무자의 시선으로 다시 들여다봅니다.

Ebi Atawodi가 처음 팀에 합류했을 때, 엔지니어링 매니저인 Gergely는 혼란스러웠다고 말합니다.

팀 회의에 처음 와서, ‘이번 제품 리뷰에서 우리가 좋지 못한 피드백을 받았다’고 말했을 때 솔직히 말해 당황했습니다. 엔지니어들은 혼란스러워했고, 저도 ‘왜 이걸 지금 말하죠?’라는 생각이 들었죠.

하지만 그게 출발점이었습니다.
그날 이후, 두 사람은 서로를 알아가기 시작했고,

제품과 엔지니어링은 ‘하나의 팀’으로 바뀌었습니다.

좋은 협업은 솔직함에서 시작된다

처음에는 충돌처럼 보였던 일도, 사실은 정보 비대칭에서 오는 오해였습니다.
제품 리뷰라는 개념 자체를 엔지니어링 팀은 처음 알았고,
그 미팅이 채용, 리소스, 전략에 얼마나 영향을 주는지도 처음 알게 된 거였죠.

“우리의 목표는 결국 같지 않나?”라는 질문은 당연해 보이지만,
실제로 팀 내에서 이 질문을 진지하게 던지는 경우는 많지 않습니다.

그러나, 솔직하게 현실을 공유하고,
그 현실을 함께 책임지기 시작하면, 팀의 관점은 달라집니다.

“이 프로젝트가 통과되지 않으면 헤드카운트를 못 받을 수 있어요.”

“이 기능이 늦어지면 브라질 GM이 마켓을 못 열어요.”

이런 맥락을 공유했을 때, 엔지니어들은 ‘왜 이것을 해야 하는가’를 이해하고
‘어떻게 해야 더 빠르고 안정적으로 만들 수 있는가’를 고민하기 시작합니다.

팀 미팅이 변해야 팀 문화가 변한다

두 사람은 기존의 팀 미팅 포맷을 바꾸었습니다.

기존엔 제품이 5분, 엔지니어링이 5분 말하고 끝나는 회의였다면,

이제는 항상 제품 이야기부터 시작합니다.

이번 주 고객 반응은 어땠는지

어떤 지표가 변화했는지

어떤 정책이나 시장 이슈가 영향을 미칠지

그다음, 자연스럽게 기술적 이슈와 연결됩니다.
그리고 회의가 끝나갈 때쯤엔, 많은 엔지니어들이 직접 의견을 내기 시작합니다.

이건 웹 기반으로 만들면 더 많은 북킹을 유도할 수 있어요.

지금 API 성능이 문제인데, 캐시를 도입하면 해결될 수 있을 것 같아요.

이런 변화는 우연이 아닙니다.
회의의 순서와 흐름, 공유하는 정보의 성격이 바뀌면서
팀이 ‘우리의 문제’를 인식하고 ‘우리의 해결책’을 말하기 시작한 것입니다.

팀은 '리듬'을 만들어야 움직인다

Ebi는 말합니다.
“사람은 심장이 있는 존재입니다. 리듬이 있어야 안정감을 느낍니다.”

그래서 팀은 세 가지 리듬을 만들었습니다.

1:1 미팅 – 인간적인 이야기, 고민, 이직 생각까지 포함해서

주간 회의 – 제품-기술 흐름이 있는 회의

분기별 플래닝 미팅 – 어떤 기술자원이 어디에 배정될지 논의

이 리듬은 팀원들에게 안정감을 줍니다.
예측 가능한 흐름이 있으니, 각자 그 안에서 창의적인 판단을 할 수 있게 되죠.

특히 인상 깊었던 건, 이 팀이 'State of the Union'이라는 프레젠테이션을 만들었다는 점입니다.

지난 분기에 우리가 만들어낸 가치

다음 분기의 전략

시장의 반응과 정책 변화

그리고 팀 내부의 기술적 문제들

이건 단순한 브리핑이 아니라,

팀 전체가 “우리는 왜 존재하는가”를 되짚는 시간이었습니다.

"PM이 아니라, 사람이 보인다"

Ebi는 이렇게 말합니다.

“나는 너의 와이프가 HTML 배우는 얘기를 기억해요.
그리고 당신은 내 생일을 기억했죠.
우리는 먼저 서로를 사람으로 만났어요.”

이 팀이 특별했던 이유는,
업무에서의 갈등조차 인간적인 신뢰 위에서 다뤄졌기 때문입니다.

상대가 누군지 알고 있으니, 충돌이 싸움이 되지 않고 대화가 됩니다.

상대의 일상을 알기에, 갑작스런 퍼포먼스 저하에도 이유를 묻고 기다릴 수 있습니다.

결국 이 팀은 4년 넘게 단 한 명의 이탈도 없이 유지됩니다.

이 정도면, 실력이나 리소스보다 더 강력한 조직 전략 아닐까요?

그래서, 나는 무엇을 바꿔야 할까?

이 글을 쓰며 이런 질문이 남습니다.

내 팀의 회의는 문제 공유에서 시작하고 있나요? 아니면 단순한 진행 상황 체크인가요?

내가 함께 일하는 PM, 디자이너, 엔지니어의 인간적인 맥락을 알고 있나요?

우리 팀에 리듬이 있나요? 아니면 매번 긴급 대응의 반복인가요?

지금 내 팀의 ‘State of the Union’을 만든다면 어떤 슬라이드로 시작할 수 있을까요?

프로세스와 협업 툴은 바꿀 수 있습니다.
하지만 신뢰는 설계할 수 없습니다. 다만 쌓일 수 있을 뿐입니다.

팀은 시스템으로 굴러가지만,
그 시스템에 의미와 온도를 부여하는 건 결국 사람의 몫입니다.