구글리니스(Googleyness)와 Google 행동 면접 질문 (2026)

"구글리니스(Googleyness)"는 Google이 면접에서 조직 문화 적합성을 평가할 때 사용하는 행동 특성의 모음입니다 — 모호한 상황을 어떻게 다루는지, 피드백을 어떻게 받아들이는지, 고장 난 시스템을 어떻게 고치는지, 사용자를 어떻게 지키는지를 봅니다. 이 가이드는 Google 면접을 준비하는 소프트웨어 엔지니어와 인접 직군 지원자를 위한 것이며, 막연한 문화 용어를 실제로 준비할 수 있는 평가 기준으로 바꿔 줍니다. 면접관이 채점하는 네 가지 축, 각 축 뒤에 있는 긍정 신호와 부정 신호, 약한 답변과 강한 답변을 비교한 답변 구조, 반복해서 나오는 질문, 7일 준비 계획을 확인하게 됩니다. 순서대로 따라가 보세요. 먼저 평가 기준을 이해하고, 답변 구조를 익힌 다음, 나만의 스토리 세트를 만들어 연습하면 됩니다.

핵심 요약

• 구글리니스는 성격 테스트가 아니라 행동 평가 기준입니다. 모호함 속에서 성장하기, 피드백 존중하기, 현상 유지에 도전하기, 사용자를 최우선으로 생각하기의 네 가지를 채점합니다.
• 이 라운드는 대개 별도로 채점되는 면접이며, 흔히 Leadership and Rapport라고 부릅니다. 코딩 라운드를 잘 봤더라도 행동 면접에서 분명한 위험 신호가 나오면 이를 만회하지 못합니다.
• STAR-L(Situation, Task, Action, Result, Learnings)을 사용하세요. Google 면접관은 Action을 가장 집요하게 파고들기 때문에, 그 안의 모든 주장에는 구체적인 근거가 있어야 합니다.
• 얕은 스토리 20개보다 깊이 있고 재사용할 수 있는 스토리 6~8개를 준비하고, 각 스토리를 두 개 이상의 평가 축에 연결해 두면 상황에 맞게 바꿔 답할 수 있습니다.
• 내가 한 행동에는 "I(저는)"를, 팀의 성과에는 "we(저희는)"를 쓰세요. 기술적으로 뛰어난 지원자가 이 라운드에서 낮은 점수를 받는 가장 흔한 이유 중 하나가 불분명한 주인의식입니다.

구글리니스는 실제로 무엇을 평가하는가

질문을 연습하기 전에, 이 단어가 무엇을 대신 가리키는지 알아 두면 도움이 됩니다. 흔히 알려진 해석은 틀렸기 때문입니다.

구글리니스는 개성이 강하거나, 외향적이거나, 팀원들과 비슷한 사람이 되는 것과는 상관없습니다. 이는 일하는 방식을 가리키는 줄임말입니다. 정해진 형태가 없는 문제 앞에서 어떻게 움직이는지, 동료가 내 설계 문서를 낱낱이 비판할 때 어떻게 반응하는지, 아무도 맡기지 않은 문제를 고치는지, 마감과 품질이 부딪칠 때 누구의 이익을 따져 보는지를 봅니다. 지원자들은 검색할 때 "Googliness"나 "Googlyness"로도 쓰며, 채용 담당자도 이 표기들을 구분 없이 사용합니다.

준비 방식에 영향을 주는 구조적 사실이 두 가지 있습니다.

1. 대개 따로 채점됩니다. 행동 면접은 보통 코딩, 설계 면접 결과와 함께 심사 자료에 들어가는 별도의 평가 결과를 만듭니다. 마지막에 나누는 편안한 대화가 아닙니다.
2. 다른 모든 라운드에도 영향을 줍니다. 코딩 면접관의 힌트를 어떻게 받아들이는지, 누군가 내 데이터 모델에 의문을 제기할 때 어떻게 대응하는지, 채용 담당자를 어떻게 대하는지는 모두 관찰되는 행동입니다. 전체 면접 과정이 평가의 일부라고 생각하세요.

관점을 바꾸면 도움이 됩니다. 면접관은 "이 사람이 좋은 사람인가?"를 묻는 것이 아니라 "이 사람이 합류하면 우리 팀의 속도와 품질이 어떻게 되는가?"를 묻습니다. 여러분이 하는 모든 이야기는 이 두 번째 질문에 답해야 합니다.

간단한 예시 상황: 두 지원자가 같은 프로젝트 진행 상황을 보고합니다. "마이그레이션은 거의 끝났고, 예외 케이스가 몇 개 남았습니다." 지원자 A는 거기서 말을 멈추고 다음으로 넘어갑니다. 지원자 B는 이렇게 덧붙입니다. "예외 케이스는 ID 형식이 잘못된 레거시 계정 세 개입니다. 티켓을 등록했고, 이 문제가 해결되기 전에 전환하면 대시보드가 깨지는 두 팀에도 알렸습니다." 면접장에서 두 사람 모두 호감 가는 인상을 줍니다. 하지만 구글리니스가 있다고 읽히는 사람은 B뿐입니다. 두 번째 답변은 "내가 호감형인가"가 아니라 "우리 팀의 속도와 품질이 어떻게 되는가"에 답하기 때문입니다.

구글리니스의 네 가지 평가 축

큰 틀을 잡았으니, 이제 평가 기준 자체를 축별로 살펴보겠습니다. 각 축에서 지원자가 가장 자주 하는 실수도 함께 짚습니다.

1. 모호함 속에서 성장하기

정의: 명세도, 담당자도, 완료 기준도 없이 주어진 문제에서 앞으로 나아가는 능력입니다.

면접관이 중요하게 보는 이유: Google 규모에서는 가치 있는 문제 대부분이 범위가 정해진 채로 오지 않습니다. 지시가 없다고 멈춰 서는 엔지니어는, 가끔 엉뚱한 것을 빠르게 만들었다가 바로잡는 엔지니어보다 팀에 더 큰 비용을 치르게 합니다.

보여 주는 방법: 혼란스러운 상황에 어떤 구조를 만들었는지 설명하세요. 누구와 이야기했는지, 어떤 데이터를 뽑았는지, 무언가를 배우기 위해 출시할 수 있는 가장 작은 단위는 무엇이었는지, 그리고 진행 도중 바뀐 요구사항을 어떻게 다뤘는지 말하면 됩니다.

흔한 실수: 답변 대부분을 프로젝트의 범위가 얼마나 엉망이었는지 설명하는 데 쓰는 것입니다. 모호함에 대한 불평은 그 상황을 불편해한다는 인상을 줍니다.

답변 도입부 예시: "결제 지연 시간을 줄이라는 지시를 받았는데, 느린 네트워크 환경의 사용자를 대상으로 하라는 것 외에는 목표도 담당자도 없었습니다. 저는 먼저 연결 유형별로 나눈 일주일 치 클라이언트 측 측정 데이터를 뽑았고, p90이 페이로드 크기가 아니라 설정값을 가져오는 하나의 차단 요청에 좌우된다는 것을 확인했습니다. 덕분에 논의할 수 있는 구체적인 목표가 생겼습니다."

2. 피드백 존중하기 (지적 겸손)

정의: 나 자신과 내가 만든 결과물을 분리해서, 설계에 대한 비판을 공격이 아니라 정보로 받아들이는 태도입니다.

면접관이 중요하게 보는 이유: Google의 엔지니어링 문화는 코드 리뷰와 공개적으로 토론하는 설계 문서를 바탕으로 돌아갑니다. 방어적인 엔지니어는 모든 리뷰 사이클을 더디게 만들고, 사람들이 실제 문제를 지적하는 것을 은연중에 막습니다.

보여 주는 방법: 누군가가 내 생각을 바꿔 놓은 이야기를 하되, 상대가 정확히 무슨 말을 했고 내가 무엇을 바꿨는지 구체적으로 밝히세요. 피드백이 듣기 불편했거나 나보다 경력이 낮은 사람에게서 나왔다면 더 좋습니다.

흔한 실수: 내가 동의하지 않았고 나중에 틀렸다는 것을 증명한 피드백을 고르는 것입니다. 그것은 겸손이 아니라 내가 옳았다는 이야기입니다.

답변 일부 예시: "팀의 신입 사원이 제 캐싱 계층이 권한을 회수한 뒤에도 최대 5분 동안 이전 권한을 그대로 제공한다고 지적했습니다. 처음에는 그 정도 시간은 감수할 만하다고 생각했습니다. 하지만 곰곰이 생각해 보니 저는 성능만 따졌을 뿐 보안 문제는 고려하지 않았다는 것을 깨달았고, 권한을 쓸 때 명시적으로 캐시를 무효화하도록 추가했습니다."

3. 현상 유지에 도전하기

정의: 무언가가 고장 났거나 느리다는 것을 알아채고, 시키지 않아도 이를 고치는 것입니다. 맡은 영역 밖의 일이어도 마찬가지입니다.

면접관이 중요하게 보는 이유: 이것이 주인의식을 보여 주는 신호입니다. 티켓만 처리하는 엔지니어와 주변 모두의 수준을 끌어올리는 엔지니어를 가르는 기준입니다.

보여 주는 방법: 내가 없앤 구체적인 비효율을 고르고, 손대기 전에 그것이 어떤 비용을 치르고 있었는지 수치로 표현하세요. 팀 간 협업이 들어가면 이야기가 더 탄탄해집니다. 내 보고 라인 밖에서 더 높은 기준을 요구하는 것이 진짜 어려운 일이기 때문입니다.

흔한 실수: 이를 반항처럼 포장하는 것입니다. "기존 시스템이 형편없었다"는 말은 좋지 않게 들립니다. 반대 의견을 내기 전에 기존 방식이 왜 그렇게 되어 있었는지 이해했다는 점을 보여 주세요.

답변 일부 예시: "통합 테스트 스위트가 너무 오래 걸려서 사람들이 병합을 하루 끝에 몰아서 했고, 그 때문에 실패 원인을 찾기 어려웠습니다. 아무도 이 문제를 맡고 있지 않았습니다. 저는 스위트를 프로파일링해서 몇 개의 테스트가 전체 픽스처 데이터를 매번 다시 채우고 있다는 것을 찾았고, 트랜잭션 범위의 픽스처를 공유하도록 다시 작성했습니다. 그 뒤로 병합이 다시 수시로 이루어졌습니다."

4. 옳은 일 하기 (사용자를 최우선으로 생각하기)

정의: 장기적인 사용자 신뢰, 접근성, 개인정보, 안전을 단기적인 출시 압박과 저울질하고, 둘이 충돌할 때 목소리를 내는 것입니다.

면접관이 중요하게 보는 이유: Google 규모의 제품은 스프린트 안에서 한 팀이 볼 수 없는 파급 효과를 낳습니다. 면접관은 다른 누군가가 하겠지 하고 넘기지 않고 우려를 직접 제기하는 엔지니어를 원합니다.

보여 주는 방법: 비즈니스 목표와 사용자의 이익이 부딪혔던 순간을 찾고, 사용자를 외면했을 때 치르게 될 비용을 구체적으로 보여 준 경험을 이야기하세요. "잘못된 방향이라고 주장했습니다"는 약합니다. "이 흐름이 화면 낭독기 사용자에게는 완전히 실패하며, 이들이 가입자의 N%라는 것을 보여 주었습니다"는 강합니다. 실제로 이야기할 때는 N 자리에 본인의 실제 수치를 넣으세요.

흔한 실수: 실제 갈등이 없는 사례를 고르는 것입니다. 아무도 내 의견에 반대하지 않았다면, 내가 무언가를 옹호한 것이 아닙니다.

답변 일부 예시: "실험에서 참여도가 올랐기 때문에 새 공유 설정을 기본값 켜짐으로 하려는 계획이었습니다. 저는 이 설정이 사용자가 기본적으로 비공개라고 생각하고 입력했던 데이터를 노출한다고 문제를 제기했습니다. 결국 기본값은 꺼짐으로 하고 안내 메시지를 띄우는 방식으로 출시했고, 기존 사용자가 조용히 동의 처리되는 일이 없도록 마이그레이션 안내문도 작성했습니다."

긍정 신호와 부정 신호 비교

앞의 네 가지 평가 축은 일관된 신호들을 통해 채점됩니다. 강력한 합격 후보로 읽히는 모습과 불합격으로 읽히는 모습을 나누면 다음과 같습니다.

패턴은 일관됩니다. 주인의식, 근거, 공을 나누는 태도는 Googly로 읽힙니다. 책임 전가, 자존심, 데이터보다 의견을 앞세우는 태도는 위험 신호로 읽힙니다.

Google 행동 면접 질문에 답하는 방법

신호를 알고 있어도 전달 방식이 그것을 묻어 버리면 소용이 없습니다. 그래서 다음 단계는 신호가 자연스럽게 드러나는 답변 구조입니다.

사용할 구조는 STAR-L입니다. Situation, Task, Action, Result, 그리고 Learnings로 이루어집니다. 추가된 L이 Google에서는 중요합니다. 면접관은 어떤 경험을 했다는 사실만이 아니라, 그 경험이 내가 일하는 방식을 바꿨다는 근거를 원하기 때문입니다. 기본 방법부터 복습하고 싶다면 PracHub의 FAANG 사례로 보는 STAR 기법 가이드를 참고하세요.

시간을 의도적으로 배분하세요.

후속 질문이 나오기 전까지 전체 이야기를 3분 이내에 마칠 수 있게 연습하세요. 면접관은 Action을 가장 깊이 파고들 것으로 예상하세요. "제가 PM을 설득해 로드맵을 바꾸게 했습니다"라고 말하면, 다음 질문은 거의 틀림없이 "어떤 데이터를 보여 줬고, 상대방은 어떻게 반박했나요?"입니다. 모호한 이야기는 이런 압박 앞에서 무너지고, 구체적인 이야기는 오히려 더 단단해집니다.

Google 채용팀은 리더십 및 행동 면접 라운드를 위해 지원자를 어떻게 코칭하는지에 대한 영상 안내를 공개했습니다.

실전 예시: 같은 이야기, 약한 답변과 강한 답변

아래 두 답변은 같은 사건을 설명합니다. 점수를 받는 것은 두 번째 답변뿐입니다.

약한 답변 (예시 답변): "저희 서비스가 계속 다운돼서 제가 재시도 로직을 다시 작성했더니 나아졌습니다. 팀도 만족했습니다."

강한 답변 (예시 답변): "Situation: 결제 서비스에서 하위 시스템의 타임아웃이 연쇄적으로 번져 일주일에 두 번꼴로 온콜 담당자에게 알림이 갔는데, 이 알림을 맡은 사람이 아무도 없었습니다. Task: 제 직접적인 담당 영역은 아니었지만 제가 이 문제를 맡았습니다. Action: 한 달 치 트레이스 데이터를 뽑아서, 백오프가 없는 재시도 경로 하나가 부분 장애 때 부하를 증폭시키고 있다는 것을 찾았습니다. 지터를 적용한 지수 백오프를 제안하는 짧은 설계 문서를 작성했습니다. 시니어 엔지니어가 이렇게 하면 진짜 문제인 상위 시스템의 장애를 가릴 수 있다고 반론을 제기했고, 타당한 지적이었기 때문에 상위 시스템 장애를 숨기지 않고 따로 보여 주는 대시보드를 추가했습니다. 플래그를 걸고 출시한 뒤 점진적으로 배포했습니다. Result: 그 연쇄 장애로 인한 알림은 멈췄고, 새 대시보드는 이후 몇 주 동안 상위 시스템의 회귀 두 건을 잡아냈습니다. Learnings: 이제는 코드를 바꾸기 전에 먼저 관측 가능성부터 확보합니다. 그 피드백 덕분에 '증상을 고친다'는 생각이 '장애가 눈에 보이게 만든다'로 바뀌었기 때문입니다."

강한 답변이 평가 축의 이름을 한 번도 말하지 않고도 무엇을 하는지 살펴보세요. 아무도 맡지 않은 문제를 가져오고(현상 유지에 도전하기), 비판을 받아들여 설계를 바꾸고(피드백 존중하기), 직감이 아니라 트레이스 데이터를 쓰고(문제 해결), 접근 방식이 실제로 달라졌다는 말로 끝납니다(Learnings). 구글리니스를 주장하는 것이 아니라 보여 주는 답변입니다.

자주 나오는 구글리니스 면접 질문

구조를 갖췄으니, Google 행동 면접에서 반복적으로 나오는 질문 유형을 각각 평가하는 축과 함께 살펴보겠습니다. 다른 회사의 기준에 맞춰 같은 패턴을 폭넓게 연습하려면 PracHub의 기출 문제 모음을 활용하세요.

아래 7번부터 12번 질문은 PracHub에서 Google 지원자들이 직접 제출한 면접 후기에서 가져왔으며, 현장 면접과 기술 스크리닝을 마친 뒤 올린 내용입니다. 같은 네 가지 평가 축에 해당하지만, 표현은 면접관이 실제로 한 말에 더 가깝습니다. 더 보려면 보고된 Google 행동 면접 질문 전체를 둘러보세요.

1. "요구사항이 전혀 명확하지 않은 상황에서 문제를 해결한 경험을 말해 주세요."

평가 항목: 모호함 속에서 성장하기.

답변 방법: 처음 마주한 혼란이 아니라 내가 만든 구조로 시작하세요. 이해관계자를 파악하고, 직접 찾아 확보한 부족한 데이터를 밝히고, 가장 작지만 쓸모 있는 단위를 제안한 다음 반복해서 개선합니다.

예시 방향: 성공 기준이 정해지지 않았던 마이그레이션에서, 측정 가능한 기준 세 가지를 직접 제안하고 합의를 얻은 사례.

2. "프로덕션이나 팀에 영향을 준 큰 실수에 대해 말해 주세요."

평가 항목: 지적 겸손, 피드백 존중하기.

답변 방법: 겸손을 가장한 자기 자랑이 아니라 실제로 결과가 있었던 진짜 실수를 고르세요. 실수 자체에는 시간을 조금만 쓰고, 근본 원인, 책임을 묻지 않는 사후 분석, 그리고 한 번의 사례가 아니라 그 유형의 실패 자체를 없애는 구체적인 안전장치에 답변 대부분을 쓰세요.

예시 방향: 한 리전을 다운시킨 설정 변경에서, 해결책이 "더 조심하자"가 아니라 배포 파이프라인에 검증 단계를 넣는 것이었던 사례.

3. "기술 리드나 매니저와 강하게 의견이 충돌했던 경험을 말해 주세요."

평가 항목: 현상 유지에 도전하기, 협업.

답변 방법: 의견 충돌이 근거에 바탕을 두고 있었고 정중하게 전달되었음을 보여 준 뒤, 결정이 내려진 후에 어떻게 되었는지 보여 주세요. 내 의견과 반대로 내려진 결정에 온전히 힘을 싣는 부분을 대부분의 지원자가 빼먹는데, 바로 이 부분이 긍정 신호와 위험 신호를 가릅니다.

예시 방향: 다른 스토리지 엔진을 주장했다가 받아들여지지 않았지만, 선택된 방식을 안전하게 운영할 수 있게 해 주는 벤치마크 도구를 직접 만든 사례.

4. "내 담당 범위 밖의 비효율적인 프로세스를 개선한 경험을 말해 주세요."

평가 항목: 현상 유지에 도전하기, 주인의식.

답변 방법: 고치기 전에 그 비효율이 조직에 어떤 비용을 치르게 하고 있었는지 밝히세요. 내부 도구, 부족한 문서, 불안정한 테스트 스위트, 몇 주가 걸리는 온보딩 프로세스 모두 좋은 소재입니다. 개선 전의 상태를 구체적으로 설명할 수 있기만 하면 됩니다.

예시 방향: 아무도 신뢰하지 않던 런북을, 온콜 로테이션 두 번을 직접 따라다니며 관찰한 뒤 다시 쓴 사례.

5. "사용자에게 맞지 않는다는 이유로 어떤 기능에 반대했던 경험을 말해 주세요."

평가 항목: 옳은 일 하기, 사용자 최우선.

답변 방법: 비즈니스 목표와 사용자의 이익 사이에 진짜 갈등이 있었던 사례를 찾고, 장기적인 비용을 다른 사람들이 따져 볼 수 있을 만큼 구체적으로 보여 준 과정을 설명하세요.

예시 방향: 전환율 지표는 높였지만 권한 요청을 거부한 사용자를 막다른 길에 몰아넣었던 온보딩 단계.

6. "누군가를 온보딩하거나 멘토링한 경험을 말해 주세요."

평가 항목: 협업, 자연스럽게 드러나는 리더십.

답변 방법: 성공을 내 결과물이 아니라 상대의 자립으로 측정하세요. 처음의 설명이 잘 전달되지 않았을 때 설명 방식을 어떻게 바꿨는지 말하면, 단순한 업무 위임이 아니라 진짜 멘토링을 했다는 점이 드러납니다.

예시 방향: 합류 6주 만에 처음으로 단독 설계 문서를 낸 팀원, 그리고 그렇게 되도록 내가 의도적으로 그만둔 일.

7. "요구사항이 아직 모호한 상태에서 프로젝트를 이끈 경험을 말해 주세요."

평가 항목: 모호함 속에서 성장하기, 자연스럽게 드러나는 리더십.

답변 방법: 이 질문은 나 혼자 하는 메모 정리가 아니라 사람에 관한 것입니다. 답이 나오기 전에 팀이 향해 갈 무언가를 어떻게 마련했는지 보여 주세요. 문서로 정리한 가설, 열린 질문마다 정한 결정 담당자, 각 가정을 확인하거나 버릴 기한이 그 예입니다. 팀이 막히지 않도록 일부러 결정하지 않고 남겨 둔 것이 무엇인지도 말하세요.

예시 방향: 최선의 추측을 바탕으로 좁은 범위의 v0를 먼저 출시하고, 팀이 오래 논쟁하던 두 가지 요구사항을 실제 사용 데이터로 정리한 프로젝트 — PracHub에서 Google 지원자가 보고한 질문입니다: 질문 보기.

8. "힘든 피드백을 받았던 경험을 말해 주세요. 어떻게 대응했나요?"

평가 항목: 피드백 존중하기, 지적 겸손.

답변 방법: 피드백이 나중에 돌아보니 타당했던 것처럼 포장하고 싶은 충동을 참으세요. 실제로 들은 말, 첫 반응, 그리고 그 반응과 이후에 한 행동 사이의 차이를 말하세요. 핵심 신호는 상대에게 다시 가서 내가 제대로 이해했는지 확인했는지, 그리고 그 후 내 행동에서 구체적으로 무엇이 달라졌는지입니다.

예시 방향: 설계 회의에서 의견 충돌을 다루는 방식에 대한 리뷰 코멘트를 처음에는 반박했다가, 다른 팀원 두 명에게 물어 확인해 본 사례 — PracHub에서 Google 지원자가 보고한 질문입니다: 질문 보기.

9. "큰 실패와 그로 인해 바꾼 점에 대해 말해 주세요."

평가 항목: 지적 겸손, 옳은 일 하기.

답변 방법: 다른 사람의 결정 때문이 아니라 내가 직접 책임졌던 실패를 고르세요. 내가 잘못 내린 판단이 무엇이었고, 당시에는 왜 옳아 보였는지 밝히세요. 그런 다음 체크리스트, 롤백 정책, 다른 에스컬레이션 습관처럼 오래 가는 변화와, 그것이 이후 프로젝트에서도 유지되었는지를 답변 대부분에 쓰세요.

예시 방향: 롤백 방안 없이 승인한 출시가, 지금도 직접 운영하는 출시 전 상시 리뷰로 이어진 사례 — PracHub에서 Google 지원자가 보고한 질문입니다: 질문 보기.

10. "함께 일하기 어려웠던 동료와 어떻게 일했나요?"

평가 항목: 협업, 옳은 일 하기.

답변 방법: 그 동료를 악당으로 만들지 말고, 문제가 없었다고도 하지 마세요. 인수인계 누락이나 서로 모순되는 리뷰 같은 구체적인 마찰을 설명하고, 내 쪽에서 먼저 무엇을 바꿨는지 말하세요. 그런 다음 문제를 해결한 장치를 보여 주세요. 공유 문서, 정기 싱크, 더 명확한 역할 경계가 그 예입니다. 결과는 관계가 아니라 일의 성과로 판단하세요.

예시 방향: 리뷰어의 차단 코멘트 때문에 일이 늦어지다가, 그 사람이 중요하게 보는 제약 조건을 미리 묻고 풀 리퀘스트를 그에 맞춰 다시 구성한 사례 — PracHub에서 Google 지원자가 보고한 질문입니다: 질문 보기.

11. "직접 만든 프로젝트의 트레이드오프를 설명하고 그것을 옹호해 보세요."

평가 항목: 현상 유지에 도전하기, 압박 속의 기술적 판단.

답변 방법: 트레이드오프를 현실로 만든 제약 조건을 밝히세요. 마감, 비용 한도, 팀 규모, 기존 시스템이 그 예입니다. 내가 버린 선택지와, 그 대가로 감수한 구체적인 비용을 말하세요. 반박이 나올 것으로 예상하고, 그것을 실제 질문으로 받아들이세요. 근거가 여전히 유효한 부분에서는 입장을 지키고, 새로운 정보가 판단을 바꿀 수 있는 부분에서는 분명하게 인정하세요.

예시 방향: 쓰기 쪽 복잡도가 커질 줄 알면서도, 사용자들이 불평하던 것이 쿼리 지연 시간이었기 때문에 비정규화된 읽기 경로를 선택한 사례 — PracHub에서 Google 지원자가 보고한 질문입니다: 질문 보기.

12. "다른 팀이 내가 만들던 것과 같은 것을 만들고 있다는 걸 알았을 때 어떻게 했나요?"

평가 항목: 옳은 일 하기, 팀을 넘나드는 자연스러운 리더십.

답변 방법: 흔한 실패 유형은 내가 만든 버전을 방어하는 것입니다. 논쟁하기 전에 먼저 상대 팀의 작업을 찾아 읽어 봤다는 점을 보여 주고, 누구의 것이냐가 아니라 어느 시스템이 살아남아야 하는지로 선택을 정리했다는 점을 설명하세요. 결정을 위해 누구를 참여시켰는지 말하고, 결론이 우리 팀이 작업을 멈추고 상대 팀의 것을 채택하는 것이었다면 솔직하게 밝히세요.

예시 방향: 병행되던 내부 도구를 발견하고, 두 팀 모두 문서로 정리하지 않았던 사용 사례를 기준으로 둘을 비교한 뒤, 데이터 모델이 더 나은 쪽으로 합친 사례 — PracHub에서 Google 지원자가 보고한 질문입니다: 질문 보기.

Google은 리더십을 어떻게 평가하는가 (IC도 해당)

위 질문 중 여럿은 사람을 관리하지 않는 직무에서도 리더십을 묻습니다. 개인 기여자(IC) 트랙의 지원자들은 이 점을 의외로 받아들입니다.

Google은 자연스럽게 드러나는 리더십을 평가합니다. 팀이 위기, 방향 전환, 기술적 교착 상태에 부딪혔을 때 직함 없이 나서는 사람이 있는지를 봅니다. 핵심은 권한 없는 영향력입니다. 조직도에서 어디에 앉아 있는지가 아니라, 생각하고 소통하는 방식으로 그룹을 움직이는 것입니다.

IC로서 이를 보여 주는 방법은 다음과 같습니다.

• 경력이 적은 엔지니어를 멘토링하고, 그들에게 무엇이 달라졌는지 구체적으로 밝힙니다.
• 서로 말이 겉돌던 팀들 사이에서 기술적 연결 고리 역할을 합니다.
• 데이터가 뒷받침하는 타협안을 중재해 시니어 동료들 사이의 교착 상태를 풉니다.
• 모두가 피해 다니는, 빛나지 않는 공용 영역(불안정한 파이프라인, 오래된 런북)을 자원해서 맡습니다.

간단한 예시 상황: 두 팀이 서로 공유 이벤트 스트림의 스키마 검증을 상대 팀이 맡는다고 생각해서, 잘못된 이벤트가 양쪽 모두로 흘러 들어갔습니다. 어느 팀 리드도 그 일을 떠맡고 싶어 하지 않았습니다. 한 페이지짜리 제안서를 쓰고, 두 리드를 20분 동안 한자리에 모은 뒤, 담당자를 정해서 나오는 IC는 타고난 리더라고 주장하는 어떤 말보다 더 설득력 있게 자연스러운 리더십을 보여 준 것입니다.

관리자 트랙을 목표로 한다면, 팀에 대해 공식적으로 책임을 지는 순간부터 기준이 달라집니다. PracHub의 엔지니어링 매니저 행동 면접 가이드가 그 차이를 다룹니다.

뛰어난 엔지니어도 탈락시키는 흔한 실수

스토리 세트를 만들기 전에 실패 유형을 알아 둘 만합니다. 대부분은 면접장이 아니라 원고를 다듬는 단계에서 피할 수 있기 때문입니다.

한 줄로 보는 개선 예시: "저희가 안정성을 많이 개선했습니다"를 "제가 재시도 증폭 경로를 제거했고, 그 알림으로 발생하던 주간 호출 횟수가 0이 되었습니다"로 바꾸세요. 같은 사건이지만 채점할 수 있는 버전입니다.

7일 준비 계획

위 내용을 모두 안다고 해도 소리 내어 연습하기 전에는 아무것도 달라지지 않습니다. 그래서 평가 기준을 실제 전달로 바꿔 주는 일정을 소개합니다.

이 계획이 효과를 내려면 세 가지 규칙이 필요합니다.

• 넓이보다 깊이. 후속 질문 세 번을 견딜 수 있는 스토리 6~8개가, 요약만 할 수 있는 20개보다 낫습니다.
• 연습하기 전에 연결부터. 어떤 질문이 나올지 통제할 수 없는 45분 이상의 라운드에서는, 두 가지 축을 다루는 스토리 하나가 두 배의 가치를 갖습니다.
• 스스로 녹화하세요. 내 답변을 직접 들으면, 읽는 것보다 훨씬 빠르게 군더더기와 빠진 근거가 눈에 들어옵니다.

모의 면접이 마무리를 해 줍니다. 실제로 보고된 질문으로 연습하면 면접장에 들어가기 전에 스토리가 버티는지 알 수 있고, 같은 스토리 세트를 다른 FAANG 행동 면접에도 적용해 보면 어느 회사에서 먼저 연락이 오든 쓸모가 있습니다.

FAQ

이 라운드를 준비하기 시작한 지원자들이 자주 묻는 질문입니다.

면접에서 "구글리니스"는 무슨 뜻인가요?

Google이 평가하는 행동 프로필입니다. 모호함 속에서 성장하기, 지적 겸손, 피드백 존중하기, 시스템 개선을 위해 현상 유지에 도전하기, 사용자를 최우선으로 생각하기가 포함됩니다. 흔히 Leadership and Rapport 라운드라고 부르는 전용 행동 면접에서 평가되며, 기술 면접 결과와 함께 채점됩니다.

Leadership and Rapport 면접을 준비하는 가장 좋은 방법은 무엇인가요?

긴 목록의 얕은 스토리 대신 깊이 있는 스토리 세트를 만드세요. 1215개의 후보 경험을 정리하고, 그중 68개를 STAR-L로 글로 쓰고, 각각을 두 개 이상의 평가 축에 연결한 뒤, 예상되는 후속 질문에 맞춰 소리 내어 연습하세요. 위의 7일 계획이 이 순서를 하루 단위로 안내합니다.

구글리니스가 부족하면 Google 면접에서 탈락할 수 있나요?

네. 행동 평가는 심사 자료에서 실제로 비중이 있습니다. 일부 지원자는 코딩과 시스템 디자인 라운드를 통과하고도, 팀원 탓하기, 피드백에 대한 방어적 태도, 모호한 문제를 구조화하지 못하는 모습 같은 위험 신호가 행동 라운드에서 드러나 불합격했다고 보고합니다.

구글리니스는 Amazon의 Leadership Principles와 어떻게 다른가요?

둘 다 행동을 평가하지만 강조점이 다릅니다. Amazon의 Leadership Principles는 공개된 명시적 목록이며 주인의식과 실행 속도에 밀접하게 연결되어 있고, 면접관은 답변을 명명된 원칙에 대응시키는 경우가 많습니다. 구글리니스는 체계화된 정도가 낮고, 호기심, 협력적 문제 해결, 팀이 제대로 돌아가게 만드는 방식에 더 무게를 둡니다. 실제로는 Amazon은 얼마나 단호하게 실행하는지를, Google은 어렵고 불분명한 문제에서 다른 사람들과 얼마나 잘 일하는지를 더 중요하게 봅니다.

행동 면접 스토리는 실제로 몇 개를 준비해야 하나요?

대개 6~8개면 충분합니다. 각 스토리가 후속 질문을 견딜 만큼 구체적이고, 두 개 이상의 평가 축에 연결되어야 합니다. 면접관은 스토리 개수가 아니라 깊이를 파고들기 때문에, 10분 동안 방어할 수 있는 스토리 하나가 소개만 할 수 있는 세 개보다 낫습니다.

Google은 지금도 브레인티저 질문을 하나요?

Google은 학교 버스에 골프공이 몇 개 들어가는지 추정하는 것 같은 전형적인 브레인티저가 실제 업무 성과를 예측하지 못한다고 판단한 뒤, 공개적으로 이를 멀리했습니다. 행동 라운드는 이제 실제 과거 경험에 초점을 맞춥니다. 일부 직무에는 여전히 열린 추정 문제가 포함되지만, 정답을 맞히는 요령이 아니라 추론 과정과 가정을 기준으로 채점됩니다.

구글리니스는 따로 채점되나요, 아니면 기술 라운드에 포함되나요?

대개는 별도로 채점되는 면접이지만, 기술 라운드의 면접관도 행동 관찰 내용을 기록할 수 있습니다. 힌트를 어떻게 받아들이는지, 내 접근 방식에 대한 반론을 어떻게 다루는지, 시간 압박 속에서 어떻게 소통하는지가 그 예입니다. 면접 과정의 모든 상호작용이 행동 평가의 일부라고 생각하세요.

같은 스토리를 서로 다른 두 질문에 사용해도 되나요?

네, 오히려 그렇게 설계해야 합니다. 모호한 문제, 힘든 피드백, 사용자와 관련된 트레이드오프가 모두 담긴 스토리 하나는, 매번 강조점을 달리해서 세 가지 질문에 답할 수 있습니다. 같은 면접관에게 똑같은 스토리를 두 번 쓰는 것은 피하고, 한 라운드 안에서는 절대 재사용하지 마세요.

실제 Google 행동 면접 질문으로 연습하기

이 모든 것을 구체적으로 만드는 가장 빠른 방법은 Google이 실제로 묻는 질문으로 연습하는 것입니다. 최근 지원자들이 보고한 실제 Google 행동·리더십 면접 질문을 둘러보고, 면접의 나머지 과정은 더 넓은 Google 기출 문제 모음에서 확인하세요. 그리고 STAR-L 스토리를 하나씩 꺼내 후속 질문 세 번을 버틸 때까지 점검해 보세요.