AI 시대, 개발은 어떻게 바뀌는가

프롬프트 엔지니어링에서 하네스 엔지니어링까지, 그리고 제 생각

이

이승재 · NHN AD

플랫폼서비스랩 · 2026년 6월 · 약 7분

들어가며

안녕하세요. NHN AD 플랫폼서비스랩의 이승재입니다. 이번 글에서는 전통적인 개발에서 하네스 엔지니어링까지의 변화와, 그에 대한 제 생각을 나눠보려 합니다.

손으로 벽돌 쌓기

제 첫 코딩은 2018년 대학에서 시작됐습니다. 소프트웨어 융합대학 소속이라 C언어와 파이썬을 필수로 배워야 했는데, 이중 for문 별찍기와 포인터를 만나기 전까지는 ‘나는 코딩 천재 아닐까?’ 하는 착각도 했습니다. 그 시절의 코딩이란 구글링과 선배들을 통해 알음알음 배워가는, 벽돌을 한 장 한 장 쌓아 프로그램을 올리는 일이었습니다.

구글링으로 방법을 찾고, 코드를 직접 타이핑하던 시절

하지만 지금은 어떤가요? 개발자들은 더 이상 구글링하지 않고, 코드를 한 줄씩 쓰지도 않습니다. 모든 일의 시작과 끝에 AI가 있고, 개발자의 역할도 ‘코드를 작성하는 사람’에서 ‘문제를 정의하고 해결하는 사람’으로 바뀌었습니다. 실제로 저는 NHN AD 입사 이후 코드를 단 한 줄도 직접 쓴 적이 없습니다.

코드를 직접 쓰지 않는다면, 개발자는 무엇을 해야 할까요?

벽돌을 더 잘 쌓는 법

제 AI 사용은 2023년, NHN Academy에서 공부하던 무렵 시작됐습니다. 유튜브와 인스타그램만 켜도 이력서 프롬프트, 글쓰기 프롬프트, 개발 프롬프트가 넘쳐나던 시기였죠. 저도 그 흐름을 따라, 늘 이런 지시문부터 적었습니다.

Prompt Engineering — 모델에게 ‘어떤 말’을 할지가 전부였다

이런 방법론을 Prompt Engineering이라 부릅니다. 주된 관심사는 단 하나, ‘모델에게 어떤 말을 해야 하나’였습니다. 역할을 부여하고, 상황과 원하는 바를 최대한 자세히 설명하는 방식이죠. 직관적이고 효과도 좋아서, NHN AD 서비스에도 Few-Shot과 ReAct 프롬프팅이 적용되어 있습니다.

Instruction과 스키마가 에이전트의 행동을 규정한다 · 서비스 특화 내용은 제외한 일반 구조

저는 오랜 기간 이 방식에 머물렀습니다. 대부분의 코드는 손으로 쓰고, 막히거나 어려운 개념이 나오면 그때 AI에게 물어보는 식이었죠.

벽돌 쌓는 시대의 종말

그러던 2025년, 저를 바꾼 사건이 있습니다. 바로 Claude Code입니다. GUI에서 CLI로, 그리고 Prompt Engineering에서 Context Engineering으로의 전환이었습니다.

예전에는 필요한 코드와 파일을 제가 직접 채워 넣고 프롬프트로 모델을 제어했습니다. 하지만 Claude Code 이후로는 AI가 파일시스템과 도구에 직접 접근해, 스스로 파일을 읽고 코드를 고치고 테스트를 돌립니다. 관심사도 ‘어떤 말을 할까’에서 ‘어떤 정보를 넣을까’로 옮겨갔습니다.

경로와 파일·함수만 가리키면, 에이전트가 직접 읽고 고치고 검증한다

핵심 사항과 제약, 메모리를 파일에 나눠 적어두고 MCP로 도구를 연결해, 필요할 때 필요한 만큼만 가져오게 했습니다. 그 무렵 제 머릿속엔 “개발자 필요 없겠는데, 취업 어떡하지?”와 “이제 진짜 빠르게 만들 수 있겠는데?”가 동시에 맴돌았습니다. 이때쯤부터 코드를 직접 치는 빈도가 줄었고, 면접에서도 Claude Code, 에이전트와 스킬, 컨텍스트 윈도우를 묻기 시작하던, Context Engineering의 시대였습니다.

Claude Code, 에이전트와 스킬, 컨텍스트 윈도우

죽은 벽돌, 살아있는 설계

2026년 현재는 하네스 엔지니어링의 시대로 보입니다. 뼈대는 Context Engineering과 비슷하지만, 한층 세련된 방식으로 시스템 자체를 설계합니다. 시스템 프롬프트를 정의하고, 서브 에이전트를 쓰며, 결정론적인 부분과 비결정론적인 부분을 나눠 관리합니다. 에이전트가 엇나가지 않게 Rule로 통제하고, 가이드를 무시하더라도 린트·타입체크·컴파일이 기계적으로 잡아내도록 강제합니다.

아래는 제가 업무에서 사용하는 구조입니다. 작업을 역할별 에이전트에 나눠 맡기고, 검증에서 나온 실수는 그때그때 고치는 데 그치지 않고 스킬·메모리·Rule에 되먹여 다시 일어나지 않게 합니다.

역할별 에이전트가 계획→구현→검증→통합→정리를 나눠 맡고, 실수는 스킬·메모리·Rule로 되먹인다 · 사내 구현은 제외한 일반 구조

repo/
├─ .claude/
│   ├─ commands/   new-feature · new-bugfix · new-hotfix …
│   ├─ agents/     pm · 백엔드 · 프론트 · 인프라 · qa · 리뷰어 · git · 정리
│   └─ skills/     반복 작업·노하우를 박제
├─ ai/          에이전트 · 람다 · 배치
├─ app/
├─ domains/     도메인 로직
├─ modules/     api-client · db-client · storage-client
├─ infra/       IaC · 배포
├─ docs/        spec · 설계 기록
├─ scripts/
└─ .legacy/     오래된 산출물 이관

폴더 예시 — 커맨드·에이전트·스킬과 작업 산출물이 한 저장소 안에서 함께 관리된다 · 사내 내용은 제외한 일반 구조

이제 저는 코드를 한 줄씩 쓰지도, 매번 긴 프롬프트를 새로 적지도 않습니다. 해야 할 일을 정의해 두면 에이전트가 스스로 필요한 파일을 읽고, 코드를 고치고, 테스트를 돌려 결과를 확인합니다. 제 역할은 무엇을 만들지 정의하고, 그 결과를 검증하는 일로 좁혀졌습니다.

앞으로의 여정

저는 지금 공모전 하나를 자동으로 진행하는 실험을 돌리고 있습니다. 매일 정해진 시각이 되면 제 노트북의 LaunchAgent가 헤드리스 Claude를 깨우고, 그날 할 일을 스스로 정리해 작업을 수행한 뒤, 자기 결과를 다시 검토하고, 하루치 리포트를 남기고 잠듭니다. 제가 손대지 않아도 다음 날 또 같은 일이 반복됩니다.

매일 스스로 깨어나 할 일을 정리하고, 수행하고, 검토하고, 리포트를 남기는 하루 단위 자동 루프

공모전 자동 진행 저장소 — 매일 task 생성·실행·자가 검증·리포트 누적 — 매일 task를 생성하고 실행한 뒤, 스스로 검증하고 리포트를 누적한다

그 결과로, 제가 직접 커밋하지 않은 날에도 저장소에는 날짜별 작업 기록이 차곡차곡 쌓여 있습니다.

매일 누적된 일자별 커밋 — 사람과 에이전트가 함께 author로 기록된다 — 사람과 에이전트가 함께 author로 남은, 일자별로 누적된 커밋

앞으로는 이 구조를 다듬어, 전자정부 표준프레임워크에 기여하는 시스템을 구축해보려 합니다. 잘 설계된 시스템이라면, 남이 만든 실제 코드베이스에 스스로 기여를 남기는 데까지 갈 수 있을 거라 생각합니다. 전자정부프레임워크 오픈 커뮤니티에서 그 여정을 이어가 보려 합니다.

읽어주셔서 감사합니다.

참조

Addy Osmani — Loop Engineering
Addy Osmani — Agent Harness Engineering
Addy Osmani — The Factory Model
Peter Steinberger — github-project-triage SKILL.md
Peter Steinberger — maintainer-orchestrator SKILL.md
Jonas Kim — 프롬프트에서 하네스까지 — AI 에이전틱 패턴 4년의 기록
YouTube — 관련 영상