// APP FACTORY · EP. 02
위험해 보이는 명령을 일일이 금지하는 방식은 오래가지 못했습니다. 결과를 되돌릴 수 있는지, 초안인지, 나중에 수정 가능한지, 아직 외부에 공개되지 않았는지를 기준으로 AI 에이전트의 자율 경계를 다시 정했습니다.
1. 처음에는 위험한 명령 목록을 만들었습니다
앱 공장을 처음 만들 때는 AI가 하면 안 되는 작업을 목록으로 적었습니다. 삭제 명령은 막고, 외부 공개는 확인하고, 위험해 보이는 작업은 사람에게 물어보라는 식이었습니다.
그런데 이 방식은 금방 한계가 왔습니다. 같은 삭제라도 다시 만들 수 있는 생성 파일을 지우는 것과 복구할 수 없는 운영 데이터를 지우는 것은 전혀 달랐습니다. 명령 이름만 보고 위험도를 정하면 매번 예외가 생겼습니다.
목록이 길어질수록 에이전트는 더 안전해지는 것이 아니라 더 자주 사람에게 질문했습니다. 결국 사람이 다시 판단해야 했고 자동화는 그 자리에서 멈췄습니다.
2. 질문을 세 가지로 바꿨습니다
그래서 작업 이름 대신 결과가 되돌릴 수 있는지를 보기로 했습니다. 초안으로 남는가, 나중에 수정할 수 있는가, 아직 외부에 공개되지 않았는가를 확인합니다.
로컬 코드 변경이나 다시 만들 수 있는 산출물은 에이전트가 진행합니다. 결과가 마음에 들지 않으면 Git에서 되돌리거나 다시 생성할 수 있기 때문입니다.
반대로 스토어 심사 제출, 운영 자격증명, 계정 전체에 영향을 줄 수 있는 변경은 사람의 확인을 남겼습니다. 기준을 이렇게 바꾸고 나니 새로운 도구가 추가되어도 금지 목록을 계속 늘릴 필요가 줄었습니다.
3. 같은 콘솔 안에서도 경계가 달라집니다
Play Console에서 하는 작업이 모두 위험한 것은 아닙니다. 앱 설명을 수정하거나 스크린샷을 교체하는 일은 다시 바꿀 수 있습니다. 이런 작업까지 매번 멈추면 자동화의 이점이 거의 없어집니다.
하지만 심사 제출 버튼을 누르는 순간은 다릅니다. 외부 심사가 시작되고, 짧은 기간에 여러 앱이 함께 심사 중일 때 하나의 문제가 다른 앱의 검토에도 영향을 줄 수 있습니다. 그래서 스토어 등록정보 작성은 자동화하되 최종 제출은 사람 몫으로 남겼습니다.
같은 도구를 사용하더라도 행위의 결과가 되돌릴 수 있는지에 따라 선이 달라지는 셈입니다.
4. 지켜야 할 규칙은 문서에서 도구로 옮겼습니다
사람이 매번 판단하지 않아도 되는 규칙은 가능한 한 코드로 옮겼습니다. 광고 ID 하드코딩, 앱에서 공유 패키지 밖의 구현을 직접 참조하는 문제, 버전 번호 규약, 테스트 광고 ID 같은 항목입니다.
문서에 금지라고 적어 두는 것만으로는 충분하지 않았습니다. 에이전트가 규칙을 읽지 못할 수도 있고, 읽었어도 구현 과정에서 놓칠 수 있었습니다. 그래서 pre-commit과 pre-push, release-ready 검사에서 실제로 실패하게 만들었습니다.
한 번 실수한 항목을 주의사항으로만 남기면 같은 실수가 다시 나왔습니다. 두 번째부터는 설명을 더 길게 쓰는 대신 도구가 막게 하는 편이 낫다고 판단했습니다.
5. 현재는 세 층으로 관리합니다
현재의 경계는 세 층으로 정리할 수 있습니다. 대부분의 작업은 기계가 검증하고 그대로 진행합니다. 규칙 위반은 도구가 자동으로 차단합니다. 기계가 정확히 판단하기 어려운 외부 공개와 계정 위험만 사람이 확인합니다.
이 구조가 완벽한 안전을 보장한다고 생각하지는 않습니다. 다만 사람이 꼭 판단해야 하는 지점을 적게 남기고, 나머지는 재현 가능한 검사로 바꿨습니다. 덕분에 사람은 모든 단계에 서 있는 대신 정말 되돌리기 어려운 결정에만 집중할 수 있게 되었습니다.
6. 정리
AI 에이전트의 자율 범위를 정할 때 어떤 명령을 허용할지만 적어서는 오래가기 어려웠습니다. 저는 되돌릴 수 있는지, 외부에 공개되는지, 영향 범위가 어디까지인지를 기준으로 다시 나눴습니다.
다음 글에서는 이 판단에 가장 큰 영향을 준 제약, 자체 서버를 두지 않기로 한 결정에 대해 정리해 보겠습니다.
답글 남기기