18주차: 최종 프로젝트

About this offer

뭐만들지... 이번 주는 최종 프로젝트 주제를 정하고 실제로 무엇을 만들지 구체화하는 데 시간을 많이 썼다. 지금까지 배운 내용을 생각하면 쓸 수 있는 기술은 꽤 많았다. LLM, Hugging Face 모델, RAG, LoRA, LangChain, LangGraph, MCP까지. 근데 막상 프로젝트를 시작하려고 하니 이걸 어디에 어떻게 써야 하는지부터 다시 생각하게 됐다. 수업에서 하나씩 배울 때와 하나의 서비스로 묶으려고 할 때는 또 느낌이 달랐다. 배운 건 많다. 그래서 이걸 어디에 쓰지...? 처음에는 개발팀 문서화 도우미, 소상공인 지원사업 신청 보조, 창작물 검수처럼 여러 주제를 비교했다. 비슷한 서비스가 있는지, 데이터를 구할 수 있는지, 반복되는 업무가 충분히 있는지도 같이 확인했다. 아이디어를 적을 때는 괜찮아 보였는데 실제 입력 데이터와 결과물을 생각하면 막히는 부분이 있었다. 계약서는 어디서 구할지, 검수 결과가 맞는지는 누가 판단할지, 사람이 하던 일 중 어디까지 자동화할 수 있을지 같은 것들이다. 멘토링을 거치면서 기획을 설명하는 순서도 조금 정리됐다. 어떤 배경에서 문제가 생겼고, 누가 불편을 겪고 있으며, 우리가 만든 서비스로 어떤 일이 달라지는지. 이 흐름부터 설명할 수 있어야 했다. 훈민정음을 예로 들었던 것도 결국 왜 필요한지와 사용했을 때의 변화를 먼저 생각해 보자는 이야기로 받아들였다. 효과를 설명할 때도 검수 시간이 줄어들 것 같다는 말에서 한 단계 더 들어가야 했다. 실제로 얼마나 걸렸는지, 어떤 오류를 놓쳤는지 비교할 방법이 필요했다. 아직 측정하지 않은 숫자를 적어두면 나중에 설명하기도 어려울 것 같다. 그렇게 정리한 주제가 광고 창작물 검수 업무를 돕는 서비스 다. 프로젝트 이름은 일단 동작그만 밑장빼기냐 . 숏츠, 인스타 릴스, 광고 이미지처럼 확인해야 할 콘텐츠는 많고 AI를 활용해서 만드는 경우도 있다. 사람이 직접 검수하더라도 상품명이나 할인율, 브랜드 표기처럼 놓칠 수 있는 부분이 생긴다. 여기에 계약서와 명세서까지 대조하려면 확인할 항목이 더 늘어난다. 그래서 문서에서 검수 기준을 읽고, 결과물이 그 기준에 맞는지 확인한 다음, 문제가 있는 위치와 근거를 보여주는 흐름을 생각했다. 사람이 최종적으로 판단할 때 참고할 수 있도록 만드는 방향이다. 처음부터 영상까지 모두 다루기는 범위가 커서 우선 광고 이미지부터 시작하기로 했다. 실제로 어떤 모습일지 보기 위해 딸기라떼 예시도 준비했다. 정상 이미지 한 장과 조건을 다르게 만든 오류 이미지 다섯 장으로 검사 흐름을 확인했다. 상품명, 할인율, 브랜드, 딸기 개수, 음료 외관처럼 비교할 항목이 있으니 화면과 기능을 이야기하기가 훨씬 쉬워졌다. Codex와 에이전트를 활용해서 기본 시제품도 만들어 실행해 봤다. 그런데 여기서 확인할 부분이 있었다. 화면에서는 검사가 되고 결과도 나오는데, 지금 이 결과를 실제로 누가 판단하고 있는가 하는 점이었다. 확인해 보니 초기 구현은 Mac 내장 OCR과 미리 정한 조건을 비교하는 방식이었다. MCP 도구 호출도 들어가 있었지만, 구상했던 LLM이나 RAG, 다중 에이전트 협업까지 연결된 상태는 아니었다. 화면은 돌아간다. 근데 내가 생각한 LLM은 아직 연결 전이었다. 그래도 이 과정을 통해 현재 구현과 앞으로 구현할 내용을 구분할 수 있었다. AI가 만들어 준 코드를 사용할 때도 어떤 모델이 호출되는지, 어디까지가 고정된 규칙인지 직접 확인해야겠다는 생각이 들었다. 화면에 결과가 나오는 것만 보고 넘어가면 내가 만든 프로젝트를 설명할 때부터 막힐 수 있다. 검사 기준을 입력하는 화면도 다시 봤다. 예제에서는 딸기라떼, 할인율, 브랜드 같은 값을 미리 넣어두었지만 실제 서비스에서는 문서를 읽어서 기준을 가져와야 한다. 사용자가 내용을 전부 다시 입력해야 한다면 우리가 줄이려던 업무가 그대로 남는다. 그래서 목표 흐름을 이렇게 잡았다. 문서 등록 → 기준 추출 → 사람 확인 → 이미지 검수 → 근거 검증 → 결과 보고 → 수정본 재검수 문서가 모호하거나 모델이 판단하기 어려운 경우에는 사람이 확인할 수 있어야 한다. 기준 자체를 잘못 읽으면 뒤에서 이미지를 열심히 검사해도 결과가 틀릴 수 있기 때문이다. 데이터를 준비하는 과정에서도 생각할 부분이 있었다. 검사용 입력 문서 안에 어떤 항목을 의도적으로 누락했는지 적혀 있으면, 모델이 결과물을 제대로 확인하지 않고도 정답을 알 수 있다. 예제를 설명하려고 넣은 문장이 평가에서는 정답을 알려주는 힌트가 될 수 있었다. 검사 문제와 답지를 같이 주고 있었던 셈이다... 앞으로는 모델에 제공할 자료와 평가용 정답을 분리해야 한다. 같은 원본에서 만든 오류 이미지 몇 장으로 동작을 확인하는 것과, 새로운 광고에서도 잘 검사하는지 평가하는 것도 나눠서 봐야겠다. 기술 구성도 역할별로 다시 정리했다. 문서에서 기준을 추출하고 설명을 작성하는 LLM은 Qwen3-8B 를 우선 후보로 잡았다. 요청 유형을 분류하는 모델은 KLUE RoBERTa 를 미세조정하는 방향으로 생각했다. 이미지 문자 추출은 PaddleOCR , 시각적인 요소를 확인하는 모델은 Qwen3-VL 을 검토했다. 아직 후보를 정리한 단계라 실제 데이터로 실행하고 비교하는 과정이 필요하다. 검색은 BGE-M3를 활용한 Dense 검색과 BM25를 결합하는 Hybrid RAG 로 설계했다. 표현이 달라도 관련된 내용을 찾는 경우와 상품명이나 정확한 문구를 찾는 경우를 함께 고려하기 위해서다. LoRA나 QLoRA는 기본 모델을 먼저 평가하고 필요한 경우 실험하기로 했다. Ragas는 검색과 답변의 품질을 확인하는 데 활용하고, 이미지 검수에서 오류를 놓치는 문제는 별도의 평가 기준을 마련해야 한다고 정리했다. 기술 이름을 나열할 때는 금방 끝났는데, 각각 어디에서 쓰고 무엇으로 평가할지 적으니 생각보다 오래 걸렸다. 실행 환경도 팀 기준으로 다시 생각했다. 처음에는 내 맥에서 실행하는 방법도 고려했지만 여러 팀원이 함께 개발해야 하니 Mac MLX는 공통 구성에서 제외했다. 로컬 CUDA 환경이나 RunPod의 GPU 서버를 활용하는 방향으로 잡았다. 내 컴퓨터에서 편한 것과 팀이 같이 사용하기 편한 것은 따로 확인해야 했다. 프로젝트 주제가 MCP 기반 다중 에이전트 업무자동화 인 만큼 에이전트 역할도 구체화했다. 업무 총괄, 문서·기준 분석, 근거 검색, 문구 검수, 시각 요소 검수, 근거·결과 검증, 보고서 작성, 수정·재검수 관리까지 여덟 역할로 나눴다. LangGraph로 작업 순서와 상태를 관리하고, 각 역할이 MCP를 통해 문서 조회나 검색, OCR, 결과 저장 같은 도구를 사용하는 구조다. 결과가 불확실하면 다시 확인하거나 사람에게 넘기는 흐름도 포함했다. 여덟 개라고 적고 끝낼 수는 없었다. 서로 어떤 결과를 전달하는지, 같은 일을 중복해서 하고 있지는 않은지까지 정해야 했다. 워크플로우로 그려보니 말로 설명할 때 빠뜨렸던 연결도 조금씩 보였다. 기획서와 기능정의서도 여러 번 수정했다. 처음에는 내용을 자세히 적는 데 집중했는데 발표용으로 보니 길었다. 그래서 상세 기능정의서와 발표용 기획서를 나누고, HTML에서 필요한 내용을 버튼으로 찾아볼 수 있게 정리했다. 배경부터 문제, 해결 방법, 기대효과로 이어지도록 문장도 다듬었다. 내가 내용을 알고 있다고 해서 읽는 사람도 같은 순서로 이해하는 건 아니었다. 기획도 생각보다 할 일이 많다... 이번 주에는 주제 선정과 요구사항 정리, 예제 데이터 준비, 기본 시제품 확인, 기술 구성과 에이전트 구조 설계까지 진행했다. LLM 연결, 모델 학습, Hybrid RAG, 여덟 에이전트의 실제 협업은 앞으로 구현하고 검증해야 한다. 중간 발표는 10월 16일 , 최종 발표는 11월 20일 이다. 다음 주에는 실제 문서를 넣었을 때 기준이 제대로 추출되는지부터 확인하려고 한다. 추출한 기준으로 이미지를 검사하고 근거가 포함된 결과까지 나오는 흐름을 먼저 연결해야겠다. 모델 후보도 직접 실행해 보면서 처리 시간과 오류를 기록할 필요가 있다. 중간 발표에서는 실제 데이터를 넣고 어떤 결과가 나오는지 보여줄 수 있어야 한다. 기획서는 꽤 채웠다. 이제 실제로 돌려볼 차례. 이번 주에는 무엇을 만들지 정리했다면, 다음 주에는 그 안에 적어둔 내용이 실제 데이터에서도 돌아가는지 확인해 봐야겠다.