코드는 풍부하지만, 신뢰는 공식이다

AI는 코드 생성을 풍부하게 만들 수 있습니다. 더 어려운 과제는 배포되는 결과물에 대한 신뢰를 구축하는 것입니다.

AI는 소프트웨어 개발의 경제학을 변화시켰습니다. 한때 몇 시간의 구현이 필요했던 작업이 이제 에이전트가 몇 분 만에 초기 솔루션을 생성하면서 시작될 수 있습니다. 에이전트들이 리포지토리 전체에서 코드를 변경하거나, 서비스를 리팩토링하고, 테스트를 작성하며, 풀 리퀘스트(pull request)를 준비하는 등 더 광범위한 작업을 맡게 되면서, 출력량은 계속해서 증가할 것입니다.

이는 엄청난 기회이며, 동시에 엔지니어링 조직의 다음 과제는 코드를 더 많이 생성하는 것이 아니라 프로덕션에 도달하는 코드에 대한 신뢰를 구축하는 것임을 의미합니다. 에이전트 기반 소프트웨어 공장에서는 에이전트들이 사람이 한 줄씩 검토할 수 있는 속도보다 빠르게 변경 사항을 작성하고, 테스트하며, 제안합니다.

코드 생성은 풍부해지고 있지만, 코드의 신뢰는 그렇지 않습니다.

이러한 구분은 중요합니다. 완료된 풀 리퀘스트가 믿을 만한 결과와 같지 않기 때문입니다. 코드는 컴파일되고 좁은 테스트 스위트(test suite)를 통과할 수 있지만, 여전히 아키텍처 규칙을 위반하거나, 보안 취약점을 도입하거나, 기존 기능을 중복하거나, 나중에 드러나는 유지보수 비용을 발생시킬 수 있습니다. 조직이 변경 사항을 더 빠르게 생성할수록, 모든 문제를 포착하기 위해 영웅적인 노력과 수동 검토에만 의존하는 것은 점점 더 어려워집니다.

앞으로 나아갈 방향은 코드 신뢰를 소프트웨어 전달 시스템에 설계할 수 있는 무언가로 취급하는 것입니다. 유용한 공식은 **의도(Intent) × 가이드레일(Guiderails) × 검증(Verification) × 증거(Evidence)**입니다. 그리고 네, 여기서 곱셈 기호는 의도적입니다. 이 네 가지 요소 각각이 중요합니다. 세 가지에서 오는 강점만으로는 네 번째 요소의 약점을 만회할 수 없습니다.

검증 없이 명확한 의도는 실수를 막지 못합니다. 증거 없이 강력한 검증은 책임성을 창출하지 못합니다. 명확한 의도 없이 가이드레일은 단순히 모호함을 자동화할 뿐입니다. 독립적인 검증 없이 증거는 에이전트가 주장한 것에 대한 기록일 뿐입니다.

공식의 각 부분이 실제적으로 무엇을 의미하는지 설명하겠습니다.

의도(Intent): 표준을 명시적으로 만들기

에이전트는 명시된 목표를 추구하는 데 놀라울 정도로 능숙합니다. 하지만 '결제 기능을 구축하라' 또는 '이 서비스를 현대화하라'는 프로덕션 코드베이스에 충분한 목표가 아닙니다. 조직이 정의하는 좋은 소프트웨어에는 비즈니스 로직, 보안 기대치, 디자인 패턴, 성능 요구 사항, 의존성, 그리고 수년간 축적된 컨벤션 등 훨씬 더 많은 것이 포함됩니다.

의도(Intent)는 이러한 기대치를 명시적으로 만드는 학문입니다. 이는 에이전트가 작업을 시작하기 전에 변경의 목표와 충족해야 할 표준을 정의하는 것을 의미합니다. 컨텍스트가 좋을수록 에이전트가 그럴듯하지만 부적합한 답변을 생성하는 사이클이 줄어들고, 나중에 개발자에게 돌아오는 재작업(rework)도 적어집니다.

가이드레일(Guiderails): 위험을 만들기 전에 작업을 형성하기

가이드레일은 의도를 에이전트가 작동하는 방식을 안내하는 경계로 변환합니다. 이는 허용되는 저장소, 의존성, 데이터 또는 액션을 정의할 수 있으며; 인간의 승인이 필요한 지점을 지정하고; 주어진 코드 클래스에 적용되는 정책을 규정할 수 있습니다.

그 목적은 모든 유용한 행동을 제약하는 것이 아닙니다. 에이전트가 생산적이고 예측 가능하게 작동할 만큼 충분한 구조를 제공하는 것입니다. 잘 설계된 가이드레일은 팀들이 더 많은 자율성을 안전하게 부여하도록 하여, 모두가 그 자율성이 적용되는 조건을 이해하기 때문입니다.

그 결과는 반복 가능한 자율성(repeatable autonomy)입니다. 모든 에이전트 주도 변경을 일회성 실험으로 취급하는 대신, 팀들은 일관된 경계를 적용하고 자신감을 가지고 에이전트 개발을 확장할 수 있습니다.

검증(Verification): 모든 변경 사항을 독립적으로 확인하기

검증은 신뢰가 테스트되는 곳입니다. 에이전트가 증가하는 규모로 코드를 생성함에 따라, 올바름(correctness), 신뢰성(reliability), 보안(security), 유지보수성(maintainability), 그리고 조직 자체의 표준 준수와 같은 중요한 품질들에 대해 모든 변경 사항은 일관된 평가를 받아야 합니다.

독립성이 필수적입니다. 모델이 자체 작업을 검토하는 데 도움을 줄 수는 있지만, 조직은 변경 사항을 생성한 것과 동일한 확률론적 시스템에만 의존하여 해당 변경 사항을 배포해도 안전한지 판단해서는 안 됩니다. 반복 가능하고 독립적인 확인 절차는 모델, 에이전트 및 툴체인 전반에 걸쳐 공통 표준을 제공합니다. 이는 특히 AI 도구 자체가 빠르게 진화하는 경우 더욱 중요합니다.

검증은 느리고 최종적인 검문소가 아니라 작업 흐름 내에서 발생해야 합니다. 목표는 에이전트나 개발자가 여전히 해결하는 데 필요한 컨텍스트를 가지고 있을 때, 문제의 근원에서 식별하고 수정하는 것입니다.

증거: 신뢰도를 가시적이고 감사 가능하게 만들기

변경 사항은 의도가 좋고, 세심하게 관리되었으며, 철저히 검사될 수 있습니다. 하지만 엔지니어링 리더, 감사자(auditors), 그리고 프로덕션에 책임이 있는 팀들은 여전히 무슨 일이 일어났는지, 그리고 왜 그런 일이 일어났는지를 알아야 합니다. 증거가 바로 지속적인 기록입니다: 어떤 표준이 적용되었는지, 무엇이 검사되었는지, 무엇이 발견되었는지, 그리고 문제가 어떻게 해결되었는지.

이는 복잡하고 규제가 많은 환경에서 가장 중요하지만, 어디서든 가치가 있습니다. 증거는 품질을 측정 가능하게 만들고, 팀들이 시간이 지남에 따라 자신들의 관행을 개선할 수 있게 하며, 조직에게 신속하게 움직일 수 있는 방어 가능한 근거를 제공합니다.

신뢰도를 중심으로 공장 구축하기

에이전트 기반 소프트웨어 개발의 가장 유망한 비전은 사람들이 프로세스에서 사라지는 것이 아닙니다. 사람, 에이전트, 그리고 검증 시스템 각각이 그들의 강점을 기여하는 것입니다. 에이전트는 실행을 가속화하고, 엔지니어는 판단력과 방향성을 제공합니다. 배포 시스템(delivery system)은 자율성이 확장될 수 있도록 표준, 통제, 증거를 공급합니다.

성공할 조직은 모든 변경 사항에, 어떤 규모로든, 에이전트 속도로 코드를 신뢰 가능하게 구축하는 조직일 것입니다.

그것이 바로 조직이 자신들이 책임질 수 있는 소프트웨어를 생산하는 에이전트 기반 소프트웨어 공장의 진정한 작업입니다.

다음번에 에이전트가 풀 리퀘스트(pull request)를 열 때, 네 가지 질문부터 시작하세요:

• 에이전트는 시작하기 전에 귀사의 표준을 알고 있었나요?
• 무엇에 접근할 수 있도록 허용되었고, 어떤 것은 인간의 결정이 필요했나요?
• 변경 사항을 작성한 모델 외에 다른 것이 그것을 확인했나요?
• 발견된 것과 그것이 어떻게 해결되었는지 보여줄 수 있나요?

답변이 '아니요'인 곳에 바로 귀사의 신뢰 격차(confidence gap)가 존재합니다. 그곳부터 먼저 메우세요.