답변.

문제의 역사:

최근 몇 년 동안 외부 서비스와 인공지능을 사용할 때 데이터 처리 및 전송 규칙의 투명한 기록이 중요한 통합 솔루션에 대한 수요가 증가했습니다. 비형식적인 데이터와 명확한 비즈니스 규칙의 부재는 오류 및 사건으로 이어집니다.

문제:

AI 및 외부 서비스의 적용은 데이터 작업을 위한 명시적인 규칙을 요구합니다: 무엇을 전송할지, 어떻게 유효성 검사할지, 실패 시 무엇을 할지, 작업을 어떻게 기록할지, 사용자에게 무엇을 반환할지. 이러한 규칙을 형식적으로 설명하지 않으면 기술적 및 비즈니스 위험이 증가합니다.

해결책:

다음 방법론이 사용됩니다:

• UML 활동 다이어그램 및 BPMN을 통한 흐름, 입력 및 출력 데이터 시각화
• 정보 경로 지정을 위한 데이터 흐름 다이어그램 (DFD)
• 조건과 동작을 명확히 정의한 규칙을 위한 표 형식 설명 (decision tables)
• 시스템 및 비즈니스 용어의 단일 사전을 위한 용어집
• 예제에 의한 규격화 — 구체적인 사용자/시스템 시나리오를 통한 형식화

주요 특징:

• 시스템 규칙과 비즈니스 규칙의 명확한 분리
• 데이터 출처에서 소비 장소까지의 추적 지원
• 통합 레지스터에서 형식화와 규칙의 지속적인 업데이트

함정 질문들.

데이터 처리 규칙을 설명하는 데 다이어그램만으로 충분한가요?

아니요, 다이어그램만으로는 부족합니다. 모호성을 최소화하기 위해 텍스트 설명, 조건표, 예제도 필요합니다.

통합 작업 중 부정적인 시나리오(장애, 오류)를 문서화해야 하나요?

네, 반드시 해야 합니다! 이러한 시나리오가 없으면 사전에 오류 처리를 제대로 계획하고 SLA를 보장할 수 없습니다.

데이터 처리 규칙을 형식화할 때 기술 용어만으로 충분한가요?

아니요, 투명성과 올바른 상호작용을 위해서는 용어집을 사용하고 비즈니스 및 기술 용어를 연결해야 합니다.

일반적인 오류 및 안티 패턴

• 부정적이고 한계 사례가 없는 happy path 시나리오만 설명
• 규칙의 불명확한 분해, 접근 제어, 유효성 검사 및 비즈니스 로직의 혼합
• 형식화된 규칙의 단일 저장소 부족

실제 사례

부정적 사례:

문서 인식 클라우드 서비스와의 통합. 시스템 분석가는 기본적인 교환만 설명하고 한계 사례(예: 응답 대기 시간, 비유효 데이터 반환, 형식 유효성 검사 오류)를 생략했습니다.

장점:

• 파일럿 단계에서 빠른 진행

단점:

• 오류 처리 미비로 인한 대규모 사건 발생, 불안정한 작동

긍정적 사례:

분석가는 happy path뿐만 아니라 모든 한계 및 예외 시나리오를 기록하고 규칙 처리를 위한 단일 decision table을 작성했습니다. AI 팀과 기술 지원 간의 용어집을 간소화하기 위한 일련의 워크숍을 진행했습니다.

장점:

• 초기 사건 예방, 높은 수준의 SLA

단점:

• 문서 처리에 좀 더 많은 시간이 소요됨