면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
최근 프로젝트에서 AI 코드 어시스턴트 도구를 개발 흐름에 처음으로 적극 활용해봤습니다. 반복적인 보일러플레이트 코드 작성이나 테스트 코드 초안을 빠르게 만드는 용도에서 생산성 향상이 가장 두드러졌습니다. 다만 AI 생성 코드를 그대로 쓰다가 엣지 케이스를 놓친 적이 있었고, 그 이후로 AI 제안은 초안으로만 보고 내 손으로 검토하는 규칙을 세웠습니다.
AI 도구는 내가 아는 것의 속도를 높여주지만 모르는 걸 대신 이해해주지는 않는다는 점이 가장 중요한 관찰이었습니다. 지금도 AI 도구를 쓸 때 생성된 코드가 왜 그렇게 동작하는지를 설명할 수 없으면 그대로 사용하지 않는 기준을 유지하고 있습니다.
인턴 프로젝트에서 AI 도구가 생성한 ORM 쿼리를 그대로 썼다가, 목록 조회 시 연관 데이터를 건당 개별로 가져오는 N+1 문제가 발생했습니다. 처음에는 데이터 양이 많아서라고 생각했는데, 쿼리 로그를 켜보니 요청 하나에 SQL이 50개 이상 찍혀 있었습니다. AI는 올바른 문법을 써줬지만 나 배치 크기 설정이 필요한 자리를 놓쳤고, 그 자리는 데이터 접근 패턴을 알아야 판단할 수 있는 부분이었습니다. 결국 Fetch Join으로 쿼리를 직접 수정했고, 응답 시간이 800ms에서 90ms로 줄었습니다. 이 경험으로 AI가 제안하는 코드는 문법은 맞아도 성능 의도가 없다는 걸 알게 됐고, 조회 쿼리는 실행 계획을 직접 확인하는 습관이 생겼습니다.
졸업 프로젝트에서 테스트 코드 작성이 밀려 있을 때 AI 도구로 테스트 초안을 빠르게 만들었습니다. AI가 정상 케이스는 잘 잡아줬는데, 경계값 처리나 예외 상황은 거의 빠져 있었습니다. 처음에는 AI가 짜준 테스트만으로 충분하다고 넘어갔는데, 배포 후 입력값이 0이나 음수인 케이스에서 오류가 나왔습니다. 이후 AI 초안은 정상 흐름 검증용으로만 쓰고, 경계값·오류·예외 경로는 직접 케이스를 설계해 추가하는 방식으로 역할을 나눴습니다. AI가 제안하는 테스트가 어떤 전제를 깔고 만들어졌는지를 읽어보는 습관도 생겼습니다. 이 방식으로 커버리지 숫자만 높이는 게 아니라 실제 버그를 잡는 테스트가 쌓이기 시작했습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.