빠른 AI 작업에 '중단 규칙(Stop Rule)'이 필요합니다

Several preparation paths converge at a verification boundary before release.(https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ff12u7e1wlye868ttl0m2.png)

빠른 구현은 중요한 결정을 건드리지 않은 채로 남겨둘 수 있습니다.

코드는 존재하고, 빌드는 통과하며, 보고서에 스크린샷이 있습니다. 하지만 이 버전이 사용자에게 도달해야 할까요? 증거가 실제로 확립하는 것은 무엇일까요? 다음에 무슨 일이 일어날지 누가 결정할까요?

AI 어시스턴트가 많은 부분을 구축하게 될 때 이러한 질문들은 더욱 중요해집니다. AI는 또 다른 버전을 빠르게 준비할 수 있습니다. 이 때문에 다음 단계를 이전 단계의 연속으로 취급하는 유혹을 느끼기 쉬운데, 비록 그 다음 단계가 다른 종류의 위험을 내포하고 있더라도 말입니다.

저는 전에 Godot 프로젝트에서 작업 분담에 대해 글을 쓴 적이 있습니다: Instinct는 구현과 테스트를 많이 담당하고; 저는 방향성, 표준, 그리고 출시(ship) 결정을 소유합니다.

실질적인 질문은 모든 작은 변경 사항을 회의로 만들지 않으면서 그 경계를 어떻게 유용하게 만드는가 하는 것입니다.

제 대답은 '중단 규칙(stop rule)'입니다.

작업과 약속 분리하기 (Separate the work from the commitment)

변경 사항에 대한 연구, 후보 빌드에 구현, 그리고 출시하는 것은 서로 다른 결정들입니다.

어시스턴트는 사람들이 그것을 받아야 한다고 결정하지 않고도 후보를 준비할 수 있습니다. 테스트 결과를 모든 제품 질문에 답한다고 결정하지 않고도 실행할 수 있습니다. 현재 버전을 변경하는 비용이 허용 가능하다고 결정하지 않고도 수정 사항을 제안할 수 있습니다.

이것은 코드의 모든 줄마다 허락을 구해야 한다는 주장이 아닙니다. 준비가 약속(commitment)이 되는 지점을 명명하는 것에 대한 주장입니다.

그 지점 이전까지는 작업을 계속 진행시키십시오. 그 지점에서는 결정에 필요한 증거를 요구하십시오.

통과한 테스트는 제한적인 의미를 가집니다

Ctrl+Alt+Liberate의 아슬아슬한 메커니즘은 유용한 예시입니다.

이전 기사에서 설명한 후보(candidate)의 경우, 배 근처를 지나가는 적대적인 샷은 약간의 FOCUS 보상을 줄 수 있습니다. 데스크톱 회귀 검사(Desktop regression checks)는 보호된 패스를 제외하는 조건이나 동일한 샷이 반복적으로 보상을 주는 것을 방지하는 것과 같은 조건을 다루었습니다.

그러한 검사들은 중요했습니다. 그것들이 손에서 진동이 느껴지는 방식, 플레이어가 휴대폰 화면의 마진을 읽을 수 있는지, 또는 게임이 스크립트 제어 장치가 아닌 사람들을 위해 균형 잡혀 있는지를 확립하지는 못했습니다.

데스크톱 패스는 다음 구현 결정(implementation decision)을 뒷받침했을 뿐입니다. 그것이 출시 결정(release decision) 자체를 확정하는 것은 아니었습니다.

그 구별은 '테스트 통과'라고만 말하는 보고서에서는 놓치기 쉽습니다. 더 나은 보고서는 어떤 주장이 통과했는지, 그리고 아직 증거가 필요한 주장은 무엇인지를 명시합니다.

결과가 도착하기 전에 중단 규칙을 작성하라

유용한 중단 규칙(stop rule)은 팀이 또 다른 해석 라운드 없이 적용할 수 있을 만큼 구체적이어야 합니다.

가상의 Android 출시를 위해, 저는 다음과 같이 작성할 것입니다:

후보를 준비하고 회귀 경로를 실행하라. 의도된 게임 플레이 화면이 보이지 않거나, 입력이 대상 장치에서 실패하거나, 또는 장치 검사가 이루어지지 않은 경우 출시 전에 중단한다. 데스크톱 패스만으로는 출력을 확정할 수 없다.

이것은 예시일 뿐이며, 현재 빌드에서 그러한 검사들이 완료되었다는 보고서는 아닙니다.

이 규칙은 어시스턴트가 작업할 여지를 줍니다. 또한 누락된 증거가 조용한 가정(quiet assumption)이 되는 것을 방지합니다.

가장 중요한 구절은 종종 '이루어지지 않았다'입니다. 누락된 검사는 실패한 검사와는 다르지만, 둘 다 통과로 제시되어서는 안 됩니다.

작은 결정 카드를 유지하라

저는 후보 변경 사항 옆에 다섯 가지 필드를 배치할 것입니다:

• 결정(Decision): 지금 무엇을 결정하고 있는가?
• 증거(Evidence): 어떤 관찰이 그 결정을 바꿀 수 있는가?
• 한계(Limit): 이 증거가 확립하지 못하는 것은 무엇인가?
• 소유자(Owner): 누가 약속을 할 수 있는가?
• 중단 조건(Stop condition): 다음 단계를 막는 것은 무엇인가?

Decision card with Decision, Evidence, Limit, Owner and Stop condition, each paired with a short question. A missing check is not a pass.

위의 가상 출시(hypothetical release)에 대해 결정할 것은 코드가 컴파일되는지 여부가 아니라, 실제로 출시할 것인지 여부입니다. 여기에는 대상 장치 경로(target-device route)가 증거로 포함됩니다. 한 번 성공적인 경로만으로는 장기적인 균형을 입증하지 못한다는 한계가 있습니다. 소유자(owner)는 출시를 책임지는 사람입니다. 중단 조건(stop condition)에는 부재하는 장치 확인(absent device check)이 포함됩니다.

이는 적은 양의 글쓰기입니다. 이 가치는 보기 좋은 결과물 때문에 모두가 조바심을 느끼기 전에 경계(boundary)를 눈에 보이게 만드는 데서 나옵니다.

프로젝트 전체가 아닌, 잘못된 다음 단계 멈추기

중단 규칙은 유용한 작업이 남아 있도록 해야 합니다.

만약 출시가 장치 확인을 기다리고 있다면, 어시스턴트는 테스트 경로를 준비하거나, 알려진 한계를 문서화하거나, 별도의 회귀(regression)를 조사할 수 있습니다. 단순히 출시는 완료되었다고 설명하거나, 누락된 장치 증거를 더 많은 데스크톱 실행으로 대체해서는 안 됩니다.

테스트가 실패했을 때도 동일한 원칙이 적용됩니다. 다음 유용한 행동은 또 다른 기능(feature)을 추가하는 것보다는 진단(diagnosis)일 수 있습니다. 더 많은 결과물이 자동으로 더 많은 진전(progress)을 의미하지는 않습니다.

저는 AI 어시스턴트가 제가 짊어져야 할 작업을 줄여주는 것이 아니라, 제가 여전히 결정해야 하는 결정을 숨겨주기를 원합니다. 명확한 경계는 이 두 가지 모두에 도움이 됩니다.

어시스턴트는 많은 작업을 수행할 수 있습니다. 증거(evidence)는 우리가 무엇을 알고 있는지 알려줍니다. 책임지는 사람은 그 지식이 충분하여 정당화될 수 있다고 결정합니다.

본 기사에 대한 참고 사항

본 기사는 제가 발표한 프로젝트 글쓰기에서 영감을 받아 준비되었습니다. 제 이름으로 보이는 모든 것에 대해 저는 책임을 집니다.