이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 LLM을 처음 실제 서비스에 연결해보면서 관심이 본격적으로 생겼습니다. 처음엔 API를 불러서 텍스트를 생성하는 것부터 시작했는데, 프롬프트 구성 방식에 따라 응답 품질이 크게 달라진다는 걸 직접 경험했습니다. RAG 구조를 적용하면서 외부 문서를 검색 결과로 삽입할 때 컨텍스트 창 한계를 어떻게 다룰지가 핵심 문제라는 걸 배웠습니다. 평가 측면에서는 BLEU나 ROUGE 같은 자동 지표보다 사람이 직접 일부를 검토하는 방식이 품질을 파악하는 데 더 유용하다는 걸 경험했습니다. Tool Calling을 활용한 연동 구조도 구현해봤는데, 스키마 설계가 에이전트 동작의 신뢰성을 결정한다는 걸 배웠습니다.
LLM은 도입 비용이 낮아졌지만, 평가와 운영 비용이 그 자리를 채운다는 걸 직접 경험하면서 느꼈습니다.
LLM 기술에 대한 관심이 실제 직무에서 어떻게 쓰일 수 있는지 생각하게 된 것은 반복적인 비정형 텍스트 처리 작업을 자동화하는 실험을 해보면서였습니다. 규칙 기반으로 처리하기 어려운 텍스트를 분류하거나 요약하는 작업에서 LLM이 일관된 결과를 낸다는 것을 확인했습니다. 이 경험에서 LLM이 잘 맞는 작업과 그렇지 않은 작업이 있다는 것을 배웠는데, 정확한 수치 계산이나 복잡한 로직 처리는 LLM보다 기존 코드가 더 신뢰할 수 있었습니다. 직무에서 LLM을 활용하려면 어떤 작업을 자동화하면 실질적인 효과가 있는지 먼저 파악하고, 그 작업에서 LLM의 출력을 어떻게 검증할지 설계하는 것이 중요하다고 생각합니다. 도구를 알고 있는 것과 어느 문제에 적합한지 판단하는 것은 다른 능력이라는 것을 이 경험에서 배웠습니다.
LLM을 서비스에 연결하면서 가장 복잡했던 부분은 검색 결과와 생성 결과가 분리된 구조에서 어디서 품질 문제가 생기는지 파악하는 것이었습니다. 사용자가 질문을 입력하면 관련 문서를 검색하고 그 문서를 바탕으로 LLM이 답변을 생성하는 흐름에서, 두 단계가 각각 실패할 수 있었습니다. 검색 단계에서 관련 문서를 잘못 가져오면 LLM이 아무리 잘 생성해도 결과가 나빠졌고, 검색이 잘 됐더라도 LLM이 그 문서를 잘못 해석하는 경우도 있었습니다. 두 단계를 분리해서 검색 단계의 정확도와 생성 단계의 품질을 따로 측정하니 어느 쪽을 개선해야 하는지 명확해졌습니다. 검색 결과 품질을 개선하는 것이 전체 시스템 품질 향상에 더 빠른 효과를 냈는데, 생성 단계는 좋은 입력이 있어야 좋은 결과가 나온다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.