AI·LLM 활용 경험을 묻는 질문은 도구를 얼마나 많이 써봤는지가 아니라 생성된 결과를 얼마나 정확히 검증하는지를 봅니다. 신입 지원자가 흔히 빠지는 함정은 속도가 빨라졌다는 성과만 강조하고, 그 속도가 어디서 리스크를 남겼는지는 말하지 않는 것입니다. 아래 심화는 답의 뼈대가 왜 그 순서로 짜여야 하는지, 합격선이 어디서 갈리는지, 가장 위험한 꼬리질문에 어떻게 대응하는지를 다룹니다.
면접관은 무엇을 보나
AI나 LLM을 활용한 경험에 대한 흔적이 답에 있어야 합니다. 없으면 면접관이 '어떤 사례가 있었나요?'를 추가로 묻는 경우가 자주 보입니다.
개발 생산성을 높인 구체적인 방식에 대한 설명이 답에 있어야 합니다. 없으면 '그런 방식이 왜 효과적이라고 생각하나요?' 같은 질문을 던지는 자리가 자주 보입니다.
사용했던 도구나 기술에 대한 흔적이 답에 있어야 합니다. 없으면 면접관이 '그 도구의 장점은 무엇인가요?'를 추가로 묻는 경우가 많습니다.
AI나 LLM 활용으로 얻은 성과에 대한 구체적인 설명이 답에 있어야 합니다. 없으면 면접관이 '결과는 어떻게 측정했나요?'를 묻는 자리에서 자주 보입니다.
읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?
모범 답변의 결
경험 중심 1인칭 답변
개발 업무에서 AI를 가장 많이 활용한 부분은 반복적인 코드 패턴 생성과 디버깅 설명이었습니다. 특히 보일러플레이트 코드, 테스트 케이스 초안, API 문서 초안은 LLM으로 초안을 만들고 검토하는 방식으로 전환했습니다. 이렇게 하면 작성보다 검토에 시간을 더 쓸 수 있어서 실수가 줄고 속도도 빠릅니다. 또한 잘 모르는 라이브러리나 레거시 코드를 분석할 때 코드를 붙여 넣고 동작 방식을 물어보는 방식을 씁니다. 공식 문서보다 구체적인 맥락에서 답을 빠르게 얻을 수 있었습니다. 다만 AI가 생성한 코드를 그대로 사용하면 보안 취약점이나 엣지 케이스를 놓치는 경우가 있어서, 반드시 직접 검토하는 단계를 포함하는 방식으로 사용합니다. LLM은 가속 도구이고 판단은 여전히 개발자가 해야 한다는 원칙을 유지하고 있습니다. 앞으로도 AI를 가속 도구로 쓰되 판단과 검토는 직접 하는 방식을 유지하겠습니다. LLM이 생성한 코드는 반드시 맥락을 검토해야 하고, 그 검토 능력이 AI 시대 개발자의 핵심 역량이라고 봅니다.
전문가의 심화 해설
속도와 검증을 분리해서 말하는 구조
이 답의 뼈대는 활용 방식 제시 다음에 반드시 검증 단계를 별도 문장으로 붙이는 구조입니다. 생성 속도가 빨라졌다는 말만 하면 면접관 입장에서는 그 결과물을 그대로 믿고 쓰는 사람인지 구분이 안 됩니다. 검증 단계를 붙이면 같은 경험이라도 판단 주체가 본인이라는 신호가 생깁니다. 이 구조가 통하는 이유는 실무에서 AI 활용 능력을 평가할 때 결국 속도가 아니라 리스크 관리 능력을 더 중요하게 보기 때문입니다. 속도만 강조한 답은 도구를 잘 쓰는 사람으로 보이지만, 검증까지 붙인 답은 도구를 책임지고 쓰는 사람으로 보입니다. 순서를 바꿔 검증을 먼저 말하면 소극적으로 들리므로, 활용 방식을 먼저 제시하고 검증을 뒤에 붙이는 순서를 지키는 것이 중요합니다.
성과를 숫자로 말하는지가 갈림선
합격선을 가르는 지점은 생산성이 좋아졌다는 표현을 체감적으로만 말하는지, 아니면 작업 시간이나 반복 횟수 같은 구체적인 기준으로 말하는지입니다. 신입 지원자는 실무 경험이 짧아 정확한 수치를 대기 어려운 경우가 많은데, 그럴 때는 억지로 숫자를 지어내기보다 어떤 상황에서 어떤 판단으로 시간을 아꼈는지를 구체적으로 서술하는 편이 낫습니다. 예를 들어 테스트 초안 작성에 쓰던 시간이 검토 시간으로 옮겨갔다는 식의 서술은 숫자가 없어도 판단 기준이 드러납니다. 반대로 편해졌다·좋아졌다는 표현만 반복하면 실제로 무엇이 개선됐는지 면접관이 재구성하기 어렵고, 이 지점에서 꼬리질문이 따라붙습니다.
결과를 어떻게 측정했는지 캐묻는 질문
가장 위험한 꼬리질문은 성과를 어떤 기준으로 측정했느냐는 질문입니다. 이 질문이 위험한 이유는 원 답변에서 생산성이 올라갔다고만 말하고 측정 기준을 안 밝힌 경우, 이 질문에 답하다가 감상적 평가에 불과했다는 게 드러나기 때문입니다. 대응하려면 처음부터 정량적 기준 하나와 정성적 기준 하나를 함께 준비해두는 것이 좋습니다. 예컨대 반복 작업 시간이 줄었다는 정량 기준과, 검토에 더 집중할 수 있게 됐다는 정성 기준을 같이 들면 질문이 나와도 답이 이미 준비돼 있는 상태가 됩니다. 준비 없이 이 질문을 받으면 대부분 '그냥 편해서요'라는 식으로 무너지고, 이 지점에서 경험의 깊이가 얕다는 인상이 남습니다.
직무에 따라 강조점이 달라지는 이유
이 질문은 개발 직무와 비개발 직무에서 답의 무게 중심이 갈립니다. 개발 직무는 코드 생성·디버깅 설명처럼 결과물의 정확성 검증이 핵심이라 보안 취약점이나 엣지 케이스를 놓치지 않는 검토 습관을 강조하는 편이 유리합니다. 기획·마케팅 직무는 아이디어 확장이나 초안 작성 속도가 중심이 되므로, 생성된 초안을 그대로 쓰지 않고 자기 언어로 다듬는 과정을 강조하는 편이 자연스럽습니다. 데이터 직무라면 분석 가설 생성에 활용한 경험이 더 설득력 있는데, 이 경우 가설을 세운 뒤 실제 데이터로 검증했는지가 관건입니다. 직무별로 축이 다른 이유는 각 직무에서 AI가 개입하는 지점과 리스크가 발생하는 지점이 다르기 때문이며, 자기 직무와 무관한 축을 억지로 가져오면 오히려 어색하게 들립니다.
도구 이름만 나열하는 답이 함정인 이유
흔한 함정은 어떤 AI 도구를 썼는지 이름만 나열하고 끝내는 답입니다. 이 답이 함정인 이유는 도구 이름 자체는 검색하면 누구나 알 수 있는 정보라서, 그것만으로는 지원자가 실제로 그 도구를 써서 무엇을 판단했는지가 전혀 드러나지 않기 때문입니다. 면접관은 도구 이름보다 그 도구를 어떤 상황에서, 어떤 대안과 비교해 선택했는지를 더 궁금해합니다. 또 다른 함정은 AI가 다 해줬다는 식으로 자신의 역할을 지워버리는 서술입니다. 이렇게 말하면 오히려 본인의 판단력이 안 보이는 답이 되어, AI를 잘 쓰는 사람이 아니라 AI에 의존하는 사람으로 읽힙니다. 도구 이름은 짧게 언급하고, 그 도구를 쓰기로 판단한 이유와 검토한 과정에 더 많은 분량을 써야 합니다.
이어질 수 있는 꼬리질문
해당 경험이 팀에 어떠한 영향을 미쳤나요?
경험이 팀에 미친 긍정적 영향을 답하는 결이 흔하게 통합니다. 팀원들과의 협업이나 업무 프로세스 개선을 언급하는 자리가 자주 보입니다.
이 기술을 사용하며 겪었던 어려움은 무엇이었나요?
경험 중 기술적 어려움을 어떻게 극복했는지를 답하는 결이 강합니다. 문제 해결 과정이나 배운 점을 짚는 답이 자주 보입니다.
이 경험을 바탕으로 앞으로 어떻게 발전할 계획인가요?
경험을 통해 배운 점을 바탕으로 발전 방향을 제시하는 결이 흔하게 통합니다. 향후 목표나 기술적 포부를 설명하는 자리가 보입니다.
흔히 빠지는 실수
- AI가 다 해줬다는 식으로 자신의 역할을 지워버려 판단 주체가 안 보이는 답이 됩니다.
- 도구 이름만 나열하고 그 도구를 선택한 이유는 설명하지 않습니다.
- 생성된 코드나 콘텐츠를 검증 없이 그대로 썼다는 인상을 남깁니다.
- 생산성이 좋아졌다는 표현만 반복하고 구체적인 기준을 대지 못합니다.
- 실패나 시행착오 없이 매끈한 성공담으로만 답을 채웁니다.
이 질문이 나온 회사
실제 면접에서 이 질문이 확인된 회사입니다.