개인 프로젝트 · 2026.06 - 2026.08

자연어 업무 시스템 생성 에이전트

LLM에게는 의도만 맡기고, 플랫폼에 쓰는 일은 결정적인 코드에 맡겼습니다.

개요

기간: 2026.06 - 2026.08
참여 형태: 개인 프로젝트
담당: 설계·구현·검증
목적: 반복되는 CRUD·승인 업무 시스템 구축을 요구사항 문서에서 바로 시작할 수 있게 하는 것
대상: 자사 솔루션으로 업무 시스템을 만드는 개발자
사용 기술: Python · MCP · PostgreSQL

자사 솔루션은 엔티티·폼·리스트·워크플로우·메뉴 같은 메타데이터로 업무 시스템을 구성합니다. 반복되는 CRUD·승인 업무 시스템을 요구사항 문서나 자연어 한 줄로 만들 수 있도록, 의도를 명세로 바꾸는 단계와 플랫폼 객체를 생성하는 단계를 나눈 에이전트를 개인 프로젝트로 설계하고 구현했습니다. 실사용자는 없고, 검증용 인스턴스에 빌드해 동작을 확인했습니다. 구현에는 AI 보조를 썼습니다.

구현 기능과 기술 선택

자연어·문서 요구사항의 명세화와 빈칸 질문
미리보기와 사람 승인 뒤의 생성
생성 결과의 E2E 시나리오 도출과 KPI 판정
요구사항 → 명세 → 결정적 그래프 → 변경 계획 파이프라인과 빈칸 질문
엔티티·필드·물리 테이블·폼·리스트·릴레이션·워크플로우·메뉴·자동화 규칙 빌더
의존 DAG·멱등·낙관적 잠금·보상 롤백 반영 엔진과 미리보기 격리 실행
상태 전이에서 E2E 시나리오를 도출하고 KPI 목표값으로 판정하는 측정 단계

LLM은 의도만, 빌더는 결정적으로: LLM이 플랫폼 메타데이터를 직접 쓰면 없는 컬럼이나 키를 만들어 낼 수 있습니다. LLM은 업무 의도와 얇은 명세만 만들고, 실제 객체는 같은 입력에 같은 결과를 내는 빌더가 생성하게 했습니다.
격리 인스턴스 적용과 보상 롤백: 요청 단위로 초안을 겹쳐 보여 주려면 플랫폼 코어를 바꿔야 했습니다. 코어를 건드리지 않으려고 격리 인스턴스에 실제로 적용했다가 보상 롤백으로 되돌리는 방식을 택했고, 대신 인스턴스당 초안 하나만 다룹니다.
사내망 전용 MCP 서버: 빌드에는 사내망 플랫폼 세션이 필요해, 원격 지식 서버에 올리지 않고 로컬에서 도는 MCP 서버(도구 4개)로 분리했습니다.

트러블슈팅

빈 DB인데 모든 객체가 '이미 있다'고 나온 이유

문제 상황

자연어 명세로 업무 시스템을 만드는 에이전트를 검증하려고 빈 DB와 WAS를 따로 세워 반영 계획을 돌렸더니, 생성되어야 할 20건이 전부 '수정'으로 나왔습니다. 그대로 반영하면 없는 객체를 고치려 하거나, 빌드 중 일부를 조용히 건너뛸 수 있었습니다.

해결 과정

계획 로직보다 응답 처리부터 따라갔습니다. 세션이 없으면 플랫폼의 /api/ 경로는 HTTP 200과 HTML 로그인 화면을 돌려주는데, 파서는 이를 문자열로 넘겼고 존재 확인은 '비어 있지 않으면 있음'으로 판정했습니다. 같은 확인을 반영 엔진과 빌더도 쓰고 있어 존재 확인 함수만 고치면 다른 곳에 같은 구멍이 남았습니다. 그래서 응답 파서에서 /api/ 경로가 로그인 화면을 주면 인증 오류로 터뜨리고, 존재 확인이 인증 오류를 '존재함'으로 읽지 않게 했습니다. 계획만 세우는 모드도 인증을 거치게 했습니다.

결과

다시 돌린 계획은 '생성 20, 수정 0'으로 빈 DB와 일치했고, 인증 확인 테스트 5케이스를 추가했습니다.

'미리보기'가 운영에 적용되지 않게 막기

문제 상황

플랫폼 코어를 바꾸지 않고 미리보기를 제공하려면 격리 인스턴스에 실제로 적용했다가 되돌려야 했습니다. 이 기능이 '미리보기'라는 이름으로 운영 서버에 쓰이는 것이 가장 큰 위험이었습니다.

해결 과정

안전장치를 기능 본체로 다뤘습니다. 허용 대상 목록에 없는 서버면 아무것도 하지 않고 거부하며, 목록의 기본값은 비워 두었습니다. 미리보기 URL은 HMAC 서명과 만료 시간을 갖고, 만료 검사는 서명 검사 뒤에 합니다. 서명이 틀린 토큰의 만료 시각을 믿으면 만료 검사를 우회당하기 때문이며, 이 순서는 테스트로 고정했습니다. 모든 상태 변화는 감사 로그에 남깁니다.

결과

검증 환경에서 미리보기 시작 시 2건이 생성되고 종료 후 0건으로 돌아오는 것을 확인했습니다. 미리보기 테스트 13케이스를 추가했습니다(전체 449개 통과).

한계: 서명 토큰은 게이트웨이의 세션 통제일 뿐 플랫폼 런타임이 검증하지 않아, 런타임 수준의 테넌트 격리는 부분적입니다.

결과와 성과

자연어 한 줄 → 객체 6개 생성 → E2E 시나리오 5/5 통과 (검증 환경)
폼 생성 실패 원인(멀티테넌시 키 전달 방식)을 규명해 검증 환경 폼 생성 22건 전건 성공
보상 롤백 후 검증 환경 잔여물 0건, 미인증 응답 오판 수정 후 빈 DB 계획이 20건 생성으로 정상화
테스트 449개 통과 (미리보기 13케이스, 인증 확인 5케이스 포함)

회고

배운 점: 저장 API가 200을 돌려줘도 조회가 된다는 보장은 없었습니다. 리스트 조회 SQL은 컬럼 하나만 틀려도 0건이 됩니다. '모르겠다'를 '있다'로 처리한 작은 존재 확인 하나가 계획 전체를 뒤집는다는 것도 배웠습니다.
아쉬운 점: 실사용자 없이 검증 환경 빌드로만 확인했고, 구축 시간 단축 효과는 측정하지 못했습니다. 미리보기는 동시 사용을 지원하지 않고, 서명 토큰은 게이트웨이 수준의 통제라 런타임 격리는 부분적입니다.
보완 계획: 실제 업무 시스템 구축에 적용해 구축 시간과 수정 횟수를 비교하고, 플랫폼 코어가 요청 단위 초안을 지원하면 격리 인스턴스 방식을 대체하는 것이 다음 단계입니다.