이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 고객 리뷰를 요약하는 기능을 만들 때, 프롬프트를 아무리 바꿔도 부정적인 리뷰만 많으면 긍정적인 측면을 균형 있게 요약하지 못하는 문제가 있었습니다. 말투를 바꾸는 프롬프트 수정은 한계가 있었습니다.
대신 입력으로 넣는 리뷰 자체를 긍정/부정 비율을 맞춰 선별하는 방식으로 바꿨습니다. 프롬프트가 아니라 무엇을 문맥으로 줄지를 설계하니 결과 품질이 확연히 달라졌습니다.
프롬프트는 어떻게 처리할지를 지시하지만, 문맥은 무엇을 처리할지를 결정한다는 걸 그때 처음 이해했습니다. 이후 LLM 기능을 만들 때 프롬프트 이전에 어떤 정보를 어떤 형태로 줄지를 먼저 설계하는 순서를 갖게 됐습니다.
팀 프로젝트에서 사내 문서를 기반으로 답변하는 챗봇을 만들 때, 문서 전체를 프롬프트에 넣으면 길이 초과가 나고, 일부만 넣으면 관련 없는 내용이 섞였습니다.
검색 단계를 앞에 두고, 질문과 가장 관련 있는 문서 청크 3개만 선택해 문맥으로 주는 방식으로 바꿨습니다. 검색 품질이 답변 품질을 결정한다는 걸 알게 됐고, 임베딩 기반 검색과 키워드 검색을 조합하니 관련성이 높아졌습니다.
실패했던 부분은 청크 분할 단위를 문장 수 기준으로만 잘랐더니 맥락이 중간에 끊기는 경우가 생겼습니다. 단락 경계를 기준으로 바꾸니 개선됐습니다. 문맥 설계는 내용뿐 아니라 단위와 순서도 함께 고민해야 한다는 걸 그때 배웠습니다.
졸업 작품으로 학습 도우미 챗봇을 만들 때, 대화가 길어질수록 앞의 내용을 잊어버리거나 입력 길이를 초과하는 문제가 생겼습니다. 전체 대화 이력을 다 넣으면 비용도 늘었습니다.
대화 이력을 요약 압축해 문맥을 유지하는 방식을 시도했습니다. 10턴이 지나면 앞 5턴을 요약으로 압축하고, 최근 5턴은 원문 그대로 유지했습니다. 요약 품질이 낮으면 중요한 정보가 사라지는 문제가 있어서 요약 프롬프트를 별도로 튜닝했습니다.
그 경험에서 문맥은 많을수록 좋은 게 아니라 핵심 정보의 밀도가 높아야 한다는 걸 배웠습니다. 무엇을 넣고 무엇을 버릴지 결정하는 것이 프롬프트를 잘 쓰는 것만큼 중요하다는 것이 지금도 제 기준입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 직방 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.