OpenPlanter로 OSINT 조사를 자동화해도 될까: 재귀 에이전트와 검증 책임

OpenPlanter의 재귀 하위 에이전트, 이기종 데이터, 엔티티 연결 구조를 살펴보고, OSINT 조사에서 권한, 환각, 비용, 근거 검증 기준을 설명합니다.

게시 2026/03/01 업데이트 2026/08/26

ShinMegamiBoson/OpenPlanter GitHub 저장소 대표 이미지

By OPSOAI 편집팀

17 분읽는 시간

OpenPlanter로 OSINT 조사를 자동화해도 될까: 재귀 에이전트와 검증 책임

OpenPlanter는 PDF, CSV, JSON처럼 흩어진 자료를 여러 하위 작업으로 나눠 탐색하고 엔티티 연결 후보를 만드는 OSINT 에이전트입니다. 재귀 위임은 넓은 조사를 병렬화할 수 있지만, LLM이 만든 동일인, 인과관계 추정을 사실로 확정해 주지는 않습니다. 도입 여부는 화려한 보고서보다 각 주장에 원문 근거가 남는지, shell, network 권한과 조사 비용을 통제할 수 있는지로 판단해야 합니다.

재귀 하위 에이전트는 무엇을 나누나

OpenPlanter는 큰 조사 질문을 ‘재귀적 하위 에이전트 위임(Recursive Sub-Agent Delegation)’으로 나눕니다. 상위 작업은 조사 계획과 결과 통합을 맡고, 하위 작업은 서로 다른 자료나 가설을 탐색할 수 있습니다.

재귀 깊이는 작업량과 오류도 함께 늘린다

OpenPlanter의 기본 max-depth는 4로 설정되어 있습니다. 거대한 조사 목표를 주면, 메인 에이전트가 하위 에이전트를 생성하고, 그 하위 에이전트가 또 다른 에이전트를 병렬로 띄워서 작업을 분담합니다.

기능	기존 표준 AI 에이전트	OpenPlanter 🌿
작업 처리	단일 스레드, 순차적 처리	병렬/재귀적 처리 (Sub-agent Delegation)
데이터 이해	단일 포맷 제한 (또는 RAG 의존)	이기종 데이터(PDF, CSV, JSON) 동시 병합 및 엔티티 리졸루션
도구 활용	제한된 API 호출	19개의 전용 도구 (Shell, Exa 웹 검색, File I/O 등)
추론 방식	단순 텍스트 매칭	확률적 이상 탐지 (Probabilistic Anomaly Detection)

엔티티 연결은 정답이 아니라 검토 후보다

예를 들어 같은 기업이 자료마다 A Corp, A Corporation, 대표자 이름으로 기록되면 단순 문자열 조인만으로 연결하기 어렵습니다. LLM은 문맥을 이용해 동일 엔티티 후보와 시간상 연관을 제안할 수 있습니다. 그러나 동명이인과 계열사, 주소 변경이 있으면 잘못 묶을 수 있고, 사건이 연달아 일어났다는 사실만으로 인과관계를 확정할 수도 없습니다.

저장소의 VISION.md는 온톨로지 계층과 19개 도구를 이용한 조사 방향을 설명합니다. 파일 조작, 백그라운드 shell, 웹 검색은 탐색 범위를 넓히지만 동시에 외부 상태 변경과 민감 자료 유출 가능성을 만듭니다. 도구 수보다 각 도구가 읽고 쓸 수 있는 범위를 먼저 확인해야 합니다.

설치 예시는 어디까지 안전을 보장하나

에이전트가 run_shell로 시스템을 다루므로 Docker 격리는 중요한 출발점입니다. 그러나 container에 host socket이나 넓은 volume, 전체 network와 production secret을 주면 격리의 효과가 줄어듭니다. 다음 명령은 실행 흐름을 보여 주며 안전한 운영 구성을 완성하지 않습니다.

설치부터 실행까지, 터미널에서 아래 코드 몇 줄이면 끝납니다.

  
# 저장소 클론
git clone https://github.com/ShinMegamiBoson/OpenPlanter.git
cd OpenPlanter

# 환경변수 세팅 (API 키 등)
cp .env.example .env
# GPT-5.2나 Claude-Opus-4.6, 혹은 로컬 Ollama 세팅을 해줍니다.

# 도커를 통한 안전한 실행
docker compose up

.env에는 API key와 endpoint가 들어갈 수 있으므로 image나 log에 복사되지 않게 해야 합니다. 입력 자료는 읽기 전용으로 mount하고 결과를 쓸 별도 directory만 허용하는 구성이 좋습니다. 로컬 모델을 쓴다면 저장은 로컬이어도 웹 검색 도구가 외부로 어떤 질의를 보내는지 별도로 확인해야 합니다.

장점과 한계는 어떤 조건에서 바뀌나

가능한 장점

서로 다른 문서 형식을 한 조사 계획에서 다룰 수 있습니다.
파일, 검색, shell 도구를 하위 작업에 나눠 병렬 탐색할 수 있습니다.
로컬 모델과 제한된 container를 선택하면 일부 민감 자료의 외부 전송을 줄일 수 있습니다.

남는 한계

하위 작업이 늘수록 토큰, 검색, 파일 읽기와 중복 조사가 함께 늘어납니다.
작은 로컬 모델은 긴 자료의 관계 판단과 지시 준수에서 충분한지 별도 정답 세트가 필요합니다.
확률적 엔티티 연결은 동명이인이나 계열사를 잘못 합칠 수 있으므로 human-in-the-loop 검증이 필요합니다.

조사 결과를 어떻게 검증할까

먼저 답을 알고 있는 작은 자료 묶음을 만듭니다. 같은 기관의 표기 변형, 실제 동명이인, 관련 없어 보이지만 같은 주소를 쓰는 사례를 포함하고 OpenPlanter가 어떤 근거로 연결했는지 봅니다. 정답 연결뿐 아니라 잘못 합친 비율과 놓친 연결을 함께 기록해야 합니다.

최종 보고서의 각 주장에는 원본 파일, 페이지 또는 URL, 인용된 필드, 수집 시각이 남아야 합니다. 하위 에이전트의 요약만 이어 붙이면 어느 단계에서 오류가 생겼는지 찾기 어렵습니다. “이상 징후”와 “확인된 사실”, “추가 확인 필요”를 다른 상태로 표시하고 결론에 반대되는 자료도 검색하게 해야 합니다.

개인정보와 공개 자료의 적법성도 별도 판단입니다. 웹에서 찾을 수 있다는 사실이 개인을 프로파일링하거나 공개 보고서에 다시 배포할 권리를 자동으로 주지는 않습니다. 조사 목적과 보관 기간, 접근자, 삭제, 정정 절차를 정하고 위험한 개인 식별 결과에는 사람 승인을 둬야 합니다.

도입 여부는 어떤 표로 결정할까

작업별로 수동 조사 시간, 에이전트의 전체 호출 비용, 근거가 확인된 주장 비율, 잘못된 엔티티 연결 수를 비교합니다. 재귀 깊이를 1부터 늘려 새 근거가 더 생기는지 보고, 같은 문서를 반복해서 읽기 시작하면 중단합니다. 로컬 모델과 외부 모델도 같은 질문, 자료, 권한으로 비교해야 비용과 품질 차이를 설명할 수 있습니다.

OpenPlanter가 적합한 경우는 조사자가 원문 검증을 계속 맡으면서 넓은 자료의 탐색 후보를 빠르게 만들고 싶은 때입니다. 자동으로 사람이나 조직의 책임을 판정하거나 근거 없는 의혹을 공개하는 용도로는 적합하지 않습니다. 에이전트는 결론을 대신하는 판정자가 아니라, 추적 가능한 조사 가설을 만드는 보조 도구로 두는 편이 안전합니다.

조사 질문은 어떻게 쪼개야 하나

“어떤 회사가 부당한 계약을 받았는가”처럼 결론을 전제한 질문은 에이전트가 그 방향의 자료만 모으게 할 수 있습니다. 대신 계약 당사자, 금액, 날짜를 추출하는 작업, 법인 식별자를 대조하는 작업, 계약 전후의 공개 사건을 시간순으로 정리하는 작업처럼 관찰 가능한 단위로 나눕니다. 마지막 단계에서만 관계 가설을 만들고 반례를 찾는 별도 하위 작업을 둡니다.

각 하위 작업의 output schema도 정합니다. 주장은 원문 위치, 원문에서 직접 읽은 값, 모델이 해석한 값, 신뢰 상태를 나눠 반환해야 합니다. 출처가 없는 항목은 다음 agent가 사실처럼 재사용하지 못하게 하고, 같은 자료를 두 agent가 다르게 읽었으면 충돌로 표시합니다.

종료 조건은 정해진 깊이뿐 아니라 새 근거의 양과 중복률로 둘 수 있습니다. 추가 탐색이 이미 본 URL과 같은 주장만 반복하면 멈추고, 중요한 식별 정보가 부족하면 사람에게 필요한 자료를 요청합니다. 이렇게 해야 비용 상한이 단순 강제 중단이 아니라 조사 품질을 설명하는 경계가 됩니다.

조사 기록에는 누가 어떤 결론을 승인했는지도 남겨 자동 탐색 결과와 사람의 최종 판단을 구분해야 합니다.

결과물은 관계 그래프보다 근거 묶음으로 검수한다

화면에 노드와 선이 많다고 조사가 깊어진 것은 아닙니다. 연결 하나를 선택했을 때 원문 위치, 수집 시각, 추출값, 모델의 해석, 반대 증거가 한 묶음으로 열려야 검수자가 판단을 되짚을 수 있습니다. 같은 이름을 주소나 법인 식별자 없이 합친 연결, 날짜 순서가 맞지 않는 연결, 한 출처만 되풀이한 연결은 우선 검토 대상으로 올립니다.

파일럿 보고서에는 전체 노드 수보다 근거가 확인된 주장 비율, 잘못 합친 엔티티 비율, 출처 없는 문장 수, 사람이 수정하는 데 걸린 시간을 적는 편이 유용합니다. 이 지표가 수동 조사보다 좋아지지 않는다면 재귀 깊이나 모델 크기를 먼저 늘리기보다 질문 분해와 출력 계약을 고쳐야 합니다. 사람에게 영향을 주는 결론은 자동 게시하지 않고, 승인된 문장과 원문 인용 범위를 별도로 고정해야 합니다.

원문과 버전 확인

공식 GitHub 저장소

함께 읽으면 이해가 이어지는 글

MarkItDown만으로 RAG 전처리가 끝날까: PDF 읽기 순서, 표, VLM 비용 점검 — PDF, 엑셀, PPT를 마크다운으로 통일하는 MarkItDown의 역할과 다단 PDF, 병합 셀, 메타데이터, VLM 비용에서 남는 검증 과제를 정리합니다.
클로드(Claude) 사용법: 프로젝트, PDF, Artifacts, Skills 실전 가이드 — 무료 계정으로 프로젝트와 PDF 분석을 시험하고 Artifacts, Skills, 메모리, 공유 기능을 안전하게 활용하는 순서와 Pro 전환 기준을 정리합니다.
RAG가 엉뚱한 문서를 찾는다면? RAFT의 Distractor 학습법 — 정답 문서와 방해 문서를 함께 넣고 근거를 인용하게 만드는 RAFT의 데이터 구성, 성능표, 적용 조건

자주 묻는 질문

OpenPlanter가 연결한 두 엔티티를 사실로 사용해도 되나요?

LLM이 이름과 문맥을 보고 제안한 연결은 조사 가설입니다. 원본 문서의 식별자, 주소, 날짜와 반대 근거를 사람이 확인하고, 각 주장에 출처를 연결한 뒤 사용해야 합니다.

Docker로 실행하면 shell 도구도 안전한가요?

컨테이너는 경계를 줄이는 수단이지만 host volume, network, secret을 과도하게 열면 피해가 밖으로 이어질 수 있습니다. 읽기 전용 입력과 제한된 출력, 네트워크로 권한을 최소화해야 합니다.

재귀 깊이를 높이면 조사 품질이 계속 좋아지나요?

하위 작업이 늘면 탐색 범위와 함께 토큰, 도구 호출, 중복 조사와 오류 전파도 커집니다. 질문별 예산과 깊이, 중단 조건을 두고 추가 단계가 새 근거를 만드는지 확인해야 합니다.

References

Tech

RAG AI에이전트