첫 AI 심사관 인터뷰 — 대체 무엇이 잘못될 수 있을까요?

AI 요약

작성자는 HackerRank의 2026년 9월 Orchestrate 24시간 해커톤에 참가해 ‘Buy or Wait?’ 과제를 수행하고, AI 심사관 Chakra와 30분간 음성 인터뷰를 진행합니다. 과제는 사용자가 예정된 미래 지출을 감당하면서 특정 비용을 지불할 수 있는지 판단하는 금융 의사결정 도구를 만드는 것이었습니다. 작성자는 이 구현에 Praxi Clew라는 이름을 붙였으며, 최종 점수는 100점 만점에 66.1점, 전체 3,062명 중 139위로 약 상위 4.5%였습니다.

■ AI가 만든 시스템을 AI에게 설명하는 상황

Praxi Clew는 메시지와 이미지에서 사실을 추출하는 AI 단계와, 90일간의 잔액을 예측하고 결제 선택지를 평가하는 Python 코드를 결합합니다. Astra가 AI 추출과 Python 예측을 조정했고, Google의 에이전틱 코딩 도구 Antigravity가 Gemini 3.8을 사용해 IDE 안에서 코드를 구현했습니다. ChatGPT Astra는 산출물 검토를 도왔습니다. 제출물에는 코드 아카이브, 250개 요청에 대한 추천 결과, 개발 과정의 transcript가 포함됐고, 이후 카메라를 켠 상태에서 제출물을 바탕으로 AI Judge 인터뷰를 받았습니다.

작성자는 인터뷰 전부터 AI를 광범위하게 사용했다는 사실을 심사관에게 반복해서 명확히 밝혔습니다. HackerRank의 행사 안내는 이 AI 심사관을 Chakra라고 설명하며, 응답에 따라 후속 질문을 생성하고 정해진 rubric으로 평가하는 적응형 인터뷰를 제시합니다. 실제 인터뷰에서도 심사관은 도입 질문에서 시작해 답변을 바탕으로 추가 질문을 만들고, 답변의 빈틈을 압박하며 더 깊은 설명을 요구했습니다. 작성자는 인터뷰 도중 답변을 준비하기 위해 채팅에 질문을 가져와 AI의 도움을 받기도 했습니다. 따라서 이 글에서 설명하는 해설은 작성자가 도움 없이 즉석에서 답한 전체 구술 기록이 아니라, 채팅에서 확인하고 정리한 내용까지 포함한 회고라고 구분합니다.

■ 구현 세부사항을 모르면 답할 수 없는 질문

변동 지출을 추정할 때 어떤 값을 사용했는지가 대표적인 질문이었습니다. 작성자는 식료품이나 교통비를 예측에 포함해야 한다는 점은 이해했지만, 최근 거래 하나를 썼는지 평균을 썼는지, 더 보수적인 값을 썼는지는 즉시 설명하지 못했습니다. 제출된 함수는 반복 지출 항목에서 최근 금액을 최대 5개까지 가져와 그 중앙값을 사용했습니다. 매우 크거나 작은 한 번의 지출이 결과를 과도하게 흔드는 것을 줄일 수 있지만, 일반적인 지출 수준이 상한선을 보장하지는 않는다는 한계도 있습니다. 코드를 확인하고 나면 짧게 설명할 수 있는 내용이었지만, 인터뷰 중에는 그 확인 자체가 필요했습니다.

급여와 청구서가 같은 날 들어오면 어떤 순서로 처리되는지도 질문받았습니다. 실제 코드는 확정된 수입을 먼저 더하고, 기존 지출을 차감한 다음, 새로 제안된 구매의 결제액을 차감했습니다. 이는 해당 날짜에 수입을 먼저 사용할 수 있다고 가정하지만, 은행의 실제 결제 시각이나 정산 순서까지 모델링하지는 않습니다. 이전에 작성된 보고서에는 출금이 먼저 처리된다고 적혀 있었지만, 제출된 함수를 직접 확인하자 수입이 먼저 처리되고 있었습니다. 두 설명 모두 그럴듯하게 들릴 수 있었지만, 실제 제출물을 설명하는 것은 하나뿐이었습니다.

■ 검증은 무엇과 비교했는지까지 설명해야 합니다

Python 코드는 허용된 변경을 최대 세 개까지 조합해 지출을 중단하거나 허용된 최소 금액까지 줄이는 방안을 탐색하고, 여러 결제 계획을 예측 결과와 비교했습니다. 보호 대상 카테고리는 변경 대상에서 제외했습니다. 심사관은 250개 요청의 결과가 모두 올바른지 어떻게 확인했는지도 물었습니다.

작성자는 공개 데이터셋에 정답이 제공된 예제가 25개뿐이며, 나머지 250개는 제출 요청이라고 설명합니다. 따라서 요청 형식, 변경 권한, 일정, 잔액을 예측과 대조하고, 내보낸 증거를 재생해 같은 출력 파일이 다시 생성되는지는 확인할 수 있습니다. 그러나 보지 못한 정답과 일치한다고 주장할 수는 없습니다. ‘검증했습니다’라는 말만으로는 부족하며, 무엇을 어떤 입력과 비교했고 어떤 한계가 남았는지를 함께 밝혀야 합니다.

요청 185번은 이 구분의 필요성을 보여줍니다. 임대료 12% 인상이 €12의 임대료로 변환됐지만, validator가 예측 코드와 같은 잘못된 값을 사용했기 때문에 검사를 통과했습니다. 원본 메시지와 추출된 사실을 비교한 뒤 임대료를 €451에서 €505.12로 수정했고, 그 결과 추천 결제 시점이 12월에서 1월로 바뀌었습니다. 동일한 오류를 공유하는 validator와 forecast만으로는 결과의 정확성을 보장할 수 없다는 사례입니다.

■ AI-assisted 개발에서의 책임 범위

‘직접 설계한 부분이 무엇인가’라는 질문에는 구현 세부사항과 다른 종류의 답이 필요했습니다. 작성자는 프로젝트를 설계하고, 에이전트가 만든 구현을 검토하며, 에이전트와 함께 버그를 해결했다고 설명합니다. HackerRank가 과제와 데이터를 제공했고 AI가 기술적 해결책의 상당 부분을 제안하고 작성했지만, 프로젝트 전체에 대한 책임은 자신에게 있다고 봅니다. 여기에는 단순히 에이전트를 지시하거나 결과를 평가하는 것을 넘어, 실제 코드가 무엇을 하는지 설명할 수 있는 책임도 포함합니다.

작성자는 빌드 중 에이전트가 자신감 있는 보고서와 수정안을 반복적으로 내놓던 상황에서 작업을 멈추고, 파일과 요구사항을 모두 다시 평가하도록 했습니다. 이후 실제 코드, 출력 결과, 요구사항, 추출된 증거를 한꺼번에 모아 검토하도록 했고, 특정 문제를 고치는 과정에서 무관한 동작까지 바뀌지 않도록 guardrail도 요구했습니다. 이는 시스템 자체의 버그뿐 아니라 시스템을 평가하는 방식까지 점검한 개입이었습니다. 다만 변수 추정 방식과 검증 세부사항을 인터뷰 중에 도움받아 확인해야 했다는 사실도 함께 인정합니다.

■ 결과와 다음 개발 방식

개발 transcript는 만점을 받았지만, 인터뷰·코드·출력 점수는 서로 크게 벌어지지 않았습니다. 따라서 결과를 인터뷰 긴장만으로 설명할 수는 없었습니다. 공개 샘플 결과에서도 결제 방법 일치율은 80%였지만, 정확히 안전한 결제 금액까지 일치한 비율은 12%에 그쳤습니다. 예측 시스템 자체와 그것을 설명하는 능력 모두 개선이 필요한 상태였고, 66.1점이라는 결과가 그 문제를 구체화했습니다.

작성자는 다음 프로젝트부터 설명을 구현 이후의 사후 작업이 아니라 개발 중간의 checkpoint로 만들겠다고 합니다. 에이전트가 답을 내놓을 때마다 해당 구성 요소가 무엇을 하고, 어떤 입력을 사용하며, 어디에서 실패할 수 있는지를 코드와 대조해 설명할 수 있어야 한다는 목표입니다. 이를 위해 채팅 로그, 테스트 출력, 추론을 다시 확인해야 했던 모든 지점을 기록하려고 합니다. 동시에 다음 대회에서는 빌드 요구사항뿐 아니라 실시간 평가에서 허용되는 지원 범위와 인터뷰 규칙도 미리 검토할 계획입니다. 이 글의 결론은 AI를 이용한 개발을 중단하자는 것이 아니라, AI-assisted builder라 하더라도 최종 구현의 결정과 한계를 스스로 설명할 수 있어야 한다는 데 있습니다.

원문: dev.to / 번역·요약: Trawling