<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Interviews · 인재덕</title>
    <link>https://jared.lynskey.co.nz/ko/tags/interviews/</link>
    <description>소프트웨어 엔지니어링과 개발 조직 리더십에 대한 이야기. 성과 리뷰, 채용과 팀 확장, CI/CD, 데브옵스 모니터링, 에이전틱 AI. 서울에서 씁니다.</description>
    <generator>Hugo</generator>
    <language>ko</language>
    <copyright>© 2026 인재덕</copyright>
    <lastBuildDate>Thu, 22 Oct 2026 00:00:00 +1200</lastBuildDate>
    <atom:link href="https://jared.lynskey.co.nz/ko/tags/interviews/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>개발자 면접에서 STAR 방식을 쓰는 이유</title>
      <link>https://jared.lynskey.co.nz/ko/posts/2024/2024-12-19-star-interviews/</link>
      <guid isPermaLink="true">https://jared.lynskey.co.nz/ko/posts/2024/2024-12-19-star-interviews/</guid>
      <pubDate>Thu, 19 Dec 2024 00:30:03 +0000</pubDate>
      <dc:creator>Jared Lynskey</dc:creator>
      <category>Hiring</category>
      <category>Interviews</category>
      <category>STAR Format</category>
      <category>Engineering Management</category>
      <description>STAR 기법으로 행동 면접을 할 때는 실제 경험 하나를 끌어내 상황, 과제, 행동, 결과 순으로 짚어 갑니다. 개발자 면접에서 실제로 쓰는 질문(리더십 질문 포함)과 눈여겨보는 포인트를 정리했습니다.</description>
      <content:encoded><![CDATA[<p>STAR 기법(STAR 면접법)은 후보자에게 &ldquo;어떻게 하겠느냐&quot;가 아니라 &ldquo;실제로 어떻게 했느냐&quot;를 묻는 행동 면접 방식입니다. &ldquo;직접적인 권한 없이 기술적 의사결정에 영향을 미친 경험을 말씀해 주세요&quot;처럼 실제 사례를 들려 달라고 한 뒤, 상황(Situation), 본인이 맡은 과제(Task), 본인이 직접 한 행동(Action), 결과(Result) 네 가지를 짚어 가며 듣습니다. 저는 개발자 면접에서 이 방식을 쓰는데, 정작 승부는 그다음 후속 질문에서 납니다.</p>
<p>올해 엔지니어링 매니저가 되면서 채용하는 쪽 자리에 앉는 일이 부쩍 많아졌습니다. 그러면서 가장 크게 느낀 점은, 후보자에게 이력서를 자유롭게 설명하게 하는 것만으로는 알 수 있는 게 거의 없다는 겁니다. 이력서를 보면 &ldquo;무엇을 했는지&quot;는 알 수 있죠. 하지만 &ldquo;어떻게 일하는 사람인지&quot;는 좀처럼 보이지 않습니다.</p>
<p>그 간극을 메우는 데 제일 도움이 된 도구가 STAR 포맷 기반의 행동 면접입니다. 후보자가 실제로 겪은 이야기를 들으면서 앞의 네 가지를 차례로 짚어 가는 거죠. 딱 봐도 HR 교육 자료 냄새가 나고, 실제로도 그렇습니다만, 구체성을 강제한다는 게 이 틀의 힘입니다. 시그널은 결국 구체적인 디테일 안에 있으니까요.</p>

<h3 class="relative group">좋은 답변의 모양
    <div id="좋은-답변의-모양" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%ec%a2%8b%ec%9d%80-%eb%8b%b5%eb%b3%80%ec%9d%98-%eb%aa%a8%ec%96%91" aria-label="앵커">#</a>
    </span>
    
</h3>
<p>&ldquo;복잡한 버그를 해결했던 경험을 말씀해 주세요&rdquo; 같은 질문을 예로 들면, 듣고 싶은 건 이렇습니다. 당시 상황(무슨 일이 있었고 왜 중요했는지), 후보자 본인이 맡았던 과제, 실제로 한 행동(&ldquo;우리가&quot;가 아니라 &ldquo;제가&rdquo;), 그리고 결과. 숫자가 붙어 있으면 더 좋습니다.</p>
<p>강한 답변은 대략 이런 느낌입니다(기술 부채 사례):</p>
<blockquote><p>&ldquo;배포 파이프라인이 45분씩 걸렸고, 불안정한 테스트 때문에 개발자들이 빌드를 여러 번 다시 돌려야 했습니다. 한 달치 손실 시간을 집계해 보니 1인당 약 15시간이더군요. 이 데이터를 경영진에 보여주고, 테스트 병렬화와 가장 불안정한 테스트 수정에 2개 스프린트를 투자하자고 제안했습니다. 그 결과 배포 시간은 12분으로 줄었고, 배포 빈도는 두 배가 됐습니다.&rdquo;</p>
</blockquote><p>상황, 과제, 행동, 결과가 다섯 문장 안에 다 들어 있고, 본인의 기여가 뭔지도 분명합니다. &ldquo;파이프라인이 느려서 고쳤습니다&quot;라는 답변 옆에 놓고 보면, 이 틀이 왜 쓸모 있는지 바로 보이죠.</p>

<h3 class="relative group">자주 꺼내 쓰는 질문들
    <div id="자주-꺼내-쓰는-질문들" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%ec%9e%90%ec%a3%bc-%ea%ba%bc%eb%82%b4-%ec%93%b0%eb%8a%94-%ec%a7%88%eb%ac%b8%eb%93%a4" aria-label="앵커">#</a>
    </span>
    
</h3>
<p>모든 걸 다 확인하려 하기보다, 지금 팀에 필요한 역량을 중심으로 질문을 정리해 둡니다:</p>
<table>
	<thead>
			<tr>
					<th>역량</th>
					<th>질문</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>문제 해결</td>
					<td>&ldquo;압박 속에서 프로덕션 이슈를 디버깅한 경험을 말씀해 주세요.&rdquo;</td>
			</tr>
			<tr>
					<td>협업</td>
					<td>&ldquo;까다로운 이해관계자와 일해야 했던 프로젝트를 설명해 주세요.&rdquo;</td>
			</tr>
			<tr>
					<td>기술 리더십</td>
					<td>&ldquo;직접적인 권한 없이 기술적 의사결정에 영향을 미친 경험을 말씀해 주세요.&rdquo;</td>
			</tr>
			<tr>
					<td>학습 민첩성</td>
					<td>&ldquo;익숙하지 않은 기술을 빠르게 익혀야 했던 때를 설명해 주세요.&rdquo;</td>
			</tr>
			<tr>
					<td>오너십</td>
					<td>&ldquo;본인이 만든 것이 실패했던 경험을 말씀해 주세요. 그때 어떻게 하셨나요?&rdquo;</td>
			</tr>
	</tbody>
</table>
<p>마지막 질문을 제일 좋아합니다. 실패를 어떻게 이야기하는지가 성공담 세 개보다 많은 걸 알려주고, 미리 대본을 준비하기도 어려운 질문이거든요.</p>

<h3 class="relative group">면접의 본게임은 후속 질문
    <div id="면접의-본게임은-후속-질문" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%eb%a9%b4%ec%a0%91%ec%9d%98-%eb%b3%b8%ea%b2%8c%ec%9e%84%ec%9d%80-%ed%9b%84%ec%86%8d-%ec%a7%88%eb%ac%b8" aria-label="앵커">#</a>
    </span>
    
</h3>
<p>후보자가 처음부터 STAR 흐름대로 완벽하게 답하는 경우는 거의 없습니다. 그래도 괜찮습니다. 후속 질문이야말로 면접의 본게임이니까요. &ldquo;성능을 개선했습니다&quot;라고 하면 얼마나, 어떻게 측정했는지 물어봅니다. 계속 &ldquo;우리&quot;라고만 하면 본인은 정확히 뭘 했는지 물어봅니다. 이야기가 이상하리만치 깔끔하게 마무리되면, 다음에 같은 상황이 오면 뭘 다르게 할 건지 물어보고요.</p>
<p>시간이 꽤 걸려서 배운 교훈이 하나 더 있습니다. 모든 후보자에게 같은 질문을 하고, 단순한 기준표로 채점하는 겁니다. 기계적으로 느껴지긴 하지만, 공정하게 비교할 방법은 이것뿐입니다. 안 그러면 결국 가장 최근에 이야기한 사람의 인상에 끌려가게 되더군요.</p>
<p>물론 이걸로 기술 평가가 필요 없어지는 건 아닙니다. 실제로 뭔가를 만들 수 있는 사람인지는 따로 확인해야 하죠. 다만 가정형 질문은 말로 넘어갈 수 있어도, 과거의 행동은 꾸며내기 어렵습니다. 1년 가까이 면접을 진행해 보니, 잘 다듬어진 &ldquo;장단점&rdquo; 답변보다 꼼꼼히 파고든 실제 이야기가 훨씬 믿을 만하다는 걸 느낍니다.</p>

<h3 class="relative group">STAR 네 줄 요약
    <div id="star-네-줄-요약" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#star-%eb%84%a4-%ec%a4%84-%ec%9a%94%ec%95%bd" aria-label="앵커">#</a>
    </span>
    
</h3>
<ul>
<li>Situation(상황): 무슨 일이 있었고, 왜 중요했는지.</li>
<li>Task(과제): 후보자 본인이 책임지고 있던 일이 무엇이었는지.</li>
<li>Action(행동): 본인이 직접 한 일. 계속 &ldquo;우리&quot;라고만 하면 본인은 정확히 뭘 했는지 물어봅니다.</li>
<li>Result(결과): 그래서 어떻게 됐는지. 숫자가 붙어 있으면 더 좋습니다. &ldquo;개선했습니다&quot;라고 하면 얼마나, 어떻게 측정했는지 물어봅니다.</li>
</ul>

<h3 class="relative group">참고 자료
    <div id="참고-자료" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%ec%b0%b8%ea%b3%a0-%ec%9e%90%eb%a3%8c" aria-label="앵커">#</a>
    </span>
    
</h3>
<p>이 사이트의 관련 글:</p>
<ul>
<li><a href="https://jared.lynskey.co.nz/ko/posts/2024/2024-07-12-coffee-chats/" >커피 챗: 채용 프로세스의 전 단계</a> — 공식 절차가 시작되기 전에 후보자와 알아가기</li>
<li><a href="https://jared.lynskey.co.nz/ko/posts/2024/2024-02-10-prioritizing-onboarding/" >엔지니어링 매니지먼트와 팀 다이나믹스</a> — 팀에 어떻게 녹아들지를 보고 채용하기</li>
<li><a href="https://jared.lynskey.co.nz/ko/posts/2024/2024-07-01-internships/" >스타트업 인턴십의 장점</a> — 주니어 후보자를 평가할 때 참고할 만한 맥락</li>
<li><a href="https://jared.lynskey.co.nz/ko/posts/2023/2023-09-01-retrospecs/" >회고: 피드백 루프의 힘</a> — 같은 회고 습관을 면접 프로세스에도 적용할 수 있습니다</li>
</ul>
<p>외부 리소스:</p>
<ul>
<li><a href="https://www.themuse.com/advice/star-interview-method"  target="_blank" rel="noreferrer">The STAR Method: The Secret to Acing Your Next Job Interview</a> — The Muse의 후보자용 가이드</li>
<li><a href="https://rework.withgoogle.com/en/guides/hiring-use-structured-interviewing"  target="_blank" rel="noreferrer">Google re:Work: Structured Interviewing</a> — 구조화 면접의 근거가 되는 연구</li>
<li><a href="https://review.firstround.com/40-favorite-interview-questions-from-some-of-the-sharpest-folks-we-know"  target="_blank" rel="noreferrer">First Round Review: 40 Favorite Interview Questions</a> — 질문 아이디어 훔쳐오기 좋은 글</li>
<li><a href="https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/"  target="_blank" rel="noreferrer">Joel Spolsky: The Guerrilla Guide to Interviewing</a> — 지금 읽어도 유효한 고전</li>
</ul>
]]></content:encoded>
      <media:content url="https://jared.lynskey.co.nz/en/posts/2024/2024-12-19-star-interviews/featured.jpg" medium="image" type="image/jpeg" />
    </item>
  </channel>
</rss>
