경험을 상황 → 과제 → 행동 → 결과 순서로 구조화해 말하는 답변 틀.
| 무엇을 말하나 | 분량 | |
|---|---|---|
| Situation | 어떤 상황이었나 (제품·환경·제약) | 짧게 |
| Task | 내가 맡은 문제 | 짧게 |
| Action | 내가 무엇을 어떻게 했나 | 가장 길게 |
| Result | 결과 (수치) + 배운 점 | 짧게 |
임베디드 면접에서의 특수성
"디버깅 과정"을 물어보는 질문이 압도적으로 많다.
"가장 어려웠던 버그는?" "재현이 안 되는 문제를 어떻게 해결했나요?" "현장에서만 발생하는 문제를 다뤄 본 적 있나요?"
이 질문들은 STAR의 A(행동)에서 "어떻게 좁혀 갔는가" 를 본다. 답을 아는 것보다 접근 방법이 평가 대상이다.
좋은 예 — 임베디드 버전
S 산업용 온도 컨트롤러 양산품에서, 현장 300대 중 5대 정도가 하루에 한두 번 재부팅되는 문제가 보고됐습니다. 실험실에서는 2주를 돌려도 재현되지 않았습니다.
T 원인을 찾아 재발을 막는 것이 제 과제였습니다.
A 먼저 리셋 원인을 남기도록 펌웨어를 수정해 배포했습니다.
RCC->CSR을 읽어 워치독 리셋임을 확인했고, HardFault는 아니었습니다. 즉 폴트가 아니라 어딘가에서 멈춘 것이었습니다. 다음으로 태스크별 체크인 방식으로 워치독을 바꿔, 어느 태스크가 멈추는지 기록하게 했습니다. 통신 태스크였습니다. 코드를 보니 RS-485 응답을while루프로 기다리는데 타임아웃이 없었습니다. 노이즈로 응답이 유실되면 영원히 대기하는 구조였습니다. 타임아웃과 재시도를 넣고, 재현 시험을 위해 의도적으로 응답을 누락시키는 테스트 모드를 만들어 검증했습니다.R 배포 후 3개월간 해당 재부팅이 0건이었습니다. 이후 팀에서 모든 블로킹 대기에 타임아웃을 강제하는 코드 리뷰 항목을 추가했고, 리셋 원인 기록을 기본 펌웨어 템플릿에 넣었습니다.
무엇이 좋은가 ✓ 재현 불가 상황에서 "증거를 남기는" 접근을 먼저 했다 ✓ 가설을 하나씩 좁혀 갔다 (폴트인가? → 아니다 → 어느 태스크인가?) ✓ 근본 원인(타임아웃 부재)까지 갔다 ✓ 검증 방법을 만들었다 ✓ 재발 방지를 프로세스로 남겼다 ✓ 숫자가 있다
흔한 실수
| 실수 | 왜 문제 |
|---|---|
| S가 너무 길다 | 배경 설명에 시간을 다 쓴다 |
| "팀이 ~했습니다" | 내 기여가 안 보인다 |
| 결과에 숫자가 없다 | 검증할 수 없다 |
| 도구 이름만 나열 | "오실로스코프로 봤습니다" → 무엇을 어떻게 봤는지가 중요 |
| 운으로 해결 | "이것저것 해 보니 됐습니다" → 방법론이 없어 보인다 |
임베디드에서 준비할 소재
- 재현이 어려운 버그를 추적한 경험 ← 가장 자주 묻는다
- 하드웨어 문제와 소프트웨어 문제를 구분한 경험
- 메모리·성능 제약을 해결한 경험
- 실시간 요구를 만족시킨 경험
- 하드웨어 엔지니어와 협업한 경험
- 양산·현장 문제를 다룬 경험
각 소재마다 숫자 하나씩 — 응답 시간, RAM 절감량, 재부팅 횟수, 전류 소모, 처리량.
꼬리질문을 예상한다
"오실로스코프로 무엇을 봤나요?" "워치독을 어떻게 구현했나요?" "타임아웃 값은 어떻게 정했나요?" "그 방법 말고 다른 대안은 없었나요?"
답변에 등장시킨 모든 용어는 깊게 물어봐도 답할 수 있어야 한다. 임베디드 면접관은 특히 구체적으로 파고든다.