연재: AI에 일자리를 빼앗길 것이라는 불안으로부터 시작하는 하네스 작성 입문

전 24회 (주 2회 · 12주간) | 제1회 / 24
이 연재는 AI로 인한 커리어 불안을 느끼는 프로그래머 · SE를 대상으로, AI 에이전트(AI Agent)를 안전하게 제어 · 검증 · 운용하기 위한 '하네스(Harness)'를 만드는 기술을 단계적으로 배우는 시리즈입니다.

이 기사는 연재 「AI에 일자리를 빼앗길 것이라는 불안으로부터 시작하는 하네스 작성 입문」의 제1회입니다.

이번에는 AI 시대의 커리어 불안을 정리하고, '하네스 작성'이라는 학습 방침을 소개하는 테마에 대해 정리합니다.

이 기사에서 다루는 불안은 다음과 같습니다.

AI에 의해 기존의 구현 작업이나 설계 보조가 대체되어, 나의 시장 가치가 떨어지는 것은 아닐까. 무엇을 배워야 할지 모르겠다.

이런 불안을 느끼는 것 자체는 자연스럽습니다. AI 코딩 에이전트(AI Coding Agent)나 생성형 AI(Generative AI)의 진화는 확실히 프로그래머나 SE의 작업 영역에 영향을 주고 있습니다.

하지만 이 기사에서는 '어떻게 하면 살아남을 수 있는가'가 아니라, '지금 있는 경험을 사용하여, AI를 업무에서 안전하게 구동하는 메커니즘을 만드는 쪽으로 옮겨갈 수 있는가'라는 방향으로 정리합니다.

• AI에게 자신의 구현 작업이 대체될까 봐 불안을 느끼는 프로그래머
• 생성형 AI 시대의 커리어에 불안이 있는 SE
• AI를 '사용'하는 것뿐만 아니라 '안전하게 운용하는 기반을 만드는' 쪽으로 옮기고 싶은 엔지니어

결론부터 말씀드리면, AI 에이전트를 단독으로 사용하는 것이 아니라, 업무 성과로 안전하게 연결하기 위한 '하네스'를 만드는 기술을 배우는 것이 기존의 SE · 프로그래머 경험을 살릴 수 있는 방향성 중 하나입니다.

요점은 다음과 같습니다.

• AI에 대체되는 작업만을 보는 것이 아니라, AI를 제어 · 검증 · 운용하는 영역을 본다
• SE · 프로그래머가 가진 설계 · 테스트 · 운용 경험은 AI 하네스 설계에서 재사용할 수 있다
• 작은 하네스부터 시작하여, Qiita 기사와 GitHub 결과물로서 학습 과정을 가시화한다

생성형 AI나 AI 코딩 에이전트의 진화에 따라 코드 생성, 설계서 초안 작성, 테스트 코드 생성 등 지금까지 프로그래머나 SE가 담당해 온 작업의 일부가 AI에게 위임 가능해지고 있습니다.

이 변화를 보며 '내 일자리가 없어지는 것은 아닐까'라고 느끼는 것은 자연스러운 반응입니다.

하지만 AI를 업무에서 사용하려고 하면 다음과 같은 과제가 발생합니다.

• AI의 출력이 올바른지 여부에 대한 검증이 필요
• 기밀 정보를 어떤 LLM(Large Language Model)에 전달해도 되는지에 대한 판단이 필요
• AI의 작업 결과를 누가 승인할 것인지에 대한 설계가 필요
• 여러 AI 에이전트나 도구를 연계시키는 메커니즘이 필요
• 장애가 발생했을 때의 재현 · 원인 조사를 위한 로그(Log) 설계가 필요

이것들은 AI를 '사용'하는 것만으로는 해결할 수 없습니다. AI를 '업무에서 안전하게 구동하기 위한 기반'을 설계 · 구축하는 사람이 필요합니다.

이 기반을 이 연재에서는 '하네스(Harness)'라고 부릅니다.

'하네스'란 본래 테스트 주도 개발(TDD)에서의 '테스트 하네스(Test Harness)'나, 전기 배선에서의 '와이어 하네스(Wire Harness)'에서 유래한 개념입니다.

이 연재에서의 'AI 하네스'는 다음을 통합하는 제어 · 운용 기반을 가리킵니다.

• AI 에이전트 (AI Agent): 태스크를 실행하는 존재
• MCP 서버 (MCP Server): AI에게 전달하는 도구 상자 (도구군)
• Knowledge / RAG: AI가 참조하는 지식 기반
• 로그 / 감사 (Log / Audit): 실행 결과를 기록하고 재현 가능하게 함
• Human-in-the-loop: 중요한 판단에서 인간이 승인하는 메커니즘
• 입출력 계약 (I/O Contract): AI에 대한 지시와 결과를 구조화함

AI 시대에 새로운 기술을 처음부터 배워야 한다고 생각할 수도 있지만, 하네스 설계에 필요한 사고방식의 상당 부분은 SE · 프로그래머가 실무에서 익히고 있는 것입니다.

실무 경험을 가진 사람일수록 'AI가 무엇을 해야 하는가'뿐만 아니라, 'AI가 틀렸을 때, 멈췄을 때, 위험할 때 어떻게 할 것인가'를 설계할 수 있습니다.

이 도표는 연재 전체를 통해 확장해 나갈 예정입니다. 이번에는 전체상을 파악하는 데 집중합니다.

먼저, 자신의 불안을 정리해 봅시다. 다음과 같은 표를 만드는 것이 첫 번째 액션이 됩니다.

AI 에이전트 (AI Agent)에게 일을 맡길 때는 자연어뿐만 아니라 구조화된 '계약 (Contract)'을 사용합니다. 다음은 최소한의 task_request 예시입니다.

{
"task_request": {
"task_id": "example_001",
...

이 JSON은 최소한의 예시이며, 실제로는 로그 출력처, 승인 플로우 (Approval Flow), 사용 모델 지정 등이 추가됩니다. 이 연재에서는 회차를 거듭할수록 task_request를 확장해 나갈 것입니다.

• 자신의 불안을 3개 이상 적어보고, '전환 대상'을 하나씩 생각해 보기
• 위의 Mermaid 다이어그램을 자신의 GitHub README에 붙여넣어 보기
• task_request의 JSON을 자신만의 용도로 하나 수정해 보기

이 기사에서는 AI 시대의 커리어 불안을 정리하고, '하네스 작성 (Harness Writing)'이라는 학습 방침에 대해 정리했습니다.

중요한 것은, AI에 의해 대체되는 작업만을 보는 것이 아니라, AI를 안전하고·재현성 높게·업무 성과로 연결하는 메커니즘을 만드는 기술에 주목하는 것입니다.

SE(시스템 엔지니어)·프로그래머로서의 실무 경험은 하네스 설계에 있어 큰 자산입니다. 요구사항 정의, 테스트 설계, 로그 설계, 운용 설계와 같은 경험은 AI 하네스의 핵심을 담당합니다.

제2회: 최소 구성의 AI 하네스를 Mermaid로 설계해 보기 (금요일 공개 예정)

다음 회차에서는 이번에 소개한 하네스의 전체상을 더욱 세분화하여, 최소 구성의 AI 하네스를 Mermaid 다이어그램으로 구체적으로 설계하는 주제를 다룹니다.

다음 회차에서 다룰 내용:

• 전체상에서 '최소한으로 동작하는 하네스'를 도출하는 사고방식
• AI 에이전트 (AI Agent)·MCP 서버·task_request / task_result 3종 세트로 최소 구성 만들기
• Mermaid 다이어그램으로 구성을 가시화하여 GitHub README에 붙일 수 있는 형태로 만들기
• 최소 구성에 포함할 것과 포함하지 않을 것의 판단 기준

다음 회차의 결과물:

• Mermaid 구성도 (최소 AI 하네스 아키텍처 다이어그램)

다음 회차 전까지 시도해 보면 좋은 것:

• 이번 회차의 전체상 Mermaid 다이어그램을 자신의 리포지토리 (Repository)에 붙여넣기
• '자신의 업무에서 AI에게 맡기고 싶은 작업'을 하나만 생각해 두기

연재 정보

• 연재명: AI에게 일을 빼앗기는 불안으로부터 시작하는 하네스 작성 입문 - 총 24회 (12주간, 주 2회)
• 게시 요일: 화요일 (커리어·설계·개념) / 금요일 (구현·검증·템플릿)