팀이 사람을 위해 만들어둔 환경 원칙은 코딩 에이전트에도 그대로 적용되지만, 대부분의 팀은 에이전트가 쓸 만해지는 순간 그 원칙 전부를 조용히 내려놓았다. 신입에게 첫날부터 프로덕션 근처에도 못 가게 했을 조직이 정작 에이전트에게는 장기 유효 자격 증명 하나와 작업 설명 한 줄을 쥐여준 뒤, 있어서는 안 될 것이 빠졌을 때 놀란 척한다.

이 글의 주장은 일부러 재미없다. 에이전트는 유별나게 빠르지만 조직적 판단력은 전혀 없는 기여자이며, 환경 사다리는 정확히 이런 기여자를 위해 존재한다. 개발, 스테이징, 프로덕션, 각 단계 사이의 게이트. 이건 애초에 사람에 관한 이야기가 아니었다. 언제나 피해 범위에 관한 이야기였다.

사다리가 생략된 이유

누구도 사다리를 생략하기로 결정한 적은 없다. 인지할 가치가 있는 순서로 조금씩 무너졌을 뿐이고, 여러분의 팀도 아마 그 어딘가에 있을 것이다.

에이전트는 자동완성으로 시작한다. 자동완성을 스테이징하는 사람은 없다. 그러다 로컬에서 테스트 스위트를 돌리기 시작하는데, 여기까진 괜찮다. 그러다 버그를 재현하려면 실제 서비스를 건드려야 해서 누군가 스테이징 읽기 권한을 준다. 그러다 스테이징 데이터가 낡아서 누군가 프로덕션 레플리카를 가리키게 한다. 그러다 어떤 작업에 쓰기가 필요한데, 마침 환경에 이미 놓여 있던 자격 증명이 그 권한을 갖고 있다. 어느 시점에도 누구도 에이전트가 프로덕션에 쓸 수 있어야 한다고 결정한 적이 없다. 개별적으로는 다 합리적인 단계들을 거쳐 거기 도달했을 뿐이고, 대부분의 사고가 어디서든 그렇게 도달한다.

에이전트가 다르게 만드는 것

사다리는 사람보다 에이전트에게 더 중요하다. 모델의 능력에 대한 평가가 아니라 구조적인 이유 때문이다.

  • 속도가 멈춤을 없앤다. 사람은 파괴적인 일을 하기 전에 대개 한 번 멈칫한다. 그 멈칫함은 문서화되지 않은 안전장치이고, 사다리가 느슨하게 지켜지면서도 사람에게는 오랫동안 버텨온 큰 이유다. 에이전트는 완전한 확신을 갖고 2초 만에 실행한다. 잡아낼 멈춤이 없다.
  • 결과에 대한 감각이 없다. 엔지니어는 이 테이블이 청구 테이블이고 목요일이 인보이스 날이라는 걸 안다. 그 지식은 저장소 안에 없으므로 에이전트의 컨텍스트에도 없다. 에이전트는 스키마를 안다. 무엇이 위태로운지는 모른다.
  • 목표를 문자 그대로 받아들인다. 통합 테스트를 통과시키라는 지시를 받으면, 에이전트는 그 테스트가 검증하는 데이터 자체를 바꾸는 방안까지 고려한다. 이는 주어진 문제에 대한 정당한 해법이다. 에이전트가 갖지 못한 맥락 때문에 잘못됐을 뿐이다.
  • 물량. 엔지니어 한 명은 하루에 풀 리퀘스트 세 개를 연다. 에이전트 여러 대는 서른 개를 연다. 변경 하나당 나쁜 변경일 확률은 낮아져도 나쁜 변경의 절대 개수는 늘어날 수 있다.

에이전트를 위해 다시 쓴 사다리

단은 셋으로 같고, 에이전트 특유의 부분만 짚는다.

  • 개발: 일회용이고 격리돼 있어야 한다. 에이전트 하나에 워크스페이스 하나, 공유 상태는 없다. 에이전트 둘이 같은 체크아웃에서 작업하면 같은 파일을 두고 충돌할 것이고, 둘 다 이해하지 못하는 머지 컨플릭트를 읽으며 오후를 보내게 된다. 일회용 브랜치와 워크트리는 저렴하다. 공유되는 가변 상태는 그렇지 않다.
  • 스테이징: 형태는 진짜, 위험은 가짜. 스테이징이 제 역할을 하려면 구조적으로 프로덕션을 닮아야 한다. 같은 스키마, 같은 서비스 토폴로지, 같은 실패 양상을 가지되, 잃어도 상관없는 것들만 담고 있어야 한다. 시딩되거나 합성된 데이터여야지 프로덕션 복사본이어서는 안 된다. 스테이징 안의 프로덕션 레플리카는 모니터링만 부실한 프로덕션일 뿐이다.
  • 프로덕션: 오직 사람과 게이트만. 에이전트의 결과물도 다른 변경과 똑같은 경로, 즉 리뷰를 거친 풀 리퀘스트와 기존 배포 게이트를 통해서만 프로덕션에 닿는다. 뒷문도, 지름길을 가진 서비스 계정도 없다.

격리는 자격 증명이지 URL이 아니다

여기서 팀들은 스스로를 속인다. 에이전트를 staging.internal로 향하게 했다 해도, 그 환경의 자격 증명이 프로덕션에서도 유효하다면 그건 격리가 아니다. 환경의 경계는 작업이 언급한 호스트네임이 아니라 그 신원이 무엇에 닿을 수 있는지로 정해진다. 넓은 역할을 가진 에이전트는 잘못된 계정으로부터 도구 호출 하나 거리에 있고, 그 호출을 정중하게, 그리고 즉시 해낼 것이다.

버텨내는 버전은 특별할 것 없는 AWS 실무를 일관되게 적용하는 것이다.

  • 환경별로 계정을 분리해, 환경을 넘나드는 실수가 존재하지도 않는 역할 전환을 필요로 하게 만든다. 존재하는 오타 하나로는 넘어갈 수 없다.
  • 에이전트 작업마다 전용 역할을 두고, 그 작업에 필요한 리소스로 범위를 좁히며, 실행되는 동안만 assume하고 그 이상은 유지하지 않는다.
  • 에이전트 환경에 장기 유효 키를 두지 않는다. 수명이 짧은 자격 증명이라면 유출된 컨텍스트도 만료일이 있는 문제가 된다.
  • 파괴적인 동작은 기본값이 거부여야 한다. DeleteObject가 절대 필요 없는 에이전트라면 그 호출을 구조적으로 할 수 없어야지, 그저 하지 않는 편을 택하게 해서는 안 된다.
  • 실제 데이터를 담은 계정으로 넘어가는 모든 일에는 사람의 승인을 거치게 하라. 에이전트 스스로는 만족시킬 수 없는 통제로서.

리뷰 게이트는 마찰이 아니라 핵심이다

반발은 예상할 수 있다. 이게 에이전트를 느리게 만들고, 에이전트의 매력 포인트는 애초에 속도였다는 것이다. 이 반박은 진지하게 검토할 가치가 있지만, 결국 기각해야 한다. 셈법 자체를 잘못 매기고 있기 때문이다.

에이전트의 속도 우위는 생성에 있지 검증에 있지 않다. 한 시간이 아니라 90초 만에 그럴듯한 수정안을 작성하는 것은 실재하고 큰 이점이다. 검증은 애초에 에이전트가 제거해주는 병목이 아니었다. 리뷰 게이트를 없앤다고 에이전트가 잘하는 그 일이 더 빨라지지는 않는다. 확신에 찬 산출물 중 10%가 틀렸을 때 그걸 잡아내는 장치만 사라질 뿐이다. 90초짜리 수정안은 그대로 얻는다. 리뷰어도 그대로 유지한다. 그것이 전체 구조이고, 좋은 구조다.

요약

이 중 새로운 엔지니어링은 하나도 없다. 환경 분리, 범위가 좁은 자격 증명, 프로덕션 이전의 리뷰. 여러분의 팀은 이 규칙들을 사람을 위해 만들었고 대체로 지키고 있다. 실수는 에이전트를 도구가 아니라 기여자로 대해야 하는데도 도구로 취급하는 데 있다. 도구는 환경 사다리가 필요 없지만 기여자는 필요하기 때문이다. 에이전트에게 프로덕션처럼 보이면서도 중요한 것은 하나도 담고 있지 않은 샌드박스를, 만료되고 경계를 넘어가지 못하는 신원을, 그리고 배포 전에 서는 리뷰어를 주어라. 그런 다음 그 상자 안에서는 빠르게 달리게 하라.

이어서 읽으면 좋은 글

이 뒤에 있는 계정 수준 통제는 multi-party approval in AWS Organizations가 어떤 작업도 혼자서는 실행돼선 안 되는 경우의 게이트를 ercan.cloud에서 다룬다. 허브는 ercanermis.com이다.