이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
LLM을 프로젝트에 처음 붙이면서 얻은 가장 큰 인사이트는 출력 형식을 구체적으로 지정하는 것이 전체 품질을 좌우한다는 점이었습니다. 처음엔 자연어로 원하는 것만 설명했는데 응답 구조가 일관되지 않아 파싱이 어려웠습니다. JSON 스키마 예시를 프롬프트 안에 넣었더니 구조가 훨씬 안정됐고, 특히 마크다운 코드 블록 없이 순수 JSON만 돌려달라고 명시하는 것이 후처리를 크게 단순하게 만들었습니다.
퓨샷 예시를 추가할 때는 긍정 예시뿐 아니라 피해야 할 음성 예시도 함께 넣는 게 효과적이었습니다. 프롬프트 길이가 길어질수록 후반부 지시사항이 무시되는 패턴도 발견했고, 핵심 규칙은 앞쪽에 두는 순서 관리도 중요한 최적화였습니다.
LLM에게 복잡한 판단을 맡겼더니 결과가 들쭉날쭉했습니다. 처음엔 결과만 달라달라 했는데, 중간 추론 단계를 먼저 써보게 하는 방식으로 바꾸니 품질이 눈에 띄게 달라졌습니다. 졸업 프로젝트에서 CoT 방식을 처음 써봤습니다. 이슈를 분류하는 작업이었는데, "먼저 원인을 단계적으로 분석하고, 그 다음에 카테고리를 골라"라고 지시하니 분류 정확도가 확연히 높아졌습니다. 단계가 길어지면 토큰 비용이 늘어난다는 부담이 있었고, 불필요한 추론 단계를 줄이는 것이 실제로는 더 어려운 문제였습니다. 중간 추론을 보이게 하는 것이 디버깅에도 도움이 됐는데, 모델이 어느 지점에서 헷갈렸는지를 파악할 수 있었습니다. 결과만 요구하는 대신 추론 경로를 먼저 그리게 하는 것이 가장 신뢰할 만한 패턴이라고 봅니다.
프롬프트를 아무리 다듬어도 모델이 틀린 정보를 자신있게 내놓는 케이스를 직접 경험했습니다. 인턴 기간에 LLM으로 FAQ를 자동 생성하는 기능을 만들었는데, 없는 기능을 있다고 설명하는 답변이 꽤 높은 빈도로 나왔습니다. 처음엔 프롬프트를 더 구체적으로 쓰면 줄어들 거라 기대했지만, 프롬프트 수준에서는 근본적으로 막기 어렵다는 걸 알게 됐습니다. 그래서 RAG 방식으로 실제 문서를 컨텍스트로 넣어주는 구조를 테스트했습니다. 문서를 넣었더니 환각 비율이 절반 이하로 줄었고, 대신 검색된 문서의 품질에 답변 품질이 크게 의존한다는 새 문제가 생겼습니다. 프롬프트 엔지니어링은 모델 자체의 한계를 없애주는 도구가 아니라, 그 한계를 더 잘 드러나게 만드는 도구라는 걸 그때 느꼈습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.