1. 기술 개요
데이터 분석 사업을 여러 건 동시에 진행하다 보면 회의록 작성이 큰 부담이 됩니다. 올해 진행 중인 경기도 분석 사업만 해도 분석 과제가 23건이고, 과제마다 방향성 회의, 진행 상황 보고 회의, 결과 보고 회의를 한 번씩만 해도 69번의 회의록을 써야 합니다. 회의를 녹음해 두어도 녹취록에는 회의와 무관한 대화가 많이 섞여 있어 정리와 공유에 시간이 걸리고, 그만큼 후속 업무도 늦어집니다. 작성자마다 정리 방식이 다르고 회의 목적에 따라 필요한 항목도 달라 양식을 맞추기도 어렵습니다.
이런 고민에서 출발해 “녹취 텍스트만 넣으면 인공지능(AI, Artificial Intelligence)이 회의 유형을 판단해 그에 맞는 회의록을 자동으로 만들어 주면 어떨까?“라는 아이디어로 LangGraph와 Gemini를 이용한 회의록 자동화 에이전트를 구축했습니다. 이 글에서는 에이전트 구조와 함께, 개발 과정에서 부딪힌 문제를 해결하며 도구 호출(Tool Calling)의 신뢰성을 높인 사례를 소개하겠습니다.
가. 에이전트(Agent)와 도구(Tool)
- 에이전트는 사용자가 원하는 목표를 이루기 위해 스스로 판단하고 필요한 작업을 계획·수행하는 인공지능 시스템을 말합니다.
- 도구는 에이전트가 실제 작업을 처리할 때 사용하는 외부 기능이나 시스템으로, 데이터 조회·문서 생성·파일 입출력 같은 특정 기능에 특화되어 있습니다.
- 즉, 에이전트는 전체 업무를 계획하고 관리하는 ‘관리자’, 도구는 지시받은 일을 실제로 처리하는 ‘실무자’ 역할로 이해하면 쉽습니다.
| 구분 | 에이전트(Agent) | 도구(Tool) |
| 역할 | 업무 계획 및 관리 | 실제 작업 수행 |
| 특징 | 목표 중심으로 의사결정 여러 도구를 조합해 업무 처리 작업 결과를 보고 다음 행동 결정 | 특정 기능 수행에 특화 에이전트의 요청에 따라 실행 실행 결과를 에이전트에 전달 |
| 주요 동작 | 요청 분석 → 계획 수립 → 도구 선택 → 실행 결과 해석 → 최종 결과 생성 | 데이터 조회, 문서 생성, 파일 입출력, 외부 시스템 연계, 계산 및 분석 |
<에이전트와 도구 비교>
<에이전트와 도구의 관계>
나. 도구 호출(Tool Calling)
- 도구 호출은 에이전트가 지금 해야 할 작업에 알맞은 도구를 고르고, 그 도구를 실행해 얻은 결과를 응답에 활용하는 과정입니다.
- 대규모 언어 모델(LLM)은 학습한 지식만으로 답하기 때문에 실시간 정보나 파일 처리에 한계가 있는데, 도구 호출을 통해 이러한 한계를 보완할 수 있습니다.
| 단계 | 내용 | 설명 |
| 1단계 | 도구 필요 여부 판단 | 요청을 처리하는 데 도구가 필요한지 결정 |
| 2단계 | 도구 선택 | 목적에 맞는 도구를 선택 |
| 3단계 | 도구 실행 | 선택한 도구를 호출해 실행 |
| 4단계 | 결과 반환 | 도구 실행 결과를 받아옴 |
| 5단계 | 결과 해석 | 받아온 결과를 바탕으로 최종 응답 생성 |
<도구 호출 처리 단계>
- 예를 들어 사용자가 “내일 서울 날씨 어때?”라고 물으면, 에이전트는 실시간 정보가 필요하다고 판단해 기상청 응용 프로그래밍 인터페이스(API, Application Programming Interface) 도구를 선택합니다.
- 도구는 “서울, 내일, 비, 강수확률 80%”와 같은 원본 데이터를 그대로 돌려주고, 에이전트는 이를 해석해 “내일 서울에 비 소식이 있으니 우산을 챙기세요”처럼 사람이 이해하기 쉬운 답변으로 바꿔 전달합니다.
다. 랭그래프(LangGraph)
- LangGraph는 에이전트 기반 인공지능 애플리케이션을 개발하기 위한 오케스트레이션(Orchestration) 프레임워크로, LangChain 팀에서 공개한 오픈소스 라이브러리입니다.
- 작업 흐름을 그래프 형태로 정의하기 때문에 시작(START)부터 종료(END)까지 어떤 순서로 작업이 실행되는지 명확하게 설계할 수 있습니다.
| 구성요소 | 설명 |
| 노드(Node) | 작업을 수행하는 실행 단위 |
| 엣지(Edge) | 노드와 노드 사이의 실행 흐름을 연결 |
| 상태(State) | 작업이 진행되는 동안 노드들이 함께 사용하는 데이터 저장 공간 |
<LangGraph 핵심 구성요소>
- 작업 흐름(Workflow) 기반으로 에이전트를 설계하고, 상태를 기준으로 데이터를 관리하며, 조건 분기와 반복 수행을 지원합니다.
- 다양한 도구를 연결해 복잡한 업무 프로세스를 자동화할 수 있어, 이번 프로젝트에서는 에이전트의 실행 흐름과 상태를 체계적으로 관리해 도구 호출의 신뢰성을 높이기 위해 LangGraph를 적용했습니다.
2. 기술 사용 상세
가. 단일 프롬프트 방식과 에이전트 구조 비교
– 처음에는 녹취록 전체를 GPT(Generative Pre-trained Transformer)에 넣고 “회의 내용을 요약하고, 주요 논의사항과 조치사항을 공공기관 보고서 형식으로 정리해 줘”라고 요청하는 방식을 시도했습니다.
– 결과물은 그럴듯해 보였지만, 실제 사람이 작성한 회의록과 비교해 보니 중요한 내용이 상당 부분 빠져 있었습니다.
| 구분 | 단일 프롬프트 방식 | LangGraph 기반 에이전트 구조 |
| 처리 흐름 | 녹취(txt) → GPT → 회의록 | 녹취(txt) → 회의 유형 분류 → 회의 내용 요약 → 회의록(hwp) |
| 누락 사례 | 설명회 운영 방안 누락 검토 과제 23개 중 8개만 작성 | 설명회 주제 선정을 위한 과제 목록 23개 중 14개 작성 |
| 원본 대비 평가 점수 (GPT 평가) | 70점 | 90점 |
<단일 프롬프트 방식과 에이전트 구조의 회의록 품질 비교 결과>
나. 회의록 자동화 에이전트 구조
- 사용자가 녹취록(txt) 파일을 선택하면, 오케스트레이터(Orchestrator)가 각 도구를 순서대로 호출하고 결과를 다음 도구로 넘겨 줍니다.
- 오류가 발생하거나 분류 신뢰도가 기준에 미치지 못하면 흐름을 분기해 사용자에게 확인을 요청합니다.
<회의록 자동화 에이전트 작업 흐름>
| 도구 | 역할 |
| transcript_loader_tool(녹취록 읽기) | 회의일자, 작성자 등 기본 정보를 추출하고 이후 분석에 쓸 데이터 준비 |
| transcript_quality_tool(입력 품질 점검) | 녹취록 길이를 확인하고 중간에 끊긴 흔적을 검출, 문제가 있으면 경고 반환 |
| meeting_classifier_tool(회의 유형 분류) | 회의 목적과 내용을 분석해 유형을 분류하고 신뢰도와 판단 근거 반환 |
| meeting_summary_tool(회의록 요약) | 회의 유형에 맞는 양식(템플릿)을 골라 보고서 형식의 회의록 초안 작성 |
| hwp_export_tool(결과 저장) | 한글 문서(HWP, Hangul Word Processor) 형식으로 회의록을 자동 생성 |
<회의록 자동화 에이전트의 도구 구성>
다. 도구 호출 신뢰성 확보 사례
(1) 회의 유형 분류 오류
처음에는 회의 유형을 아래 네 가지로 정의했습니다.
| 유형 | 설명 |
| analysis_plan (분석 기획) | 어떤 과제를 할지, 범위·일정·추진 계획을 정하는 단계 |
| analysis (분석 회의) | 정해진 과제를 어떻게 분석할지 방향·데이터·방법을 논의 |
| analysis_report (진행 보고) | 진행 상황과 이슈를 공유 |
| progress_report (결과보고) | 완료된 분석 결과를 보고하고 활용 방안을 논의 |
<초기 회의 유형>
– 그런데 주간회의처럼 여러 과제의 진행 현황 공유와 향후 계획 논의가 함께 이루어지는 회의는 네 가지 중 어디에도 명확히 속하지 않았습니다.
– 이를 해결하려고 ‘과제 추진·기획 회의(task_planning)’ 유형을 새로 추가했지만, 이번에는 analysis_plan과 task_planning의 경계가 모호한 회의가 생기면서 오히려 분류 오류 가능성이 커졌습니다.
– 아래는 실제 분류 결과로, 1위와 2위 유형의 점수 차이가 0.05에 불과해 어느 쪽이 맞는지 확신하기 어려운 상황입니다.
| ⚠ 사람 확인 필요 분류 추정: task_planning 분류 신뢰도(1위 점수): 0.90 1위-2위 점수 차이: 0.05 근거: 여러 분석 과제의 진행 현황을 검토하고 신규 분석 과제를 발굴하며, 제안 설명회 준비를 위한 폭넓은 논의를 다루고 있어 과제 추진·기획 회의에 가장 적합함 유형별 적합도 점수: – task_planning: 0.90 – analysis_plan: 0.85 – progress_report: 0.40 – analysis: 0.20 – analysis_report: 0.10 |
<회의 유형 분류 결과 예시>
– 이 문제를 줄이기 위해 신뢰도 기반 안전장치를 추가했습니다. 분류 신뢰도가 0.6 미만이거나 1위와 2위의 점수 차이가 0.2 미만이면 에이전트가 임의로 결정하지 않고 사용자에게 회의 유형 확인을 요청하며, 사용자는 분류 결과와 근거를 검토해 필요하면 유형을 직접 다시 선택할 수 있습니다.
(2) 녹취록 입력 누락
– 에이전트를 검증하기 위해 제가 작성한 회의록 외에도 팀원분들이 작성한 회의록과 녹취록을 받아 비교했는데, 그중 한 건에서 문제가 발견되었습니다.
– 에이전트가 만든 회의록에는 “10분 휴식 후 구글 드라이브에 업로드된 자립지원관 분석 자료를 바탕으로 세부 논의를 진행할 예정”이라는 내용만 있었는데, 팀원분이 작성한 회의록에는 그 이후 논의된 자립 성과 영향 요인, 보고서 종류, 자립지원기간 등이 상세히 정리되어 있었습니다.
– 원본 녹음본을 다시 확인해 보니, 휴식 직전에서 녹취록이 끊겨 이후 내용이 입력 파일에 아예 포함되지 않은 상태였습니다.- 원본 녹음본을 다시 확인해 보니, 휴식 직전에서 녹취록이 끊겨 이후 내용이 입력 파일에 아예 포함되지 않은 상태였습니다.
| 참석자 2 1:35:11 네 그러면은 한 10분만 쉬었다가 자립 지원관 분석 한 번만 마지막으로 얘기하고 참석자 1 1:35:19 예 그러시죠. 참석자 2 1:35:21 구글 드라이브에 올려놓은 참석자 1 1:35:22 예 알겠습니다. 45분에 다시 봬요. |
<녹음이 중단된 녹취록 일부 (클로바노트 녹음본)>
– 이런 누락을 막기 위해 회의록을 만들기 전에 입력 품질 점검 도구를 추가했으며, 녹취록 길이와 휴식·중단을 뜻하는 문구, 비정상적인 종료 여부 등을 확인해 문제가 있으면 경고를 띄웁니다.
(3) 과제 판단 기준의 모호성
– 주간회의에서 설명회 주제 선정을 위해 검토한 과제는 사람이 작성한 회의록 기준으로 23개였는데, 에이전트는 14개만 정리했습니다.
– 그래서 프롬프트를 아래처럼 훨씬 구체적으로 수정했습니다.
| [1차 프롬프트] “주요 논의안건”: ( “안건명은 회의에서 다룬 주제를 간결하게 괄호 안에 표기.” “진행 현황·신규 과제를 제외한 모든 논의를 빠짐없이 담을 것.” ) [2차 프롬프트] “주요 논의안건”: ( “진행 현황을 제외한 모든 논의 내용을 빠짐없이 작성할 것.” “회의에서 독립적으로 논의된 주제는 각각 [소제목] 형태로 구분할 것.” “소제목은 회의 내용에 맞게 자유롭게 생성하되, 실제 논의 단위를 기준으로 작성할 것.” “특정 주제 안에서 검토한 과제나 사례는 요약·통합하지 말고 1개 항목당 1개씩 모두 작성할 것.” “과제 수를 줄이거나 대표 사례만 선택하면 안 됨.” “내용 생략 없이 개조식으로 작성할 것.” ) |
<1차·2차 프롬프트 비교>
| 구분 | 사람 작성본 | 에이전트 1차 | 에이전트 2차 |
| OOOO 발표 후보 | 13개 | 8개 | 22개 |
| OOOOO 발표 후보 | 7개 | 3개 | 5개 |
| 도정업무계획 | 3개 | 3개 | 3개 |
| 합계 | 23개 | 14개 | 30개 |
<프롬프트 수정 전후 과제 목록 개수 비교>
– 그런데 프롬프트를 구체화하자 이번에는 원본보다 많은 30개가 나오는 등 결과가 계속 달라졌습니다.
– 녹취록을 살펴보면 “이거는 어때요?”, “이거는 한계가 있지 않았어요?”, “이거는 좀 뺐으면 좋겠고”, “그렇게 명확하지 않습니다”처럼 과제를 넣자·빼자·더 검토하자는 의견이 뒤섞여 있었고, 과제 선정과 제외에 대한 의견도 300줄 넘게 흩어져 있었습니다. 모델을 바꾸고 프롬프트를 개선해도 ‘최종 결정사항’의 판단 기준을 명확히 정의하기 어려웠고, 결국 AI가 최종 확정 과제를 일관되게 판단하기는 어렵다는 결론을 내렸습니다.
– 그래서 AI는 회의에서 언급된 과제를 최대한 빠짐없이 추출하고, 최종 포함 여부는 담당자가 검토해 확정하도록 역할을 나누었습니다.
(4) 도구 호출 추적성 확보
– 단일 프롬프트 방식은 녹취록이 GPT를 거쳐 곧바로 회의록이 되기 때문에, 결과에 문제가 생겨도 원인을 확인할 방법이 없습니다.
– 에이전트 방식에서는 각 도구가 호출될 때마다 실행 기록(로그)을 남기도록 했습니다.
| [Tool Call] transcript_loader_tool ✓ 녹취록 로드 완료: 12,293자 / 461줄 ✓ 회의일자: 2025.05.21 [Tool Call] transcript_quality_tool ✓ 입력 품질 정상 ✓ 점검 결과: 경고 없음 [Tool Call] meeting_classifier_tool ✓ 회의유형: analysis ✓ 신뢰도: 0.85 / 1위-2위 차이: 0.40 ✓ 후보 점수: analysis 0.85, analysis_plan 0.45, progress_report 0.35 [Tool Call] meeting_summary_tool ✓ 회의록 요약 완료 ✓ 생성 항목: 회의 제목, 안건, 분석 방향, 데이터 현황 및 확보 방안, 현장 조사 계획, 타 기관 분석 사례 … [Tool Call] hwp_export_tool ✓ HWP 저장 완료: 해충 기피제 분사기 설치 입지 선정 회의_2025.05.21.hwp |
<실제 에이전트 실행 로그>
– 실행 기록(로그)을 통해 어떤 도구가 호출되었는지, 어떤 결과가 반환되었는지, 어느 단계에서 문제가 생겼는지 한눈에 확인할 수 있게 되었습니다.
3. 결론
최종 완성한 회의록 생성 프로그램은 사용법이 간단합니다. 녹취록(txt) 파일을 선택하고 회의 유형을 ‘자동 판단’으로 둔 채 [회의록 생성] 버튼만 누르면 됩니다. 프로그램은 도구 호출 과정을 실시간 로그로 보여 주면서 요약 내용과 한글 문서 회의록을 함께 만들어 주며, 자동 판단 결과가 애매하면 사용자가 회의 유형을 직접 골라 다시 생성할 수 있습니다.
실제 사업 회의(익산시 데이터 분석 사업 수요부서 회의, 경기도 데이터 분석 사업 주간보고)를 대상으로 사람이 쓴 회의록과 AI가 만든 회의록을 비교한 결과는 다음과 같습니다.
| 비교 결과 | 내용 | 평가 |
| 사람·AI 모두 동일 | 핵심 업무 내용과 조치사항을 정확히 추출일정, 담당자, 후속 업무 정리에 강점 | 1차 초안 작성에 필요한 핵심 정보는 대부분 확보 가능 |
| AI가 검토 단계를 확정으로 작성 | 논의 단계와 확정 단계를 구분하지 못함실제 업무에서 잘못된 의사결정이 전달될 가능성 | 최종 배포 전 검토는 필요하지만 초안 작성에는 큰 영향 없음 |
| AI가 내용을 축약·누락 | 세부 논의 과정이 축약되어 의사결정 배경 추적이 어려움 | 사람의 검토로 보완 가능하며 전체 회의 흐름은 유지됨 |
<사람 작성 회의록과 AI 작성 회의록 비교 결과>
| 구분 | 사람 회의록 | AI 회의록 |
| 작성 방식 | 논의 과정과 발언 맥락 중심 | 핵심 안건과 결과 중심 |
| 구성 | 결론이 나온 배경 설명 포함검토 단계와 확정 단계를 구분해 기록 | 업무·과제·조치사항 위주로 구조화비슷한 내용을 묶어 간결하게 정리 |
| 강점 | 참석자 관점의 의사결정 근거 보존회의의 흐름과 맥락을 이해하기 쉬움 | 담당자 관점의 후속 업무 파악결과를 빠르게 공유하고 초안 작성하기 쉬움 |
<사람 회의록과 AI 회의록의 특징>
정리하면, 사람이 쓴 회의록은 “왜 그런 결론이 나왔는가“를 기록하고, AI가 쓴 회의록은 “무엇을 해야 하는가“를 정리합니다. AI는 핵심 안건과 업무 내용을 대부분 추출하지만 논의 과정과 세부 맥락은 일부 축약하기 때문에, 현재로서는 AI가 초안을 빠르게 만들고 담당자가 검토·확정하는 방식이 가장 현실적입니다.
이번 프로젝트를 통해 도구 호출의 신뢰성은 프롬프트만 다듬어서는 확보하기 어렵고, ① 신뢰도 기준에 따른 사람 확인, ② 입력 품질 점검, ③ AI와 사람의 역할 분담, ④ 도구 호출 추적성 같은 구조적인 안전장치가 함께 필요하다는 점을 확인했습니다. 앞으로 회의 유형별 양식을 다양화하고 팀마다 다른 작성 방식까지 반영한다면, 더 많은 회의록 작성 업무를 자동화할 수 있을 것으로 기대됩니다.