‘LLM 하나’로 보이던 서비스를 책임 단위로 나눈다
학교 규정 안내 서비스가 틀린 답을 냈을 때 모델만 고치면 될까요? 오래된 규정 문서를 검색했을 수도 있고, 권한 확인이 빠져 교사용 문서를 학생에게 보여 주었을 수도 있으며, 출처 대응 단계가 답변과 다른 문서를 붙였을 수도 있습니다. 시스템 구성도는 사용자 화면, 업무 서비스, 검색 색인, 문서 저장소, 모델 제공 영역과 운영 기록을 분리합니다. 이때 상자 수를 늘리는 일이 목적은 아닙니다. 각 상자가 책임과 변경 이유를 하나 이상 분명히 가지도록 나누는 것이 핵심입니다.
사람과 외부 시스템에서 시작해 필요한 만큼만 들어간다
C4 모델은 소프트웨어 구조를 문맥, 컨테이너, 컴포넌트, 코드의 네 수준으로 확대합니다. 시스템 문맥도는 사용자와 외부 시스템 사이에서 우리 서비스가 맡는 역할을 보여 줍니다. 컨테이너도는 서비스 안의 웹 애플리케이션, 서버 애플리케이션, 데이터 저장소처럼 각각 실행되거나 배포되는 큰 단위를 보여 줍니다. 여기서 컨테이너는 반드시 도커 컨테이너를 뜻하지 않습니다. 컴포넌트도는 한 컨테이너 안에서 권한 확인, 검색 조정, 문맥 구성처럼 관련 기능을 묶은 책임 단위를 보여 줍니다. 모든 수준을 한 장에 섞기보다 독자의 질문에 맞춰 한 장씩 확대합니다.[1]
코드 수준은 구현을 확인할 때만 추가합니다. 대부분의 설명에서는 문맥도와 컨테이너도만으로도 충분합니다.
상자 안에 이름·종류·책임을 함께 적는다
좋은 구성도 상자는 “검색 서비스”라는 이름만 쓰지 않습니다. ‘서버 애플리케이션’ 같은 종류와 ‘권한이 허용한 문서에서 관련 구간을 찾음’이라는 책임을 함께 적습니다. 연결선에는 HTTPS, 내부 함수 호출, 비동기 작업 큐처럼 통신 방법과 ‘질문·문서 구간·답변’ 같은 핵심 데이터를 적습니다. 화살표 방향은 누가 연결을 시작하는지 또는 정보가 어느 쪽으로 가는지를 범례에서 정합니다. 시스템 경계는 조직이 책임지는 범위를 표시하고, 외부 모델 API나 외부 검색 서비스는 경계 밖에 둡니다.
[서버 애플리케이션]
권한 확인·검색 호출·모델 문맥 구성
관련 문단·문서 ID 반환
문맥을 받아 답변 초안 반환
학교 규정 안내 서비스는 권한과 출처를 서비스 안에서 책임진다
학생은 웹 화면에서 질문합니다. 화면은 인증 서비스에서 사용자의 학년과 역할을 확인한 뒤 답변 조정 서비스로 질문을 보냅니다. 답변 조정 서비스는 문서 검색에 권한 범위를 함께 전달하고, 검색 결과의 문서 ID와 문단을 모델 입력으로 묶습니다. 모델 제공자는 초안을 돌려주지만 최종 출처 대응과 금지 표현 검사는 답변 조정 서비스가 수행합니다. 이렇게 그리면 모델 API가 문서 접근 권한을 직접 판단하거나 출처를 보증한다고 오해하지 않게 됩니다.
작성 도구·번역 서비스·상담 보조는 경계가 서로 다르다
사내 문서 작성 도구는 회사 계정, 문서 저장소와 승인 워크플로를 조직 경계 안에 두고 외부 모델에는 필요한 구간만 보낼 수 있습니다. 실시간 번역 서비스는 음성 인식, 번역, 음성 합성을 각각 독립 부품으로 두며 지연 시간을 줄이는 연결이 중요합니다. 상담 보조 서비스는 상담원 화면과 고객 기록 저장소 사이에 개인정보 가림과 접근 감사 부품을 둡니다. 세 사례 모두 LLM을 사용하지만 책임 경계를 복사해서는 안 됩니다. 누가 데이터를 보유하고 어떤 부품을 독립적으로 교체해야 하는지가 구성도를 결정합니다.
| 서비스 | 중심 부품 | 중요한 경계 |
|---|---|---|
| 사내 문서 작성 | 권한·문서 검색·승인 | 회사 문서와 외부 모델 사이 |
| 실시간 번역 | 음성 인식·번역·합성 | 지연 시간과 스트림 연결 |
| 상담 보조 | 개인정보 가림·감사 기록 | 고객 기록 접근 |
독자와 확대 수준을 먼저 지정한다
“아키텍처를 그려 줘”라는 요청만으로는 코드 함수와 외부 서비스가 한 장에 뒤섞일 수 있습니다. 대상 독자가 운영 책임자인지 개발자인지, 문맥도와 컨테이너도 가운데 어느 수준이 필요한지, 시스템 경계와 외부 시스템이 무엇인지 알려 줍니다. 부품마다 이름·종류·한 문장 책임을 쓰고, 연결선에는 통신 방식과 주요 데이터를 적게 합니다. 원문에 없는 제품명과 배포 기술은 추정하지 않고 ‘결정 필요’ 목록으로 보내도록 요구합니다.
다음 학교 규정 안내 LLM 서비스의 시스템 구성도 초안을 작성해 주세요. 독자: 서비스 책임자와 개발자가 함께 본다. 수준: 먼저 시스템 문맥도, 다음에 컨테이너도. 코드·함수 수준은 제외한다. 시스템 경계 안: 웹 화면, 답변 조정 서비스, 문서 검색, 규정 저장소, 운영 기록. 경계 밖: 학생·교사, 학교 인증 서비스, 외부 모델 제공자. 규칙: 각 상자에 이름 / 종류 / 한 문장 책임을 쓴다. 연결선에 통신 방식과 주요 데이터를 쓴다. 확인할 책임: 권한 확인, 검색 범위, 문맥 구성, 출처 대응, 오류 기록. 금지: 원문에 없는 제품명·배포 방식·자동 승인·암호화 방식을 확정하지 않는다. 출력: ① 문맥도 ② 컨테이너도 ③ 경계별 책임표 ④ 미결정 질문.
서로 다른 확대 수준과 데이터 흐름을 한 장에 섞지 않는다
잘못된 구성도는 ‘사용자’ 옆에 함수 이름, 데이터베이스 테이블, 외부 모델과 버튼을 같은 크기로 놓습니다. 상자 사이 화살표에는 ‘호출’만 적혀 무엇이 오가는지 알 수 없습니다. 수정할 때는 먼저 전체 문맥도에서 사람·우리 시스템·외부 시스템만 남깁니다. 다음 장의 컨테이너도에서 화면·서비스·저장소를 펼치고, 특정 서버의 내부 책임이 필요할 때만 컴포넌트도를 만듭니다. 실행 순서와 조건은 시퀀스·활동도로 분리하고, 데이터의 상세 이동은 9회의 데이터 흐름도로 보완합니다.
상자의 수준과 책임이 서로 다릅니다.
2장: 화면–서버–검색–저장소–모델
각 장의 추상화 수준을 고정합니다.
연결선마다 실패·재시도·관찰 책임을 붙인다
구성도가 완성되면 각 연결선에 세 질문을 던집니다. 연결 대상이 응답하지 않으면 어느 부품이 시간 제한과 재시도를 담당하는가, 개인정보나 비밀값이 넘어가는가, 오류를 어느 기록에서 확인할 수 있는가입니다. 외부 모델 호출이 실패했을 때 웹 화면이 직접 재시도하면 중복 요청을 만들 수 있습니다. 답변 조정 서비스가 요청 식별자를 유지하고 재시도 횟수를 제한하는 편이 책임을 모으기 쉽습니다. 구성도는 고정된 배치 그림이 아니라 운영 중 문제를 찾을 수 있는 책임 지도여야 합니다.
| 연결 | 실패 책임 | 민감 데이터 | 관찰 위치 |
|---|---|---|---|
| 화면 → 답변 조정 | 화면 시간 제한·중복 방지 | 사용자 질문 | 요청 ID |
| 답변 조정 → 검색 | 검색 재시도·대체 안내 | 정제 검색어 | 검색 지연 |
| 답변 조정 → 모델 | 호출 제한·오류 처리 | 모델 문맥 | 모델 호출 기록 |
독자에 맞는 확대 수준을 골라 보자
교장에게 서비스 도입 범위를 설명하는 자리에서는 외부 사용자와 학교 시스템, 모델 제공자까지 보이는 문맥도가 적절합니다. 개발자가 검색 오류를 고치려면 답변 조정 서비스 안의 검색 질의 생성·권한 필터·결과 정렬 컴포넌트가 필요합니다. 개인정보 담당자가 검토할 때는 컨테이너 경계와 외부 전송 데이터가 중요합니다. 아래에서 독자를 고르면 필요한 요소와 제외할 세부가 표시됩니다.