01
프로세스에는 눈에 보이는 정의가 있습니다
프로세스가 특정 개인의 작업 습관 속에만 존재하면 검토할 수도, 인계할 수도 없습니다. 프로세스에는 팀 모두가 열어 볼 수 있는 정의가 필요합니다.
Braidrun의 방식
각 워크플로우는 하나의 YAML 정의이며, 캔버스와 코드가 양방향으로 동기화됩니다. 8가지 단계 유형이 단일 Agent, 코드, 분류기, 다중 Agent 토론, 상태 머신, 서브 워크플로우를 아우릅니다.
개념 가이드
AI Native란 무엇인가요?
'AI Native'는 지금 유행하는 용어이지만, 그 의미는 저마다 제각각으로 쓰이곤 합니다. 이 페이지에서는 실행 가능한 정의 하나, 판단 방법 하나, 그리고 다섯 가지 질문으로 된 자가 점검 목록을 제시합니다.
정의
세 가지 행동으로 AI Native를 정의합니다
AI Native는 업무 프로세스가 어떻게 돌아가는지를 설명하는 개념이며, 팀이 AI 도구를 얼마나 많이 구매했는지와는 직접적인 관계가 없습니다. 어떤 팀이 AI Native인지 판단하려면 아래 세 가지 행동을 확인하십시오.
RUN
프로세스를 AI가 실행합니다
업무 프로세스는 예약 또는 이벤트 트리거로 자동 실행됩니다. 사람은 더 이상 단계마다 조작하지 않고, 핵심 작업의 승인과 예외 처리만 담당합니다.
LOG
실행마다 기록이 남습니다
각 단계에서 무엇을 했는지, 입출력은 무엇인지, 비용은 얼마나 들었는지를 사후에 하나씩 확인할 수 있으며, 문제가 생기면 특정 단계까지 짚어낼 수 있습니다.
TEAM
프로세스는 팀의 것입니다
프로세스는 공유된 정의로 작성되어 새 동료도 이해하고 넘겨받아 수정할 수 있으며, 특정 개인의 채팅 기록에 갇혀 있지 않습니다.
판단 방법
사고 실험 하나: 계정을 회수할 것인가, 플랫폼을 끌 것인가
두 가지 가상의 일을 각각 해 보고, 어느 쪽이 업무에 더 큰 영향을 미치는지 비교합니다.
A
ChatGPT 계정 하나를 회수하기
팀에서 AI를 가장 잘 쓰는 동료의 채팅 계정을 회수한다고 가정해 봅시다. 흔한 결과는 이 동료의 효율은 떨어지지만 업무 자체는 평소대로 돌아가는 것입니다.
B
자동화 플랫폼을 하루 끄기
팀이 사용하는 워크플로우 플랫폼을 하루 멈춘다고 가정해 봅시다. 아침 리포트를 아무도 보내지 못하고, 승인 대기 중인 변경이 쌓이고, 예약 작업이 모두 멈춘다면, 업무 프로세스가 이미 AI 위에서 돌아가고 있다는 뜻입니다.
두 실험의 차이가 바로 'AI 활용'과 AI Native의 차이입니다. 채팅 계정은 개인 도구여서 회수해도 한 사람의 효율에만 영향을 미치지만, 워크플로우 플랫폼은 업무 프로세스를 담고 있어 중단하면 팀 전체의 산출에 영향을 미칩니다.
자가 점검
다섯 가지 질문으로 우리 팀을 점검합니다
'예'라는 답이 많을수록 AI Native에 가깝습니다. 대부분 '아니오'라면 AI가 아직 개인 도구 단계에 머물러 있다는 뜻입니다.
- 01
팀이 사용 중인 자동화 플랫폼을 하루 끄면 영향을 받는 업무 프로세스가 있습니까?
- 02
지난달 AI가 특정 프로세스에 얼마를 썼는지 구체적인 수치를 조회할 수 있습니까?
- 03
AI가 예산을 변경하거나 콘텐츠를 게시하거나 운영 데이터를 기록하기 전에 강제적인 사람의 승인 단계가 있습니까?
- 04
AI 실행이 잘못된 결과를 냈을 때, 오류가 난 단계를 짚어내고 당시의 입력과 출력을 확인할 수 있습니까?
- 05
프로세스를 구성한 동료가 2주간 휴가를 가더라도, 다른 사람이 이 프로세스를 이해하고 안심하고 수정할 수 있습니까?
대조
'AI 활용'과 AI Native를 항목별로 비교
같은 일을 두 가지 업무 방식에서 처리할 때의 차이입니다.
| 차원 | AI를 활용하는 팀 | AI Native 팀 |
|---|---|---|
| 역량 진입점 | 각자 개인의 채팅 창 | 팀이 공유하는 워크플로우 플랫폼, 각 프로세스에 이름과 정의가 있음 |
| 경험 보존 | 잘 쓰이는 프롬프트가 개인 즐겨찾기에 저장됨 | 프롬프트가 워크플로우 정의에 작성되어 팀 전체가 동일한 버전을 사용함 |
| 실패 처리 | 수동으로 다시 실행하고, 질문 방식을 바꿔 재시도함 | 실행 기록을 조회해 오류가 난 단계를 짚어내고, 그 단계부터 다시 실행함 |
| 감사 | 문제가 생기면 채팅 기록을 뒤짐 | 실행마다 로그가 있고, 핵심 변경에는 승인 기록이 있음 |
| 비용 계산 | 월말에 구독 총 청구서 하나를 확인함 | 실행마다 token 사용량과 비용이 항목별로 기록됨 |
| 확장 방식 | AI를 쓸 줄 아는 사람을 한 명 더 채용함 | 워크플로우 하나를 복제하고 파라미터를 바꿔 두 번째 업무를 실행함 |
엔지니어링 요건
AI Native를 실현하려면 엔지니어링 측면에서 네 가지가 필요합니다
각 항목 아래에 Braidrun의 해당 메커니즘을 적어 두었으며, 가입 후 하나씩 검증할 수 있습니다.
02
핵심 작업에는 강제 승인이 있습니다
AI는 실수를 합니다. 예산 변경, 콘텐츠 게시, 운영 데이터 기록과 같은 작업은 실행 전에 멈춰서 사람의 확인을 기다려야 합니다. 확인 단계는 프로세스 정의에 명시되어야 건너뛰어지지 않습니다.
Braidrun의 방식
manual_approval 단계는 실행을 일시 중지하고 App 내, 이메일 또는 API를 통해 승인자에게 알립니다. 승인되면 계속 진행하고, 거부하거나 시간이 초과되면 중단하며 운영 환경에는 아무것도 변경하지 않습니다. 승인 양식의 값은 직접 수정할 수 있습니다. 예를 들어 AI가 제안한 입찰가를 낮춘 뒤 승인할 수 있습니다.
03
실행마다 완전한 기록을 남깁니다
AI의 출력은 매번 다를 수 있습니다. 문제가 생기면 어느 단계가 잘못됐는지, 당시의 입출력은 무엇이었는지, 이번 실행에 얼마가 들었는지에 답할 수 있어야 합니다.
Braidrun의 방식
실행마다 타임라인이 있어 단계별로 로그, token 사용량, 비용을 기록하며, 실행 과정은 JSON 또는 YAML로 내보낼 수 있습니다. 실패 후에는 지정한 단계부터 다시 실행할 수 있으며, 이미 완료된 LLM 단계는 중복 과금되지 않습니다.
04
모델과 배포를 교체할 수 있습니다
모델은 빠르게 갱신되어, 오늘 적합한 선택이 반년 뒤에는 달라질 수 있습니다. 프로세스 정의와 모델은 분리되어야 하며, 모델을 교체할 때 프로세스 자체를 다시 작성할 필요가 없습니다.
Braidrun의 방식
본인의 모델 API Key를 사용하며, 15개 이상의 공급업체와 로컬 Ollama, LM Studio를 지원합니다. 하나의 워크플로우에서 각 Agent에 서로 다른 모델을 설정할 수 있습니다. 자격 증명은 AES-256-GCM으로 암호화 저장되며, 온프레미스 배포를 지원합니다.
FAQ