이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 REST API 명세 문서를 작성할 때 생성형 AI를 처음 써봤습니다. 엔드포인트가 20개를 넘어가면서 하나하나 설명을 쓰는 데 시간이 많이 걸렸습니다.
코드에 주석을 달아두고, 그 주석을 생성형 AI에 붙여넣어 API 문서 형식으로 정리해달라고 요청했습니다. 초안이 바로 나왔는데, 파라미터 설명이 실제 동작과 다른 경우가 3건 있었습니다. 코드를 직접 읽지 않고 주석만 보고 쓴 내용이 그대로 들어간 것이었습니다. 직접 검토하지 않고 배포했다면 문제가 됐을 부분이었습니다.
생성형 AI가 초안 속도를 크게 줄여주지만, 결과를 직접 검증하는 과정은 빠뜨릴 수 없다는 걸 그 경험에서 배웠습니다.
팀 프로젝트에서 단위 테스트를 처음 짜봤는데, 어떤 케이스를 커버해야 하는지 막막했습니다. 작성한 함수 코드를 생성형 AI에 넣고 엣지 케이스 목록을 뽑아달라고 요청했습니다.
15개 케이스가 나왔는데, 그 중 제가 생각하지 못한 게 4개 있었습니다. 빈 입력 처리, 음수 값, 문자열과 숫자 혼용 등이었습니다. 그 케이스로 테스트를 짰더니 실제로 2개에서 버그가 발견됐습니다.
AI가 모든 케이스를 완벽하게 잡아내진 않았지만, 생각의 범위를 넓히는 데 효과적이었습니다. 혼자 생각할 때 놓치기 쉬운 경계 조건을 빠르게 나열하는 데 유용한 도구라는 걸 그때 배웠습니다.
사이드 프로젝트를 하다가 비동기 처리 관련 버그에서 2일 동안 막혔습니다. 에러 내용과 관련 코드를 생성형 AI에 붙여넣고 원인 가설을 물어봤습니다.
3가지 가능한 원인을 알려줬는데, 그 중 하나가 Promise 체인에서 예외 처리가 누락된 부분을 가리켰습니다. 직접 확인했더니 실제로 그 부분이 문제였습니다. 나머지 2가지 가설은 제 코드 구조와 맞지 않는 것이었습니다.
에러 메시지만으로 보이지 않는 가능성을 빠르게 나열하는 데 유용하다는 걸 그때 배웠습니다. 다만 제시된 원인을 코드에서 직접 확인하지 않으면, 엉뚱한 부분을 수정하는 시간을 오히려 더 쓸 수 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.