
연재: AI에게 일자리를 빼앗길 불안에서 시작하는 하네스(Harness) 작성 입문 제3회 - AI에게 코드를 쓰게 하는 것만으로는 부족한 이유
요약
AI 코딩 에이전트의 코드 생성 능력을 넘어, 이를 실제 업무 성과로 연결하기 위한 '운용(Operation)' 관점의 중요성을 다룹니다. 검증, 로그, 승인, 재현성이라는 4가지 핵심 요소를 통해 AI를 안전하게 제어하는 '하네스(Harness)'의 개념을 소개합니다.
핵심 포인트
- AI 코드 생성과 업무 운용 사이의 격차를 메우는 것이 하네스의 역할임
- 안전한 운용을 위해 검증, 로그, 승인, 재현성 관점이 필수적임
- 단순 사용을 넘어 품질 게이트를 설계하는 운용 역량이 중요함
- SE 및 프로그래머의 기존 경험이 AI 운용의 핵심 자산임
연재: AI에게 일자리를 빼앗길 불안에서 시작하는 하네스(Harness) 작성 입문
전 24회 (주 2회 · 12주간) | 제3회 / 24
이 연재는 AI로 인한 커리어 불안을 느끼는 프로그래머·SE를 대상으로, AI 에이전트(AI Agent)를 안전하게 제어·검증·운용하기 위한 「하네스(Harness)」를 만드는 기술을 단계적으로 배우는 시리즈입니다.
이 기사는 연재 「AI에게 일자리를 빼앗길 불안에서 시작하는 하네스 작성 입문」의 제3회입니다.
제1회에서는 하네스라는 개념을 소개했고, 제2회에서는 최소 구성을 Mermaid 다이어그램으로 설계했습니다. 이번에는 AI를 「사용하는 것」과 「운용하는 것」의 차이에 대해 정리합니다.
이 기사에서 다루는 불안은 다음과 같습니다.
AI 코딩 에이전트(AI Coding Agent)로 코드를 생성하고 있지만, 이를 업무에서 안전하게 사용하려면 무엇이 부족한지 모르겠다.
이러한 불안은 자연스러운 것입니다. AI 코딩 에이전트는 확실히 코드를 생성할 수 있습니다. 하지만 생성된 코드를 그대로 업무에 사용할 수 있는지 여부는 별개의 문제입니다.
이 기사에서는 「코드 생성」과 「업무 운용」 사이에 있는 격차를 밝히고, 그 격차를 메우는 것이 하네스의 역할임을 보여줍니다.
- AI 코딩 에이전트를 사용하여 코드를 작성하고 있지만, 업무에서의 안전한 운용에 불안을 느끼는 프로그래머
- 「AI에게 코드를 쓰게 하는 것」만으로 충분하다고 생각했지만, 무언가 부족하다고 느끼는 엔지니어
- AI를 업무에 도입할 때의 「운용」 관점이 아직 정리되지 않은 SE
결론부터 말씀드리면, AI에게 코드를 쓰게 하는 것은 「AI를 사용하는 것」의 일부이며, 업무 성과로 연결하기 위해서는 「검증」, 「로그」, 「승인」, 「재현성」이라는 운용 관점이 필요합니다.
요점은 다음과 같습니다.
- 「AI에게 코드를 쓰게 하는 것」은 「AI를 사용하는 것」의 입구일 뿐이며, 업무에서는 「운용」이 필요함
- 「운용」에는 검증 · 로그 · 승인 · 재현성이라는 4가지 관점이 있음
- SE · 프로그래머의 운용 경험은 이 격차를 메우는 데 직접적인 도움이 됨
AI 코딩 에이전트는 확실히 강력한 도구입니다. 다음과 같은 일을 할 수 있습니다.
- 자연어 지시로부터 코드를 생성함
- 기존 코드의 리팩터링(Refactoring)을 제안함
- 테스트 코드(Test Code)를 자동 생성함
- 설계서의 초안을 작성함
이것들은 확실히 작업을 효율화합니다. 하지만 이것만으로 업무에 사용할 수 있느냐고 묻는다면, 그렇지 않습니다.
AI가 생성한 코드를 업무에서 사용하려고 하면 다음과 같은 문제가 발생합니다.
| 문제 | 구체적인 예시 |
|---|---|
| 생성된 코드가 맞는지 알 수 없음 | AI가 할루시네이션(Hallucination)으로 존재하지 않는 API를 호출함 |
| ... |
이것들은 모두 「코드 생성」의 후공정에 있는 문제입니다. AI를 「사용」하는 것만으로는 해결할 수 없으며, 「운용하는」 관점이 필요합니다.
이 연재에서 가장 중요한 개념 중 하나가 「사용하는 것」과 「운용하는 것」의 구별입니다. 아래의 역할 비교표가 이번의 가장 중요한 결과물입니다.
| 관점 | AI를 「사용하는 것」 | AI를 「운용하는 것」 (하네스) |
|---|---|---|
| 목적 | 코드나 문서를 생성함 | 업무 성과를 안전하게 전달함 |
| ... |
이 표의 오른쪽(「운용하는 것」 측)이 하네스가 담당하는 영역입니다. 제2회에서 설계한 최소 구성(task_request + AI 에이전트 + MCP 서버)은 이 「운용」의 입구입니다.
「사용」에서 「운용」으로의 격차를 메우는 것은 SE · 프로그래머가 실무에서 일상적으로 수행하고 있는 일입니다.
| 기존 경험 | 「운용」에서의 활용 방법 |
|---|---|
| 코드 리뷰 (Code Review) | AI 생성 코드의 품질 게이트(Quality Gate) 설계 |
| ... |
이러한 경험이 있기 때문에 「AI가 생성한 것을 그대로 사용하는 것은 위험하다」고 느끼는 것입니다. 그 감각은 옳으며, 그것을 설계로 녹여내는 것이 하네스 작성입니다.
「사용」에서 「운용」으로 넘어가기 위해 필요한 4가지 관점을 정리합니다. 이것들은 이 연재의 후반부에서 각각 자세히 다룹니다.
AI는 할루시네이션(Hallucination, 환각)을 일으킬 수 있습니다. 생성된 코드가 올바르게 작동하는지, 보안상의 문제가 없는지 확인하는 메커니즘이 필요합니다.
이는 실무에서의 코드 리뷰나 테스트 설계 경험이 그대로 살아나는 영역입니다. 상세 내용은 제17~18회에서 다룹니다.
AI 에이전트가 무엇을 입력으로 받아 어떤 도구(Tool)를 호출하고 무엇을 출력했는지. 이를 기록해 두지 않으면 문제가 발생했을 때 원인을 추적할 수 없습니다.
장애 대응이나 인시던트 관리(Incident Management) 경험이 있는 사람에게 로그 설계의 중요성은 직관적으로 이해될 것입니다. 상세 내용은 제13~14회에서 다룹니다.
AI의 출력을 그대로 업무에 반영하는 것이 아니라, 중요한 포인트에서 인간이 승인하는 메커니즘이 필요합니다.
릴리스 판정이나 승인 플로우 (Approval Flow) 경험이 있는 사람에게 '어디에 승인 포인트를 넣을 것인가'의 설계는 익숙한 작업입니다. 상세 내용은 제15~16회에서 다룹니다.
AI의 출력은 동일한 프롬프트 (Prompt)라도 결과가 달라질 수 있습니다. task_request에서 지시를 구조화하고 실행 로그 (Execution Log)를 남김으로써, '언제·무엇을·어떻게 지시해서·무엇이 돌아왔는가'를 재현 가능하게 만듭니다.
이는 제4회의 task_request / task_result 설계와 제13~14회의 로그 설계에서 구체화합니다.
| 주의점 | 이유 | 대책 |
|---|---|---|
| 「운영」을 처음부터 완벽하게 하려 하지 말 것 | 전부 갖춘 뒤에 시작하려고 하면 영원히 시작할 수 없음 | 제2회의 최소 구성부터 시작하여 단계적으로 추가한다 |
| ... |
- 위의 역할 비교표를 자신의 업무에 대입하여, 「운영」이 필요한 포인트를 하나 특정해 보세요.
- AI에게 코드를 작성하게 한 경험이 있다면, 「무엇이 부족했었는지」를 써 보세요.
- 제2회의 Mermaid 도표에 「검증」, 「로그」, 「승인」 중 무엇을 가장 먼저 추가하고 싶은지 생각해 보세요.
이 기사에서는 AI를 「사용하는 것」과 「운영하는 것」의 차이를 정리했습니다.
중요한 것은, 코드 생성은 「AI를 사용하는 것」의 입구일 뿐이며, 업무 성과로 연결하기 위해서는 「검증」, 「로그」, 「승인」, 「재현성」이라는 운영 관점이 필요하다는 점입니다.
SE·프로그래머가 실무에서 수행하는 코드 리뷰 (Code Review), 장애 대응, 승인 플로우, 보안 설계의 경험은 이 격차를 메우는 데 직접적인 도움이 됩니다.
제4회: task_request / task_result로 AI 에이전트의 업무를 계약화하기 (금요일 공개 예정)
다음 회차에서는 하네스 (Harness)의 핵심인 task_request / task_result의 설계를 자세히 다룹니다.
다음 회차에서 다룰 내용:
- task_request의 필수 필드와 옵션 필드
- task_result의 상태(Status)·출력·에러 핸들링 (Error Handling)
- 「계약」으로서의 JSON 스키마 (Schema) 설계
다음 회차의 결과물:
- JSON 템플릿 (task_request / task_result의 견본)
다음 회차 전까지 시도해 보면 좋은 것:
- 이번 역할 비교표를 살펴보며, 자신의 업무에서 「운영」이 부족한 포인트를 특정하기
- 제1회에서 소개한 최소 task_request JSON을 자신의 태스크에 맞춰 다시 써 보기
| 회차 | 제목 | 상태 |
|---|---|---|
| 1 | AI에게 일자리를 빼앗길 불안에서 시작하는 하네스(Harness) 작성 입문 | ✅ |
| 2 | 최소 구성의 AI 하네스를 Mermaid로 설계해 보기 | ✅ |
| 3 | AI에게 코드를 쓰게 하는 것만으로는 부족한 이유 (이 기사) | 📖 |
| 4 | task_request / task_result로 AI 에이전트의 업무를 계약화하기 | 다음 회차 |
| 5 | SE의 설계 경험을 AI 에이전트 제어에 전용하기 | ─ |
| 6 | 하네스용 디렉토리 구성과 README 만들기 | ─ |
| ... | 총 24회의 연재를 예정하고 있습니다 | ─ |
연재 정보
- 연재명: AI에게 일자리를 빼앗길 불안에서 시작하는 하네스 작성 입문 - 총 24회 (12주간·주 2회)
- 게시 요일: 화요일 (커리어·설계·개념) / 금요일 (구현·검증·템플릿)
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기