소프트웨어 실행 거버넌스는 프로덕션 이전부터 시작됩니다

대부분의 팀은 여전히 거버넌스(Governance)가 배포(Deployment) 시점에 시작되는 것처럼 이야기합니다.

승인(Approvals). 프로덕션 접근 권한(Production access). 컴플라이언스 검토(Compliance review). 감사 추적(Audit trails).

이 모든 것들은 중요합니다.

하지만 소프트웨어가 프로덕션(Production)에 도달할 때쯤이면, 가장 중요한 실행 결정 중 상당수는 이미 완료된 상태입니다:

의존성(Dependencies)이 설치됨
스크립트(Scripts)가 실행됨
서비스(Services)가 시작됨
환경(Environments)이 구성됨
비밀 정보(Secrets)가 요구됨
에이전트(Agents)가 동작을 허용받음

그렇기 때문에 저는 일반적인 프레임워크가 불완전하다고 생각합니다.

소프트웨어 실행 거버넌스(Software execution governance)는 프로덕션 이전부터 시작됩니다. 누군가가 저장소(Repository)를 실행하는 순간부터 시작됩니다.

대부분의 팀이 여전히 무시하고 있는 간극

대부분의 조직은 프로덕션은 주의 깊게 거버넌스를 적용하면서도, 저장소 실행(Repository execution)은 느슨하게 관리된 채로 방치합니다.

기여자(Contributor)는 저장소를 클론(Clone)하고, README를 읽고, 적절해 보이는 설정 경로를 실행합니다.

어쩌면 잘 작동할 수도 있습니다.

어쩌면 문서화되지 않은 서비스(Services)를 필요로 할 수도 있습니다.

어쩌면 로컬 상태(Local state)를 변형할 수도 있습니다.

어쩌면 외부 시스템(External systems)에 접속할 수도 있습니다.

어쩌면 AI 에이전트(AI agent)에게 무엇이 안전한지 추론하도록 요청할 수도 있습니다.

실행은 이미 일어나고 있습니다. 거버넌스 계층(Governance layer)이 단지 누락되어 있을 뿐입니다.

그것이 바로 간극(Gap)입니다.

리스크는 배포 시점에 시작되지 않습니다

저장소는 배포가 존재하기도 전에 많은 일을 할 수 있습니다:

소프트웨어 설치
스크립트 실행
파일 수정
인프라(Infrastructure) 시작
자격 증명(Credentials) 요청
포트(Ports) 바인딩
Docker, 데이터베이스(Databases) 또는 클라우드 도구(Cloud tools) 접촉

이 중 어떤 것도 저장소를 "나쁘게" 만드는 것은 아닙니다.

단지 실행이 대부분의 거버넌스 모델이 인정하는 것보다 훨씬 더 이른 시점에 결과(Consequences)를 초래한다는 것을 의미할 뿐입니다.

운영자(Operator)는 다음과 같을 수 있습니다:

개발자(Developer)
CI 러너(CI runner)
자동화 시스템(Automation system)
AI 에이전트(AI agent)

운영자는 변합니다.

실행 리스크(Execution risk)는 변하지 않습니다.

왜 AI가 이를 무시할 수 없게 만드는가

수년 동안 팀들은 인간이 누락된 부분을 채울 수 있었기 때문에 취약한 저장소 거버넌스로도 버틸 수 있었습니다.

누군가는 알고 있었습니다:

어떤 명령어가 실제로 중요한지
어떤 서비스가 먼저 실행되어야 하는지
어떤 스크립트가 오래되었는지
어떤 경로가 안전한지
"완료(Done)\

리포지토리가 이를 선언하지 않는 한, AI 에이전트(AI agents)는 그 숨겨진 컨텍스트(context)에 접근할 수 없습니다.

그것이 바로 AI가 이미 존재하던 문제를 드러내고 있는 이유입니다.

문제는 에이전트가 본질적으로 무모하다는 것이 아닙니다.

문제는 많은 리포지토리(repositories)가 실행이 시작되는 바로 그 시점에 여전히 암묵적 지식(tribal knowledge)에 의존하고 있다는 점입니다.

추론(Inference)은 거버넌스(governance)가 아닙니다.

하나의 실제 리포지토리 형태의 문제

실제 리포지토리를 압박 테스트(Pressure-testing)해 보면 이 사실은 빠르게 명확해집니다.

n8n과 같은 리포지토리를 예로 들어보겠습니다.

이 리포지토리는 여러 개의 정당한 실행 경로(execution paths)를 가지고 있습니다:

모노레포(monorepo)를 통한 기여자 경로(contributor path)
npx n8n을 통한 퀵스타트(quickstart) 경로
Docker를 통한 컨테이너(container) 경로

세 가지 모두 실제 경로입니다.

하지만 이들은 동일한 전제 조건(prerequisites), 동일한 설정 경로(setup path), 또는 동일한 준비 상태(readiness)의 의미를 공유하지 않습니다.

만약 그 진실이 README의 산문, 스크립트, CI 워크플로(workflows), 그리고 유지 관리자의 기억 속에만 퍼져 있다면, 해당 리포지토리는 프로덕션(production)이 관련되기 전부터 이미 거버넌스가 부족한 상태입니다.

그것이 바로 Ota가 해결하려는 문제입니다.

거버넌스는 의도를 선언하는 것을 의미합니다

좋은 거버넌스는 관료주의가 아닙니다.

그것은 모호함의 감소(ambiguity reduction)입니다.

거버넌스가 적용된 리포지토리는 다음 질문에 답할 수 있어야 합니다:

이 리포지토리가 무엇을 필요로 하는가
어떤 워크플로(workflow)가 의도된 진입점(front door)인가
작업이 실행되기 전에 무엇이 일어나야 하는가
어떤 서비스가 중요한가
"준비됨(ready)"은 무엇을 의미하는가
어떤 작업이 안전한가
어떤 경로가 보호되는가
어떤 검증(verification)이 필요한가
실행이 언제 중단되어야 하는가

이것들은 실행(execution)에 관한 질문들입니다.

그리고 이 질문들은 배포(deployment) 이전에 나타납니다.

Ota가 명시적으로 만드는 것들

Ota의 핵심 아이디어 중 하나는 간단합니다:

리포지토리가 유지 관리자의 번역 없이도 스스로 어떻게 작동하는지 설명할 수 있어야 한다는 것입니다.

즉, 리포지토리가 다음과 같은 사항들을 선언할 수 있음을 의미합니다:

무엇이 필요한가
무엇이 실행될 수 있는가
무엇이 실행되어야 하는가
무엇이 실행되지 말아야 하는가
무엇이 승인을 필요로 하는가
검증(verification)이 무엇을 의미하는가
실행이 언제 중단되어야 하는가

그리고 더 중요한 것은, Ota가 하나의 계약(contract)을 통해 이러한 답변들을 실행 가능한(executable) 상태로 만들 수 있다는 점입니다.

압축된 형태는 다음과 같습니다:

version: 1
project:
...

이것은 단순한 명령 노출(command exposure)이 아닙니다.

이것은 실행 거버넌스(execution governance)입니다:

하나의 선언된 진입점 (one declared front door)
하나의 선언된 검증 경로 (one declared verification path)
하나의 에이전트 안전 경계 (one agent-safe boundary)
고위험 실행을 위한 하나의 명시적 승인 경계 (one explicit approval boundary for higher-risk execution)
하나의 명시적 보호 경로 표면 (one explicit protected-path surface)

명령 계층(Command Layer) 또한 중요합니다

계약(contract)이 존재하면, 리포지토리(repo)는 인간과 에이전트 모두에게 더 신뢰할 수 있는 실행 경로를 노출할 수 있습니다:

ota validate
ota doctor
ota up
...

이 명령들은 서로 다른 질문에 답합니다:

ota validate는 계약(contract) 자체가 건전한지 확인합니다.
ota doctor는 현재 무엇이 차단되었는지 설명합니다.
ota up은 선언된 경로에 따라 리포지토리(repo)를 준비합니다.
ota run verify는 표준 검증 작업(canonical verification task)을 실행합니다.

이는 “README를 읽고, 스크립트를 조사하며, 진짜 경로를 찾기를 바라는” 방식보다 더 강력한 운영 모델입니다.

이것은 리포지토리의 관심사가 되고 있습니다

AI 보조 개발(AI-assisted development)이 일상이 됨에 따라, 인간이 유지 관리자(maintainer)에게 올바른 명령이 무엇인지 묻기도 전에 더 많은 리포지토리(repo)가 자동화 및 에이전트에 의해 실행될 것입니다.

이는 거버넌스(governance)가 더 이상 프로덕션(production) 전용 개념으로 남아있을 수 없음을 의미합니다.

리포지토리(repositories)에는 다음이 필요합니다:

선언된 운영 규칙 (declared operating rules)
검증 경계 (verification boundaries)
기계 판독 가능한 실행 계약 (machine-readable execution contracts)
하나의 실행 진실 원천 (one source of execution truth)

다시 말해, 리포지토리(repository) 경계 자체에서 소프트웨어 실행 거버넌스(software execution governance)가 필요합니다.

결론

기존 모델은 소프트웨어가 프로덕션(production)에 도달할 때 거버넌스가 시작된다고 말합니다.

그것은 너무 늦습니다.

실행(execution)은 훨씬 더 일찍 시작됩니다:

리포지토리(repository)가 클론(cloned)될 때
설정(setup)이 시작될 때
서비스가 런칭(launched)될 때
CI가 실행될 때
AI 에이전트(AI agent)가 작업을 시작할 때

그곳이 바로 신뢰가 시작되는 지점입니다.

그곳이 바로 가정이 행동이 되는 지점입니다.

그리고 그곳이 바로 거버넌스(governance)가 속해야 할 곳입니다.

소프트웨어 실행 거버넌스(software execution governance)는 프로덕션(production)에서 시작되지 않기 때문입니다.

실행(execution)이 시작되는 바로 그 순간 시작됩니다.

Ota 시작 가이드 (getting started guide)를 살펴보세요
Ota 예제 (examples) 리포지토리를 확인해보세요

원문 게시처: ota.run