8월 30일 일요일
에이전트가 더 많은 코드를 만드는 시대의 병목은 생성량이 아니다. 명세를 먼저 고정하고, 값싼 결정적 검사부터 수학적 증명까지 검증의 층을 설계하는 일이 핵심이다.
코드 생성 속도보다 먼저 쌓아야 할 검증 스택
Figma의 조직 경험, 스펙 주도 개발, 형식 검증을 한 흐름으로 연결하면 에이전트에 무엇을 맡기고 어떤 게이트에서 멈출지 선명해진다.
작은 성공을 큰 작업에 복사하면 품질이 무너진다
Figma가 설명한 에이전트 도입은 세 단계로 진행된다. 작고 명확한 작업에서는 큰 속도 향상을 경험하지만, 같은 방식을 큰 문제에 적용하면 버그와 나쁜 코드가 늘며 신뢰가 꺾인다. 그 뒤에야 팀은 프롬프트, 컨텍스트, 가드레일, 검증 절차를 함께 설계하는 법을 배운다. 핵심 투자는 생성 능력을 더하는 것이 아니라 사람이 반복하던 확인을 린터·컴파일러·단위 테스트 같은 결정적 검사로 앞당기는 일이다. 이미 알고 있고 테스트로 표현 가능한 절차는 매번 모델이 추론하게 두지 않고 자동화해야 토큰과 시간, 결과 변동성을 함께 줄일 수 있다. 사람은 기계적으로 확인 가능한 항목이 아니라 실제 기능과 사용자 경험, 무엇을 만들 가치가 있는지 판단하는 상위 계층에 남는다.
프롬프트가 아니라 저장소의 명세가 변경의 기준점이 된다
스펙 주도 개발은 일회성 지시 대신 헌법, 명세, 계획, 태스크를 저장소에 남긴다. 헌법은 프로젝트가 쉽게 바꾸면 안 되는 원칙을 고정하고, 명세는 구현 방법과 분리해 무엇과 왜를 정의한다. 계획은 기술 선택과 구조를 결정하며, 태스크는 독립적으로 구현·검토할 수 있는 단위로 이를 쪼갠다. 이 순서는 단순한 문서 양식이 아니다. 코드가 먼저 나오고 테스트가 뒤따를 때 생기는 사후 정당화를 줄이고, 에이전트가 긴 작업 중 목적에서 벗어났는지 비교할 기준을 제공한다. 작은 실제 기능 하나에서 시작해 산출물을 검토하고, 반복해서 배운 규칙을 헌법과 명세에 되돌려 넣어야 문서가 살아 있는 검증 입력이 된다.
테스트의 표본을 넘어 모든 입력의 보증이 필요한 곳
테스트는 선택한 사례에서 동작을 확인하지만, 형식 검증은 명세를 논리식으로 표현하고 구현이 모든 가능한 입력에서 그 명세를 만족하는지 증명하는 접근이다. Lean4는 정의와 증명을 같은 언어에서 다루고 작은 커널이 증명 결과를 확인한다. Rust 코드에는 Verus가 사전 조건과 사후 조건을 두고 solver와 연결하며, Eneus는 Rust를 Lean의 함수적 표현으로 옮기는 흐름을 다룬다. 그렇다고 모든 코드를 한꺼번에 증명해야 한다는 뜻은 아니다. 압축 라이브러리나 권한 정책처럼 실패 비용이 크고 계약을 명확히 쓸 수 있는 핵심 경로부터 고르는 것이 현실적이다. 이 층에서도 사람이 소유해야 할 것은 명세다. 틀린 요구를 완벽히 증명하면 구현과 증명이 모두 통과해도 제품은 틀릴 수 있다.
개인의 좋은 프롬프트를 조직의 실행 자산으로 바꾸기
스킬은 반복 가능한 노하우의 단위가 될 수 있지만, 레지스트리·소유권·평가·권한 통제가 없으면 새로운 기술 부채가 된다.
에이전트 워크플로를 여러 팀으로 확장할 때 무엇을 표준화하고 무엇을 분리해야 하는가?
에이전트의 안쪽 루프는 컨텍스트, 도구·MCP, 메모리, 스킬을 조립해 한 작업을 수행한다. 바깥쪽 워크플로는 스킬과 서브에이전트, 훅, MCP 서버를 어떤 순서와 조건으로 사용할지 정한다. 여기서 조직의 방법론과 판단 기준을 담는 핵심 단위가 스킬이다. 도구 연결만 제공하면 언제 어떤 기준으로 호출할지 매번 다시 해석해야 하고, 서브에이전트만 늘리면 컨텍스트는 나눌 수 있어도 노하우의 일관성은 생기지 않는다. 스킬은 한 과업에 전문화되고 다른 하네스로 옮길 수 있으며, 여러 워크플로에서 조합 가능해야 한다. 이 구분은 코딩 흐름만 봐서는 잘 드러나지 않는다. 실제 제품 생명주기는 전략, 시장조사, 고객 발견, 데이터 준비, 개발, 인프라 운영, 출시, 최적화와 장애 대응까지 이어진다. 조직마다 이 순서와 시스템이 다르므로 하나의 만능 워크플로를 강요할 수는 없다. 대신 각 단계에서 반복되는 전문 판단을 작고 이동 가능한 스킬로 만들고, 필요한 흐름에서 조합하는 편이 변화에 강하다.
- 01
발견과 버전
팀이 만든 스킬을 중앙 레지스트리에서 찾고 검증된 버전을 가져갈 수 있어야 한다. 이름만 비슷한 중복 스킬이 늘면 어떤 규칙이 최신인지 알 수 없고, 토큰 비용과 결과 차이가 함께 커진다.
- 02
평가와 관찰성
스킬 적용 전후의 결과를 평가하고 실패 경로를 관찰해야 한다. 같은 입력에서 일관된 절차를 따르는지, 품질 기준을 통과하는지 확인할 수 없다면 재사용성은 문서 복사에 그친다. 모델 자체의 성능 향상과 스킬이 더한 효과도 분리해 봐야 어떤 투자가 실제 개선을 만들었는지 알 수 있다.
- 03
소유권과 권한
도메인 소유자가 규칙의 의미와 변경을 책임하고, 중앙 플랫폼은 접근 제어와 배포 경계를 제공해야 한다. 스킬이 불필요하게 넓은 도구 권한을 얻으면 편리함이 보안 위험으로 바뀐다. 자동으로 진화하는 스킬도 변경 근거와 평가 결과를 남기고 승인된 버전으로 배포해야 하며, 편리한 자기 수정이 검토와 책임을 우회하지 않게 해야 한다.
표준화의 대상은 모든 팀의 업무 방식이 아니라, 반복해서 재사용할 판단과 품질 게이트다. 조직마다 다른 제품 생명주기는 별도 워크플로로 두고, 검증된 스킬을 조합하는 방식이 중앙 통제와 현장 적응 사이의 현실적인 경계다.
좋아 보이는 클래스 구조와 좋은 경계는 다르다
객체지향 문법을 더 쓰는 대신, 행동·제약·변경 이유가 실제 도메인과 맞는지 확인하는 세 가지 비교 기준이다.
겉보기 추상화필요한 메서드가 있다는 이유로 상속해 도메인에 없는 is-a 관계를 만든다. 구현 세부를 얻으려 만든 부모·자식 관계는 부모의 계약과 자식의 실제 의미가 어긋나는 출발점이 된다.
의미를 지키는 경계공유 구현은 합성으로 주입하고, 타입 계층은 실제 행동·제약·의미가 다를 때만 사용한다. 재사용과 도메인 모델링을 분리하면 구현을 바꿔도 타입의 뜻을 거짓으로 만들지 않는다.
겉보기 추상화검증·재시도처럼 독립적으로 켜지는 옵션의 모든 조합을 서브클래스 이름으로 늘린다. 기능이 하나 추가될 때마다 계층의 순서와 클래스 수가 함께 늘어나 실제 변화 이유를 읽기 어려워진다.
의미를 지키는 경계설정 객체와 작은 함수·전략을 조합해 기능을 독립적으로 바꾸고 조합 폭발을 피한다. 검증을 동기화 바깥 단계로 분리할 수 있는지도 확인해 옵션과 핵심 동작의 결합을 더 낮춘다.
겉보기 추상화여러 기능을 가진 거대한 기본 클래스를 넘겨 호출자가 쓰지 않는 메서드까지 보게 한다. 구현되지 않은 기능도 계약에 포함되어 런타임 오류가 날 수 있고, 함수의 실제 요구사항이 객체 크기에 가려진다.
의미를 지키는 경계인증·재고 조회처럼 실제로 필요한 능력만 작은 Protocol로 요구해 결합과 잘못된 호출 가능성을 줄인다. 큰 구현 객체를 전달하더라도 호출 함수가 보는 정적 경계는 작게 유지할 수 있다.
코드 모양이 비슷하다는 이유만으로 추상화하지 말고, 같은 의미를 가지며 같은 이유로 바뀔 때 경계를 묶어야 한다. 읽기 전용 객체를 쓰기 가능한 부모의 하위 타입으로 만들어 부모의 약속을 깨는 식의 설계도 피해야 한다. 중복이 조금 남더라도 의미가 아직 같다고 확신할 수 없다면 구체적인 함수로 두는 편이 안전하다. 클래스는 기본 선택이 아니라 불변 조건과 의미 있는 행동을 보호할 때 쓰는 도구다. 에이전트가 빠르게 계층을 확장할수록 리뷰에서는 ‘문법상 객체지향인가’보다 대체 가능성, 최소 능력, 변경 이유가 정렬됐는지를 확인해야 한다.
아직 못 읽은 북마크
북마크를 고르는 중…