RAG 채팅만으로는 부족해서, 지식그래프에 버튼을 만들었습니다
채팅으로 매번 같은 질문을 하고 있었습니다
RAG 채팅을 만들고 나서, 처음에는 모든 걸 자연어로 물어보는 게 편했거든요. "물류서버-A에 연결된 시스템은?", "물류서버-A 장애 시 복구 절차 알려줘" 같은 질문을 던지면 답변이 나오니까요.
그런데 실제로 쓰다 보니 패턴이 보이더라고요. 같은 유형의 질문을 반복해서 치고 있었습니다. 서버 점검할 때마다 "이 서버에 연결된 시스템은?" 물어보고, 장애 날 때마다 "복구 절차 알려줘" 물어보고. 매번 자연어로 타이핑하고, LLM이 라우팅하고, 검색하고, 답변 생성까지 기다리는 거예요.
"이거 버튼 하나로 되면 안 되나?" 싶었습니다.
채팅과 버튼은 푸는 문제가 다릅니다
생각해보면 질문에는 두 종류가 있었어요.
"올해 인프라 이슈 중에서 인증서 관련된 것만 정리해줘" — 이런 건 탐색적 질문입니다. 뭘 물어볼지 미리 정해져 있지 않고, 대화하면서 범위를 좁혀가는 거예요. 이건 채팅이 맞습니다.
"물류서버-A에 연결된 시스템 보여줘" — 이런 건 반복 작업입니다. 질문 형태가 정해져 있고, 입력만 바뀌는 거예요. 서버 이름만 다르지, 매번 같은 구조의 질문이거든요. 이건 버튼이 맞습니다.
채팅 | 버튼 | |
|---|---|---|
적합한 상황 | 탐색적 질문, 범위를 모를 때 | 반복 작업, 입력만 바뀔 때 |
장점 | 유연함, 예상 못한 질문 가능 | 정확함, 빠름, 실수 없음 |
단점 | 라우팅 실패 가능, 느림 | 미리 정의한 것만 가능 |
둘 중 하나를 고르는 게 아니라, 둘 다 필요했습니다.
Action이라는 개념을 도입했습니다
버튼을 만들려면 "어떤 버튼이 있고, 어떤 노드에서 쓸 수 있고, 누르면 뭘 실행하는지"를 어딘가에 정의해야 합니다. 이걸 Action이라고 부르기로 했어요.
팔란티어 Foundry에서 이 패턴을 배웠습니다. 팔란티어는 온톨로지에 Action Type을 등록해두고, 노드를 선택하면 해당 노드 타입에 맞는 Action 버튼이 자동으로 나타나는 구조를 쓰거든요. "이 버튼을 누르면 이 로직을 실행해라"를 미리 정의해놓는 겁니다.
같은 원리를 적용해서, actions.yaml 파일에 Action을 중앙에서 정의하고 여러 곳에서 쓰는 구조를 만들었어요.
현재 정의된 Action은 이렇습니다.
Action | 동작 | 대상 |
|---|---|---|
영향도 분석 | N홉 파급 범위를 depth별 색상으로 시각화 | System, Service, Person |
의존성 경로 | 두 노드 사이 최단 경로 탐색 | System, Service, Person |
복구 플랜 생성 | 단일 시스템 장애 시 AI가 복구 절차 자동 생성 | System, Service |
RAG 질의 | 채팅 페이지로 이동해서 해당 노드 기반 질문 | System, Service, Person |
한 곳에서 정의하고, 여러 곳에서 씁니다
Action을 yaml 파일 하나에 모아둔 이유가 있습니다. 같은 Action이 여러 화면에서 쓰이거든요.
그래프 다이어그램에서 노드를 클릭하면 상세 패널이 열리고, 거기에 Actions 드롭다운이 있습니다. 이 드롭다운의 목록이 actions.yaml에서 해당 노드 타입에 맞는 Action만 필터링돼서 나와요. System 노드를 클릭하면 영향도 분석, 의존성 경로, 복구 플랜, RAG 질의 4개가 보이고, Person 노드를 클릭하면 복구 플랜은 빠지는 식입니다.
장애 분석 보고서 생성 페이지에서도 같은 Action 정의를 씁니다. 분석 유형 카드가 actions.yaml에서 동적으로 생성되거든요. 새로운 분석 유형을 추가하고 싶으면 yaml에 Action을 하나 추가하면 됩니다.
이 구조의 장점은 Action을 추가할 때 프론트엔드를 건드리지 않아도 된다는 거예요. yaml에 정의하고, 필요하면 백엔드 API를 만들고, 프롬프트를 추가하면 끝입니다. 화면에서는 API로 Action 목록을 받아서 동적으로 표시하니까요.
실행 방식도 Action마다 다릅니다
Action마다 결과를 보여주는 방식이 다릅니다. 영향도 분석은 그래프 페이지에서 바로 실행되고, 복구 플랜은 팝업으로 결과가 나오고, 복합 장애 분석은 별도 보고서 페이지로 이동하거든요.
이걸 mode라는 필드로 구분했습니다.
mode | 동작 | 예시 |
|---|---|---|
graph | 그래프 페이지에서 바로 실행 | 영향도 분석 |
popup | 상세 패널 위에 팝업으로 결과 표시 | 의존성 경로, 복구 플랜 |
page | 별도 페이지로 이동 | 복합 장애 분석 (예정) |
external | 외부 페이지로 이동 | RAG 질의 → 채팅 페이지 |
mode 하나로 "이 Action은 어떻게 실행되는지"가 결정되니까, 새 Action을 만들 때 mode만 지정하면 프론트엔드가 알아서 처리합니다.
자주 쓰는 패턴이 보이면 버튼으로 승격합니다
팔란티어에는 Forward Deployed Engineer가 현장에서 업무 프로세스를 파악하고 Action을 설계해주거든요. 우리한테는 그런 컨설턴트가 없으니까 다른 방식으로 접근했습니다.
채팅 로그를 보면서 자주 나오는 질문 패턴이 보이면 그때 Action으로 만드는 거예요. "이 서버에 연결된 시스템은?" 패턴이 반복되니까 영향도 분석 버튼을 만들었고, "장애 시 복구 절차 알려줘" 패턴이 반복되니까 복구 플랜 버튼을 만든 거죠.
온톨로지 거버넌스에서 미매핑 타입을 시그널 누적으로 승격하는 것과 같은 패턴이에요. 채팅 질문을 수집하고, 자주 나오는 패턴을 발견하고, Action으로 승격하는 피드백 루프입니다.
채팅은 탐색용, 버튼은 반복 업무용
결국 두 채널이 역할을 나눠 갖는 구조가 됐습니다. 그래프 페이지에서 노드를 클릭하면 Action 드롭다운으로 영향도 분석이나 복구 플랜을 바로 실행하고, 탐색적 질문이 필요하면 채팅으로 넘어가는 흐름이에요.
팔란티어도 원래는 구조화 UI(버튼)만 쓰다가, 2024년에 AIP Chat으로 자연어 채팅을 추가했습니다. 우리는 반대로 채팅부터 시작해서 버튼을 추가한 거고요. 방향은 반대였지만 결국 "채팅 + 버튼 병행"이라는 같은 구조에 도착했습니다.
반복 작업을 채팅으로 처리하고 있다면, 자주 쓰는 패턴을 Action으로 만들어보는 걸 추천합니다. yaml 하나에 정의하면 여러 화면에서 쓸 수 있고, 새 Action 추가도 코드 수정 없이 가능합니다.