경험을 상황 → 과제 → 행동 → 결과 순서로 구조화해 말하는 답변 틀.
| 무엇을 말하나 | 분량 | |
|---|---|---|
| Situation | 어떤 상황이었나 (배경·규모) | 짧게 |
| Task | 내가 맡은 문제는 무엇이었나 | 짧게 |
| Action | 내가 무엇을 어떻게 했나 | 가장 길게 |
| Result | 결과가 어땠나 (수치) | 짧게 + 배운 점 |
왜 이 순서인가
면접관이 알고 싶은 것은 "이 사람이 우리 회사에서 어떻게 일할까" 다. 과거 행동이 가장 좋은 예측 지표라고 보기 때문에 행동 기반 질문을 한다.
A(행동)가 답변의 핵심인데, 준비 없이 말하면 S에서 배경만 길게 설명하다 정작 무엇을 했는지 흐릿하게 끝난다. 그것을 막는 장치다.
좋은 예
S 일 100만 건을 처리하는 주문 API에서 p99 응답이 3초까지 올라갔습니다. 사용자 이탈 문의가 하루 20건씩 들어오던 상황이었습니다.
T 원인을 찾아 p99를 500ms 이하로 낮추는 것이 제 과제였습니다.
A APM으로 구간을 나눠 보니 주문 목록 조회가 2.8초를 차지했습니다. 실행계획을 확인해 보니
member_id인덱스를 타지 못하고 있었는데, 조건에DATE(created_at)함수를 씌워 인덱스가 무효화된 것이 원인이었습니다. 범위 조건으로 바꾸고(member_id, created_at)복합 인덱스를 추가했습니다. 추가로 목록 조회에 N+1이 있어default_batch_fetch_size를 적용했습니다. 변경 전후를 부하 테스트로 비교해 회귀가 없는지 확인했습니다.R p99가 3초에서 320ms로 줄었고 이탈 문의가 사라졌습니다. 이후 팀에서 PR 체크리스트에 실행계획 확인 항목을 추가했습니다.
흔한 실수
| 실수 | 왜 문제인가 |
|---|---|
| S가 너무 길다 | 배경 설명에 2분을 쓰면 정작 행동을 말할 시간이 없다 |
| "우리 팀이 ~했습니다" | 내가 무엇을 했는지가 안 보인다 |
| 결과에 숫자가 없다 | "빨라졌습니다"는 검증할 수 없다 |
| 실패를 숨긴다 | 시도했다 안 된 것과 그 판단 근거가 오히려 신뢰를 준다 |
| 기술 나열 | "Redis를 썼습니다"보다 "왜 Redis였나"가 중요하다 |
왜 그렇게 했는지를 반드시 넣는다
❌ "캐시를 적용해서 빨라졌습니다" ✅ "먼저 인덱스로 해결을 시도했지만 집계 쿼리라 한계가 있었고,
- 데이터가 5분 정도 늦어도 되는 성격이라 캐시를 선택했습니다"
대안을 검토하고 근거로 골랐다는 것이 드러나야 한다. 면접관이 보는 것은 결과가 아니라 판단 과정이다.
미리 준비할 소재
- 성능을 개선한 경험
- 장애를 해결한 경험
- 기술을 선택하고 그 근거를 댄 경험
- 협업 중 갈등을 조정한 경험
- 실패했지만 배운 경험
각 소재마다 숫자 하나씩은 외워 둔다 — 응답 시간, 처리량, 비용, 건수. "3초 → 320ms" 같은 구체적 수치가 답변의 신뢰도를 크게 올린다.
꼬리질문을 예상한다
좋은 답변은 반드시 꼬리질문을 부른다. "인덱스를 추가하면 쓰기 성능은 어떻게 됐나요?" "부하 테스트는 어떤 도구로 했나요?" "같은 문제가 다시 안 생기게 어떻게 했나요?" 답변에 등장시킨 모든 기술 용어는 깊게 물어봐도 답할 수 있어야 한다. 모르면서 언급하는 것이 가장 위험하다.