몰래쓰는블로그

프로덕트 관점으로 보는 <흑백 요리사>

넷플릭스 프로그램 “흑백 요리사”가 최근 아주 화제다. 우리나라 정상급 셰프들이 나와서 요리 경연을 펼치는 프로그램으로, 그 중에서도 “밈”이 되어 많은 사람들에게 각인된 장면들 위주로 프로덕트 관점에서 생각해 보려고 한다.  

#1. 안성재 심사위원

<흑백 요리사>의 심사위원은 총 2명으로, “더본 코리아”의 대표이사 이기도 하고 수많은 방송 출연으로 시청자들에게 익숙한 백종원 심사위원과 2024 기준 국내 유일의 미슐랭 3스타 파인 다이닝 “모수 서울”의 오너 셰프인 안성재 심사위원이다. 이번 편은 안성재 심사위원의 짤 중심으로 이야기를 써보려 한다.

셰프의 의도와 프로덕트의 의도

안성재 심사위원은 음식을 평가할 때 “셰프의 의도”를 계속 질문한다. 셰프가 어떤 의도로 요리를 하고 그 의도를 고객에게 전달하는 것은 셰프의 기술적 숙련도이고, 그 의도가 고객에게 먹히는지는(고객이 좋아하는지는) 그 다음 문제인 것이다. 당연히 의도를 전달할 때는 다른 요소들은 명확한 이유를 가지고 기술적으로 통제해야한다. "고기의 이븐함 정도" 밈에서 알 수있듯이 셰프의 의도와 관계 없이, 통제 되지 않은 변수가 고객이 느끼는 맛에 영향을 미친다면 기술적 숙련도가 부족하다는 것이다.

안성재 셰프는 나폴리 맛피아의 음식에서 아무 의미 없는 꽃 장식을 보고는 맛있게 먹었음에도 불구하고 “통과’가 아닌 “보류”로 결정한다. 다소 극단적이지만 토스의 송금 버튼에 꽃 장식이 아무 의미 없이 들어가 있다고 생각해보자. 만약 이 하나로 고객이 이탈한다면, 의도를 알 수 없는 장식 하나가 전체 가설에 노이즈를 일으킬 수도 있는 것이다. 나폴리 맛피아의 의미 없는 꽃 역시도 잘 정의된 가설에 노이즈를 일으킬 수 있는, 통제하지 못한 변수인 것이다. 

프로덕트에서도 "의도"는 아주 중요하다. PM의 기술적 숙련도 역시 "기획자의 의도"를 고객에게 전달하는 것이다. 이 때도 역시 다른 요소들을 명확히 통제해야 한다. 한 번에 하나의 가설만 검증하라는 이유도 이와 같다. 내가 의도를 정확히 전달하지 못했는데, 가설의 성공 여부는 판단할 수도 없는 것이다. 잘 정의된 문제는 고객을 모을 수 밖에 없다. “문제 정의”야 말로 기획자의 의도인 동시에 기술적 숙련도를 보여주는 것이 아닐까 한다. 

채소의 익힘과 데이터 중심 의사결정

안성재 심사위원이 이렇게 셰프의 의도를 계속해서 물어보는 것은 분석적이고 통계적인 데이터 중심 프로덕트 의사 결정과도 비슷한 것 같다고 생각이 든다. 요리도 과학과 데이터가 몹시 중요한데, 이는 안성재 셰프의 또다른 밈인 “채소의 익힘 정도” 에서 알 수 있다.

채소는 그 익힘 정도마다 식감이 달라지고, 영양소가 파괴되기도 한다. 예를 들어 잘 익은 아스파라거스는 씹는 느낌이 아삭하고, 많이 익으면 흐물하다. 이것이 채소의 익힘에 관한 데이터인 것이다. 이런 관점에서 보면 안성재 셰프는 얼마나 데이터에 근거한 의사결정을 하는가도 판단 기준이었던 것이라 할 수 있겠다. 철가방 요리사님은 청경채에 대한 데이터를 잘 활용한 요리를 보여주었던 것이다. 급식 대가님 역시도 아이들이 먹는 데이터에 기반해 메뉴 구성을 달리해 잘 먹을 수 있는 한 상을 만들어냈다. 

프로덕트에서도 데이터에 근거한 의사 결정을 해야 한다. 데이터 기반 의사 결정은 객관적인 판단을 할 수 있게 해주고, 효과적인 성과 측정이나 리스크 관리를 할 수 있게 해준다. A/B테스트나 퍼널 분석 같은 측정, 분석은 그것을 위한 도구라고 할 수 있다. 이런 도구들을 활용해 요리처럼 얼마나 의도를 잘 표현해내는가 가 PM의 능력이겠다. 데이터에 근거한 의사 결정은 실험 환경에서 성공했고, 같은 환경이라면 다시 성공할 수 있는 “물고기 잡는 방법”인 것이다.

문제 정의와 데이터에 기반한 의사 결정에 대한 이야기를 <흑백 요리사>와 같이 풀어봤습니다. 여기까지 안성재 셰프의 밈과 함께한 “프로덕트 관점으로 보는 <흑백 요리사> 였습니다. 흑백 요리사로 다른 내용들도 다뤄보려 했는데 뭔가 시간이 지나서 글 쓸 의지가 좀 떨어져서,, 한편으로 마무리 하겠습니다. 감사합니다.

노코드 툴 softer에 google analytics 연결하는 방법입니다. 

사이드 프로젝트로 softer를 이용해 웹 사이트를 만들었습니다. GA를 연결하려고 하는데, 도움이 되는 글이 많이 없어서 찾아보고 연결한 방법을 포스팅 하려 합니다. 

Softer : https://www.softr.io/

GA : https://developers.google.com/analytics/devguides/collection/ga4?hl=ko

1. GA 계정 생성

아래 경로로 들어가 계정을 새로 만들어줍니다.

• GA > 설정 > 만들기 > 계정

사진 순서대로 쭉 진행해줍니다. 

저는 Softer 이용해서 웹 페이지를 만들었기 때문에 웹을 선택했습니다. 

URL도 등록해줍니다. 

계정 생성을 완료했고 위 화면의 측정 ID (G - 00000000 형태 ) 를 복사해줍니다. 

2. Softer에서 GA 측정 ID 등록

본인의 프로젝트에서 아래 경로에 방금 복사한 측정 ID를 입력하면 끝입니다.

• Settings > Integrations > Google Analytics

G - 라고 되어 있는 부분에 넣어주면 됩니다. 간단하죠?

저는 하는김에 태그매니저도 넣어줬습니다.

Softer랑 GA의 연결이 끝났다면 언젠가 아래 화면처럼 통계를 볼 수 있을겁니다. 

아래 화면은 작년에 진행한 프로젝트의 통계입니다. GA는 연결하고 바로는 동작하지 않을 수도 있으니 급하게 통계를 봐야한다면 꼭 미리미리 연결해두세요.

이제 곧 광고도 좀 태워보고 유입 분석을 해볼 예정입니다. 잘 되면 블로그에도 올려볼 수 있지 않을까요?

목표는 DAU 200입니다. 여러분들도 열심히 한 사이드 프로젝트 GA 연결해서 통계도 보고 잘 개선해 나가시길 기원합니다. ^^7

컨설팅 펌에서 프레임워크는 문제 해결 과정을 구조화 해놓은 사고의 틀을 의미한다.

현실은 이론처럼 정확히 디자인된 그래프를 따라서 수치들이 움직이지 않는다. 모든 요인을 고려해야 하는 만큼 이론보다 훨씬 분석하기 어렵다고 할 수 있다. 프레임워크는 이런 복잡한 상황과 문제들을 단순화 시킬 수 있는 좋은 도구이다. 

예를 들면 BCG에서는 회사의 포트폴리오를 시장 성장률/ 시장 점유율 두가지 축으로 나누어 매력도를 분석하고 어느 지점에 있는지에 따라서 행동 방침을 구조화했다. BCG 매트릭스는 경영학에서 필수적으로 배우는 정도가 되었다.

잘 알고 있는 SWOT분석이나 이전에 포스팅한 MECE, KPI등도 이런 프레임워크의 예시가 될 수 있겠다. 요즘은 많이 사용하는 단어인 블루 오션, 대학생이라면 한번쯤 들어봤을 법 한 파레토 법칙, 롱 테일 법칙과 같은 경제학 법칙들도 역시 프레임워크이다. 컨설턴트라면 이런 프레임워크를 적재적소에 맞게 만들거나 찾아서 사용하는 것이 중요하다.

취준생 시절에 본인에 대해 SWOT 분석을 한 장표를 포트폴리오에 삽입하거나 면접 대상 기업에 대해 분석해 가산점을 얻는 친구들을 보았다. SWOT 분석이 좋은 프레임워크라기보다 사고가 체계적인 점이 좋아보이지 않았나 싶다. 신입사원을 뽑을 때 체계적인 사고를 하는 사람이 더욱 가르치기도 쉽고, 협업할 때 유의미한 결과를 만들 가능성이 높다고 생각하지 않을까.

일을 효율적으로 하기 위해 체계적, 구조적인 사고를 하는 것이 좋다. 이런 사고력을 기르려면 프레임워크를 만들고 활용하는 연습 또한 꾸준히 하는 것이 좋은데, 다른 사람이 만든 유명한 프레임워크들을 마냥 사용하는 것이 아니라 틀을 통해서 무엇을 하고 싶은지 핵심을 파악해 적재 적소에 이를 활용하는 것이 중요하다. 대표적인 프레임워크인 Value Chain Framework, STP, KPI 등은 한 번쯤 분석하고, 예시를 통해 적용해 보는 것이 좋을 것 같다.

다만 매력적이고 상황에 알맞는 프레임워크는 꾸준히 생겨난다. 따라서 어떤 프레임워크를 공부했다고 해서 한 가지에 매몰되어 모든 상황에 적용하려 들면 안 될 것이다.

프레임워크는 결국 업무의 체계화, 구조화를 통해 결국 생산성을 높이는 도구이다. 무엇이든 효율적으로 하기 위해서는 복잡한 것을 간단하게 보는 눈이 중요하다는 생각이 든다. 언제나 문제의 본질을 파악하고 핵심을 짚어낼 수 있도록 하자.

문제를 풀기 위해서는 본질적 질문인 Key Question을 설정하는 것이 중요하다.

핵심 문제에 대해 단계별로 쪼개서 생각하며, 가설과 문제를 하나씩 매칭할 수 있다. 

단계별로 진행하며 issue Tree를 그려 보면서 사고해 볼 수 있다. 

- 문제를 작은 단위로 분해하며 쉽게 풀기 위해

- 문제가 발생한 원인, 해결 방안을 빠짐없이 도출

- 문제 해결을 위한 지도로 사용하며, 나중에 활용 가능하다.

문제를 쪼개서 해결책을 구성한다는 방면에서는 OKR에서의 Objective &  Key Result와도 유사하다. 

OKR을 구성할 때도 Key Question을 구성하는 방식과 동일하게 같은 레벨일 때는 MECE하게 구성하는 것이 더욱 효율적일 것으로 생각된다. 

배운대로 한번 예시를 들어 보겠다.  

예시

Key question : 어떻게 식자재 마트의 수익성을 개선할 것인가?

Level 1 : 

- ⓐ매출을 증가시키는 방법은 무엇인가?

- ⓑ비용을 절감시키는 방법은 무엇인가?

Level 2 : 

ⓐ

- 기존 고객의 매출을 어떻게 증가시킬 수 있을까?

- 새로운 거래처를 어떻게 늘릴 수 있을까?

ⓑ

- 최초 도매 원가를 어떻게 줄일 수 있을까?

- 유통 단가를 어떻게 줄일 수 있을까?

- 직원들을 어떻게 효율적으로 배치할 수 있을까?

- 나도 모르게 나가고 있는 비용은 없을까?

Level 3 : 

ⓐ' 

- 개인 고객의 매출을 어떻게 늘릴 수 있을까?

- 업체/ 대량 구매 고객의 매출을 어떻게 늘릴 수 있을까?

ⓐ'' 

- 개인 고객들을 어떻게 추가로 획득할까?

- 기업 고객들을 어떻게 추가로 획득할까?

예시를 만들어 보면서 느낀 것은 아래와 같다.

1. 얼마나 MECE하게 하위 항목을 나눌 것인가?

2. 각각의 항목에 영향을 주는 변수를 전부 파악 했는가?

"항목에 영향을 주는 변수를 전부 파악했다." = "MECE하게 나누었다."

이렇게 생각해 볼 수도 있겠다. 1번과 2번을 계속 반복적으로 생각하면 문제를 잘 나누어 볼 수 있지 않을까 싶다. 

배운대로 적어보긴 했는데, 간단한 문제 여러개를 나누어서 체계적으로 생각해보는 훈련이 필요할 것 같다. 정답은 없지만 한 눈에 기준이 잘 보일 수록 잘 나눈 문제가 아닐까 싶다. Key question tree를 그리는 연습을 하면, OKR을 나눌 때에도 목표와 핵심 지표를 설정할 때 큰 도움이 될 것 같다. 

베인, 맥킨지, 보스턴과 같은 컨설팅 펌에서는 문제 해결을 위해 여러 기술을 사용하는데, MECE 기법도 그 중 하나이다. 

MECE "Mutually Exclusive, Collectively Exhausive" 

맥킨지 컴퍼니에서 처음으로 사용한 용어이며, "미씨" 라고 읽으면 된다고 한다. 

한국어로는 겹치지 않게, 전체를 포괄하도록 문제를 구분하는 방법이다. 

고등 수학에서 집합을 배웠다면 어렵지 않게 머리에 그림을 그려볼 수 있다. 

A 집합과 B집합이 서로소이며, 두 집합의 합집합이 전체 집합이라면 MECE 하다고 생각할 수 있겠다.

물론 문제에 따라 서로소인 집합들이 A, B 이상으로 많아지겠지만 빠짐없이 검토하기 위한 방법으로 활용된다고 한다.

반대로 MECE 하지 못한 사고는 "Random"한 사고 방식이라고 이야기한다고 한다. 집합 전체를 파악하지 못하고 미시적인 것에 몰입하는 사고인 것이다. 

MECE 기법은 비즈니스적인 부분 이외에도 유용하게 적용할 수 있다. 이를테면 도서분류, 마트의 코너 분류 등 일상적으로 사용되는 많은 색인이 MECE 하게 적용되어 있다. 문제 해결에 있어서 구조적으로 사고하는 사람은 그렇지 않은 사람과 매우 큰 차이를 보일 수 밖에 없다. 

도서관 책 분류
- 총류, 철학 종교, 사회과학, 순수과학, 기술과학, 예술, 언어, 문학, 역사 
위스키 분류 (재료, 블렌딩)
- 몰트 (싱글 몰트, 블렌디드), 그레인, 블렌디드, 기타

MECE하게 문제를 나누었다면?

1. 중복되지 않는다. 

2. 전체를 포괄한다. 

문자 그대로, 전체 문제를 겹치지 않게 나누었으므로 일이 중복될 수 없다. 여러번 일하지 않아도 되니 효율성이 올라간다. 전체 문제를 파악했기 때문에, 누락이 없다. 

문자에 포함되지 않는 구조화된 사고의 또 하나의 장점이 있다.

3. 다른 사람과 협업하기 쉽다. 

내가 어떤 논리로 문제를 분할했는지 다른 사람들도 알 수 있다. 또한 분할된 문제에서 파생되는 가설과 해결책들도 함께 논의하기 쉬울 것이다. 만일 내가 분할한 방법에 구멍이 있거나, 중복된 부분이 있다면 다른 사람들이 이를 짚어내기 쉬울 것이다. 

컨설팅펌에서는 문제를 논리적으로 분석해 결정권자를 설득하는 방향으로 활용할 것이다. 

어찌 보면 일상 생활에도 자주 사용되고 있어서 당연하게 느껴지긴 하지만, 실제로 이런 사고를 체화시키는 것은 어려울 수도 있다. 간단한 주제부터 적용해나가는 연습을 통해 더 어려운 주제나 실무에서 체계적으로 사고할 수 있도록 연습하는 것이 좋을 것 같다. Top-down 방식으로 구조화하는 방식을 통해 문제를 효율적으로, 완전하게 해결할 수 있도록 하자.

인터넷을 돌아디니며 찾아보니 LISS 라는 방법도 존재하는 것 같다. Linearly Independent Spanning Set 이라는 방법인데, 나중에 이것도 찾아봐야겠다.