
연재: AI에 일자리를 빼앗길 불안에서 시작하는 하네스 작성 입문 제5회 - SE의 설계 경험을 AI 에이전트 제어에 전용하기
요약
SE(Software Engineer)의 설계 경험을 AI 에이전트 제어 메커니즘인 '하네스(Harness)' 설계에 전용하는 방법을 다룹니다. 요구사항 정의, 책임 분리, 사양 구조화 등 기존 엔지니어링 역량이 AI 에이전트의 안정적인 동작을 제어하는 데 핵심적인 역할을 함을 강조합니다.
핵심 포인트
- SE의 설계 역량은 AI 에이전트 제어 설계의 강력한 기반이 됨
- AI 에이전트 제어는 문맥을 모르는 신입 엔지니어를 관리하는 것과 본질적으로 유사함
- 요구사항 정의, API 연동 설계 경험은 AI task_request 설계로 직접 전용 가능
- AI 시대에도 기존 소프트웨어 엔지니어링의 구조적 사고는 여전히 유효함
연재: AI에 일자리를 빼앗길 불안에서 시작하는 하네스 작성 입문
전 24회 (주 2회 · 12주간) | 제5회 / 24
이 연재는 AI에 일자리를 빼앗길지도 모른다는 불안을 '하네스(AI 에이전트 제어 메커니즘)'를 직접 만드는 행동으로 바꾸는 시리즈입니다.
"지금까지 쌓아온 SE 경험이 AI 시대에는 통하지 않게 되지 않을까" —— 이런 불안을 느껴본 적이 없으신가요?
새로운 기술이 등장할 때마다 '제로 베이스에서 다시 배워야' 하는 것이 아닐까 생각하면, 지금까지의 경험이 부정당하는 듯한 기분이 들 때가 있습니다. 하지만 결론부터 말씀드리면, SE 경험자가 가진 스킬셋은 AI 에이전트 제어(하네스 설계) 분야에서 큰 어드밴티지(Advantage)가 됩니다.
지난 회차(제4회)에서는 task_request / task_result라는 AI와의 '계약'을 정의하는 사고방식을 배웠습니다. 이번에는 그 계약을 설계하는 '당신 자신의 기술'에 초점을 맞춥니다.
- SE·프로그래머로서 3년 이상의 실무 경험이 있는 분
- 요구사항 정의, 설계서 작성, 코드 리뷰 등의 경험이 있는 분
- AI 시대에 자신의 기술이 진부해질까 봐 불안을 느끼는 분
- 지난 연재를 읽어온 분 (읽지 않았더라도 이해할 수 있는 구성입니다)
SE 경험자가 가진 **「요구사항을 정리하는 힘」 「책임을 분리하는 힘」 「사양을 구조화하는 힘」**은 AI 에이전트 제어 설계에 거의 그대로 전용(Transfer)할 수 있습니다. 오히려 이러한 기술이 없다면 AI를 안전하고 효과적으로 제어하는 하네스는 만들 수 없습니다. 새로 배워야 할 것은 AI 고유의 지식(프롬프트 설계, 토큰 제약 등)뿐이며, 설계의 토대는 이미 당신 안에 있습니다.
AI 에이전트(LLM 기반 툴)는 지시가 모호하면 의도하지 않은 동작을 합니다. 이는 인간 개발 팀에서도 마찬가지입니다. 요구사항 정의가 모호한 프로젝트가 파국(炎上)을 맞는 것처럼, AI에 대한 지시가 모호하면 '폭주'합니다.
즉, AI 에이전트의 제어는 「우수하지만 문맥을 모르는 신입 엔지니어에 대한 지시 설계」와 본질적으로 같습니다. SE 경험자는 이 '지시 설계'를 일상적으로 해온 사람들입니다.
이하에 SE 경험이 AI 하네스 설계에서 구체적으로 어떻게 활용되는지에 대한 판단 기준을 제시합니다.
- 「이 경험은 AI 제어에 전용할 수 있을까?」라고 망설여진다면 → 「팀 개발에서 동일한 과제가 있었는가?」를 생각한다
- 팀 개발에서 필요했던 기술은 거의 모두 AI 에이전트 제어에도 필요하다
- 차이점은 「상대가 인간인가, AI인가」뿐이다
다음 대응표는 SE 경험과 AI 하네스 설계의 전용 맵입니다. 이번 회차의 주요 성과물로서 꼭 저장해 두시기 바랍니다.
| SE 경험 (스킬) | AI 하네스로의 전용처 | 전용 포인트 |
|---|---|---|
| 요구사항 정의 | task_request의 설계 | AI에게 「무엇을」 「어디까지」 시킬지를 구조화한다 |
| ... |
다음 Mermaid 다이어그램은 SE 경험이 어떻게 AI 하네스 설계로 흘러가는지를 보여줍니다.
실제로 어떻게 전용하는지 한 가지 예를 살펴보겠습니다.
기존의 시스템 개발에서 외부 API와 연동하는 기능을 설계할 때, 당신은 다음 사항들을 생각합니다.
- 입력 데이터의 형식과 제약 (필수 항목, 타입, 길이)
- 출력 데이터의 형식과 기대값
- 에러 발생 시의 동작 (타임아웃, 재시도, 폴백 (Fallback))
- 전제 조건과 사후 조건
AI 에이전트에 대한 지시(task_request)를 설계할 때도 생각하는 것은 같습니다.
{
"task_request": {
"task_type": "article_generation",
...
외부 API 연동 설계 경험이 있는 분이라면, "이거 하는 일은 똑같네"라고 느낄 것입니다. 차이점은 상대가 REST API가 아니라 LLM이라는 점뿐입니다.
전용 시 주의해야 할 포인트를 정리합니다.
| 주의점 | 이유 | 대책 |
|---|---|---|
| AI의 출력은 비결정적 (Non-deterministic) | 동일한 입력이라도 매번 다른 출력이 반환됨 | 출력의 유효성 검사(Validation) 규칙을 명확히 한다 |
| ... |
다음 체크리스트를 사용하여 자신의 SE 경험 중 '전용 포인트'를 찾아보세요.
- 위의 대응표를 확인하고, 자신이 특히 강점이 있는 SE 경험을 3가지 선택한다
- 선택한 3가지에 대해 「AI 하네스에서 어떻게 쓸 수 있는가」를 한 줄씩 메모한다
- 가장 전용하기 쉬워 보이는 기술을 하나 골라 첫 번째 전용 포인트로 삼는다
- 선택한 전용 포인트를 「task_request의 어느 부분에 반영할 것인가」를 메모한다
- (발전) 팀 내에서 「SE 경험 × AI 활용」 스터디 주제로 공유한다
이번에는 SE 경험이 AI 에이전트 제어(하네스 설계)에 어떻게 전용될 수 있는지를 대응표로 나타내 보았습니다.
핵심 포인트 (Key Points)
- SE 경험자의 스킬은 AI 하네스 설계에 「그대로 사용할 수 있는」 부분이 많다
- 특히 「요건 정의 (Requirements Definition)」「책임 분리 (Separation of Concerns)」「테스트 설계 (Test Design)」는 직접 전용 가능하다
- 새롭게 배워야 할 것은 AI 고유의 제약 사항 (비결정성 (Non-determinism), 토큰 제한 (Token Limit) 등)뿐이다
- 「팀 개발에서 필요했던 스킬 $\approx$ AI 제어에서 필요한 스킬」이라고 생각하면 판단하기 쉽다
여러분의 커리어는 헛되지 않습니다. 오히려 AI 에이전트를 「제어할 수 있는 쪽」으로 가기 위한 최대의 무기입니다.
**제6회 「하네스용 디렉터리 구성과 README 만들기」**에서는 드디어 구현에 들어갑니다.
-
하네스 프로젝트의 디렉터리 구성안 (SE적인 관점에서 설계)
-
README.md의 구조와 작성해야 할 내용
-
.gitignore및 라이선스 파일 등 처음에 설정해야 할 파일들 -
복사해서 바로 쓸 수 있는 디렉터리 구성 템플릿
-
README.md의 초안 (Template)
-
GitHub 계정 준비 (아직 없는 분은 미리 생성해 둘 것)
-
선호하는 코드 에디터 (VS Code 권장) 설정
-
이번 대응표를 메모로 남겨두기 (다음 회차부터 설계의 지침으로 사용합니다)
| 회차 | 제목 | 상태 |
|---|---|---|
| 제1회 | 「AI에게 일을 빼앗긴다」는 불안의 정체를 분해하기 | ✅ |
| ... |
연재: AI에 일자리를 빼앗길 불안에서 시작하는 하네스 작성 입문**
저자: @and-and-and | 주 2회 업데이트
다음 회차는 「하네스용 디렉터리 구성과 README 만들기」를 예정하고 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기