AI 앱 설계란 「도메인 지식을 나리지(Knowledge)에 둘 것인가 로직(Logic)에 둘 것인가」의 배분이다 🧩

변호사·세무사 오타가키(@yoshiki_otagaki)입니다.

전문직 현장에서 실제로 움직이고 있는 AI 활용·업무 자동화에 대해 발신하고 있습니다.

Next.js + Supabase + Anthropic API + 독자적인 MCP 서버로 법률 사무소용 SaaS 「LegalFlow」를 혼자서 개발·운영 중입니다.

지난 기사 「MCP 네이티브 SaaS의 데이터 모델 설계」에서는 「AI가 조작한다는 전제로 리소스를 설계한다」는 이야기를 썼습니다. 이번에는 그 한 단계 앞선, **「애초에 AI를 사용한 소프트웨어란, 구성 요소 중 어디에 AI를 사용하고 있는가」**라는 조금 더 추상적인 설계론을 쓰고자 합니다.

제가 법률 SaaS를 혼자 만들며 도달한, AI 앱 설계의 머릿속 정리입니다. 이론에 가깝지만, 구체적인 예시는 법률 도메인에서 가져옵니다.

SaaS는 궁극적으로 4가지 요소로 이루어져 있다

Salesforce든 무엇이든, 업무용 SaaS를 분해하면 결국 이 4가지로 귀결된다고 생각합니다.

데이터베이스 (Database) — 무엇을 저장하고 있는가 -
프론트엔드 UI (Frontend UI) — 인간이 어떻게 조작하는가 -
나리지 (Knowledge) — 프로그램이 참조하는 지식·정보 -
로직 (Logic) — 프로그램이 어떻게 처리·판단하는가

①과 ②는 이해하기 쉽습니다. 논의가 흥미로워지는 것은 ③나리지 (Knowledge)와 ④로직 (Logic)입니다. 보통 이 둘은 「백엔드 (Backend)」라고 한데 묶어 부르지만, AI 시대의 설계를 논한다면 이곳을 나누어야 한다는 것이 본 기사의 출발점입니다.

정의를 명확히 해두겠습니다.

나리지 (Knowledge, WHAT) = 프로그램이 참조하는 정보 그 자체. 외부에서 주어지며, 필요할 때 가져오는 재료 -
로직 (Logic, HOW) = 프로그램의 행위를 규정하는 구조. 처리나 판단의 「형식」

변호사의 업무에 비유하면 이해하기 쉽습니다. 나리지는 「찾아보는 자료」 (조문집, 양식, 과거 사례). 로직은 「머리에 배어 있는 절차의 형식」 (민사 소송이 어떻게 진행되는지, 당사자가 어떻게 구조화되는지). 전자는 사건마다 가져오지만, 후자는 체화되어 있어 일일이 참조하지 않습니다.

「AI를 사용한 소프트웨어」란 무엇을 하고 있는 것인가

여기서 본론입니다. 「AI를 사용한 소프트웨어」란 구성 요소 중 어디에 AI가 들어가 있는가.

저의 정리는 이렇습니다.

AI를 사용한다는 것은, ③나리지 (Knowledge)에 「AI 모델이 가진 범용 지식」을 사용하고, ④로직 (Logic)에 「AI 모델의 추론 (Inference)」을 사용하는 것

즉, 기존에는 인간 개발자가 전부 작성했던 「나리지 (Knowledge)」와 「로직 (Logic)」을 AI 모델이 대신하게 하는 것. 이것이 본질입니다.

이를 바탕으로 하면, 세상에 있는 「AI 앱」은 3개 층으로 나눌 수 있습니다.

(1) 기존형 SaaS

나리지 (Knowledge) = 개발자가 전부 DB에 작성
로직 (Logic) = 개발자가 전부 코드로 작성
→ AI를 사용하지 않음. 견고하지만, 만드는 것도 유지보수하는 것도 무거움

(2) 순수 AI 래퍼 (AI Wrapper)

나리지 (Knowledge) = AI 모델의 범용 지식에 통째로 맡김
로직 (Logic) = AI 모델의 범용 추론에 통째로 맡김
→ 무엇이든 할 수 있지만, 범용적이라 실무에서는 디테일이 부족함. 「그럴듯하지만 현장에서는 쓸 수 없다」가 되기 쉬움

(3) 도메인 특화 AI 앱 (LegalFlow가 지향하는 것)

나리지 (Knowledge) = AI의 범용 지식 ＋ 도메인 고유의 나리지를 부가
로직 (Logic) = AI의 범용 추론 ＋ 도메인 고유의 제약을 구조로 부가
→ AI가 이미 가지고 있는 부분은 맡기고, AI가 모르거나 틀리는 고유한 부분만을 인간이 채움

(3)의 발상을 한마디로 말하면, **「AI의 범용성과 도메인의 고유성 사이의 "차이(Difference)"만을 인간(해당 분야의 전문가)이 주입한다」**는 것입니다. AI가 9할을 할 수 있다면, 남은 1할의 고유성을 어떻게 채우느냐가 설계의 승부처가 됩니다.

핵심: 그 고유성을 「나리지 (Knowledge)」에 둘 것인가 「로직 (Logic)」에 둘 것인가

여기서부터가 이 기사에서 가장 하고 싶은 말입니다.

도메인 고유성을 AI 앱에 주입할 때, 나리지 (Knowledge)로서 주입할 것인가, 로직 (Logic)으로서 주입할 것인가라는 설계 판단이 발생합니다. 같은 「도메인 지식」이라도 놓이는 장소가 두 군데가 있습니다.

나리지 (Knowledge)로서 주입하는 예

AI에게 「참조시킬 재료」로 제공하는 패턴.

공개된 서식·템플릿을 포함하여 참조하게 함: 예를 들어, 공공기관이 배포하는 정형 문서 템플릿을 소프트웨어에 갖추고, 문서 작성 시 AI가 이를 참조하게 함
Web 검색으로 나리지 (Knowledge)를 동적으로 확장: 최신 정보나 그 자리에서 필요해진 지식을 검색을 통해 가져옴
축적된 정보를 필요할 때 끌어옴 (RAG적인 사용법): 유사한 케이스나 과거의 정리 내용을 답변 생성 시의 참고 자료로 전달 (※후술하겠지만, 이 부분은 다루는 정보의 성질에 주의가 필요함)

공통점은, AI의 추론 프로세스(Inference Process)의 "외부"에 있으며, 필요할 때 가져온다는 것입니다. AI의 두뇌는 그대로 두고, 참조할 자료를 더해주는 이미지입니다.

로직 (Logic)로서 주입하는 예

AI의 "행동을 구조로 제약하는" 패턴입니다.

당사자의 구조를 데이터베이스 (DB) 스키마에 새김: 예를 들어 법적 분쟁에는 「신청인／피신청인」과 같은 역할 구조가 있습니다. 이를 DB 설계 자체에 반영해 두면, AI는 그 구조에서 벗어난 데이터를 만들 수 없습니다.
취할 수 있는 선택지를 마스터화하여 입력을 제약: 예를 들어 절차상의 고비(기일)의 종류는 유한하므로, 이를 고정 리스트로 만들어 두고 AI가 그중에서만 선택할 수 있도록 합니다.

공통점은, 설계 시에 정적으로 "타입 (Type)"을 심어두어, AI가 틀릴 수 없는 상태로 만드는 것입니다. 프롬프트(Prompt)로 "이렇게 행동해줘"라고 부탁하는 것이 아니라, 구조로 "그렇게밖에 행동할 수 없게" 만드는 것입니다.

흥미로운 점은, 「당사자의 역할」이나 「기일의 종류」는 **이름만 보면 나리지 (Knowledge, 지식)**인데,

DB의 구조로서 새기는 순간 로직 (Logic, 행동의 규정)이 된다는 것입니다. 지식을 구조화하여 심으면, 그것은 참조되는 재료가 아니라 시스템의 행동 그 자체가 됩니다.

어떻게 배분할 것인가: 판단 기준

그렇다면 어떤 도메인 지식을 나리지에 둘 것인가, 로직에 둘 것인가. 저의 판단 기준은 다음과 같습니다.

나리지 (Knowledge)에 둘 것	로직 (Logic)에 둘 것
적합한 지식	다양·무한한 변형·타입에 떨어지기 어려움
...

거칠게 말하자면,

"실수가 허용되지 않음·유한함·명확한 타입이 있음" $\rightarrow$ 로직으로 (구조로 제약)
"다양함·참조하면 충분함·타입에 떨어지지 않음" $\rightarrow$ 나리지로 (재료로서 전달)

예를 들어, 절차상의 고비 종류를 AI의 추론에 맡겼다가 틀린다면 실무에서는 사고가 됩니다. 그러므로 구조로 제약합니다 (로직). 반면, 문서의 말투나 참고가 될 만한 전례는 무한한 변형이 있어 구조화하기 어렵고, 그럴 필요도 없습니다. 그러므로 참조 재료로서 전달합니다 (나리지).

이 배분의 판단이야말로 그 도메인을 깊이 아는 인간만이 할 수 있는 일입니다. AI는 "어디에 두어야 할지"를 판단할 수 없습니다. 왜냐하면 그것은 "이 분야에서 무엇을 절대로 틀려서는 안 되는가"라는, 현장의 책임 의식에 뿌리를 둔 판단이기 때문입니다.

왜 "구조 (Logic)"에 치중하면 강한가

마지막으로 설계 지침으로서 한 가지 말씀드립니다.

도메인 특이성(Domain Specificity)은 가능한 한 프롬프트 (휘발적)가 아니라, 데이터 모델 (Data Model)이나 리소스 구조 (영속적)로서 주입해야 한다고 생각합니다.

이유는 AI 모델이 진화하며 교체되기 때문입니다. 오늘날의 모델을 위해 작성한 프롬프트는 차세대 모델에서는 최적이 아닐 수도 있습니다. 프롬프트에 써넣은 지식은 모델 의존적이라 취약합니다.

반면, 구조에 새긴 제약은 모델이 바뀌어도 살아남습니다. "당사자는 이렇게 구조화된다", "이 항목은 필수다"와 같은 타입은, 뒷단의 AI가 Opus이든 다음 세대 모델이든 상관없이 계속 작동합니다.

이는 지난 글에서 썼던 "멱등성(Idempotency)이나 표기 불일치 대책은 프롬프트가 아니라 데이터 모델로 지켜야 한다"는 이야기와 같은 사상입니다. 그리고 더 나아가 말하자면——

AI 모델은 진화하며 교체됩니다. 하지만 도메인의 구조는 진부해지지 않습니다.

그렇기에 도메인 특이성을 구조로서 갖춘 앱은 AI의 세대교체를 넘어 가치를 지속합니다. 이것이 범용 AI 시대에 「도메인 특화된 구조를 가진 앱」이 살아남는 이유라고 저는 생각합니다.

요약

SaaS는 ①DB ②UI ③나리지 (Knowledge) ④로직 (Logic)의 4요소로 분해할 수 있다
「AI를 사용한다」는 것은, ③나리지에 AI의 범용 지식을, ④로직에 AI의 추론을 사용하는 것이다
단순한 AI 래퍼 (Wrapper)는 「너무 범용적이라 마무리가 부족하다」.
AI의 범용성과 도메인 고유성의 "차이"를 인간이 메우는 것이 도메인 특화 앱 - 그 고유성을
나리지 (참조 재료)에 둘 것인가, 로직 (구조적 제약)에 둘 것인가의 배분이 설계의 핵심 - 「실수가 허용되지 않음·유한함·형태가 있음」은 로직으로, 「다양함·참조만으로 충분함」은 나리지로
고유성은
프롬프트 (Prompt)보다 구조 (Structure)에 가깝게 가져간다. AI 모델은 교체되지만, 도메인 구조는 진부해지지 않기 때문

AI 앱 설계를 「프롬프트를 어떻게 작성할 것인가」가 아니라 「도메인 지식을 나리지와 로직에 어떻게 배분할 것인가」로 파악하면, 설계 판단이 단번에 명확해집니다. 앞으로 AI를 도입한 업무용 앱을 만드실 분들의 생각을 정리하는 데 도움이 되기를 바랍니다.

실무에서의 사용법이나 SaaS로서의 사고방식은 note에 적어두었습니다:

🛠 LegalFlow → https://flow.legal-consulting.jp

오타가키 요시키 (Yoshiki Otagaki)

변호사 (도쿄 변호사회·등록 번호 51084) / 세무사 / 소프트웨어 개발자.

Next.js + Supabase + Anthropic API + 독자적인 MCP 서버로 법률 SaaS 「LegalFlow」를 개발 및 운영 중.

note: https://note.com/yoshiki_otagaki ｜ X: https://twitter.com/yoshiki_otagaki