Coreline Meta Harness — 스킬 프로젝트 소개

팀을 실행하기 전에 팀이 받을 입력을 만들기

Coreline Meta Harness에서 제가 맡긴 책임은 요청에 맞는 팀을 정의하는 일이었습니다. 어떤 도메인 규칙이 필요한지, 어떤 역할을 구성할지, 각 역할이 무슨 스킬로 어느 산출물을 만들지 정합니다. 팀을 실제로 실행하고 상태를 관리하는 기능은 별도 실행 환경으로 전달합니다.

이 경계를 나누면 하네스가 준비할 결과도 분명해집니다. 요청 해석과 도메인 선택, 역할과 스킬의 연결표, 산출물 기준, 검토 기준이 필요합니다. 역할 이름을 여러 개 만드는 것만으로 실행할 수 있는 팀이 되는 것은 아닙니다.

에이전트 정의보다 스킬과 입력·출력 관계를 먼저 정하도록 했습니다. 역할이 읽을 자료와 만들어야 할 결과를 정한 뒤 스킬을 연결합니다. 역할이 여러 개여도 다음 담당이 받을 자료가 빠지면 작업은 이어지지 않습니다.

파일은 있는데 작업은 대기로 남았습니다

2026년 4월 5일의 작은 로컬 smoke에서는 실행 상태와 실제 작업 폴더가 어긋나는 모습을 확인했습니다. 첫 관찰에서는 네 작업이 완료되고 프런트엔드 작업 하나가 대기로 남았습니다. 그런데 작업 폴더에는 프런트엔드 산출물이 있었습니다.

검토 문서가 산출물이 없다고 판단한 내용과 후속 관찰에서 파일이 존재한 상태도 함께 나타났습니다. 이어진 재현 smoke에서는 일부 문서와 코드가 생겼는데 작업 상태와 대화 기록이 바로 따라오지 않는 모습을 살폈습니다. 이것을 모든 작업이 정상 완료됐다는 결과로 정리하지 않았습니다.

저는 파일 존재와 실행 상태를 각각 확인해야 한다는 조건을 남겼습니다. 결과 파일이 있다고 worker가 종료됐다고 판단할 수 없고, 대기 상태라고 반드시 아무 결과도 없다고 판단할 수도 없습니다. 당시 관찰은 상태 전달이나 시점 차이의 가능성을 보여 줬지만, 그 자체로 원인을 확정한 수정 완료 보고는 아니었습니다.

문서 준비에도 서로 다른 수준을 두기

이 차이를 다루기 위해 문서 준비 상태와 실행 성공을 따로 판단했습니다. 요청과 역할만 정한 상태, 패키지 골격을 만든 상태, 검토 자료를 갖춘 상태, 실행 환경에 넘길 규칙까지 정리한 상태를 구분했습니다.

예를 들어 역할 연결표와 산출물 목록이 있으면 패키지의 구조는 볼 수 있습니다. 하지만 실제 검토 자료가 없으면 결과 간 충돌을 판단하기 어렵습니다. 실행 환경에 넘기려면 작업 공간과 팀, 스킬을 어떻게 연결할지도 있어야 합니다.

실행 환경에서 이상 상태가 발견됐다고 문서 계약 전체를 즉시 미완료로 바꾸지는 않습니다. 어떤 계약은 맞고 어떤 실행 상태가 남았는지 따로 기록합니다. 반대로 문서가 전달 가능한 수준이라는 표시를 실행 완료로 읽지도 않습니다. 두 판단의 근거가 달라야 다음 수정의 담당을 찾을 수 있습니다.

SEO 샘플에서는 진단을 먼저 넘겼습니다

SEO 도메인 샘플을 만들 때는 진단, 키워드 전략, 세 종류의 계획, 최종 검토로 순서를 정했습니다. 진단과 키워드는 먼저 끝내고, 그 결과를 받은 페이지 내용·기술 상태·링크 전략 계획을 나란히 구성합니다. 마지막 검토는 세 계획의 연결과 충돌을 확인합니다.

이 샘플은 실제 사이트의 검색 순위가 오른 사례가 아닙니다. 팀 구성과 산출물 전달을 설명하기 위한 패키지입니다. 그래서 검토 질문도 “SEO가 좋아졌는가”보다 진단의 중요한 문제가 계획에 반영됐는지, 핵심 키워드가 대상 페이지에 배정됐는지로 구체화했습니다.

계획끼리 같은 페이지에 모순된 지시를 하거나 링크 전략이 없는 페이지를 대상으로 하면 문제가 됩니다. 페이지 설명을 추가하라는 계획과 그 페이지를 삭제하라는 계획이 함께 있으면 최종 검토에서 연결을 다시 봐야 합니다. 각 담당의 결과가 존재하는 것과 전체 전략이 이어지는 것은 다릅니다.

사람에게 읽히는 순서도 검사기가 받아들여야 했습니다

4월 11일에는 패키지 검사가 샘플 문서와 맞도록 보완했습니다. 역할 연결표의 실행 순서에 숫자뿐 아니라 순차·병렬 설명이 함께 들어갈 수 있었습니다. 이전 방식처럼 셀 전체를 정수로 바꾸면 이런 표기를 읽지 못합니다.

저는 순서 셀에서 숫자를 읽는 처리로 바꾸고, 역할과 산출물뿐 아니라 스킬의 순서도 같은 연결표에서 얻도록 했습니다. 별도의 엄격한 표 문자열을 다시 찾기보다 한 번 읽은 결과를 입력 시점 검사에 사용했습니다.

이 검사는 스킬이 자신의 결과보다 뒤에 만들어지는 자료를 입력으로 요구하지 않는지 살피는 데 연결됩니다. 문서가 보기에는 자연스럽더라도 아직 존재하지 않는 후속 산출물을 시작 조건으로 삼으면 실제 흐름은 끊깁니다. 읽기 좋은 표현과 검사 가능한 구조를 함께 맞추는 것이 이 수정의 목적이었습니다.

내부 분류 수만큼 스킬을 늘리지 않기

스킬을 설계하는 내부 분류와 실행 환경에 노출할 스킬 수는 따로 정했습니다. 요구 정리나 검토에 여러 판단 축이 필요하다고 해서 각 축을 전부 독립 스킬로 만들지는 않습니다. 기본적으로 하나의 역할에 필요한 축을 하나의 복합 스킬로 조립하도록 했습니다.

별도로 나눌 때는 산출물이나 다음 소비자, 검토 기준, 입력 조건이 실제로 달라야 합니다. 이름만 다른 얕은 스킬이 늘어나면 역할 연결표는 커져도 어느 결과를 누가 확인할지 흐려질 수 있습니다.

도메인 팩도 상위 분류 이름으로만 고르지 않습니다. 실제로 연결할 구체적인 규칙 묶음을 선택하고, 그 안에서 역할과 스킬을 정합니다. 웹 앱과 SEO는 필요한 결과가 다르므로 같은 역할 이름을 그대로 복제하는 대신 각 결과의 계약을 다시 구성합니다.

완료라는 말을 어떤 근거로 쓸지

준비 상태를 쓸 때는 무엇이 갖춰졌는지도 함께 적습니다. 역할만 정리했는지, 검토할 산출물이 있는지, 실행 환경에 넘길 규칙까지 정했는지를 구분합니다. 실행 결과는 별도 상태와 실제 작업 폴더를 함께 확인합니다.

새 요청을 적용할 때도 요청, 도메인, 역할, 스킬, 산출물, 검토 기준을 연결한 뒤 전달합니다. 실행 중 문제가 나타나면 그것이 입력 계약의 누락인지 worker의 상태 문제인지 먼저 나눕니다. 그래야 문서를 고쳐야 할지 실행 환경을 살펴야 할지 판단할 수 있습니다.

산출물이 생겼는데 상태가 남았던 smoke는 완료 표시 하나로 모든 것을 판단하기 어렵다는 경험을 남겼습니다. 저는 그 차이를 역할 설계와 준비 수준, 실행 상태로 나눠 다루는 쪽으로 하네스를 구성했습니다. 팀을 만드는 판단과 팀의 실행을 연결하되, 각자 확인해야 할 사실을 분명히 남기는 것이 핵심입니다.