자료 흐름도 작성: 출처·저장소·신뢰 경계 추적

자료 흐름도 작성은 외부 출처, 데이터를 변환하는 프로세스, 데이터를 보관하는 저장소, 그 사이에서 전달되는 데이터의 이름을 식별하는 데서 시작합니다. 먼저 시스템 경계를 정하고, 들어오거나 나가는 데이터를 바꾸지 않으면서 내부 이동을 상세히 표현합니다. 허용 필드와 신뢰 경계에 관한 주석을 추가하면 검토자가 의도치 않은 정보 노출을 발견할 수 있습니다.

작성: Ai Flowi · 게시일 2026-10-11

의사결정 순서보다 데이터 이동을 표현하기

자료 흐름도는 “이 정보는 어디에서 와서, 어디에서 바뀌고, 어디로 가는가?”에 답합니다. 승인 실행 순서를 나타내지는 않습니다. 프로세스 이름에는 동사를, 저장소 이름에는 보관하는 데이터를, 화살표 이름에는 실제 전달 내용을 사용합니다. 저장소는 요청을 승인할 수 없습니다. 프로세스가 저장소에서 읽은 데이터에 작업을 수행합니다.

이 예시는 승인된 문의 데이터를 발신자에게 돌려주는 상황을 다룹니다. 발신자가 제출한 텍스트는 신뢰할 수 있는 서비스 경계 밖에서 시작합니다. 권한 있는 검토 프로세스가 결정 기록을 별도로 제공합니다. 이 도식은 호출자가 제공한 불리언 값으로 승인을 추론하지 않으며, 워크플로우 빌더가 사람의 검토용 수신함을 제공한다고 주장하지도 않습니다.

먼저 컨텍스트 뷰 그리기

여기서 “레벨 0”은 서비스를 하나의 프로세스로 표현한 컨텍스트 뷰를, “레벨 1”은 그 프로세스를 상세히 펼친 뷰를 뜻합니다. 팀마다 번호 부여 방식이 다르므로 사용하는 방식을 기록합니다. 이 Mermaid 소스는 둥근 프로세스 도형, 직사각형 외부 개체, 상세 뷰의 저장소 도형을 사용합니다. 신뢰 경계로 묶는 것은 실행 규칙이 아니라 추가 주석입니다.

flowchart LR
    S[External sender] -- Enquiry fields --> P(Approved enquiry service)
    R[Authorized review process] -- Decision record --> P
    P -- Public enquiry receipt --> S

컨텍스트 뷰에는 의도적으로 입력 데이터 계약 2개와 출력 계약 1개만 드러냅니다. 모든 문의가 승인된다는 뜻은 아닙니다. 접수 확인 응답은 서비스에서 합의한 계약에 따라 상태가 확정된 경우에만 대기, 수락 또는 거절 상태를 나타낼 수 있습니다. 뷰를 상세히 펼칠 때도 원래의 업무 의미를 유지합니다.

변환과 검토 저장소 상세히 표현하기

서비스 경계를 점선으로 표시한 상세 데이터 이동도입니다. 화살표 이름은 실행 순서가 아니라 필드 계약을 나타냅니다.

flowchart LR
    S[External sender]
    R[Authorized review process]
    subgraph T[Service trust boundary]
        P1(1.1 Normalize permitted enquiry fields)
        P2(1.2 Associate reviewed version)
        D[(Review store)]
        P3(1.3 Project public receipt)
        P1 -- Normalized enquiry --> P2
        P2 -- Reviewed enquiry record --> D
        D -- Approved receipt fields --> P3
    end
    S -- Enquiry fields --> P1
    R -- Decision record --> P2
    P3 -- Public enquiry receipt --> S

내부 상자의 개수보다 경계를 통과하는 화살표를 비교하여 두 뷰의 균형을 확인합니다. 문의 필드와 결정 기록은 여전히 들어오고, 공개 접수 확인 응답은 여전히 나갑니다. 레벨 1에서 다른 제공업체로 보내는 메시지가 갑자기 추가되면 컨텍스트 뷰가 불완전한 것입니다. 검토 저장소가 제출 계약에 없는 개인정보를 받으면 상세 뷰에 설명되지 않은 출처가 생긴 것입니다.

내부 저장소에 쓰는 작업은 개념적인 프로세스 요구사항입니다. 아래에서 설명하는 Read Range 컴포넌트는 저장소 쓰기를 구현하지 않습니다. 특히 출력에 “승인됨”이라는 이름을 붙일 때는 의도한 아키텍처와 제한된 컴포넌트 실습을 구분합니다.

데이터 사전 첨부하기

이 사전은 제안된 설계 산출물이며 운영 환경의 보관 정책은 아닙니다. 출시 전에 담당 역할이 필드의 목적과 보관 방침을 승인해야 합니다. “결정 필요”는 아직 끝나지 않은 작업을 뜻하며, 기록을 무기한 보관해도 된다는 허가로 해석해서는 안 됩니다.

가상 문의 서비스의 허용 데이터 계약
데이터 계약	허용 필드	담당 역할	보관과 경계
문의 필드	enquiry_ref, version, message	접수 팀	발신자 → 서비스; 원본 제출 내용의 보관이 필요한지 결정
결정 기록	enquiry_ref, reviewed_version, disposition, review_ref	검토 팀	권한 있는 검토 프로세스 → 서비스; 결정 이력의 보관 방침 합의
검토된 문의 기록	enquiry_ref, version, message, disposition, review_ref	서비스 운영 담당	내부 저장소; 삭제와 접근 관리 책임 문서화
공개 접수 확인 응답	enquiry_ref, disposition	API 유지보수 팀	서비스 → 발신자; message, review_ref 및 연결 메타데이터 제외

신뢰 경계는 데이터를 통제하거나 읽을 수 있는 주체가 바뀌는 지점을 표시합니다. 인증이 되었다고 해서 모든 필드를 반환해도 되는 것은 아닙니다. 서비스에서 발신자로 향하는 화살표는 권한 있는 검토 입력과 별도로 검토합니다. 발신자는 내부 검토 참조값을 보지 않고도 처리 결과를 받을 수 있습니다.

데이터 흐름도에서 비공개 필드의 전파와 출처가 불분명한 저장소를 어떻게 찾나요?

가상 초안에서 개발자가 검토된 전체 기록을 공개 접수 확인 응답에 직접 연결합니다. 이 기록에는 review_ref가 포함되지만, 사전이 해당 경계를 통과하도록 허용하는 필드는 enquiry_ref와 disposition 뿐입니다. “전체 기록” 대신 이름이 있는 필드 투영을 사용하고, 정확한 필드 구성을 공개 계약과 비교합니다.

다른 초안에서는 나가는 화살표만 있고 들어오는 데이터는 없는 “보관소”라는 저장소를 추가합니다. 검토자는 누가 데이터를 넣었는지, 어떤 필드가 있는지, 기록이 승인된 버전에 속하는지 알 수 없습니다. 설명되지 않은 저장소를 제거하거나 실제 생성 주체, 입력 계약, 보관 책임을 추가합니다. 도식을 대칭으로 만들려고 보관소 입력을 지어내지 않습니다.

수정된 예시를 따라가 봅니다. 발신자는 문의 참조값 “enquiry-demo”, 버전 “v2”, 가상 메시지를 제공합니다. 검토 기록은 동일한 참조값과 버전을 식별해야 합니다. 저장된 연결 관계에는 내부 검토 참조값이 포함될 수 있지만, 공개 접수 확인 응답에는 문의 참조값과 확정된 처리 결과만 들어갑니다. 이는 설계된 필드 구성이지 기록된 서비스 응답이 아닙니다.

범위를 제한한 AI Flowi 읽기와 필드 투영 살펴보기

상태: 문서화됨. Read Range와 여기서 제안하는 JSON Operations 필드 투영은 카탈로그에 문서화되어 있습니다. Ai Flowi가 두 설정을 조합하여 운영 환경에서 테스트한 구성은 아닙니다.

설정 예시이며, 기록된 테스트는 아닙니다

이 제한된 실습에 사용하는 읽기·변환 인터페이스는 Google Sheets 참조 문서와 JSON Operations 참조 문서에 설명되어 있습니다.

AI Flowi Workflow 계정과 비공개 가상 시트를 준비하고, 본인의 Google 계정은 Google 연결 설정을 통해 연결합니다. 제공업체 사용료는 별도로 청구됩니다.
Read Range에서 google_account와 spreadsheet_id를 테스트 대상으로 설정하고, range_name은 ReviewDemo!A:B로 설정합니다. 이 범위에는 문의 참조값과 처리 결과만 포함합니다.
매핑을 제안하기 전에 반환된 행을 확인합니다. JSON Operations에서는 확인한 결과를 data에 제공하고, JQ Expression에서 operations을 선택한 다음, query를 작성하여 확인된 래퍼 구조와 2열 계약을 반영합니다.
필드 투영으로 만든 접수 확인 응답 목록을 나가는 화살표와 대조합니다. 읽기와 이 필드 투영 모두 도식의 개념적인 저장소 쓰기를 구현하지 않습니다.

버전 불일치 사례 살펴보기

정규화된 문의에 참조값 enquiry-demo, 버전 v2 , 수정된 가상 메시지가 들어 있다고 가정합니다. 별도의 결정 기록에는 동일한 참조값이 있지만 reviewed_version=v1로 되어 있습니다. 참조값만으로 조인하면 새로운 내용에 이전 처리 결과가 붙습니다. 연결 프로세스는 이 불일치를 미해결 상태로 유지해야 하며, 확정된 승인 처리 결과가 접수 확인 응답의 필드 투영으로 넘어가서는 안 됩니다.

사전에 연결 규칙을 추가합니다. 검토된 기록은 문의 참조값과 검토된 버전이 모두 일치해야 합니다. 서로 다른 두 결정이 동일한 쌍을 가리킬 때 마지막 행을 조용히 선택하지 않습니다. 결정 출처의 충돌 규칙을 확인하거나 연결을 미해결로 남깁니다. 이는 제안된 데이터 계약 규칙이지 읽기 컴포넌트가 이를 강제한다는 주장은 아닙니다. 별도의 권한 통제에는 승인 워크플로우 요구사항을 참고합니다.

이제 제안된 기록 3개를 사전에 따라 추적합니다. v2에 v1 결정이 연결되면 미해결로 남습니다. v2에 확정된 v2 결정 하나가 연결되면 그 처리 결과를 제공할 수 있습니다. v2에 충돌하는 v2 결정들이 연결되면 대조와 조정이 필요합니다. 모든 경우에 외부로 나가는 필드는 enquiry_ref와 disposition로 유지됩니다. 내부 충돌이 있다고 해서 공개 응답에 결정 이력, 메시지 내용, 검토 참조값을 추가할 수는 없습니다.

누락된 셀은 누락된 정보로 검토합니다. 빈 처리 결과는 거절이 아니며, 문의 참조값이 없으면 연결할 수 없습니다. 헤더 행은 문의가 아닙니다. 좁은 읽기 범위는 원본 시트에서 해당 계약을 해결한 뒤에만 유용합니다. 데이터의 출처를 입증하거나 과도한 공유 권한을 수정하지는 못합니다. 대체 상태를 지어내지 말고 미해결 연결을 설계에 드러냅니다.

기존 레시피를 근거로 활용하기: 아키텍처 입증은 별개

상태: 테스트됨. 리드 데이터 정제 에는 해당 정규화·추가 레시피에 대해 32개 사례 중 32개 통과 라는 결과가 기록되어 있습니다. 상태: 테스트됨. 시트를 JSON API로 사용하기 에는 26개 사례 중 25개 통과라는 결과가 기록되어 있으며, 실패한 정보 노출 검사는 외부로 나가는 경계에서도 여전히 중요합니다.

정확한 매핑과 실행 근거는 해당 페이지에 있습니다. 이 도식은 계보와 필드 권한을 추가합니다. 해당 구축 지침을 재현하거나 그 결과를 문의 아키텍처에 그대로 적용하지는 않습니다. 인터페이스 정의에는 API 용어집을, 의사결정과 책임 경로에는 프로세스 맵 템플릿을 사용합니다.

경계 검토로 마무리하기

모든 출력 화살표에서 수신자를 식별하고 필드를 승인된 계약과 비교합니다. 모든 저장소에서 생성 주체, 사용 주체, 보관 결정을 확인합니다. 모든 변환에서 무엇을 제거하거나 도출하는지 설명합니다. 답을 모르면 설계를 미해결로 표시합니다. 자료 흐름도는 검토를 돕지만, 접근 통제, 삭제 강제 적용, 안전한 실행 동작을 입증하지는 않습니다.