Harness engineering 면접 질문: AI 엔지니어를 위한 22개 질문과 답변

준비 방법

Harness engineering 면접은 보통 일반적인 질문에서 구체적인 질문으로 나아갑니다: 하네스란 무엇인지, 어떤 구성 요소로 이루어지는지, 문제를 어떻게 진단하는지, 효과를 어떻게 측정하는지. 면접관이 찾는 것은 엔지니어링적 사고입니다: 모델의 문제와 환경의 문제를 구분하고, 검증 가능한 해결책을 제시할 수 있는지. 아래에 주제별로 묶은 22개 질문과 답변이 있습니다.

기초

1. 에이전트의 하네스란 무엇인가요?

하네스는 AI 에이전트가 작동하는 전체 환경으로, 모델을 제외한 모든 것입니다: 지침, 도구, 실행 환경, 상태 저장, 피드백 루프. 모델은 결정을 내리고, 하네스는 모델이 무엇을 알고, 무엇을 할 수 있고, 결과를 어떻게 알게 되는지를 결정합니다. 같은 모델도 서로 다른 하네스에서는 매우 다른 품질을 보입니다.

2. Harness engineering은 prompt 및 context engineering과 어떻게 다른가요?

Prompt engineering은 하나의 요청을 어떻게 표현할지, context engineering은 매 단계마다 모델의 창에 무엇이 들어갈지를 다룹니다. Harness engineering은 둘 다 포함하고, 텍스트로 해결되지 않는 것을 더합니다: 도구 접근, 재현 가능한 환경, 세션 사이의 상태, 기계에 의한 결과 검증.

3. 하네스의 다섯 구성 요소를 말해 보세요.

지침(AGENTS.md, CLAUDE.md, skills, 문서), 도구(shell, 테스트, linter, 브라우저, MCP), 환경(의존성, 런타임, Docker, worktree), 상태(PROGRESS.md, 기능 목록, 결정 기록), 피드백(make check, E2E, hooks, 평가자). 어느 한 구성 요소가 빠지면 "조금 더 나쁜" 결과가 아니라 체계적인 종류의 실패가 생깁니다.

4. 더 강력한 모델로 바꾸는 것이 왜 자주 도움이 되지 않나요?

많은 실패가 모델의 지능과 관련이 없기 때문입니다. 강력한 모델도 주어지지 않은 명령에는 접근할 수 없고, 상태 파일 없이는 어제의 세션을 기억하지 못하며, 아무도 실행하지 않은 깨진 migration을 알아차리지 못합니다. 특정 팀의 관례도 모델이 저절로 알 수 없습니다.

진단

5. 에이전트가 CLAUDE.md에 적힌 규칙을 어깁니다. 어떻게 하시겠습니까?

먼저 에이전트가 그 규칙을 보고 있는지 확인합니다. 수십 개 항목이 있는 긴 파일은 중요한 내용을 흐리게 만듭니다. 파일을 목차 수준으로 줄이고, 세부 내용은 조건부로 로드되는 문서로 옮깁니다. 규칙이 중요하다면 실행 가능한 검사로 바꿉니다: linter, 테스트, grep-guard, hook. 그러면 위반이 모델의 주의력에 기대지 않고 기계에 의해 드러납니다.

6. 증상을 보고 어떤 구성 요소가 고장 났는지 어떻게 알 수 있나요?

알려진 관례가 어겨지면 지침. 에이전트가 "하고 싶은데 못 한다"면 도구. 매 세션이 환경 수리로 시작되면 환경. 새 세션이 어디서 멈췄는지 모르면 상태. "완료"와 현실이 맞지 않으면 피드백.

7. 하네스를 어느 구성 요소부터 만들며, 이유는 무엇인가요?

피드백부터. "작동하는지 아닌지"를 기계가 알려 주는 명령이 없으면 다른 어떤 변경의 효과도 측정할 수 없습니다. 그다음에는 보통 지침, 상태, 환경, 도구 순이지만, 순서는 경험적이며 어떤 구성 요소가 가장 심하게 고장 났는지에 따라 달라집니다.

8. 하네스의 한 구성 요소가 기여하는 바를 어떻게 측정하나요?

Ablation으로: 모델과 작업 세트를 고정하고, 구성 요소를 하나씩 끄면서 하락을 봅니다. 다만 먼저 병목을 빨리 보여 주는, 계층별로 분류한 실패 기록부터 만드는 것이 좋습니다. 하락이 0이라고 해서 구성 요소가 쓸모없는 것은 아닙니다. 선택된 작업들이 그것을 건드리지 않았거나, 다른 구성 요소의 빈틈을 메우고 있을 수 있습니다.

지침과 context

9. 좋은 AGENTS.md는 어떻게 구성하나요?

교과서가 아니라 라우터처럼: 프로젝트가 무엇인지, 어떻게 실행하고 검사하는지, Definition of Done, 그리고 필수 제약의 짧은 목록. 세부 내용은 "결제 관련 작업이면 읽을 것"처럼 조건을 붙인 링크로 별도 문서에 둡니다. 파일은 불변 조건을 서술하며("데이터는 경계에서 검증한다"), 구현이나 라이브러리를 한 줄씩 지시하지 않습니다.

10. Subagent는 왜 사용하나요?

Context를 격리하기 위해서입니다. 코드베이스 검색, 리뷰, 검사 같은 곁가지 작업은 자기 context에서 수행되고 결과만 돌려줍니다. 주 흐름이 오염되지 않으며, 검사를 맡은 subagent는 실행자의 추론을 물려받지 않으므로 정직한 평가에 중요합니다.

11. "하네스 부채(harness debt)"란 무엇인가요?

하네스와 현실 사이에 쌓인 어긋남입니다: 오래된 규칙, 더 이상 작동하지 않는 명령, 존재하지 않는 모듈에 대한 문서. 기술 부채처럼 조용히 쌓이고, 에이전트의 실패로 대가를 치르게 됩니다. 하네스는 한 번 설정하고 끝내는 것이 아니라 정기적으로 점검해야 합니다.

상태와 세션

12. 에이전트의 세션 간 건망증은 어떻게 다루나요?

상태를 저장소에 둡니다: PROGRESS.md(상태, 완료한 일, 막힌 부분, 다음 단계), DECISIONS.md(결정, 이유, 기각된 대안), 상태가 있는 기능 목록, 잦은 커밋. 지침에 시작 순서를 정해 둡니다: 진행 상황을 읽고, 환경 점검 스크립트를 실행하고, 활성 기능을 가져오기.

13. WIP=1 규칙은 왜 필요한가요?

에이전트가 여러 기능을 동시에 시작하면 상태가 흩어집니다: 아무것도 끝나지 않고, 변경이 서로 섞이고, 되돌리기가 어려워집니다. 활성 기능이 하나면 명확한 검사 지점, 깔끔한 커밋, 실패 후 간단한 복구가 가능합니다.

14. "콜드 스타트 테스트"란 무엇인가요?

새 세션이 사람의 도움 없이 기본적인 질문에 답할 수 있는지 확인하는 것입니다: 이 프로젝트는 무엇인지, 어디서 멈췄는지, 어떤 기능이 활성인지, 모든 것이 정상인지 어떻게 확인하는지. 에이전트가 추측 없이 파일에 근거해 답하면 상태 구성 요소가 제대로 작동하는 것입니다.

검증

15. 초록색 unit 테스트가 기능이 작동한다는 것을 왜 증명하지 못하나요?

Unit 테스트는 모듈을 격리하고 의존성을 mock으로 대체하므로 연결부를 보지 못합니다: 인터페이스 불일치, 상태 전파(스키마는 바뀌었는데 캐시는 옛것), 자원 누수, 설정과 환경 문제. Unit 테스트가 잡는 결함은 integration 테스트가 잡는 결함의 부분집합이고, integration 테스트가 잡는 결함은 E2E가 잡는 결함의 부분집합입니다.

16. Verification gap이란 무엇이며 어떻게 계산하나요?

에이전트가 "완료"라고 보고했지만 독립된 검증이 확인하지 못한 작업의 비율입니다. 최근 10개 작업을 골라 각각에 대해 두 가지 사실을 기록합니다. 이 지표는 기준선을 제공합니다: 하네스를 바꾼 뒤 비슷한 작업 세트에서 다시 계산합니다.

17. 에이전트를 위한 Definition of Done은 어떻게 작성하나요?

AGENTS.md에 검증 가능한 항목의 목록으로: 검사 명령이 코드 0으로 끝남, 기능에 대한 E2E가 존재함, migration이 적용됨, 진행 상황이 갱신됨. 완료로 인정되지 않는 것도 명시하면 유용합니다: "보기에 맞다", "unit 테스트가 통과한다", "내 로컬에서는 된다".

18. 에이전트가 왜 스스로 "완료" 표시를 하면 안 되나요?

모델은 자기 작업을 과대평가하는 경향이 있고, 이런 자기 평가는 결정이 내려진 바로 그 context 안에서 이루어집니다. passing 표시는 검증 스크립트가 실행 결과에 따라 찍어야 하며, 커밋 해시를 증거로 기록해야 합니다.

19. 독립 평가자는 어떻게 구성하나요?

요구사항, diff, 실행 결과만 보고 실행자의 추론은 보지 않는 별도의 에이전트나 세션입니다. 루브릭(정확성, 아키텍처, 테스트, 오류 처리)으로 평가하고, 각 판단은 파일, 줄, 로그를 인용합니다. 맹점이 겹치지 않도록 가능하면 다른 모델을 씁니다.

20. 아키텍처 규칙을 실행 가능하게 만들려면 어떻게 하나요?

세 단계: grep-guard(빠르고, 패턴 기반), import 그래프를 이해하는 linter 규칙(import-linter, dependency-cruiser), CI의 아키텍처 테스트. 셋 모두 make check에 포함되고, 0이 아닌 코드로 실패하며, 에이전트가 스스로 위반을 고칠 수 있도록 WHY와 FIX를 출력합니다. 새 검사를 추가하는 신호는 같은 리뷰 코멘트가 두 번째로 나올 때입니다.

자율 작업

21. 에이전트를 몇 시간 동안 일하게 두려면 무엇이 필요한가요?

명확한 목표, 단조 증가하는 진행 지표(예: passing 상태인 기능 수), 기능당 시간과 시도 횟수 예산, 회귀 시 자동 롤백, 그리고 사람이 맡아야 할 일의 목록: migration, 인프라, 돈. 또한 격리도 필요합니다: sandbox나 별도의 git worktree로 오류가 작업 환경에 닿지 않게 합니다.

22. 단일 에이전트 순환으로 충분하지 않을 때는 언제이고, 역할 그래프는 어떻게 구성하나요?

실행자가 스스로를 검사하기 시작해 막힐 때입니다. 그럴 때는 작업을 역할로 나눕니다: 구현, 리뷰, 테스트, 머지. 리뷰는 깨끗한 context와 루브릭을 받고, 머지는 review == pass일 때만 실행됩니다. 리뷰가 실패하면 기능은 구현 단계로 돌아가고, 여러 번 실패하면 깨끗한 context에서 다시 시작합니다. 그 시점의 문제는 코드가 아니라 작업의 이해에 있기 때문입니다.

마무리

Harness engineering 면접에서 가장 강한 답은 검증 가능한 답입니다: 어떤 파일, 어떤 명령, 어떤 지표인지. 다섯 구성 요소, verification gap, "완료 표시는 스크립트가 한다"는 원칙을 머릿속에 두세요. 이 주제들은 모두 실제 프로젝트에서 하나의 하네스로 묶어 실습 과정에서 가르칩니다.