안녕하세요. 저는 마키나락스의 FDE(Forward Deployed Engineer, 전방 배치 엔지니어) 김태민입니다.

저는 최근 합동참모본부의 ‘생성형 AI 적용 KJCCS 정보 검색 및 운영 기술 실증’ 프로젝트에 참여했습니다. 이번 프로젝트는 KJCCS 전장망 AI 적용 사례로, 마키나락스는 AI OS Runway 기반으로 전장망에 AI 개발·운영 환경을 구축했고, 2026 을지 자유의 방패(UFS) 연습에서 실제 군 운용 환경을 대상으로 활용 가능성을 검증했습니다.

프로젝트 전체 내용은 마키나락스 공식 보도자료에서 확인하실 수 있습니다.

이 글에서는 프로젝트 전체보다, 제가 현장에서 기존 시스템과 AI 서비스를 연결하면서 실제로 부딪혔던 문제들을 이야기해보려고 합니다.

폐쇄망 AI, 들어가 보기 전에는 알 수 없었던 것들

이번 프로젝트에서 제가 맡은 일은 KJCCS 안의 문서와 기존 시스템을 AI 서비스에 연결해 실제 전장망에서 사용할 수 있게 만드는 것이었습니다.

개발 환경에서는 Runway 위에 챗봇 서비스를 배포하는 데까지는 확인할 수 있었습니다. 하지만 실제 전장망의 데이터와 문서 환경은 밖에서 그대로 재현할 수 없었습니다.

현장에서는 외부 인터넷에 접속할 수 없었고, 새로운 패키지나 라이브러리를 가져오는 데도 제약이 있었습니다. 프로그램을 수정해 다시 반입하는 일도 바로 할 수 있는 일이 아니었습니다. 이런 폐쇄망 AI 환경의 제약은 공공·국방 환경에서 AI를 구축할 때 반복해서 마주치는 문제이기도 합니다.

결국 현장에 들어가고 나서야 알게 되는 조건들이 있었습니다. DB는 어떻게 연결돼 있는지, 파일은 어떤 경로로 들어오는지, 전달받은 규칙이 실제 데이터에서도 그대로 맞는지 하나씩 확인해야 했습니다.

기존에는 사용자가 자료실에서 필요한 문서를 직접 찾아야 했습니다. 우리가 만들려던 서비스는 이 자료를 인덱싱해, 자연어로 질문하면 관련 문서를 찾고 답변과 출처를 함께 보여주는 방식이었습니다.

전장망의 기존 문서 시스템과 분류 정보가 수집·인덱싱을 거쳐 챗봇 검색으로 이어지는 개념 구조

전장망의 기존 문서 시스템과 분류 정보가 수집·인덱싱을 거쳐 챗봇 검색으로 이어지는 개념 구조

그림으로 그려 놓으면 단순합니다. 문제는 저 화살표 사이였습니다.

폐쇄망에서 직접 접근할 수 없는 시스템을 연결하는 일

현장에서는 엔지니어가 작업하는 단말에서 고객 시스템에 바로 접근할 수 없었습니다. 접근할 수 있는 영역과 권한이 제한돼 있었고, 고객 시스템 자체를 우리가 임의로 수정할 수도 없었습니다.

필요한 DB와 서버는 별도의 조회 권한을 받아 확인했고, 일부 연동은 Runway가 설치된 서버를 경유해 접근했습니다. 우리가 만든 서비스의 로그와 실행 상태는 직접 볼 수 있었지만, 고객 시스템 쪽에서 문제가 생기면 담당자와 함께 확인해야 했습니다.

평소 개발하던 방식과는 문제를 찾는 순서부터 달랐습니다. 코드를 바로 열어보는 대신, 먼저 어디까지 접근할 수 있는지와 어느 구간까지 정상인지부터 확인해야 했습니다.

계정은 정상인데, DB에는 들어갈 수 없었다

문서 정보와 카테고리를 가져오기 위해 RDBMS를 연결해야 했습니다.

SDK가 있었기 때문에 처음에는 어렵지 않을 거라고 생각했습니다. 하지만 실제 Linux 환경에서는 별도의 접속 설정 파일과 환경변수가 필요했고, Python과 드라이버 사이의 문자 인코딩도 맞춰야 했습니다.

드라이버가 올라오는지, 접속 정보는 제대로 읽히는지, DB 서버까지 통신이 되는지 하나씩 확인했습니다. 그래도 인증은 계속 실패했습니다.

계정은 정상이었습니다. 연결 문자열에서 비밀번호를 감싸고 있던 중괄호 { }를 현장 드라이버가 비밀번호의 일부로 해석하고 있었습니다. 전달 형식을 바꾸자 접속이 됐습니다.

인증 실패라는 메시지만 보고 계정만 계속 확인했다면 꽤 오래 헤맸을 문제였습니다.

비밀번호를 입력하기도 전에 SSH가 끊겼다

파일 서버 연동에서도 비슷한 일이 있었습니다.

SSH로 원본 파일을 가져와야 했는데 비밀번호를 검증하기도 전에 연결이 끊겼습니다. 원인은 현장 서버의 구형 호스트키 알고리즘과 최신 클라이언트의 기본 허용 범위가 맞지 않았기 때문이었습니다. 인증 단계에 들어가기도 전에 통신 협상에서 실패하고 있었습니다.

현장 서버가 지원하는 조건에 맞게 클라이언트 설정을 조정한 뒤, 개발 환경에도 같은 조건의 구형 SSH 서버를 구성해 오류를 재현했습니다. 수정 후에는 접속 여부만 확인하지 않고 실제 파일 전송과 배치 동기화까지 다시 실행했습니다.

접속이 됐다고 끝낼 수는 없었습니다. 실제 파일을 가져와 다음 처리 단계까지 넘겨본 뒤에야 이 연동을 마무리할 수 있었습니다.

현장에서 확인한 증상에서 원인을 좁히고, 대응 후 실제 동작까지 검증한 세 가지 연동 사례

현장에서 확인한 증상에서 원인을 좁히고, 대응 후 실제 동작까지 검증한 세 가지 연동 사례

사용자 계정 연동에서도 비슷했습니다. 전달받은 비밀번호 검증 규칙대로 구현했지만 실제 저장값과 맞지 않았고, 테스트 계정의 계산값과 원천 저장값을 비교해 입력 조합과 인코딩 방식을 다시 맞췄습니다.

DB, SSH, 계정 연동 모두 결국은 실제 값과 실행 결과를 직접 확인하면서 풀었습니다.

그래서 현장에서 바로 확인할 수 있는 도구를 만들었다

몇 번 이런 일을 겪고 나니, 현장에서는 “안 된다”는 것보다 어디까지 되고 어디서부터 안 되는지 바로 볼 수 있는 것이 더 중요했습니다.

이번 프로젝트는 미리 알 수 없는 정보가 많았습니다. DB의 테이블명과 컬럼명도 직접 확인해야 했고, 문서가 들어오는 경로와 인덱싱 방식도 하나가 아니었습니다. 그런데 조건이 하나 달라질 때마다 밖에서 코드를 수정해 다시 반입할 수는 없었습니다.

그래서 i4e(indexer4engineer)를 만들었습니다.

DB 연결 상태와 가져온 데이터를 보고, 파일을 탐색하고, 수동 인덱싱이나 동기화 배치를 직접 실행할 수 있는 도구입니다. 현장에서 설정을 바꾼 뒤 바로 다시 돌려볼 수 있게 했습니다.

FDE 현장 운영 도구 i4e 문제 확인 설정 조정 재검증 흐름

i4e를 통해 현장 조건을 확인하고 원인의 범위를 좁힌 뒤, 설정을 조정하고 다시 검증하는 흐름

i4e가 있으니 새 조건이 나왔을 때 그 자리에서 확인하고, 원인을 좁히고, 설정을 바꾼 뒤 다시 실행해볼 수 있었습니다.

해결한 내용은 history 폴더에도 남겼습니다. 같은 문제를 다음 프로젝트에서 또 처음부터 찾지 않기 위해서였습니다. 현장에서 한 번 알아낸 것을 개인의 기억으로만 남기지 않고, 다음 작업에서 다시 쓸 수 있게 해두는 것도 중요했습니다.

실제 훈련보다 더 긴장됐던 건 그 전이었다

연동을 마친 뒤에는 10GB가 넘는 실제 자료를 인덱싱했습니다. 그때부터 개발 환경에서는 보지 못했던 것들이 나오기 시작했습니다. DRM이 적용된 문서도 있었고, 지원 범위를 벗어난 확장자도 섞여 있었습니다. 처리 가능한 문서와 실패한 문서를 나누고, 원천 데이터 조회부터 파일 수집과 인덱싱까지 다시 확인했습니다.

실제로 가장 긴장됐던 때는 UFS가 시작된 뒤보다 직전이었습니다. 챗봇은 벡터 DB에 문서가 제대로 들어가 있으면 동작하지만, 그 상태를 만들려면 여러 배치 작업이 중간에 끊기지 않고 돌아가야 했습니다. 훈련 전에 이 흐름을 안정화하는 일이 중요했습니다.

훈련이 시작된 뒤에도 현장에 함께 있었습니다. 서비스 상태와 인덱싱을 보고, 사용자 문의와 검색 결과를 확인하면서 필요한 설정을 조정했습니다. 결국 배포가 끝났다는 것보다, 실제 사용자가 쓸 수 있는 상태인지 확인하는 게 더 중요했습니다.

다음 현장에서는 무엇을 먼저 볼 것인가

이번 프로젝트를 끝내고 나니, 다음 폐쇄망 프로젝트에 들어가면 무엇부터 확인해야 할지가 전보다 훨씬 분명해졌습니다.

DB와 파일 서버의 접속 조건, 접근 권한, 실제 데이터의 형태처럼 밖에서는 알기 어려웠던 것들입니다.

이번에 확인한 내용과 해결 방법은 기록과 도구로 남겼습니다. 다음에는 같은 문제를 처음부터 다시 풀지 않기 위해서입니다.

한 현장에서 알아낸 것을 다음 현장에 가져갈 수 있게 만드는 것까지가, 제가 이번 프로젝트에서 배운 FDE의 역할 중 하나였습니다.

KJCCS 프로젝트에서도 DB나 파일 서버를 연결하는 것 자체가 목표는 아니었습니다. 전장망에 있던 자료가 AI 서비스에서 검색되고, 실제 UFS 훈련에서 사용자가 활용하는 데까지 가는 것이 목표였습니다.

현장에서 실제 조건을 확인하고, 맞지 않는 부분을 하나씩 연결하고, 마지막에는 사용자가 실제로 쓸 수 있는 상태까지 만드는 것. 제가 이번 프로젝트에서 경험한 FDE의 일은 그런 일이었습니다.

향후 확장성을 기대하기 위해서는 방대한 비문에 대한 처리가 실시간으로 권한에 맞춰 이루어져야 합니다. 현재 기능실별 데이터 적재를 설계에 반영하여 적재하고 있어서 내년 훈련에서는 보다 광범위한 서비스를 제공할 수 있을 것으로 기대하고 있습니다.