쿠팡이츠 4차 Leadership Interview

다른 강의는 핵심 20%를 골라 관통하는 방식이 통한다. 넓은 지식 체계에서 자주 쓰이는 부분만 먼저 익혀도 나머지는 나중에 채울 수 있기 때문이다.

면접 준비는 그렇지 않다. 면접관은 내가 준비한 곳만 골라서 묻지 않는다. 안 본 섹션이 정확히 그날의 질문이 될 수 있고, 그 한 번을 못 넘기면 나머지를 아무리 잘해도 만회가 안 된다.

그래서 나누는 축이 "중요도"가 아니라 "몇 번 볼 것인가"다.

🔁 반복 — 면접 직전까지 계속 볼 것. LP 15개 원문 어구(§3) · 번역 치트시트(§4) · 3층 사다리(§5) · 답변 설계 전부(§6) · 앵커 표(§7) · 카드 매칭(§8) · 채우기 목록(§9) · 직전 1장(§10). 그리고 §2의 결정들.

🧩 1회독 — 이해하면 다시 안 봐도 됨. 개념 비유들(의사 두 명, 준비물 알림 문자)과 LP 5묶음 지도. 아래에 🧩 롱테일 배지로 표시해 뒀다. 버리라는 뜻이 아니라, 시간이 없을 때 여기부터 건너뛰라는 뜻이다.

안내문이 예시로 든 키워드 넷 — Customer Obsession · Bias for Action · Earn Trust · Learn and Be Curious — 은 쿠팡 LP 15개에 하나도 없다. 전부 아마존 LP 이름이다.

"이런 결의 이야기를 하라"는 뜻이지 그 단어를 쓰라는 게 아니다. 면접장에서 아마존 용어를 내가 먼저 꺼내면 "쿠팡 LP를 안 찾아봤구나"로 읽힌다.

단, 면접관이 먼저 그 표현을 쓰면 그냥 받아서 답한다. 안내문에 있으니 면접관도 쓸 수 있다. "그건 아마존 LP인데요"라고 정정하면 재수 없게 들리고 얻는 것도 없다.

git 이력상 회원가입 재구축(2026-03 VENUS-835)의 동기는 고객 지표가 아니라 ①반복 버그 ②디자인 시스템 전환 ③레거시 정리로 보인다.

2024-12에만 같은 계열 버그 5건 — APP-292 이름 입력 후 안 넘어감 · APP-315 주민번호 뒷자리 2개 입력 · APP-359 화면이 우상단부터 그려짐 · APP-453 약관 갔다 오면 스크롤 튐 · APP-463 붙여넣기 가능. 이후 2025-01~2026-03 디자인 시스템 순차 마이그레이션.

→ Jira VENUS-835 배경에 고객 지표가 없으면, 이건 Wow the Customer가 아니라 Think Systematically 카드다. 그 경우 이렇게 말한다:

"같은 계열 버그가 한 달에 다섯 건씩 났습니다. 하나씩 고쳐도 계속 나왔고, 그건 개별 버그가 아니라 구조가 그런 버그를 계속 만들어내는 상태라는 뜻이었습니다. 그래서 패치를 멈추고 갈아엎었습니다."

→ §1의 "누가 실수했느냐가 아니라 구조가 문제였다" 와 같은 사고라 한 세트로 읽힌다. 따라서 "회원가입 완료율이 최대의 한 방"이라는 이전 판정은 보류 — 그 숫자가 애초에 측정되지 않았을 수 있다.

다른 빈칸은 "없으면 그 카드를 안 내면 그만"이다. 그런데 이미 제출한 이력서에 적힌 숫자는 면접관이 물어볼 권리가 있고 나는 답할 의무가 있다.

대상: 디자이너 커뮤니케이션 20% 절감 · 이슈 분석 30분→5분 · 크래시-프리 96→99%의 측정 도구

하나가 무너지면 나머지 숫자까지 같이 의심받는다. 이게 가장 무서운 부분이다.

면접이 한국어로 진행되면 면접관 머릿속에 있는 건 한글판이다. 그런데 두 판본은 어디에 힘을 주는지가 다르다.

Ruthless Prioritization — 영문은 "give up what we want to do"(하고 싶은 걸 포기)에서 끝나지만, 한글은 여기까지 간다: "쉽고 잘 할 수 있는 일부터 하려는 유혹에서 벗어나 어렵고 불편해도 해야만 하는 일부터 우선한다."

Aim High and Find a Way — 영문은 "work backwards"지만, 한글은 "절충안 대신 근본적 해결책을 찾아내고… 합리적 목표는 변화를 겁내는 마음에서 태어난다." 완전히 다른 무게다.

"크래시 75%↓ = 매출 75%↑"로 말하면 끝이다. 죽던 세션이 전부 신청 플로우였던 게 아니기 때문이다.

비즈니스 연결은 방향으로 말하고, 등치는 거부한다. 그 거부가 오히려 데이터 감각으로 읽힌다.

"AI한테 맡기면 본인 분석력이 떨어지지 않나요?" → 위 💬 문장 그대로.

"그 도구 지금 팀이 실제로 씁니까? 본인만 쓰는 거 아닌가요?" ← ✅ 답이 있다. 세게 답한다

"팀이 쓰고 있습니다. 저는 만든 것보다 그게 더 중요하다고 봅니다. 사내 도구는 만들었다는 것과 쓰인다는 게 전혀 다른 얘기라서요. 안 쓰이면 그건 제 취미지 조직 자산이 아닙니다."

→ 이 답이 Company-wide Perspective를 닫는다. 그리고 앞서 말한 scalable 주장이 말이 아니라 사실이 된다 — 사람 수에 안 묶인다는 걸 팀이 쓰고 있다는 것으로 증명하는 것.

→ 여유가 있으면 일관성을 드러낸다: "디자인 시스템도 같은 생각으로 만들었습니다. 남이 저한테 안 물어보고도 쓸 수 있게 인터페이스를 분리하고 예제 앱을 붙였고요. 제가 붙들고 있어야 도는 건 잘 만든 게 아니라고 봅니다."

"AI가 원인을 틀리게 진단하면요?"

"틀릴 수 있습니다. 그래서 원본 이슈를 지우거나 닫지 않습니다. 분석 결과는 먼저 볼 실마리지 결론이 아니고, 최종 판단은 사람이 합니다. 도구가 하는 일은 어디서부터 볼지를 정해주는 것까지입니다."

여기서 막히면 "관측을 개선했다"가 "관측을 껐다"로 뒤집힌다. 코드 확인 결과 답은 명확하다 — 끈 건 자동 캡처 하나뿐이고 신호는 다 남겼다.

"관측을 없앤 게 아니라 노이즈만 골라서 버리고 신호는 남겼습니다. 세 가지로 나눠서 했는데요 —

하나, 자동 캡처만 껐습니다(enableCaptureFailedRequests = false). 이미 우리가 처리한 실패까지 전부 이벤트로 올라와서 신호를 가렸으니까요.

둘, 우리 API 요청은 브레드크럼으로 그대로 남깁니다. 대신 우리 서버가 아닌 도메인은 걸렀고요. 그래서 크래시가 났을 때 직전에 어떤 API가 실패했는지는 지금도 보입니다.

셋, 에러도 전부 버리는 게 아니라 무시할 코드 목록만 정해서 버립니다. 요청 취소, 인터넷 끊김, 연결 유실, 타임아웃 네 가지요. 이건 사용자 네트워크 상황이지 우리 버그가 아니라서 걸렀습니다. 서버 5xx 같은 진짜 실패는 그대로 올라옵니다."

→ 덧붙이면 강해진다: "오히려 스크린샷과 뷰 계층을 붙이고 브레드크럼을 200개로 늘려서 남은 이슈는 더 잘 보이게 했습니다."

"MTTR은 얼마나 줄었나요?" (실측 없음 — 절대 지어내지 말 것)

"MTTR은 기대 효과로 제시했고 실제로 측정하지는 못했습니다. 제가 방어할 수 있는 건 노이즈 건수와 원인 파악 시간까지입니다. 돌아보면 제안할 때 지표를 걸어놓고 측정 체계까지 같이 만들었어야 했다는 게 아쉬운 부분입니다."

→ 마지막 문장이 Learn Voraciously("실수를 합리화하지 않고 스스로를 기꺼이 비판한다")를 그대로 친다. 약점을 LP로 바꾸는 자리다.

"팀 발표가 어떻게 전사로 갔나요?"

"제가 전사에 뿌린 게 아니라 VP가 보시고 공유하셨습니다. 팀 문제로만 쓰지 않고 운영과 고객까지 영향을 정리해서 올린 게 그 이유였다고 생각합니다."

→ Influence without Authority 원문이 "지위가 아닌 지식이 권위가 되는 환경을 만든다". 정확히 이 이야기다.

"재현이 안 됐다면서 어떻게 원인을 찾았나요?"

"Sentry 스택트레이스에 문자열 인덱스 연산이 찍혀 있었고, 그 지점이 홈 화면 로고 URL 변환 함수였습니다. 거기서부터는 '어떤 입력이 들어오면 이 연산이 실패하는가'를 거꾸로 좁혔습니다. 네 칸을 빼는데 문자열이 네 글자보다 짧으면 되겠더라고요. 그 조건에 맞는 금융사가 실제로 있는지 데이터로 확인했습니다."

"가드 하나면 끝날 일 아니었나요?"

"가드를 넣으면 그 크래시는 멈춥니다. 그런데 왜 네 칸인지를 아는 사람이 저밖에 없는 코드가 그대로 남습니다. 확장자가 .jpeg로 바뀌면 또 틀리고요. 위치를 세는 방식이 문제라서 방식을 바꿨습니다."

"27건을 어떻게 다 찾았나요?"

"유형을 먼저 정의했습니다. 배열에 첨자로 바로 접근하는 지점, 빈 배열에 [0]이나 removeLast를 쓰는 지점, 컬렉션뷰에서 섹션 인덱스를 이중으로 첨자하는 지점, 문자열 범위 연산. 유형이 정해지고 나니 기계적으로 훑을 수 있었습니다. 어려운 건 찾는 게 아니라 찾아야겠다고 마음먹는 것이었습니다."

"그 세 개가 하나의 프로젝트인가요?" → 마스터플랜인 척하면 사후 서사화로 읽혀 신뢰도가 날아간다. "처음부터 3단계로 계획한 건 아닙니다. 1단계를 하다 보니 노이즈가 병목이라는 게 보여서 2단계로 간 겁니다." — 연쇄로 말하는 게 오히려 "prompt feedback mechanisms"에 정확히 맞는다.

"96에서 99가 정말 본인 덕인가요?" → "전부 제 덕이라고 말씀드리지 않겠습니다. 제가 방어할 수 있는 건 제가 고친 33건의 시그니처가 실제로 사라졌다는 것이고, 시그니처 단위로 추적했습니다."

"클린 빌드가 왜 반으로 줄죠?" → 클린 = 병렬 컴파일 + 중복 제거 / 증분 = 바뀐 것만 재빌드. 절대 섞지 말 것. 여기서 꼬이면 다른 숫자 신뢰도까지 흔들린다.

"클린 빌드는 정의상 다 처음부터 짓는 건데 왜 반으로 줄죠?"

클린 = 병렬 컴파일 + 중복 제거 / 증분 = 바뀐 것만 재빌드. 절대 섞지 말 것. 여기서 꼬이면 다른 숫자 신뢰도까지 흔들린다.

회원가입은 Wow 카드로 쓰지 않는다. 물어보면 Think Systematically로 답한다 — "같은 계열 버그가 한 달에 다섯 건씩 났고, 그건 구조가 그런 버그를 계속 만들어내는 상태였습니다."

📊 숫자
96→99% (크래시 세션 ¼) · 1,500→400건 · 30분→5분 · 18모듈 27건 · 39모듈·387파일 · 600→300초 · 211→101MB

🪤 순간적으로 헷갈리는 함정 3개

⛔ 지어내지 말 것
MTTR · 회원가입 완료율 · 크래시 화면별 분포 → 전부 "측정하지는 못했습니다"
숫자 근거를 물으면 → "엄밀하게 트래킹한 수치는 아니고, ○○를 기준으로 본 값입니다." 모르는 게 감점이지 정성적인 게 감점이 아니다.

⛔ 내가 먼저 꺼내지 말 것
Customer Obsession · Bias for Action · Earn Trust · Ownership · Learn and Be Curious
전부 아마존 용어. 단, 면접관이 먼저 쓰면 그냥 받아서 답한다.

① 화면을 뒤지지 말 것. 스크롤하면 티가 난다. 이 표 하나만 보고 안 나오면 그냥 말로 푼다.

② 빈칸을 채우려고 지어내지 말 것. MTTR·완주율·크래시 분포는 없는 게 맞다. "측정하지는 못했습니다"가 정답이다.

③ 사과하지 말 것. "죄송합니다, 제가 준비를 못 해서…"는 답변 하나를 인상 전체로 번지게 한다. 담담하게 넘어가면 그 질문 하나로 끝난다.