운영 애플리케이션의 의사결정 설계
운영 애플리케이션(Operational application)은 사용자가 정보를 확인하고 선택지를 비교한 뒤, 결정한 내용을 업무 시스템에 반영하도록 만든 인터페이스입니다. 읽기 전용 대시보드가 제공하는 정보에 시뮬레이션과 실행 기능을 연결합니다.
민감한 데이터를 사용하거나 중요한 결정을 지원한다면 필요한 목적에 맞게 정보 범위를 제한합니다. 자동화와 AI의 제안 중 어떤 내용에 사람이 책임을 지고 검토해야 하는지도 앱을 설계할 때 정합니다.
1. 지원할 결정을 정하기
화면을 만들기 전에 사용자가 내려야 할 결정을 구체적으로 씁니다. 어떤 선택을 해야 하는지, 판단에 필요한 정보가 무엇인지, 선택한 뒤 무엇이 달라져야 하는지를 정하면 앱의 목적과 필요한 기능이 분명해집니다.
예를 들어 납기가 위험한 운송을 보여 주는 차트에 머물지 않고, 대체 운송사를 선택하여 배차를 바꾸는 업무를 지원할 수 있습니다. 이때 성공 기준은 차트를 본 횟수보다 실제 판단과 후속 처리에 맞춥니다.
2. 결정에 필요한 현재 상태 보여 주기
온톨로지에 반영된 현재 상태에서 관련 객체, 링크와 속성을 조회합니다. 원천 시스템의 모든 열을 한 화면에 넣기보다 사용자가 그 결정을 내리는 데 필요한 정보와 실행 문맥을 보여 줍니다.
온톨로지에 아직 반영되지 않은 원천 변경까지 자동으로 보여 주는 것은 아니므로 데이터가 갱신되는 업무 흐름도 함께 고려합니다. 여러 사용자는 각자의 접근 권한 안에서 같은 업무 대상을 다룹니다.
3. 적용 전 결과 비교
온톨로지 시나리오에서 기준 데이터와 분리한 변경을 적용하고 여러 대안을 비교할 수 있습니다. 액션으로 후보 상태를 만들고 모델을 연결하여 비용이나 도착 시각 같은 영향을 예측합니다.
시나리오에서 편집할 수 있는 범위와 운영 데이터에 적용할 권한은 별개입니다. 선택한 결과는 허용된 병합이나 액션을 통해 실제 데이터에 반영합니다. 시나리오는 베타 기능으로 플랫폼 인스턴스에서 사용 가능해야 합니다.
4. 같은 앱에서 결정 적용
액션은 사용자의 결정을 온톨로지 변경으로 반영합니다. 제출 조건에 조직의 업무 규칙과 실행 조건을 구성하여 허용된 변경을 받습니다.
사용자가 분석을 마친 뒤 다른 도구에서 같은 객체를 다시 찾아 입력하게 하기보다, 판단에 사용한 문맥을 유지하면서 실행하도록 연결합니다. 함수 기반 액션은 코드로 계산한 편집을 같은 처리 경로에 넣습니다.
5. 결과 공유와 후속 처리
성공한 액션의 온톨로지 편집은 원자적으로 커밋됩니다. 액션 완료 후 시작한 질의와 액션은 커밋한 편집을 읽을 수 있으며, 해당 객체에 접근할 수 있는 다른 사용자의 업무에도 같은 결정이 반영됩니다.
원자성은 온톨로지 편집 묶음의 보장입니다. 알림 전송, 웹훅과 외부 호출의 성공까지 하나의 트랜잭션으로 보장하지는 않습니다. 화면이 언제 다시 조회하는지와 외부 작업의 실패 처리도 함께 구성합니다.
| 후속 기능 | 업무에 연결하는 방식 |
|---|---|
| 부수 효과 | 앱 알림이나 이메일을 보내고 외부 시스템과 연결합니다. |
| 웹훅 | 외부 API 또는 다른 Foundry API를 호출하여 기준 시스템을 갱신하거나 메시지와 후속 작업을 시작합니다. |
| 함수 기반 액션 | 서버리스 함수나 Compute Module에서 편집 로직을 계산합니다. |
| 스케줄 빌드 시작 | 데이터 통합 파이프라인을 다시 계산하도록 요청합니다. |
| Automate | 조건을 지속적으로 또는 정한 일정에 따라 확인하고 충족 시 효과를 실행합니다. Autopilot에서 여러 자동화의 동작을 살펴보고 문제를 추적합니다. |
| 에이전트 | 허용한 후속 업무를 수행하거나 변경 제안을 사람이 검토하는 흐름에 전달합니다. |
| 액션 로그 | 로그를 구성한 액션의 성공한 제출을 객체로 기록합니다. 입력과 판단 근거를 기록하도록 설정하면 분석과 감사에 활용할 수 있습니다. |
액션 로그를 켜기 전의 제출이나 실패한 제출이 모두 자동 기록되는 것은 아닙니다. 실패와 실행 시간은 액션 지표로 확인하며, 로그에는 보존할 업무 맥락을 구성합니다.
가상 물류 업무 예
자동차 조립 공장에 부품을 납품하는 회사에서 운송사 고장으로 변속기 부품의 도착이 늦어진다고 가정합니다. 납기 지연은 생산 중단과 위약금으로 이어질 수 있습니다.
읽기 전용 화면에서는 담당자가 지연 표시를 확인한 뒤 승인 운송사 표, 운송 가능 여부에 관한 이메일, 고객의 납품 시간과 위약금 조건을 따로 모아야 합니다. 전화로 대체 운송을 결정해도 계획 담당자나 고객에게 변경 내용이 전달되지 않으면 같은 조사를 반복하거나 이전 계획을 그대로 사용할 수 있습니다. 판단 근거가 남지 않으면 다음 사례에도 활용하기 어렵습니다.
운영 앱에서는 다음과 같이 구성합니다.
- 운송 중인 부품, 납품 시간, 위약금, 현재 운송사와 대체 운송사의 가용량, 가격 및 정시 도착 이력을 함께 보여 줍니다.
- 후보 운송사별 시나리오에서 도착 시각, 비용, 정시 도착 확률과 다른 운송에 미칠 영향을 모델로 비교합니다.
- 담당자가 선택한 운송사로 변경하는 액션을 제출합니다. 고객 알림과 계획 파이프라인 갱신은 해당 부수 효과와 빌드 경로로 연결합니다.
- 고객 서비스는 바뀐 예상 도착과 사유를, 재무는 비용과 위약금 영향을, 공장 계획 담당자는 변경된 공급 일정을 확인합니다. 각 화면은 해당 사용자의 권한과 갱신 동작을 따릅니다.
- 선택과 근거를 기록하여 시뮬레이션의 예상 결과와 실제 결과를 비교합니다. 다음 배차 판단에 이 기록을 사용할 수 있습니다.
예측은 후보 비교에 쓰는 모델 결과입니다. 실제 도착이나 외부 알림 성공은 후속 상태로 확인합니다.
에이전트가 수행할 범위와 사람의 검토
AIP Logic, Automate 및 에이전트로 반복 작업을 자동화하더라도 사람이 검토하고 방향을 조정할 화면이 필요합니다. 자동 실행할 액션과 아직 적용하지 않은 제안으로 남길 액션을 구분합니다.
지정된 담당자가 승인해야 하는 지원 변경 요청에는 Approvals를 사용할 수 있습니다. 프로젝트 접근이나 온톨로지 제안처럼 이 기능에 연결된 요청은 필요한 승인을 받은 뒤 적용합니다. Checkpoints는 지원되는 민감한 상호작용에서 목적이나 사유를 받아 이후 검토할 기록을 남깁니다. 에이전트의 업무 제안을 검토하는 앱 흐름과 이러한 권한 승인 및 목적 기록을 맞춥니다.
물류 예에서 사람은 가격, 도착 시각과 정시 확률로 한 후보가 분명히 우세한 저가 운송을 자동 처리하도록 기준을 정할 수 있습니다. 모호하거나 영향이 큰 사례는 사람에게 올립니다. 담당자는 자동 처리 결과와 성능 변화를 감시하여 기준을 조정하고, 복잡한 맥락이 필요한 경로 변경은 직접 판단합니다. 에이전트가 활용할 기록에는 정량 결과뿐 아니라 담당자가 남긴 이유도 포함합니다.
업무 흐름 점검
| 질문 | 설계에서 확인할 내용 |
|---|---|
| 사용자가 내리는 결정을 구체적으로 말할 수 있는가? | 화면의 목적이 단순 정보 조회에 머무는지 확인합니다. |
| 선택과 근거를 다시 기록하는가? | 결정 이후 다른 업무가 사용할 데이터를 남기는지 확인합니다. |
| 실행을 위해 다른 도구로 이동해야 하는가? | 필요한 입력과 액션을 현재 문맥에서 연결할 수 있는지 확인합니다. |
| 대안을 비교할 수 있는가? | 시나리오와 모델로 선택의 영향을 검토할 수 있는지 확인합니다. |
| 다른 담당자의 업무에도 결과가 전달되는가? | 접근 권한, 화면 갱신과 후속 시스템 연결을 확인합니다. |
구현 도구 선택
Workshop은 객체 중심 화면, 레이아웃과 이벤트 및 위젯을 조합하는 기본 경로입니다. OSDK React 앱은 완전히 맞춤화한 인터페이스에 적합하며 Pilot으로 자연어 요구에서 시작할 수 있습니다.
Custom widget은 Workshop에 필요한 React 화면만 추가하거나 한 개의 전체 페이지 위젯으로 사용할 수 있습니다. Pilot으로 위젯을 구성하는 경로도 있습니다. Slate는 HTML과 JavaScript를 포함한 맞춤 화면을 구성합니다.
Code Workspaces는 Streamlit, Dash와 Shiny 앱을 게시하는 경로입니다. REST API로 Foundry 바깥의 앱에서 온톨로지를 조회하고 액션을 적용할 수도 있습니다. 도구별 역할은 유스케이스 개발에서 비교합니다.