하네스 엔지니어링으로 코딩 에이전트 소프트웨어 팩토리 만들기

메타데이터

• 원문 제목: [한영자막] 하네스 엔지니어링: 코딩 에이전트로 '소프트웨어 팩토리'를 만드는 방법
• URL: https://www.youtube.com/watch?v=sAu_4QuAI0w
• Video ID: sAu_4QuAI0w
• 발행일: 2026-10-10
• 처리일: 2026-10-11
• 채널: Tech Bridge
• 발표자: Dru Knox, Tessl 제품·디자인 총괄(Head of Product and Design)
• 핵심 주제: Harness Engineering, agentic development, coding agents, software factory
• 태그: #하네스엔지니어링 #HarnessEngineering #코딩에이전트 #소프트웨어팩토리 #Tessl #ClaudeCode #Codex #AIEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코딩 에이전트가 제품 코드를 만들도록 맡기는 수준을 넘어, 엔지니어링 팀이 에이전트가 안정적으로 제품을 생산하는 ‘소프트웨어 팩토리’ 자체를 구축해야 한다.== 그 공장으로 나아가는 핵심 실천이 하네스 엔지니어링(Harness Engineering)이며, 자율성·자동화·품질을 단계적으로 끌어올리는 개선 루프를 설계하는 일이다.

• 소프트웨어 팩토리는 최종적으로 사용자에게 전달되는 제품을 에이전트가 만들고, 엔지니어는 공장의 자율성·자동화·품질을 높이는 시스템을 만드는 구조다.
• 자율성은 에이전트가 사람의 수정 없이 정답에 도달하는 정도이고, 자동화는 사람이 결과를 얼마나 신뢰해 검토 없이 실행시킬 수 있는 정도라서 서로 다르다.
• 이너 루프·아우터 루프·메타 루프를 나누면 빠른 반복, 값비싼 검증, 조직 차원의 학습을 각각 자동화할 수 있다.
• 컨트롤 플레인, 에이전트 레디 인프라, 개선 루프를 순서대로 갖춰야 에이전트의 작업과 실패 신호를 읽고 되먹임할 수 있다.
• 진행률은 수동 개입과 사람의 PR 코멘트를 줄이고, 사람 없이 시작되는 PR을 늘리되 품질을 먼저 유지하고 이후 높이는 방식으로 측정한다.

소프트웨어 팩토리의 목적은 단순히 더 빠른 기능 출시가 아니다. 에이전트가 반복적으로 코드를 만들 수 있게 되면 팀은 버그 수정·테스트 품질·아키텍처 리팩터링·새로운 탐색처럼 기존 백로그에 밀려 있던 일을 처리할 여유를 얻고, 비기술 직군도 아이디어를 제품으로 실험할 수 있다. 엔지니어의 중심 업무는 개별 기능을 직접 구현하는 데서 공장을 관찰하고 개선하는 일로 이동한다.

1. 소프트웨어 팩토리의 정의와 목표

소프트웨어 팩토리는 제품 개발자를 대체하는 단일 도구가 아니라, 에이전트가 제품을 생산하고 사람이 생산 시스템을 발전시키는 조직 운영 모델이다.

1.1. 소프트웨어 팩토리의 작동 방식

1. 에이전트가 최종 산출물을 생산한다

   1. 제품 코드의 주체: 사용자가 실제로 마주하는 제품의 최종 코드가 코딩 에이전트에 의해 만들어지고 배포된다.
   2. 엔지니어링 팀의 역할: 소프트웨어 엔지니어는 기능 코드를 직접 찍어내는 사람보다 공장을 구축하는 내부 도구 제작자에 가까워진다.
   3. 공장의 개선 목표: 팀은 에이전트의 자율성, 실행 자동화, 산출물 품질을 높이는 기반 시스템과 규칙을 만든다.

2. 조직 전체의 개발 시스템이 바뀐다

   1. 내부 도구 빌더로의 전환: 팀의 모든 구성원이 제품을 만드는 시스템을 개선하는 내부 도구를 만들고 사용한다.
   2. 기능 생산과 공장 생산의 분리: 기능 하나를 만드는 것보다 같은 기능을 반복해서 안전하게 만들 수 있는 워크플로와 검증 장치를 만드는 일이 중요해진다.

1.2. 도입 전제와 발표의 범위

1. 코딩 에이전트 사용 경험이 전제된다

   1. 대상 수준: 코딩 에이전트를 이미 사용하며 한 번에 몇 개의 세션을 운영하는 사람을 대상으로 한 고급 주제다.
   2. 적합한 시점: 쉬운 작업과 중간 복잡도의 작업에서 에이전트가 자주 올바른 결과를 내는 ‘스위트 스팟’에 도달했을 때 하네스 엔지니어링을 시작하기 좋다.
   3. 초보자의 시작점과 구분: 코딩 에이전트를 처음 접했다면 이 구조부터 시작하기보다 기본적인 에이전트 사용법과 작업 분해를 먼저 익혀야 한다.

2. 특정 제품보다 기법이 중심이다

   1. 일반화 가능성: 하네스 엔지니어링의 대부분은 특정 기술 스택에 종속되지 않는 기법이다.
   2. Tessl의 위치: Tessl은 여정의 일부를 돕는 제품 사례로 제시되지만, 동일한 구조는 다른 도구를 조합해 직접 구현할 수도 있다.

2. 소프트웨어 팩토리를 측정하는 세 기둥

소프트웨어 팩토리로 가는 순서는 자율성을 높이고, 그 위에서 자동화를 확대하며, 품질을 일정하게 유지한 뒤 더 높은 수준으로 끌어올리는 것이다.

2.1. 자율성: 에이전트가 스스로 정답에 도달하는 정도

1. 자율성의 측정 대상

   1. 사람의 수정 횟수: 올바른 결과를 얻기 위해 사람이 코드를 직접 고치거나 에이전트의 방향을 다시 잡아줘야 하는 횟수를 잰다.
   2. 에이전트의 원샷 성공: 문제를 전달했을 때 에이전트가 사람의 추가 지시 없이 한 번에 해결하는 빈도가 자율성을 보여준다.

2. 자율성을 먼저 높여야 하는 이유

   1. 작업 자체의 안정화: 에이전트가 반복 작업을 자주 제대로 처리해야 다음 단계에서 그 작업을 무인 실행으로 넘길 수 있다.
   2. 교정 신호의 내장: 이너 루프에 검증과 교정 장치를 넣으면 사람이 매번 개입하지 않아도 에이전트가 실패를 감지하고 다시 시도할 수 있다.

2.2. 자동화: 결과를 믿고 실행을 맡기는 정도

1. 자동화와 자율성의 차이

   1. 자동화의 질문: 에이전트가 만든 결과를 어느 정도까지 사람의 검토 없이 실행시킬 수 있는가를 묻는다.
   2. 검토와 신뢰: 코드를 직접 읽고 수동으로 검증해야 한다면 에이전트가 자율적으로 정답을 내더라도 자동화 수준은 낮다.

2. 서로 다른 두 상태

   1. 높은 자율성·낮은 자동화: 에이전트가 문제를 자주 원샷으로 풀지만 결과를 아직 믿지 못해 사람이 모든 코드를 검토할 수 있다.
   2. 단계적 관계: 자율성을 먼저 쌓아야 자동화로 이동할 수 있지만, 자율성이 높아졌다고 자동화가 자동으로 따라오는 것은 아니다.

2.3. 품질: 사용자에게 전달되는 결과의 수준

1. 품질의 구성 요소

   1. 제품 지표: 사용자가 경험하는 제품의 일반적인 분석 지표가 포함된다.
   2. 개발 지표: 테스트 품질, 테스트 커버리지 같은 검증 지표가 포함된다.

2. 품질을 지키는 전환 원칙

   1. 초기 목표: 팩토리로 전환하는 동안 품질을 일정하게 유지하고, 아주 작은 하락은 감수할 수 있지만 큰 하락을 정상으로 취급하지 않는다.
   2. 후기 목표: 자율성과 자동화를 높인 뒤에는 오히려 더 높은 품질을 목표로 삼는다.

3. 속도보다 품질과 개발 여유가 중요한 이유

소프트웨어 팩토리의 단기 효과는 출시 속도지만, 지속적인 가치는 팀의 미처리 백로그를 줄이고 품질을 높일 수 있는 생산 능력을 만드는 데 있다.

3.1. 기능 출시 속도에 대한 오해

1. 단기적인 속도 상승

   1. 초기 기대: 에이전트가 등장하면 약간의 거친 부분을 감수하는 대신 훨씬 더 많은 기능을 출시해 비용 대비 효과를 얻을 수 있다고 생각하기 쉽다.
   2. 실제 효과: 팩토리를 갖추면 개발 속도는 실제로 빨라지지만, 그것만을 최종 목표로 삼으면 공장의 잠재력을 과소평가하게 된다.

2. 품질과 속도의 관계

   1. 전환기의 균형: 초기에는 품질을 일정하게 유지하면서 자율성과 자동화를 올리는 것이 우선이다.
   2. 후속 보상: 공장이 안정화되면 코드 품질을 더 높이는 방향으로 생산 능력을 사용할 수 있다.

3.2. 백로그가 사라질 때 생기는 여력

1. 미뤄진 작업의 처리

   1. 버그 수정: 모든 팀이 시간 부족으로 남겨둔 버그 수정 백로그를 더 적극적으로 처리할 수 있다.
   2. 개선과 탐색: 기존 코드의 개선, 새로운 아이디어와 제품 방향에 대한 탐색을 수행할 여유가 생긴다.
   3. 품질 투자: 테스트 품질 개선과 아키텍처 리팩터링을 기능 출시와 경쟁시키지 않고 진행할 수 있다.

2. 생산 능력의 재배분

   1. 백로그의 의미 변화: 반복적인 기능 생산이 자동화되면 ‘할 일이 계속 쌓여서 못 한다’는 백로그 자체가 점차 사라진다.
   2. 엔지니어의 집중: 엔지니어는 개별 기능의 손코딩보다 시스템 품질과 생산 라인의 병목을 개선하는 데 집중한다.

3.3. 비기술 직군과 협업하는 방식의 변화

1. 아이디어 참여의 문턱 하락

   1. 비기술 구성원의 기여: 기술 직군이 아닌 구성원도 에이전트를 통해 아이디어를 제안하고 실험하기 쉬워진다.
   2. 관점의 확장: 더 많은 관점이 개발 과정에 들어오며 제품 탐색 범위가 넓어진다.

2. 엔지니어링 팀의 역할 집중

   1. 기반 시스템 구축: 엔지니어는 모든 기능을 직접 구현하기보다 여러 사람이 사용하는 기반 시스템을 발전시킨다.
   2. 조직 경험의 변화: 개발 경험이 더 역동적이고 포용적으로 바뀌며, 한정된 개발 인력의 시간을 공통 인프라와 품질에 쓸 수 있다.

4. 하네스 엔지니어링과 세 가지 개선 루프

하네스 엔지니어링은 에이전트로 제품을 만드는 일이 아니라, 제품을 만드는 에이전트의 품질을 자동으로 개선하는 루프를 설계하는 일이다. 최근에는 같은 개념을 ‘루프 엔지니어링(loop engineering)’이라고도 부른다.

4.1. 이너 루프(Inner Loop): 에이전트 작업 중의 빠른 교정

1. 작동 시점과 목적

   1. PR 이전: 코딩 에이전트가 코드를 작성하고 PR을 올리기 전의 작업 과정에 해당한다.
   2. 반복 속도: 에이전트가 계속 실행할 수 있도록 빠르고 저렴해야 한다.

2. 자율성에 미치는 효과

   1. 조기 오류 포착: 에이전트가 코딩하는 동안 문제를 즉시 찾아낸다.
   2. 사람 없는 교정: 검증 결과를 에이전트에게 돌려보내 스스로 수정하게 함으로써 사람의 개입을 줄인다.

4.2. 아우터 루프(Outer Loop): PR 단위의 값비싼 검증

1. 검증의 위치와 성격

   1. PR 이후: PR이 올라온 뒤 실행하는, 더 비싸고 철저한 검사 영역이다.
   2. 반복 실행과의 구분: 에이전트가 기능을 수정할 때마다 돌리기에는 비용이 커서 이너 루프에 넣지 않는다.

2. 사람의 신뢰를 대체하는 검사

   1. 인간 검증의 자동화: 사람이 직접 확인해야 시스템을 신뢰할 수 있었던 항목을 자동 검증으로 옮긴다.
   2. 구체적 사례: 에이전트 기반 QA(agentic QA)를 실행하거나, 테스트 스위트가 실제 결함을 잡는지 mutation testing으로 검사한다.
   3. 에이전트의 후속 반복: PR이 올라간 뒤 검증 결과를 에이전트에게 전달하고 에이전트가 그 결과를 반영해 다시 수정한다.

4.3. 메타 루프(Meta Loop): 조직 차원의 학습과 재발 방지

1. 관찰 범위

   1. 개발 바깥의 루프: 메타 루프는 개별 기능 개발 과정의 외부에서 작동한다.
   2. 관찰 데이터: 코딩 에이전트 로그, PR, 이슈 트래커, 사용자 피드백을 함께 본다.

2. 실패를 시스템 개선으로 바꾸는 과정

   1. 실패 발견: 사용자에게 도달한 실수나 사람이 막기 위해 직접 교정했던 실수를 찾는다.
   2. 되먹임: 발견한 문제를 이너 루프와 아우터 루프에 반영해 동일한 실수가 다시 발생하지 않게 한다.
   3. AI 네이티브 수준의 상승: 세 루프를 위한 기반을 갖춘 뒤 메타 루프에 투자할수록 조직의 AI 활용 수준이 높아진다.

5. 하네스 엔지니어링이 어려운 이유

하네스 엔지니어링은 도구를 하나 도입하는 프로젝트가 아니라, 빠르게 바뀌는 지식과 예측할 수 없는 작업을 기존 출시 일정 속에서 처리하는 조직 변화다.

5.1. 새롭고 빠르게 변하는 분야

1. 지식의 유효기간이 짧다

   1. AI 연구자 역할: 팀은 하네스 엔지니어링을 따라가기 위해 논문을 읽고 블로그를 보며 사실상 AI 연구자처럼 움직여야 한다.
   2. 빠른 노후화: 이번 주의 모범 사례가 다음 주에는 낡고, 2주 뒤에는 더 이상 쓰면 안 되는 안티패턴이 될 수 있다.

2. 지식 갱신을 위한 운영 설계

   1. 시간과 공간의 확보: 매주 바뀌는 지식을 따라갈 시간과 조직적 여유를 사전에 마련해야 한다.
   2. 업데이트 방식의 결정: 누가 새 논문·도구·사례를 수집하고, 어떤 기준으로 현재 워크플로에 반영할지 정해야 한다.

5.2. 계획하기 어려운 비계획 업무

1. 실패를 예측할 수 없다

   1. 실패 형태의 불확실성: 새 기능을 출하하기 전에는 에이전트가 실패할지, 어떻게 실패할지, 고치는 데 얼마나 걸릴지 알기 어렵다.
   2. 개선 작업의 경쟁: 에이전트를 더 나아지게 만드는 작업이 기능 출시와 같은 시간과 인력을 요구한다.

2. 일정과 개선 사이의 함정

   1. 개선하지 않는 경우: 개선 작업을 하지 않으면 에이전트가 영원히 같은 수준에 머무르는 ‘로컬 최댓값(local maxima)’에 갇힌다.
   2. 개선하는 경우: 개선 작업을 진행하면 기능 마감일을 놓쳐 일정 압박을 받는다.
   3. 반복되는 회피: 이 양쪽의 트레이드오프가 너무 어려워서 조직은 결국 하네스 개선을 계속 미루게 된다.

5.3. 필요한 신호가 흩어져 있다

1. 정보가 읽히지 않는 위치에 있다

   1. 로컬 로그: 중요한 에이전트 작업 기록이 개인 컴퓨터의 로컬 코딩 에이전트 로그에 묻혀 있다.
   2. 개인 의존성: 필요한 지식이 누군가의 머릿속에 있거나, 특정 사람이 가진 환경에만 존재한다.

2. 최적화 가능한 표면으로 이동해야 한다

   1. 워크플로 가시화: 에이전트가 무엇을 했고 어디서 실패했는지 나중에 분석할 수 있는 표면으로 작업을 옮긴다.
   2. 저장·공유: 데이터와 작업 결과를 저장하고 조직에 공개해야 이후 개선 루프가 접근할 수 있다.

6. 하네스 엔지니어링의 세 계층

Tessl의 관점에서 세 계층은 컨트롤 플레인, 에이전트 레디 인프라, 개선 루프 순서로 쌓인다. 이름 자체는 업계의 표준 용어가 아니라 실무를 설명하기 위한 분류다.

6.1. 계층 1 — 컨트롤 플레인(Control Plane)

컨트롤 플레인은 에이전트 작업의 시작점·상태·결과·개선 신호를 읽을 수 있게 만드는 운영 표면이다.

1. 작업을 추적 가능한 흐름으로 만든다

   1. 이슈에서 시작: Tessl에서는 모든 작업이 이슈 트래커의 이슈로 시작한다.
   2. 헤드리스 에이전트 실행: 이슈가 샌드박스에서 실행되는 headless agent로 전달된다.
   3. PR 생성: 에이전트가 코드를 작성하고 PR을 올린다.
   4. 댓글을 통한 교정: 엔지니어는 PR 댓글로 수정 방향을 전달한다. 수동 교정과 수동 인터페이스는 남아 있지만 모든 접점이 기록된다.

2. 세 가지 기본 도구를 갖춘다

   1. 이슈 추적과 작업 시작: 이슈를 기록하고 그 이슈에서 에이전트 작업을 시작할 수 있어야 한다.
   2. GitHub PR 리뷰: 에이전트가 올린 PR을 사람이 검토하고 결과를 다시 에이전트에게 전달할 수 있어야 한다.
   3. 스킬·워크플로 레지스트리: 에이전트를 더 나아지게 하는 스킬과 플레이북을 표준화하고 배포할 공유 저장소가 필요하다. 공유 GitHub 저장소도 한 방법이다.

6.2. 계층 2 — 에이전트 레디 인프라(Agent-Ready Infrastructure)

에이전트 레디 인프라는 사람이 당연하게 쓰던 환경과 조직 지식을 에이전트도 안전하게 사용할 수 있도록 연결하는 작업이다.

1. 숨은 의존성을 드러낸다

   1. 로컬 설정의 문제: 다른 사람이 다시 설정할 수 있다고 생각했던 프로젝트를 옮겨보면, 격리돼 있다고 믿은 의존성이 실제로는 개인 환경에 얽혀 있음을 발견한다.
   2. 에이전트에서도 같은 문제: CLI, API, 제품 화면을 클릭할 권한처럼 에이전트가 쉽게 쓸 것이라 생각한 기능도 실제로는 연결되지 않은 경우가 많다.
   3. 과소평가의 경고: ‘우리 조직은 어렵지 않을 것’이라고 시작한 팀 중 끝까지 그렇게 말하는 팀은 없을 만큼 범위가 크다.

2. 회사 지식과 서비스에 접근시킨다

   1. 회사 두뇌의 문서화: 일을 처리하는 방식, 팀의 워크플로, 운영 규칙을 문서로 남겨 에이전트가 참조하게 한다.
   2. 내부 서비스 연결: 내부 서비스에 API 접근을 제공하되 권한과 거버넌스 질문을 함께 해결해야 한다.
   3. 제품 조작 경로: CLI와 API뿐 아니라 에이전트가 제품을 실제로 클릭하고 사용해 기능을 구축할 수 있는 경로도 마련한다.

3. 실행과 관찰의 안전 경계를 만든다

   1. 프로덕션 로그: 에이전트가 운영 로그에 접근해 실제 문제를 분석할 수 있게 한다.
   2. 컴플라이언스: 운영 데이터와 내부 서비스에 대한 접근에는 조직의 컴플라이언스 입장과 보안 규칙이 따라야 한다.
   3. 실행 환경: 에이전트가 작성한 코드를 실제로 실행하고 검증할 수 있는 샌드박스 환경이 필요하다.
   4. 조직별 차이: 연결해야 할 항목은 회사마다 크게 다르며, 에이전트가 사람의 개입 없이 코드를 올리게 만들면서 각 조직의 병목이 드러난다.

6.3. 계층 3 — 개선 루프(Improvement Loops)

개선 루프는 하네스 엔지니어링에서 가장 많은 시간을 쓰는 영역이며, 메타 루프를 실제 자동화로 구현하는 구성 요소다.

1. 저장소 유지보수 자동화

   1. 정기 스캔: 매일·매일 밤·매주처럼 정해진 주기로 코드베이스를 훑어 문제를 찾는다.
   2. 지속적인 예방: 문제가 발생한 뒤에만 고치는 대신 정기 검사를 통해 누적되는 품질 저하를 조기에 발견한다.

2. 개발 플레이북을 만든다

   1. 공통 작업의 표준화: CLI에 기능을 추가하는 방법처럼 반복되는 개발 관행을 플레이북으로 정리한다.
   2. 에이전트 품질 향상: 플레이북과 스킬은 에이전트가 조직의 방식에 맞춰 일하게 하는 공유 지식이 된다.

3. 반복 작업을 자동화한다

   1. 반복 패턴 발견: 사람이 계속 수행하는 같은 종류의 작업을 식별한다.
   2. 실행 장벽 제거: 자동화가 복잡하거나 오래 걸리면 사람이 쓰지 않으므로 최대한 빠르고 쉽게 실행되게 만든다.

4. 결과 품질을 학습으로 환류한다

   1. 일관된 품질 관찰: 생성된 코드와 작업 결과의 품질을 지속적으로 확인한다.
   2. 스킬 업데이트: 에이전트가 같은 실수를 했으면 스킬이나 CLI 기능 추가 플레이북을 갱신한다.
   3. 재발 방지: 한 번의 실패에서 얻은 학습을 전체 코드베이스와 다음 에이전트 작업에 전달한다.

7. Tessl이 제공하는 구현 방식

Tessl의 제품군은 하네스 엔지니어링을 한 번에 끝내는 대규모 전환이 아니라, 작은 개선을 지속해서 쌓는 방식으로 제공한다.

7.1. 제품 철학

1. 작은 개선의 누적

   1. 지속 가능한 최첨단 접근: 빠르게 변하는 분야에서 한 번의 거대한 프로젝트보다 반복 가능하고 지속 가능한 작은 개선을 목표로 한다.
   2. 비유: ‘한 번에 거대한 무스(moose)를 삼키는 뱀’처럼 모든 것을 한꺼번에 해결하는 대신, 작은 리프트를 여러 번 쌓는다.
   3. 업무 중단 최소화: 6개월 뒤 소프트웨어 팩토리의 40%에 도달하더라도 배송을 멈추거나 지연시키지 않는 점진적 경로를 지향한다.

2. 지식 격차를 대신 관리한다

   1. 배터리 포함(batteries included): 하네스 엔지니어링의 최신 모범 사례를 제품 경험에 포함해 팀이 모든 변화를 직접 추적하지 않아도 되게 한다.
   2. 지속적인 갱신: 빠르게 바뀌는 지식과 관행을 Tessl이 업데이트해 에이전트 경험에 반영한다.

3. 모듈성과 개방성

   1. 모든 구성 요소를 독점하지 않음: 공장의 모든 구성 요소가 한 회사 제품일 때 최고 수준이 된다고 가정하지 않는다.
   2. 스택별 선택권: 조직이 자신의 스택에서 가장 중요한 부분만 골라 사용할 수 있게 한다.
   3. 직접 구축 가능성: 소개된 기법은 Tessl 없이도 직접 구현할 수 있으며, Tessl은 설치·운영·개선의 마찰을 줄이는 선택지다.

7.2. 컨트롤 플레인 지원

1. 스킬 레지스트리

   1. 버전 관리: 조직이 만든 워크플로와 자동화를 게시하고 버전별로 관리한다.
   2. 거버넌스: 보안 리뷰, 품질 리뷰, 게시·수정 권한 통제를 내장한다.

2. 이슈 트래커와 GitHub 연결

   1. 현재 연결: Linear 이슈를 생성하면 GitHub 워크플로를 실행할 수 있도록 연결한다.
   2. 확장 방향: 다른 이슈 트래커와의 연결도 추가할 계획으로 제시된다.

3. 에이전트 코드 리뷰

   1. 표준화된 리뷰: 조직의 에이전트 코드 리뷰 기준을 쉽게 설정한다.
   2. 표적 검사: 일반적인 리뷰 외에도 특정 위험과 품질 항목을 겨냥한 검사를 추가한다.
   3. 레지스트리 워크플로 검사: 게시된 워크플로를 보안, 품질, 에이전트 산출물 개선 효과 관점에서 스캔한다.

7.3. Tessl Agent와 개선 루프

1. 반복 작업을 찾아 자동화한다

   1. 변경 관리 지원: PR과 이슈를 분석해 팀이 반복하는 작업을 찾고, 이를 자동화할 시간을 확보하게 한다.
   2. 구체적 사례: 매주 flaky test를 찾는 작업을 발견하면 해당 워크플로를 스킬로 만들고 GitHub Action으로 자동 실행한다.
   3. 한 번에 하나씩: 자동화는 한 워크플로씩 추가해 팀이 변화를 감당할 수 있게 한다.

2. 기본 유지보수 작업을 제공한다

   1. 정기 검사: 아키텍처 품질, 코드 중복, 테스트 스위트의 수준, 보안 취약점을 주기적으로 점검한다.
   2. 원클릭 설치: 여러 유지보수 작업을 한 번에 설치해 별도의 운영 노력 없이 매주 코드베이스를 개선한다.

7.4. Tessl Launch와 여러 코딩 에이전트

1. 스킬을 실행 가능한 워크플로로 전환한다

   1. 스킬의 역할: 스킬은 특정 업무 흐름을 코드화한 지식·절차다.
   2. Tessl Launch: 스킬을 자동화 워크플로로 만들고, 그 작업을 처리할 코딩 에이전트를 선택하는 명령이다.

2. 에이전트 선택과 실행 환경

   1. 선택지: Tessl Agent뿐 아니라 Codex, Claude Code, Gemini 같은 코딩 에이전트를 작업에 맞춰 선택할 수 있다.
   2. 샌드박스 권한: 선택한 에이전트는 필요한 권한이 설정된 샌드박스에서 실행된다.
   3. 장시간 작업: 워크플로는 오래 실행될 수 있다.
   4. PR과 댓글: GitHub 토큰을 사용해 에이전트가 PR을 올리고, 사람이 남긴 댓글에 응답하며 반복 수정할 수 있다.

8. 진행률을 판단하는 운영 지표

하네스 엔지니어링의 성과는 ‘AI를 쓴다’는 선언이 아니라 사람의 개입이 실제로 줄고 에이전트가 스스로 시작·수정·검증하는 작업이 늘어나는지로 판단한다.

8.1. 줄여야 할 수동 개입

1. 수동 테이크오버

   1. 측정 대상: 에이전트가 멈춰 사람이 직접 작업을 넘겨받은 횟수를 추적한다.
   2. 개선 방향: 실패 원인을 이너·아우터·메타 루프에 반영해 같은 테이크오버를 줄인다.

2. 사람의 PR 코멘트

   1. 측정 대상: 에이전트가 올린 PR에 사람이 수정 지시를 남기는 횟수를 측정한다.
   2. 해석: 코멘트가 줄어들면 에이전트가 조직의 규칙과 품질 기준을 더 잘 이해하고 있다는 신호다.

8.2. 늘려야 할 에이전트 주도 작업

1. 사람 없이 시작된 PR

   1. 핵심 신호: 사람이 직접 작업을 시작하지 않아도 이슈·자동화에서 PR이 생성되는 비율을 높인다.
   2. 자동화의 증거: 사람의 입력 없이 시작되는 PR이 많아지는 것은 시스템이 더 많이 자동화됐다는 뜻이다.

2. 품질을 함께 해석한다

   1. 첫 단계: 자율성과 자동화를 키우는 동안 품질을 일정하게 유지한다.
   2. 다음 단계: 품질을 희생하지 않고 생산량을 높인 뒤, 공장의 검증 능력을 이용해 품질 자체를 끌어올린다.

주요 발언 모음

“소프트웨어 팩토리는 제품을 만드는 에이전트 시스템이고, 소프트웨어 엔지니어링 팀은 사실상 그 팩토리를 만드는 데 집중한다.”

“자율성과 자동화는 비슷하게 들리지만 다르다. 자율성이 높아도 아직 결과를 믿지 못해 모든 코드를 직접 리뷰한다면 자동화는 낮을 수 있다.”

“자율성을 먼저 쌓아야 자동화로 이동할 수 있다.”

“하네스 엔지니어링은 팩토리의 품질을 자동화하고 개선하는 루프를 만드는 일이다.”

“사람이 막기 위해 교정했던 실수를 메타 루프가 찾아 이너 루프와 아우터 루프에 되돌려 보내야 같은 실수가 다시 일어나지 않는다.”

“한 번에 거대한 무스를 삼키려 하지 말고, 작은 리프트를 여러 번 쌓아라.”

“수동 테이크오버와 사람의 PR 코멘트를 줄이고, 사람의 입력 없이 시작되는 PR을 늘려라. 다만 먼저 품질을 일정하게 유지한 뒤 품질을 높여야 한다.”

핵심 데이터 & 수치

• 세 가지 핵심 지표: 자율성(autonomy), 자동화(automation), 최종 품질(final quality)이다.
• 세 가지 개선 루프: 이너 루프, 아우터 루프, 메타 루프다.
• 세 가지 구축 계층: 컨트롤 플레인, 에이전트 레디 인프라, 개선 루프다.
• 6개월 후 40%: Tessl은 대규모 중단 없이 작은 개선을 쌓아 6개월 뒤 소프트웨어 팩토리 구축이 40% 진행된 상태를 지향하는 예시를 든다.
• 주기적 검사: 저장소는 매일·매일 밤·매주 등 정해진 주기로 스캔하고, flaky test·아키텍처 품질·코드 중복·테스트 품질·보안 취약점을 점검한다.
• 핵심 방향 지표: 수동 테이크오버와 사람의 PR 코멘트는 감소하고, 사람 없이 시작된 PR은 증가해야 한다.
• 전환 품질 기준: 자율성과 자동화를 높이는 동안 품질을 먼저 일정하게 유지한 뒤 품질 향상을 목표로 삼는다.

결론 및 시사점

1. 코딩 에이전트 도입의 다음 단계: 에이전트에게 작업을 시키는 것에서 멈추지 말고, 에이전트가 반복적으로 일할 수 있는 추적·실행·검증 표면을 구축해야 한다.
2. 자율성과 자동화를 분리해 관리: 에이전트가 문제를 잘 푸는지와 결과를 사람 없이 실행할 만큼 신뢰하는지는 다른 지표이므로 따로 측정해야 한다.
3. 루프별 비용을 설계: 이너 루프는 빠르고 싸게, 아우터 루프는 비싸더라도 철저하게, 메타 루프는 조직의 실패를 재발 방지 규칙으로 바꾸도록 구성한다.
4. 세 계층을 순서대로 구축: 이슈·PR·스킬을 추적하는 컨트롤 플레인을 먼저 만들고, 내부 서비스·로그·실행 환경을 에이전트 레디 상태로 연결한 뒤, 개선 루프를 자동화한다.
5. 비계획 업무를 운영에 포함: 하네스 엔지니어링의 실패와 개선은 예측하기 어렵기 때문에 별도 시간과 담당 구조를 확보하지 않으면 기능 출시 일정에 밀려 사라진다.
6. 개인 지식을 공유 가능한 표면으로 이동: 로컬 로그와 개인의 머릿속에 남은 작업 방식을 문서·레지스트리·플레이북·PR 기록으로 옮겨야 메타 루프가 학습할 수 있다.
7. 작게 시작해 중단 없이 확장: 반복되는 flaky test 탐색 같은 한 가지 작업을 스킬로 만들고 자동화한 뒤, 매주 하나씩 범위를 넓히는 방식이 현실적인 출발점이다.
8. 최종 성공 기준: 사람의 수동 개입과 PR 지시는 줄고, 사람 없이 시작된 PR과 제품 품질은 높아져야 한다. 속도만 높이고 품질이 떨어진다면 소프트웨어 팩토리의 목표를 달성한 것이 아니다.