이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
생성형 AI를 활용한 앱을 설계할 때 제가 가장 먼저 고민하는 건 '출력이 예측 가능한가'입니다. 같은 입력에도 다른 결과가 나올 수 있는 특성 때문에, 프롬프트 설계와 출력 검증 구조가 애플리케이션 신뢰성의 핵심이라고 생각합니다. 토이 프로젝트에서 문서 요약 기능을 만들 때, 처음엔 단순하게 요약해달라는 프롬프트만 썼습니다. 결과가 너무 들쭉날쭉해서 출력 길이와 형식을 프롬프트에 명시하고, 결과를 파싱하는 검증 단계를 추가했습니다. 그래도 특정 케이스에서 형식이 깨지는 경우가 발생해서, 폴백 로직을 추가했습니다. 아직 실무 수준은 아니지만, LLM은 확률적 시스템이라 결정론적 소프트웨어와 다른 방식으로 접근해야 한다는 걸 이 과정에서 배웠습니다. 입사하면 이 경험을 기반으로 실제 서비스 수준의 신뢰성을 갖추는 방법을 배우고 싶습니다.
생성형 AI 앱을 설계할 때 환각(hallucination) 문제를 어떻게 줄일 것인가가 가장 큰 고민입니다. 모델이 그럴듯하게 틀린 답을 내놓는 것이 사용자 신뢰를 가장 빠르게 깨뜨리기 때문입니다. 수업에서 RAG(검색 증강 생성) 패턴을 배웠는데, 모델이 외부 문서를 참조해서 답변하도록 설계하면 환각을 크게 줄일 수 있다는 게 핵심이었습니다. 스터디에서 간단한 질의응답 앱을 RAG 방식으로 구현해봤는데, 처음엔 검색한 문서와 질문이 잘 연결되지 않아서 엉뚱한 문단을 가져오는 경우가 많았습니다. 임베딩 유사도 기준을 조정하면서 개선됐는데, 검색 품질이 전체 출력 품질을 결정한다는 걸 배웠습니다. 아직 실무 수준과 차이가 있지만, 이 패턴의 개념은 이해하고 있습니다.
생성형 AI 앱을 설계할 때 출시 후 품질이 유지되는가가 일반 소프트웨어보다 훨씬 어렵다고 생각합니다. 모델 동작이 비결정적이고, 사용자 입력 패턴이 계속 바뀌기 때문입니다. 수업에서 AI 프로덕트 설계 사례를 배우면서, 출력 품질을 자동으로 평가하는 지표를 처음부터 설계하는 것이 중요하다는 걸 알게 됐습니다. 토이 프로젝트에서 사용자 피드백 버튼(좋아요/싫어요)을 로그로 수집하는 구조를 추가했는데, 실제로 특정 유형의 질문에서 부정 피드백이 몰린다는 패턴을 발견했습니다. 그 패턴을 기반으로 프롬프트를 개선하는 실험을 진행했고, 부정 피드백이 줄었습니다. 처음엔 로그 설계를 생략했다가 나중에 추가하는 게 훨씬 복잡했습니다. 설계 초기에 평가 루프를 포함하는 것이 중요하다는 걸 실수로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.