브라운필드 에이전틱 엔지니어링
TMT오래된 코드베이스에서 에이전틱 엔지니어링을 한다는 것은, 숨어 있는 제약을 눈에 보이게 만들고 값싸게 만든 변경을 믿을 수 있게 만드는 일입니다. 브라운필드 코드베이스에서 무엇을 해야 하는지 이야기해 보겠습니다.
저는 일해 오는 동안 코드베이스가 오래된 팀에 여러 번 속해 있었습니다. 그런 시스템을 브라운필드라고 부릅니다. 저장소만 봐서는 그 시스템이 실제로 어떻게 동작하는지 온전히 알 수 없다는 뜻입니다. 조직에 축적된 지식, 임시로 붙여 놓은 땜질, 레거시 서비스, 다른 팀이 의존하고 있는 기대치는 소스 트리 밖에 살아 있습니다. 새 코드를 쓰기 전에 그런 제약을 먼저 익혀야 하고, 변경이 그 제약을 깨지 않았다는 것을 증명해야 합니다. 저는 에이전트와 함께 코딩하는 것을 정말 좋아하지만, 오래된 브라운필드 코드베이스에 감독 없이 에이전트를 풀어 놓으면 '돌아가기는 하는데' 시스템 설계가 잘못되고 테스트는 부실한 결과물을 손에 쥘 수도 있습니다.
AI가 없던 시절에도 현대화를 하고 싶어 하는 팀은 아주 잘게 쪼개서 조금씩 나아가야 했고, 튼튼한 테스트와 무언가를 깨뜨리지 않았다는 확신을 받쳐 줄 장치를 갖춰야 했습니다. 실제 사용자 여정 테스트 위에 반복 실행할 수 있는 테스트를 잔뜩 깔아서, 진행하는 마이그레이션이 의도한 대로 동작하는지 확인해야 한다는 것을 모두가 어느 정도는 알고 있었습니다. 요즘은 판단 하나하나를 내가 직접 내리지 않은 코드를 에이전트가 떨어뜨리는 순간 이미 브라운필드 프로젝트에 들어선 것이라고 말하는 사람도 있습니다. 어느 쪽이든, 변경을 값싸게 그리고 안전하게 할 수 있는 방향으로 최적화하는 것이 좋습니다.
그리고 요즘, 특히 지난 5~10년 사이에는 테스트를 더 챙기고, 검증을 더 챙기고, 무언가를 깨뜨리지 않는 방식으로 변경하는 법을 더 챙기자는 생각이 훨씬 많은 관심을 받게 된 것 같습니다. 그렇다고 해도 달라지지 않는 사실이 있습니다. 에이전틱 엔지니어링을 도입하고, 거기에 소프트웨어 팩토리처럼 큰 코드베이스를 자율적으로 헤쳐 나가는 여러 패턴까지 얹으려면, 상당히 더 많은 주의를 따로 갖춰 두어야 하고 그러지 않으면 기술 부채의 세계에 발을 들이게 됩니다.
본격적으로 들어가기 전에, 코드가 진실의 출처라고 전제하겠습니다. 브라운필드를 돕기 위해 그 위에 얹는 것은 코드에서 쉽게 유추할 수 없는 내용이어야 합니다. 이 이야기를 존(zone)과 폭발 반경(blast radius), 그리고 도움이 될 만한 몇 가지 패턴으로 풀어 보겠습니다.
존
한동안 굴러온 오래된 코드베이스에 들어간다면, 저는 먼저 어떤 코드를 건드리지 않아야 하는지 감을 잡고 싶습니다. 이것을 존으로 나눠 생각할 수 있습니다. 예를 들어 초록 존은 안전하고 테스트가 잘 되어 있고 격리된 코드, 노랑은 품질이 섞여 있는 코드, 빨강은 인증·결제·권한처럼 민감한 코드입니다.
코드베이스에서 아주 민감한 부분, 혹은 모두가 잘 이해하고 있지는 못한 부분은 어디인가요? 그런 곳을 서로 다른 존으로 칠해 두면 좋습니다. 테스트 커버리지가 아주 좋고, 지금 통용되는 최신 관례를 따르고, 격리도 잘된 초록 영역이 있을 수 있습니다. 시스템의 그런 부분은 에이전트가 알아서 빠른 루프를 돌며 작업해도 됩니다.
제가 일해 본 사이트, 특히 커머스 사이트 중에는 부서 대여섯 곳이 각자 마이크로사이트를 운영하는데도 최종 사용자에게는 하나의 경험처럼 느껴지는 곳이 흔했습니다. 그리고 표면 아래에는 실제로 상당한 복잡성이 깔려 있습니다. 어떤 팀은 자기 코드의 테스트 커버리지가 아주 좋고, 최근 몇 년 안에 만든 것일 수도 있습니다. 다른 팀은 그렇지 않을 수 있습니다. 그렇게 초록 존이 생깁니다.
노랑 존은 품질이 섞여 있는 곳입니다. 여러 가지가 뒤섞여 있을 수 있고, 에이전트는 특성화 테스트(characterization test)를 작성한 뒤에 그곳의 코드를 바꿀 수 있습니다.
그리고 빨강 영역이 있습니다. 인증, 결제, 권한, 급여처럼 민감한 코드, 평소라면 서둘러 손대지 않을 코드입니다. 예를 들어 그 동작을 이해하는 사람이 몇 명뿐인 경우가 그렇습니다. 그런 시스템에서 감독 없는 재작성은 원하지 않을 것입니다.
존이 비유에 그치지 않고 실제 운영 절차가 되려면 규칙 세 가지가 필요합니다. 첫째, 지도는 에이전트가 아니라 사람이 그립니다. 알아서 고르게 두면 에이전트는 가장 무서운 파일부터 손을 댑니다. 가장 무서운 파일에 가장 흥미로운 이름이 붙어 있기 때문입니다. 둘째, 존은 자격을 얻었을 때만 옮겨 갑니다. 특성화 테스트가 갖춰지고 그 모듈의 담당자가 에이전트의 첫 변경을 리뷰한 뒤에야 노랑이 초록이 됩니다. 셋째, 존이 허용되는 동작을 정합니다. 초록은 빠른 루프, 노랑은 테스트 먼저, 빨강은 모든 단계에 사람이 함께 붙거나 아니면 그 작업을 하지 않는 것입니다.
코드가 말해 주지 못하는 것을 적어 두세요
자율성의 수준은 폭발 반경과 관측 가능성, 복구 가능성에 따라 정해야 합니다. 모델이 얼마나 자신 있어 하는지는 좋은 기준이 되지 못합니다.
그래서 세상의 지도를 어떻게 바라볼지, 그리고 에이전트가 코드베이스만 보고 스스로 알아낼 수 있는 것은 어디까지인지 최소한의 감은 갖고 있는 게 좋다고 생각합니다. 실제로 에이전트는 코드 자체에서 꽤 많은 것을 알아냅니다. 한동안은 무엇이든 다 마크다운 파일로 적어 두고 그것을 컨텍스트 윈도에 밀어 넣으려는 흐름이 있었습니다. 에이전트는 시스템의 지도를 파악하는 일을 꽤 잘합니다. 에이전트에게 줘야 하는 것은 코드만 봐서는 드러나지 않는 것들입니다. 관례가 있나요? 패턴이 있나요? 코드에 담기지 않은 미묘한 사정이 있나요? 이 부분이 중요하다고 생각합니다.
구체적으로는 이런 것들입니다. 사업이나 팀에 특수한 사정, 시스템이 왜 그런 구조가 되었는지 설명해 주는 트레이드오프, 정적 분석이나 도구로 강제되지 않는 가이드라인, 도메인마다 다른 규칙, 외부에서 걸려 있는 제약, 직관에 어긋나는 구현 뒤에 있는 역사적 배경 같은 것들입니다.
코드가 말해 주지 못하는 것만 적고, 나머지는 적지 마세요.
조사한 내용이 세션보다 오래 남게 하세요
에이전트가 탐색한 결과가 오래 남는 산출물로 이어지지 않으면, 다음 에이전트가 같은 발굴 작업을 다시 해야 합니다.
그 지도에 제가 하나 더 얹고 싶은 것이 오래 남는 조사 산출물입니다. 노랑과 빨강 작업에서는 읽기만 하는 단계를 따로 두고 짧은 이해 메모를 만드는 방식을 선호합니다. 진입점, 담당자, 호출하는 쪽, 이미 있는 추상화, 테스트, 운영 환경의 신호, 관련된 이력, 그리고 아직 풀리지 않은 질문을 담습니다. 메모에 적는 주장은 파일이나 이슈, 담당자 기록, 대시보드를 근거로 제시해야 합니다.
그러지 않으면 기본 루프는 조사한 내용을 그냥 버립니다. 에이전트는 인증 흐름이 어떻게 동작하는지 알아내고, 작업을 마치고, 세션이 끝나면서 그 이해를 잃습니다. 대화 기록은 기록 체계로 쓸 만한 것이 아닙니다. 특히 컨텍스트가 압축된 뒤에는 더 그렇습니다.
조사가 끝나면 저는 컨텍스트를 비운 상태에서 계획을 시작합니다. 후보로 놓은 접근 방식들이 각각 어떤 파일을 건드리는지, 어떤 불변 조건을 지키는지, 되돌릴 방법은 무엇인지 물어보세요. 경로는 사람이 고릅니다. 구현하는 중에 지도가 틀렸다는 것을 발견하면 거기서 멈춰야 합니다. 리뷰는 다시 백지에서 시작해 인수 조건에서 거꾸로 따라 내려갑니다. 컨텍스트가 깨끗한 리뷰어라야 테스트가 요구사항은 놓친 채 구현만 증명하고 있다는 것을 알아챌 가능성이 높습니다.
지시문이 하네스가 되는 순간
같은 지적을 반복하고 있다면, 그만큼 하네스에 빠진 조각이 있다는 뜻입니다.
각 조각이 어디에 들어가는지 분명히 해 두면 도움이 됩니다. 지시문(instructions)은 저장소에 관한 특이한 사실을 기록합니다. 스킬(skills)은 폭발 반경을 확인하거나 스키마 변경을 검증하는 것처럼 되풀이해 쓰는 절차를 하나로 모아 둡니다. 플러그인(plugins)은 담당자 카탈로그나 장애 기록, 대시보드에 통제된 방식으로 접근할 길을 열어 줍니다.
하네스는 에이전트를 둘러싼 작업 환경입니다. 컨텍스트, 도구, 권한, 테스트, 로그, 복구 수단이 여기에 들어갑니다. 팩토리는 믿을 수 있는 루프를 여러 개 스케줄링하고, 상태를 오래 유지하고, 처음 보는 사례는 사람에게 돌려보냅니다.
실질적인 시험대는 에이전트가 무언가를 틀렸을 때 무슨 일이 벌어지는지입니다. 조용히 diff를 손봐서 고치면 다음 세션에서 같은 일이 되풀이될 수 있습니다. 같은 리뷰 코멘트가 또 나왔다면, 그것을 린트 규칙이나 훅, 타입, 테스트, 스킬로 옮기세요. 산문으로 적어 두는 것은 기계적으로 강제할 수 없는 제약에만 쓰세요.
거부 규칙이나 범위가 한정된 자격 증명, CI 검사는 무언가를 기억할 필요가 없습니다. 시간이 지나면 하네스는 팀이 두 번 값을 치르지 않기로 결정한 실패들의 기록이 됩니다.
위험이 없는 작업부터 시작하세요
무엇이든 개선하게 하기 전에, 지금의 동작을 먼저 고정하세요.
이미 있는 코드베이스에 에이전트를 들여오는 일은 다른 현대화 작업과 아주 비슷합니다. 위험이 없는 작업부터 시작하면 좋습니다. 자, 이 모놀리스를 Rust로 다시 쓰자는 식이어서는 안 됩니다. 먼저 이것들이 어떻게 동작하는지 설명해 보라고 하는 편이 낫습니다.
현재 동작을 고정할 수 있는 특성화 테스트를 만들어 두세요.
특성화 테스트는 시스템이 지금 실제로 어떻게 동작하는지를 문서로 남겨, 레거시 코드를 안전하게 리팩터링하거나 변경할 수 있게 해 주는 자동화 테스트다
특성화 테스트란, 그 모듈이 오늘 무엇을 하는지를 못 박아 두는 테스트를 말합니다. 보기 흉한 부분까지 포함해서요. 오래된 시스템에서는 그 흉한 동작이 사업을 떠받치고 있는 경우가 있고, 에이전트는 초록불이 켜진 테스트 뒤에서 그것을 기꺼이 '고쳐' 버리기 때문입니다. 문제가 오래된 것이라서 그 장치도 오래된 것입니다. Netflix는 GraphQL 전환에서 같은 아이디어를 운영 규모로 썼습니다. 트래픽을 옛 경로와 새 경로에 함께 재생하고 흘려보내서 응답을 비교하고, 서로 일치할 때만 새 경로로 승격했습니다. 홈페이지급 화면에 정직한 단위 테스트가 없을 때 쓸 수 있는 승격 경로가 바로 이것입니다. 짐작하지 말고, 둘 다 돌려서 비교하세요.
테스트를 통과시키는 주체가 에이전트라면, 그 테스트를 같은 세션에서 혼자 쓰게 두지 마세요. 별도의 단계로 하거나 사람이 직접 해서 동작을 먼저 못 박고, 그다음에 에이전트를 일하게 하세요. 그러지 않으면 방금 지어낸 구현을 그대로 담아 둔 초록불 테스트만 남습니다.
그다음에 기계적인 변환 작업으로 넘어갑니다. 죽은 코드와 쓰이지 않는 익스포트를 목록으로 정리하는 일도 할 수 있습니다. 시스템에서 가장 까다롭고 지저분한 부분부터 시작하는 것은 피해야 합니다. 그리고 결국 이런 마이그레이션은 어느 것이든 확신을 갖고 해야 합니다.
큰 코드베이스에서 일하는 동안 여러 종류의 마이그레이션을 했던 기억이 있습니다. 이미 망가진 것을 고칠 때조차 사람들은 대단히 조심스럽게 움직였습니다.
제가 일했던 오래된 코드베이스 중 하나는 AOL에 있었습니다. 쉬는 날이었던 어느 날, 사무실 근처 만화책 가게에 가 있었는데 마침 상사에게서 잠깐 들러 줄 수 있느냐는 문자가 왔습니다. AOL.com 홈페이지가 완전히 망가졌는데, 원인을 찾아낼 자바스크립트 전문가가 사무실에 충분히 없었던 것입니다. 그래서 알겠다고, 들어가서 한번 보겠다고 했습니다. 요즘 감각으로는 홈페이지 하나가 뭐 그리 복잡하겠냐고 생각할 수 있습니다. 그런데 수십 개 부서의 사람들이 각자 여러 컴포넌트를 맡고 있고, 서로 다른 조건과 스크립트, A/B 테스트가 얽혀 있으면, 다른 모든 사람의 세상을 깨뜨리는 일은 피해야 합니다. 원하는 만큼 테스트 커버리지가 곳곳에 깔려 있지는 않기 때문입니다. 그때는 문제를 고칠 수 있었지만, 자체 단위 테스트가 없는 것들은 최소한 사용자 관점에서 직접 확인해 봐야 했습니다. 모두에게 문제를 일으키지 않으면서 잘 동작하고 있는지 말입니다. 그 확인이 꽤 중요했습니다.
지금도 일의 본질은 같습니다. 에이전트는 수십 개 부서라는 문제를 지워 주지 않습니다. 그 상황에서 변경을 시도하는 비용을 낮춰 줄 뿐입니다. 운영 트래픽만이 제대로 이해하고 있는 화면은 정의상 빨강 존이고, 그 트래픽을 대신할 장치를 마련하기 전까지는 제가 쉬는 날에 했던 사용자 확인이 여전히 관문입니다.
마이그레이션은 완결된 단위로 하세요
마이그레이션은 새 경로가 동작하고 옛 의존성이 사라졌다는 것을 보여 줄 수 있을 때 끝난 것입니다.
절반만 끝난 마이그레이션은 에이전트를 특히 헷갈리게 만듭니다. 검색해 보면 옛 방식이 파일 40개에서, 새 방식이 12개에서 나오고, 둘 다 현재 방식인 것처럼 보여 주는 심(shim)까지 걸려 있습니다. 에이전트는 서로 모순되는 선례를 보게 됩니다.
파일 30개를 바꿔 놓고 두 패턴을 다 살려 두는 것보다, 라우트 하나를 옛 경로 제거까지 포함해 끝에서 끝까지 마무리하는 편이 낫습니다. 삭제가 나중에 처리할 정리 티켓으로 남아 있다면, 그 마이그레이션 단위는 완결되지 않은 것입니다.
새 구현이 여전히 레거시 구현을 호출하고 있어도 테스트는 초록불을 유지할 수 있습니다. SWE Refactor Bench는 이것을 마이그레이션 '실명(blindness)'이라고 부릅니다. 에이전트 실행 520건 가운데 마이그레이션 감사와 동작 테스트, 독립 검증을 모두 통과한 것은 28건뿐이었습니다.
코드모드(codemod)로 반복적인 변경을 처리할 수 있다면, 에이전트는 그 코드모드를 쓰고 검증하는 일에 활용하세요. 에이전트에게는 예외 처리 대기열을 맡기세요. Stripe의 마이그레이션이 여기서 참고가 되는 이유는 바로 에이전트가 전혀 관여하지 않았다는 점입니다. 오래 남은 산출물은 마이그레이션을 수행하는 기계 장치였습니다.
더 큰 마이그레이션에서 얻는 교훈
Bun이 Zig에서 Rust로 포팅한 작업은 53만 5천 줄 규모의 코드베이스를 대상으로 11일 동안 워크플로 약 50개를 돌렸습니다. 생성된 단위마다 서로 반대편에서 따지는 리뷰어를 둘씩 붙이고, 이미 있던 테스트 스위트 전체를 머지 관문으로 삼았습니다. 여기서 따라 할 만한 대목은, 에이전트를 한 번도 돌리기 전에 Zig 관용구를 Rust로 어떻게 옮길지 정리한 포팅 가이드에 몇 시간을 들였다는 점입니다. Anthropic이 쓰는 마이그레이션 절차는 버릴 셈으로 만든 소규모 마이그레이션에 규칙집을 먼저 걸어 시험해 보고, 본격적인 실행을 시작하기 전에 그 시험 결과물은 버립니다.
VB6에서 C#으로 옮긴 통제 연구에서는 단순한 기능의 동작 일치율이 92퍼센트, 복잡한 기능은 47퍼센트로 측정됐습니다. 결국 단위 크기가 레버입니다. 이런 양상은 에이전트가 등장하기 전부터 있었습니다. Stripe는 에이전트 없이 몇 달에 걸친 코드모드 작업으로 370만 줄을 단 하나의 PR로 TypeScript로 옮겼고, Google의 대규모 변경을 다룬 장은 코드베이스가 커질수록 한 번에 원자적으로 바꿀 수 있는 범위가 왜 줄어드는지 설명합니다. Spotify는 몇 해 전에 Backstage로 깔아 둔 레일 위에서 지금 매달 650건이 넘는 에이전트 PR을 머지한다고 밝힙니다.
Asana는 몇 년째 밀려 있던 Enzyme 관련 백로그를 달력상 2주 만에, 모델과 인프라 비용 약 1만 2천 달러로 정리했습니다. 이 1만 2천 달러는 토큰 청구서일 뿐이고, 장부에 올라 있던 5년치 인력 추정치를 대체하는 숫자는 아닙니다. 통제된 절감 효과 연구가 아니라 벤더가 보고한 생성 비용으로 받아들이는 게 맞습니다. 여기서 옮겨 쓸 수 있는 부분은 Bun과 같습니다. 범위가 좁은 기계적 마이그레이션, 이미 갖춰져 있던 테스트 스위트, 그리고 모든 변경을 여전히 사람이 리뷰한다는 것입니다.
회사에서 회사로 옮겨 갈 수 있는 것은 에이전트를 둘러싼 구조입니다.
실제로 달라진 것
에이전트는 그럴듯한 구현을 여러 개 시도해 보는 값을 바꿔 놓았습니다. 그중 하나를 고를 때 필요한 근거는 바꾸지 못했습니다.
아마 보셨을 텐데, 올해는 자리를 잡은 기업들이 에이전트를 써서 큰 재작성을 진행한 사례를 점점 더 많이 읽게 됩니다. 저는 팀이 에이전트로 서로 다른 언어나 프레임워크로 재작성을 여러 번 시도해 보게 허용하는 CTO들과도 이야기를 나눴습니다. 이제는 그렇게 해 보고 트레이드오프를 따져 보는 일을 훨씬 싸게 할 수 있기 때문입니다.
Shopify는 소비자용 Shop 앱을 React Native에서 네이티브 Swift와 Kotlin으로 12주 만에 다시 만들었습니다. 소규모 팀이, 화면 하나 크기의 체크포인트마다 에이전트가 관문을 지키는 방식으로 진행했습니다. 훨씬 큰 판매자용 앱은 여전히 브라운필드 문제로 남아 있습니다. 화면이 수백 개고, 플랫폼과 깊게 얽혀 있으며, 관문은 같지만 걸리는 시간은 더 깁니다.
Rust로 재작성한 다른 사례도 보셨을 것입니다. 프레임워크 수준의 마이그레이션도 보셨을 것입니다. 온갖 종류의 마이그레이션이 진행됐습니다. 그리고 많은 경우 이들은 원래라면 훨씬 긴 기간에 걸쳐 했을 마이그레이션입니다. 요즘은 토큰이 넉넉하다면, 여러 스택이나 언어에 걸친 마이그레이션을 에이전트가 직접 끝까지 시도해 보게 할 수 있습니다.
서로 경쟁하는 선택지 여러 개로 같은 기능을 실제로 구현해 보게 할 수도 있습니다. 한 팀이 하나의 선택지를 골라 거기에 모든 것을 걸게 하는 대신, 전부 다 구현하게 하는 것입니다. 모두 여러분의 단위 테스트로 검증할 수 있습니다. 전부 성능 프로파일링을 해 보고 나서 결정을 내릴 수 있는데, 경우에 따라 예전보다 훨씬, 훨씬 싸게 할 수 있는 방법입니다. 요즘 팀들에게는 이것이 완전히 다른 게임이라고 생각합니다.
병렬화는 맨 나중에
생성되는 코드가 많아지면 사람의 리뷰는 더 선별적이어야 하고, 사람이 지는 책임이 줄어들어서는 안 됩니다. 루프와 목표, 병렬화를 고민하는 길로 들어서기 전에, 브라운필드 프로젝트가 성공할 발판이 무엇인지 진지하게 따져 보세요.
소프트웨어 팩토리는 여러 변경을 한꺼번에 돌릴 수 있습니다. 저라면 단위 하나가 믿을 만한 판정 장치와 복구 경로, 사람이 소화할 수 있는 리뷰 형식을 갖춘 다음에야 그 방식을 가져올 것입니다.
병렬화는 이미 있는 병목을 몇 배로 키웁니다. 자동 검증은 검사를 거친 변경 다섯 건도 감당할 수 있습니다. 반면 모든 줄을 읽는 시니어 한 명에게는 대기열이 쌓이고, 주의가 흩어지고, 결국 형식적인 승인만 남습니다.
저는 자동 리뷰가 의도, 달라진 불변 조건, 테스트 결과, 동등성 비교에서 어긋난 지점, 되돌릴 경로를 먼저 보여 주는 쪽을 선호합니다. 전체 diff는 그대로 볼 수 있게 남겨 둡니다. 사람의 주의는 폭발 반경이 가장 크고 판정 근거가 가장 약한 곳에 먼저 갑니다.
워크트리는 변경을 격리하지만 동작을 격리하지는 않습니다. Git 메타데이터와 자격 증명, 로컬 서비스, 네트워크 접근은 공유될 수 있습니다. 신뢰할 수 있는 작업이라면 그 트레이드오프를 받아들일 만합니다. 신뢰할 수 없는 콘텐츠를 다루면서 사람이 지켜보지 않는 에이전트에게는 더 강한 샌드박스와 범위가 한정된 자격 증명이 필요합니다.
에이전트는 애매함에 값을 매깁니다
생성된 줄 수는 코드베이스가 나아졌는지 알려 주지 않습니다. 저라면 리드 타임, 리뷰에 쓴 시간, 사람이 개입한 횟수, 빠져나간 결함, 롤백, 판정 기준과 어긋난 건수, 그리고 뒤에 남겨 둔 경고 억제를 추적할 것입니다.
마이그레이션이라면 남아 있는 옛 임포트, 새 경로가 처리하는 트래픽, 동등성 비교에서 어긋난 지점, 제거한 레거시 의존성을 추적하세요. 모든 트래픽이 여전히 옛 경로로 흐르는데 테스트만 초록불인 상태는 헛일입니다.
에이전트는 애매함에 눈에 보이는 값을 매깁니다. 구성원끼리 암묵적으로 공유하던 관례는 되풀이되는 리뷰 코멘트로 드러납니다.
그 비용은 원래도 있었고, 온보딩과 리뷰, 장애 복구 과정에서 치러 왔습니다. 에이전트는 그 비용을 더 많이 셀 수 있게 만듭니다. 그러면 팀이 이미 가치 있다고 알고 있던 유지보수 작업을 주장할 근거가 더 강해집니다.
다음번에 에이전트가 그 홈페이지에 해당하는 작업을 맡는다면, 저는 수리한 결과만 남기지 않기를 바랍니다. 합성한 사용자 여정과 담당자 기록, 회귀 테스트까지 남기기를 바랍니다.
다음 엔지니어와 다음 에이전트가 무엇을 물려받는지도 중요합니다.