01 · 하네스는 에이전트가 일하는 환경이다
자연어로 프로그램을 만드는 경험은 진입 장벽을 낮춥니다. 하지만 화면이 표시되는 것과 실제 사용 가능한 제품을 완성하는 것은 다릅니다. 저장 버튼은 보여도 새로고침하면 자료가 사라질 수 있습니다. 하네스는 모델 주변의 도구, 실행 환경, 작업 상태, 검증과 종료 조건을 묶어 이 간극을 다루는 실행 구조입니다.
Anthropic의 2026년 3월 실험은 생성자와 평가자를 분리하고 실제 앱을 조작해 피드백을 전달하는 구성을 소개합니다. 모델이 바뀌면 필요한 보조 구조도 다시 평가해야 한다는 점도 강조합니다. 특정 구조를 모든 프로젝트에 그대로 적용할 근거는 아닙니다. 아래는 이 원리에서 출발한 소규모 프로젝트용 설계 제안입니다.
02 · 요청을 완료 계약으로 바꾸기
연습 과제를 “학습 기록 앱을 만들어 줘”에서 “제목과 날짜를 입력하면 목록에 나타나고, 새로고침 후 유지되며, 빈 제목은 저장되지 않는다”로 바꿔 봅니다. 각 문장은 관찰 가능한 동작입니다. 모바일 화면에서 버튼이 가려지지 않는다는 조건까지 있으면 기능과 사용성을 함께 검증할 수 있습니다.
계약에는 작업 범위와 완료 증거를 같이 씁니다. 저장 기능이라면 입력·읽기·검증이 범위이고, 새로고침 전후의 동일한 기록이 증거입니다. 디자인 취향을 점수 하나로 압축하지 말고 글자 대비, 읽기 순서, 빈 화면 안내처럼 확인할 수 있는 항목을 먼저 정하세요.
03 · 작은 기능 하나를 끝내는 루프
첫 순환은 자료를 저장하는 경로 하나에 집중합니다. 현재 실패를 재현하고 원인을 가정한 뒤 코드를 고칩니다. 같은 입력으로 다시 실행해서 기대한 상태인지 확인합니다. 성공하면 관련된 오류 입력과 기존 조회 기능도 검사합니다. 검사 결과가 달라지면 그 차이가 다음 수정의 입력이 됩니다.
이때 “테스트 통과”라는 요약만 저장하지 마세요. 실행 명령, 종료 코드, 확인한 화면 상태, 남은 문제를 남겨야 다음 사람이 재현할 수 있습니다. 테스트가 없어서 실행하지 못했다면 통과가 아니라 미검증입니다. 테스트 자체가 잘못된 기대를 검사하는지도 리뷰해야 합니다.
04 · 반복에는 예산과 종료 조건이 필요하다
무조건 다시 시키는 무한 루프는 같은 실수를 늘릴 수 있습니다. 이 실습에서는 최대 세 번 수정, 같은 실패 두 번이면 원인 재검토, 외부 의존성 장애이면 현재 상태를 보존한다는 규칙을 제안합니다. 숫자는 정답이 아니라 과제 규모에 맞춰 바꿀 초기값입니다.
성공 종료는 완료 계약을 충족하고 알려진 차단 문제가 없을 때입니다. 예산 종료는 완료와 구분해서 남깁니다. 중간 인계 파일에는 완료 항목, 실패 입력, 수정한 파일, 다음 확인 명령을 적습니다. 배포나 데이터 삭제 권한을 반복 실행 과정에서 자동으로 확대하지 않습니다.
05 · 학생과 시스템 엔지니어에게 적용하기
학생은 브라우저의 할 일 목록으로 저장·검증·오류 안내를 익힐 수 있습니다. 서버 개발자는 테스트용 저장소로 API 상태 변화까지 확인할 수 있습니다. 시스템 엔지니어는 샘플 로그 분석 스크립트를 대상으로 정상 로그와 깨진 로그를 넣어 루프를 구성할 수 있습니다.
어떤 직무든 포트폴리오에 최종 화면만 올리기보다 최초 실패, 수정 판단, 검증 증거를 함께 기록해 보세요. 결과를 설명하고 반례를 찾는 능력이 AI를 이용한 개발에서도 중요한 학습 목표입니다.