데이터베이스 브랜치 기능을 통해 AI 에이전트의 쓰기 권한을 안전하게 관리할 수 있을까요?

질문에 답하자면: 우리 쪽은 쓰기 작업을 하긴 하지만, raw access가 아니라 제한된 툴을 통해서만 함. 툴의 경계가 곧 피해 범위를 결정함. diff 리뷰에 관해서는: 마찰이 생길 거라는 걱정은 현실적임, 리뷰어가 다시 병목 현상이 될 테니까. 내가 주의 깊게 볼 건 삭제의 비대칭성임: 인서트나 업데이트는 before-image를 보관하면 복구 가능하지만, 삭제는 무서운 범주임. 초반에는 삭제 건수는 몇 개든 절대 자동 머지 안 되게 할 거임. 그리고 CRM 사례는 대량 삭제였는데, 멍청한 수준의 문장당 행 제한만 있었어도 브랜칭이 필요하기 전에 막았을 거임.

맞음, 프로덕션 환경에서 싹 날려 먹고 나면, 머지 전에 브랜치 생성 후 diff 확인하는 게 내가 신뢰할 수 있는 유일한 방법임. 그리고 '대량 삭제 금지' 규칙을 강하게 걸어서, 작은 행 수정은 자동 머지하고 그보다 큰 건은 사람이 확인하게 해야 함.

'N개 이하 삭제' 같은 제한은 에이전트가 작업을 어떻게 나눌지 선택하지 못할 때만 유효함. 읽은 내용에 따라 움직이는 에이전트는 똑같은 삭제 작업을 제한치 이하로 쪼개서 실행할 수 있고, 그러면 리뷰 큐는 깔끔한 diff들로 가득 차게 됨. 문장 단위가 아니라 전체 실행이나 브랜치 전체를 기준으로 제한을 걸어야 함.

브랜치가 있었다면 리드 리스트는 살렸겠지만, 머지 규칙은 단순히 삭제 건수 N개 이상 여부만 봐서는 안 됨. 삭제가 0건이라도 잘못된 CRM 행 5,000개를 덮어쓸 수 있음. 머지 전에 영향을 받는 테이블/테넌트, 행 개수, 변경된 필드, 그리고 요청이 해당 범위를 명시했는지 확인해야 함. 머지를 위한 before-image와 롤백 경로도 유지해야 하고.

브랜치는 무엇이 변경되었는지는 보여주지만, 이번 실행에서 어떤 주체(principal)가 해당 브랜치를 열 수 있도록 허용되었는지는 보여주지 않음. 데이터베이스 역할이나 도구 ACL은 연결이 무엇을 호출할 수 있는지만 답해줄 뿐임. 나는 첫 쓰기 작업 전에 안정적인 에이전트나 서브에이전트 ID와 이번 실행에 대한 위임 범위(delegation scope)가 기록되고, 그 동일한 ID가 병합 결정에 첨부되기를 원함. 그게 없으면 diff는 그냥 '모델이 뭔가를 했다'는 식으로 읽히고, 병합을 승인하는 사람은 스코프가 지정된 실행인지, 아니면 같은 쓰기 도구를 재사용하는 다른 서브에이전트인지 구분할 수 없음. 행 단위 diff와 삭제 제한(delete cap)은 여전히 가치가 있음. 다만, 누가 실행을 시작할 권한을 받았는지에 대한 문제를 대체할 수는 없음.

전부 삭제해버리는 오류는 눈에 확 띄니까 바로 잡을 수 있음. 내가 더 무서워하는 건 조용히 잘못된 값을 쓰는 경우임: 직함, 회사명, 소유자 정보가 자신 있게 업데이트되고, 모든 작업은 성공으로 뜨는데, 다른 시스템들은 며칠 동안 잘못된 정보로 돌아가는 상황이지. 브랜치와 병합 전 before/after 리뷰는 이런 상황에 큰 도움이 됨. 특히 아웃바운드나 결제에 영향을 주는 필드라면 더더욱. 나 같으면 대량 업데이트(bulk update)나 식별 필드(identity fields)를 건드리는 작업은 행 수가 적더라도 무조건 사람이 확인하게 할 거임. 권한 설정만으로는 허용된 범위 내에서 잘못된 값이 입력되는 걸 막을 수 없으니까.

에이전트별 브랜치 모델 좋네. 두 가지만 더하자면, 브랜치는 단기로 유지해. 오래될수록 머지할 때 stale read 문제가 생기거든. 그리고 에이전트가 변경 근거로 삼은 읽기 작업들을 기록해둬. 그래야 머지할 때 그 조건들이 여전히 유효한지 확인할 수 있지. 이건 위 댓글에서 말한 전제 조건(preconditions)이랑 비슷해. 삭제, 스키마, 권한 변경 같은 건 diff 리뷰하는 게 적절한 마찰(friction)이라고 봐. 작은 업데이트들은 행 개수 제한 규칙만으로도 충분하고.

네, 브랜치를 만드는 건 쉬운 부분이라고 생각합니다. 진짜 어려운 건 병합이고, 제가 신뢰하기 위해 해결되어야 할 부분도 바로 그겁니다.

검토 과정에서는 단순히 건드린 행만 보여줄 게 아니라, 그 변경이 무엇에 영향을 미치는지 보여줘야 합니다. 삭제된 리드 리스트는 diff에서 바로 보이죠. 하지만 세 가지 자동화가 읽고 있는 필드가 변경된 건, 리뷰 시스템이 그 필드에 의존하는 것들을 추적할 수 없다면 알기 어렵습니다. 테이블, 행, 변경 전후 데이터는 좋은 시작점이지만, '무엇이 이걸 읽는가'를 파악하는 게 진짜 무서운 사고를 막아줍니다.

충돌 문제도 위치가 아니라 의미 중심으로 다뤄야 합니다. 두 에이전트가 같은 레코드의 서로 다른 필드를 수정하는 건 보통 충돌로 보면 안 됩니다. 반면 각각은 괜찮아 보여도 합치면 규칙을 깨뜨리는 변경은 충돌로 처리해야 하며, 행 단위 병합으로는 이걸 알 수 없습니다. 작성자님이 말한 'N개 이상의 삭제 금지' 규칙은 그 아이디어의 좋은 첫걸음이네요. 그 방향으로 계속 나아가 보세요.

의존성 매핑이 핵심입니다. 변경된 필드를 읽는 하위 자동화들을 보여주면, 모든 워크플로우를 일일이 열어보지 않고도 검토 가능한 수준의 diff가 됩니다.