AI가 짓는 집, 설계도는 누가 그리나…AI 코드 시대의 거버넌스 설계
필자가 데브옵스 기업에 가장 먼저 묻는 질문은 개발 및 운영 표준에 관한 것이다. 타협할 수 없는 데브옵스 관행은 무엇인가? 데이터 거버넌스의 제1원칙은 무엇인가? 어떤 관찰가능성 표준이 적용되는가? 보안이 어떻게 데브옵스에 내장되는가? 이런 질문을 출발점으로 해서 예를 들어 기능 요구사항을 작성하는 방법에 관한 표준을 검토할 수 있다. AI 에이전트를 개발하는 기업이라면 비기능 요구사항(NFR)과 테스트 수행 방법을 묻는다.
많은 데브옵스 기업이 AI 코드 생성기와 바이브 코딩을 사용하고 사양 주도 개발 방식을 적용하면서 질문도 함께 늘어나고 있다. AI가 기업의 표준을 어떻게 인지하는가? 이런 표준을 모니터링하고 강제하는 프로세스는 무엇인가? 결과에 대한 개발자의 책임은 무엇인가?
블루미라(Blumira)의 보안 및 IT 담당 디렉터인 마이크 툴은 “생성형 AI가 건네는 것은 진짜 집처럼 보이는 영화 세트다. 문과 창문이 열리고 데모도 문제없이 실행된다. 그러나 벽 뒤에는 배관이나 배선, 즉 입력 검증도, 인증 경계도 없다. 집을 지탱하는 것이 아무것도 없다. ‘실행이 잘 되고, 괜찮아 보이는가?’만 묻는다면 결국 실제 건물이 아니라 세트를 얻게 된다”고 말했다.
한 보고서에 따르면 2026년 현재 개발자의 92%가 매일 AI 코딩 툴을 사용하며, 전 세계 코드의 41%가 AI로 생성된다. 이 모든 코드가 제공하는 것은 가치일까, 운영 문제일까, 아니면 AI 부채일까? AI로 생성된 코드를 기업의 표준에 맞게 유지하는 방법, AI 코드 생성기의 컨텍스트를 단순한 기능 요구사항 이상으로 정의하는 방법에 대해 여러 전문가의 의견을 들어봤다.
공사 시방서처럼 문서화하기
건축에서 원청 업체는 현재 개발 중인 대상을 보여주는 건축정보모델(BMI)을 살펴본다. 그러나 구성요소 규정과 성능 요구사항이 포함된 많은 세부사항은 공사 시방서에 들어간다. AI 이전 시대의 데브옵스 팀은 기업과 아키텍처, 애플리케이션에 상응하는 문서를 마련하지 않았다 해도 대충 넘어갈 수 있었다. 그러나 AI 코드 생성기에는 기능 프롬프트에 앞서 기관 지식과 규정준수 요구사항이라는 컨텍스트가 필요하다.
글린(Glean)을 창업한 엔지니어 에디 저우는 “AI로 생성된 코드가 엔지니어링 표준에 맞게 유지되기 위해서는 표준이 명시적이고 사용 가능하며 우회하기 어려워야 한다. 아키텍처, 승인된 라이브러리, 데이터 취급 규칙, 보안 통제, 명명 규칙, 관찰가능성, 테스트 기대 사항, 비기능 요구사항을 사양과 자동화된 검사에 포함해야 한다. 그런 다음 모델에 이 컨텍스트를 제공하되, 사람이 작성한 코드에 대해 실행하는 것과 동일한 검토, 테스트, 스캔, 프로덕션 모니터링을 통과하기 전까지는 그 출력을 신뢰할 수 없는 것으로 취급해야 한다”고 말했다.
부족 지식(tribal knowledge)은 항상 까다로운 과제였다. 기능 출시에 대한 압박을 받는 데브옵스 팀 상황에서 문서화를 충실히 유지할 만한 유인 요소는 거의 없기 때문이다. 데브옵스 팀은 AI 역량을 도입하는 동시에 실행 방식도 맞춰야 한다는 면에서 필자가 생각하는 가장 중요한 AI 리더십 스킬 두 가지는 변화 관리와 애자일 협업 리더십이다.
저우는 “AI는 좋은 엔지니어링을 증폭하지만 모호성과 취약한 거버넌스 역시 똑 같은 효율로 증폭한다. 표준이 부족 지식에만 존재한다면 AI는 그 문제를 해결하는 것이 아니라 드러내는 역할을 하게 된다”고 덧붙였다.
비기능 요구사항을 자동화된 테스트로 코드화
요구사항 문서와 참조 아키텍처의 문제는 인간 또는 AI 개발자에게 직접적으로 강제할 수 없다는 점이다. 데브옵스 팀이 표준에 합의하고 이를 문서화한다면 다음 단계는 이를 CI/CD 파이프라인의 자동화된 승인 기준으로 코드화하기 위한 접근 방식을 개발하는 것이다.
어뎁티아(Adeptia)의 AI 제품 관리 부사장인 마이클 베빌라쿠아는 “AI 코드 생성기와 인간 개발자는 기능적 정확성, 즉 기능이 작동하도록 하는 데 주력하면서 성능, 보안 태세, 오류 처리, 관찰가능성, 감사 가능성을 비롯한 실질적인 표준의 대부분이 포함된 비기능 요구사항은 조용히 생략한다. NFR을 실행 가능한 승인 기준으로 코드화해서 생성된 코드가 이 기준을 통과한 후에 병합되도록 해야 한다. 이렇게 하면 파이프라인은 모든 변경 사항에 ‘표준 부합’이라는 관문을 적용하게 된다”고 말했다.
예들 들어 모든 웹 페이지에 대해 총 페이지 용량이 2MB 미만이어야 한다는 성능 요구사항은 풀 요청 중에 검증이 가능하며, 첫 바이트까지의 시간(TTFB)을 800ms 미만으로 요구하는 조건은 스테이징 환경의 CI/CD에서 자동화할 수 있다.
이해관계자와 AI를 위한 요구사항
성능과 보안, 기타 기업 수준의 규정준수 요구사항을 다루는 아키텍처와 자동화된 비기능 요구사항은 AI 코드 생성기와 공유하는 기본적인 수준의 컨텍스트 표준이 되어야 한다. 정확한 컨텍스트를 설정하기 위한 다음 고려 사항은 애플리케이션 및 에이전트별 요구사항, 각각의 의도된 사용례, 구체적인 규정준수 가드레일부터 시작된다.
페가시스템즈(Pegasystems)의 제품 전략 및 마케팅 부문 디렉터인 맷 힐리는 “CIO들은 AI에 더 빠르게 앱을 구축하도록 지시하지만 많은 이가 속도가 병목 지점이 아니라는 사실을 깨닫고 있다. 코드가 많다고 해서 비즈니스 가치가 저절로 창출되지는 않기 때문이다. 개발자가 코드를 작성하기 전에 기업은 고객의 요구를 이해하고 레거시 시스템을 평가하고 최신 규정과 모범 사례를 파악하고 엔터프라이즈 아키텍처와 통합을 매핑하고 비즈니스와 IT를 정렬해야 한다”고 말했다.
이때 요구사항 이해의 3단계를 고려해야 한다. 이해관계자가 비즈니스 가치와 의도를 정하면 개발자는 먼저 구현 전략을 도출하고 성능, 비용, 기타 절충점을 논의하고, 이후 이해관계자와 다시 만나 구현 절충점을 검토해야 한다. 힐리는 “대규모 프로젝트에서는 솔루션과 성공 지표를 정의하는 데 구축 작업 못지않은 시간이 걸릴 수 있다. 리더는 단순히 개발 속도를 높이기 위해서가 아니라 경영진, 비즈니스 애널리스트, 제품 책임자, IT 팀이 더 효과적으로 협업하도록 지원하기 위해 AI를 사용하고 있다”고 덧붙였다.
세 번째 단계는 목표, 사용자 요구사항, 구현 접근 방식을 개발 컨텍스트로 취합하는 것이다. 그러나 여기서 끝나지 않는다. 데이터 요구사항과 운영상의 고려사항도 AI 코드 생성기에 제공하는 컨텍스트에 포함해야 한다.
거버넌스를 사양 안에 구축
개발 중인 애플리케이션이나 AI 에이전트가 액세스 가능한 데이터를 사용하는 방법에 관한 명확한 사양이 필요하다. 데이터 거버넌스 프로그램에는 데이터 세트, 정의된 역할, 자격, 사용 사양을 기반으로 하는 표준이 있어야 한다.
렐티오(Reltio)의 부사장 겸 CTO인 캐시 메흐디는 “앞서 나가는 팀은 데이터 거버넌스를 사후 감사가 아니라 AI에 대한 입력으로 취급한다. 이들은 신뢰할 수 있고 의미적으로 일관적인 데이터 모델, 승인된 사양, 그리고 보안 정책을 툴의 기반으로 삼아 AI가 임의로 표준을 만들어내지 않고 기업의 표준을 상속하도록 한다. 이 거버넌스 컨텍스트 계층이 없으면 소수의 AI 지원 워크플로우를 수천 개로 확장할 수 없고, 비일관적인 코드를 더 빠르게 축적하게 될 뿐”이라고 말했다.
표준을 만들 때 고려할 옵션은 두 가지다. 첫째, 용도 변경이 가능한 데이터 세트를 통합 및 사용 규칙이 정의된 데이터 제품으로 구축한다. 데이터 세트와 통합 지점이 많은 기업은 데이터 패브릭을 고려해야 한다. 둘째이자 핵심적인 요구사항은 사람과 기계가 읽을 수 있는 형식으로 데이터 계약의 형식을 표준화해서 데이터 소유자, 사용자, AI 코드 생성기가 일관된 원칙 모음을 기반으로 움직이도록 해야 한다.
TiDB의 공동 창업자 겸 CEO인 에드 황은 “AI는 컴파일되고 테스트를 통과하는 코드를 작성하지만 데이터 계약을 무시하기 때문에 문제 발생 시 빌드 오류가 아니라 프로덕션에서 손상된 상태로 나타나게 된다. 해결책은 스키마 제약 조건, 액세스 정책, 데이터 품질 규칙 등을 모델이 읽지 않는 위키에 문서화하는 것이 아니라 AI가 우회할 수 없는 데이터베이스 계층에 적용해서 거버넌스를 기계가 검사할 수 있도록 만드는 것이다. 데이터베이스를 표준 강제 지점으로 취급하면 쿼리를 작성한 주체가 인간인지 에이전트인지는 더 이상 중요하지 않게 된다”고 말했다.
관찰가능성과 테스트를 우선시
AI가 코드를 생성할 때 모범 사례는 정적 애플리케이션 보안 테스트(SAST)와 기타 코드 분석 툴을 사용해 자동화된 코드 검토를 수행하는 것이다. 또 다른 모범 사례는 애플리케이션을 대상으로 침투 테스트와 기타 애플리케이션 보안 검증을 수행하는 것이다. 그러나 AI가 개발한 코드 관점에서 이런 툴의 상당수는 외부에 존재한다. 내부 시야를 위해서는 관찰가능성과 테스트 요구사항을 표준으로 포함하고, AI에 개발을 맡긴 핵심 트랜잭션에 대한 구체적인 요구사항을 명시해야 한다.
코스모스(Kosmos)의 CEO 겸 창업자인 산제이 기드와니는 “코드의 양이 많아지면 조사에 더 많은 시간이 소요되는데, 해결책은 배포하기 전에 코드를 더 신중하게 살펴보는 것이 아니라 관찰가능성 신호, 즉 문제가 발생한 요소를 그 문제를 일으킨 구체적인 변경 사항과 연결하는 것이다. 이 연결 고리가 없으면 과거와 똑같은 수동 조사를, 더 많은 코드를 대상으로 하게 될 뿐”이라고 말했다.
테스트 요구사항은 자동화된 테스트를 생성하고 합성 데이터를 사용해 테스트 패턴을 확장하고 지속적 테스트를 구현하는 데 그쳐서는 안 된다. 몬테 카를로(Monte Carlo)의 공동 창업자 겸 CTO인 리오 가비시는 “하나의 출력에 대해 하나의 입력을 테스트하는 것이 아니라, 광범위하게 생성된 입력에 걸쳐 불변성이 유지되는지를 테스트해야 한다. 이는 AI의 무한한 입력 공간과 비결정적 출력에 잘 맞는 방식이다. 나는 이를 스택의 한 계층으로 취급하면서 평가를 통해 입력 공간을 매핑하고 속성 기반 테스트를 통해 엣지 케이스와 취약성에 대한 스트레스 테스트를 수행하고 라이브 트래픽에 대한 관찰가능성으로 프로덕션이 협상 불가능한 조건으로 정의해둔 속성에서 벗어나는지 여부를 확인한다”고 말했다.
표준 패키징과 발전
앱파이어(Appfire)의 CTO 에드 프레데리치는 린터, 포매터, 타입 검사를 포함한 표준을 기계가 읽을 수 있는 규칙으로 코드화할 것을 권장한다. 기업 및 애플리케이션 표준을 AI 코드 생성 툴과 공유하는 하나의 컨텍스트로 병합한다. 그 외에 프레데리치가 권장하는 사항은 다음과 같다.
- 지속적 통합에서 표준을 강제해 위반 발생 시 병합이 차단되도록 한다.
- AI에 CLAUDE.md, 스타일 가이드, 아키텍처 문서와 같은 지속적인 컨텍스트를 제공한다.
- 변경 사항을 작고 검토 가능하도록 유지한다.
- 모든 풀 요청에 대해 사람의 검토를 의무화한다. AI가 생성한 코드도 다른 기여자가 작성한 코드와 동일한 수준의 철저한 검토를 예외 없이 받아야 한다.
- 퇴행을 포착하기 위한 견고한 테스트 커버리지로 이 접근 방식을 뒷받침한다.
- 표준이 발전함에 따라 정기적으로 표준 이탈 여부를 감사한다.
코드는 확장과 유지관리가 필요하다. 그 기반이 되는 개발 표준도 마찬가지임을 기억하는 것이 중요하다. 코도(Qodo)의 CEO 겸 공동 창업자인 이타마르 프리드먼은 “AI로 생성된 코드는 정적인 규칙 스냅샷이 아니라 지속적으로 학습하는 컨텍스트 엔진에 의해 구동될 때만 표준 준수 상태를 유지한다. 이는 코드베이스의 발전하는 표준, 팀의 PR 이력, 엔지니어들이 이미 내린 이전 의사결정에 지속적으로 적응하는 엔진을 의미한다. 이를 통해 AI는 단순히 지침을 따르는 것이 아니라 실제 팀의 작업 방식을 이해하게 된다”고 말했다.
