이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
최근 프로젝트에서 AI 에이전트 기반 개발 방식을 처음 실험해봤습니다. AI 코드 어시스턴트가 코드를 제안하면 검토 후 수정하는 방식으로 진행했는데, 생성 코드의 품질이 컨텍스트를 얼마나 잘 제공하느냐에 따라 크게 달라지는 경험을 했습니다. 프롬프트에 기존 코드 구조와 팀 컨벤션을 명확히 포함시키면 그냥 질문만 했을 때보다 수정 횟수가 절반 이하로 줄었습니다.
에이전트 반복 루프를 활용해 테스트 실패를 피드백으로 넣어 코드를 자동 수정하는 흐름도 실험했는데, 에이전트 기반 개발에서 가장 중요한 건 출력 검증 기준을 명확히 정의하는 것이었습니다. 지금도 AI 도구를 쓸 때 어떤 기준으로 결과를 수용하거나 거부할지를 먼저 정하는 것이 생산성을 높이는 핵심이라고 느끼고 있습니다.
AI 에이전트를 개발에 도입했을 때 처음엔 코드가 맞는지 판단하기 어려운 상태였습니다. 생성된 코드가 동작은 하는데 내가 의도한 방식으로 구현된 건지 확인하는 기준이 없었습니다.
이후엔 AI에게 작업을 넘기기 전에 "어떤 제약 조건이 있고, 어떤 경우를 피해야 하는가"를 먼저 명시하는 방식으로 바꿨습니다. 테스트 케이스를 먼저 작성하고 AI가 생성한 코드가 통과하는지 확인하니 "이 코드가 맞는가"를 판단할 수 있는 기준이 생겼습니다.
이 경험으로 AI 기반 개발에서 개발자의 역할은 코딩보다 명세와 검증 기준을 만드는 것으로 이동한다는 걸 배웠습니다. 기준이 없으면 AI 출력이 맞는지 판단할 수 없습니다.
AI 에이전트 기반 개발에서 가장 조심해야 했던 건 코드가 동작하는 것과 코드가 안전한 것의 차이였습니다. AI가 생성한 코드가 기능적으로는 작동했는데, 도메인 맥락이 없어 예외 케이스를 빠뜨리는 경우가 있었습니다.
예를 들어 결제 취소 흐름에서 특정 상태에서는 취소가 불가능한 규칙을 AI는 모른 채 코드를 만들었습니다. 단위 테스트로는 잡히지 않고 통합 테스트에서야 드러났습니다. 도메인 규칙이 코드에 없으면 AI도 그 규칙을 따르지 않습니다.
이 경험으로 AI 기반 개발에서 개발자가 놓치면 안 되는 건 도메인 규칙을 명시하는 것이라는 걸 배웠습니다. 규칙을 모르면 검증도 할 수 없었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.