숭실대학교 소프트웨어특강2

AI Agent 시대와
인간 개발자의 역할

에이전트에게 맡길 것, 사람이 쥘 것 — 내 장애 기록으로 보는

PASS T03 all ArgoCD apps Synced+Healthy

실제로는 ArgoCD 앱이 0개였다.

2026-10-14 (수)

cne.io.kr

오늘의 순서

항목을 누르면 해당 장으로 이동한다. 구간 2~4가 본론이다.

0도입 — 먼저 답 · 학습목표3~4장 1나의 AI 여정5~10장 2에이전트란 무엇인가11~18장 · 25분 3에이전트가 조용히 틀리는 방식19~30장 · 25분 · 사례 1~4 4인간과 AI의 역할 분담31~39장 · 23분 · 사례 5 →마무리 — 오늘 밤 체크리스트와 과제40장 부록용어집 · 사례 6 · 사례 5 숫자41~49장

AI Agent 시대와 인간 개발자의 역할

먼저 답: 에이전트는 초안·반복·탐색, 사람은 목표·기준·승인

오늘 주제에 먼저 답하고, 오늘 사례로 확인한다.

1

에이전트에게 맡길 것 — 초안 작성, 반복 검증 실행, 조사·탐색

2

사람이 쥘 것 — 목표와 기준, 승인(책임은 승인·배포 권한을 가진 사람과 조직에 있다), 재발 방지 장치

→

오늘 사례 5건(실패 4건 + 기여 1건)으로 확인한다.

주석 재발 방지 장치 판별 기준·회귀 테스트처럼 같은 실패가 다시 나오지 않게 막는 검사.

학습목표 4개

이 자료를 다 읽고 나면 아래 네 가지를 할 수 있습니다.

1

AI 에이전트의 동작 원리(도구 선택·호출, 컨텍스트·하네스, 멀티 에이전트)를 설명할 수 있다.

2

에이전트 개발 환경(모델·컨텍스트·하네스)을 구성 수준에서 설명할 수 있다.

3

에이전트가 조용히 틀리는 방식을 알고, "완료" 보고를 증거로 검증할 수 있다.

4

인간과 AI의 역할 분담(맡길 것/쥘 것, 책임과 예방)을 설명하고 자기 프로젝트에 적용할 수 있다.

주석 멀티 에이전트 여러 AI 에이전트가 역할을 나눠 일하는 방식.

나의 AI 여정내 경험

AI를 쓰는 방식은 이렇게 바뀌었다

내가 AI를 쓴 순서를 6단계로 정리했다. 도구 이름보다 쓰는 방식이 달라졌다.

1

ChatGPT

이미지를 지브리 스타일로 바꿔 보며 흥미 위주로 썼다

2

Perplexity

무료 이벤트(약 1.5년). 검색하고 복사·붙여넣기 위주로 썼다

3

Claude Pro

저녁에 잠깐씩. Claude CLI(Claude Code)로 에이전트 개발을 시작했다

4

Gemini Pro

1년 구독(큰 폭 할인). Gemini CLI → Antigravity CLI로 개발에 적응했다

5

Claude Max 5x

본격 개발. 여러 OSS를 만들고 eGovFrame에도 기여했다

6

ChatGPT Plus

무료 이용권. Codex CLI로 에이전트끼리 팀을 이뤄 서로 보완하게 썼다

쓰는 방식의 변화

재미

검색

시켜 보기

적응

본격 개발

팀으로

나의 AI 여정내 경험

①~③ 보여 주기에서 시켜 보기로

쉽게 말하면 AI에게 맡기는 일이 "받기"에서 "고르기"를 거쳐 "시키기"로 커졌다.

① 결과만 받는 사용

ChatGPT · 이미지 변환

AI가 만든 결과를 받아 본다.

비유: 사진관에 맡기고 완성된 사진을 받는 것.

→

② 내가 판단하는 사용

Perplexity · 검색

AI가 찾은 내용을 내가 읽고, 골라서 복사·붙여넣는다.

비유: 사서가 자료를 찾아 오면 내가 읽고 고르는 것.

→

③ 에이전트 사용

Claude Pro · Claude CLI(Claude Code)

AI가 직접 파일을 읽고, 고치고, 명령을 실행한다.

비유: 일을 맡기면 직원이 직접 파일을 열어 고치고 실행해 보는 것.

③의 어려움

쓸 수 있는 토큰이 적어 힘들었다. 그래도 이때부터 CLI로 개발하기 시작했다.

주석 CLI Claude Code·Gemini/Antigravity CLI·Codex CLI처럼 명령어 창에서 쓰는 AI 개발 도구.주석 에이전트 AI가 직접 파일을 읽고 고치고 명령을 실행하는 방식의 도구.주석 토큰 AI가 읽고 쓰는 글자 조각의 단위이자 사용량 한도의 기준.

나의 AI 여정내 경험

④ 적응, 그리고 한도의 현실

Gemini Pro 1년 구독(큰 폭 할인). Gemini CLI → Antigravity CLI로 CLI 개발에 조금씩 적응하던 시기였다.

구독 초창기

토큰을 넉넉히 줬다.
쓸 만했다.

→

나중에

많이 아쉬웠다.

한 줄 정리

한도와 조건은 시간이 지나며 바뀐다. 한 도구에 기대지 않는 구성이 필요했다.

주석 구독 정해진 기간 동안 요금을 내고 서비스를 쓰는 방식.주석 토큰 AI가 읽고 쓰는 글자 조각의 단위이자 사용량 한도의 기준.주석 Antigravity CLI Google의 코딩 에이전트 도구. Gemini CLI는 2026-06-18 Antigravity CLI로 대체됨(geminicli.com 문서, 2026-10-05 확인).

나의 AI 여정내 경험

⑤ 본격 개발: 만들고, 기여하다

Claude Max 5x로 본격 개발을 시작해 여러 OSS를 만들었고, eGovFrame에도 기여했다.

github.com/dasomel

29

공개 저장소
(포크 제외)

20

그중 2026년에
만든 저장소

GitHub 생성일 기준 · 2026-10-11 조회

eGovFrame 기여: PR 485건

병합 222

병합 없이 닫힘 263

열림 0건. 2026-10-05 조회.

이 숫자만으로 AI 효과를 말할 수는 없다. 사례는 사례 5(33·34장), 숫자는 부록 49장.

주석 OSS 오픈소스 소프트웨어. 소스코드가 공개되어 누구나 보고 고칠 수 있는 소프트웨어.주석 eGovFrame 전자정부 표준프레임워크. 공공 소프트웨어 개발에 쓰는 공통 틀.

나의 AI 여정내 경험

⑤ 본격 개발: 대표 공개 프로젝트

github.com/dasomel의 공개 저장소 가운데 대표 8개를 한 줄로 소개한다.

narwhal

재현 가능한 쿠버네티스 개발자 플랫폼. 클라우드·내 서버·폐쇄망(인터넷이 막힌 망)에서 쓴다.

narwhal-portal

narwhal을 관리하는 포털 화면.

kubemetal

Apple Silicon 맥에서 쓰는 MLOps 데스크톱 앱.

beluga

로컬 쿠버네티스 위에 직접 세워 쓰는 데이터 플랫폼.

clusterdeck

쿠버네티스 접속 정보(SSH·kubeconfig)를 관리하는 macOS 앱.

ldapium

OpenLDAP 서버, 관리 화면, Helm 차트를 한데 묶었다.

kube-ready-box

쿠버네티스용 Ubuntu Vagrant 박스(가상 환경 이미지).

nfs-quota-agent

공유 저장소(NFS)의 용량 제한을 거는 에이전트.

그 밖에 egovframe-launcher(표준프레임워크 예제 실행 런처) · egovframe-boot-starter 6종 · openforge(오픈소스 프로젝트 청사진과 엔지니어링 표준)

주석 쿠버네티스 여러 서버에 프로그램을 나눠 띄우고 관리해 주는 도구.주석 MLOps AI 모델을 만들고 배포·운영하는 일을 체계적으로 관리하는 방법.

나의 AI 여정내 경험

⑥ 에이전트끼리 팀을 이루다 → 이 강의로

ChatGPT Plus 무료 이용권으로, 멀티 에이전트를 팀처럼 써 보고 있다.

⑥ 지금

ChatGPT Plus 무료 이용권으로 Codex CLI를 쓴다. ChatGPT의 멀티 에이전트로 에이전트끼리 팀을 구성해, 서로 보완하는 역할로 쓰는 중이다. 지금은 Claude CLI · Antigravity CLI · Codex CLI를 모두 함께 쓴다.

이 팀 구성은 16장 허브앤스포크 하네스와 이어진다.

이 여정이 이 강의로 이어진 이유 (내 경험이며, 일반화하지 않는다)

1

도구와 한도는 바뀐다.

2

에이전트를 많이 쓸수록 결과를 검증해야 한다.

3

먼저 에이전트가 어떻게 움직이는지 25분 보고, 그다음 내 기록으로 간다.

주석 멀티 에이전트 여러 AI 에이전트가 역할을 나눠 일하는 방식.주석 agy Antigravity CLI의 명령어 이름.

구간2

에이전트란 무엇인가

25분 · 챗봇과의 차이 · 모델 · 컨텍스트와 하네스(MCP) · 워크플로(Ralph) · 멀티 에이전트 · 내 개발 방식

역할을 나눠 주려면 먼저 그것이 어떻게 움직이는지부터.

에이전트란 무엇인가

챗봇과 에이전트의 차이: 도구를 스스로 고른다

같은 AI라도 답만 돌려주는 것과, 일을 맡아 움직이는 것은 다르다.

챗봇

질문을 받고 답을 돌려준다
판단과 실행은 사람이 한다

에이전트

목표를 받아 도구(파일 읽기·수정, 명령 실행, 검색)를 스스로 고르고 호출한다
결과를 보고 다음 행동을 정한다

남길 문장

그래서 에이전트는 더 많은 일을 맡을 수 있고, 같은 이유로 조용히 틀릴 수 있다(구간 3).

주석 에이전트 AI가 직접 파일을 읽고 고치고 명령을 실행하는 방식의 도구.주석 도구 호출 에이전트가 파일 읽기·명령 실행·검색 같은 도구를 골라 실제로 쓰는 것.

① 모델 종류2026-10 기준 예시

모델을 고르는 두 가지 기준

모델 이름은 계속 바뀐다. 기준 둘만 기억하면 된다: 누가 만든 모델이냐, 어디서 돌리느냐.

기준 1 · 프런티어: 회사가 서버에서 돌리는 최고 성능급 모델을 API로 빌려 쓴다.
예: Claude Sonnet 5.5 · GPT-6 Sol · Gemini 3.8 Flash

기준 1 · 오픈웨이트: 모델 파일이 공개되어 있어 내려받아 쓸 수 있다.
예: Gemma 4(Apache 2.0) · Qwen3.8 · DeepSeek V4

기준 2 · 로컬 vs 클라우드: 모델이 실행되는 위치의 차이(기준 1과는 다른 축).
로컬 모델 호출은 내 기기 안에서 처리된다(연결한 도구가 외부로 전송하지 않는 한) · 호출당 비용 0 · 내 하드웨어와 모델 크기가 한계 / 클라우드 프런티어 성능 · 관리해 줌

에이전트로 쓸 때는 도구를 고르고 호출하는 능력이 중요하다. 작은 모델은 이 부분이 불안정할 수 있다.

주석 프런티어 그 시점에 가장 높은 성능을 내는 최신 모델군.주석 오픈웨이트 학습된 모델 파일(가중치)이 공개되어 내려받을 수 있는 모델.주석 API 프로그램에서 서비스를 호출하는 접속 창구.

③ 엔지니어링 흐름

프롬프트에서 컨텍스트, 하네스로

질문 한 번 잘 쓰기에서, 같은 실수를 반복하지 않게 일하는 틀을 설계하는 일로.

AGENTS.md(에이전트용 지침 파일), MCP(외부 도구 연결 규격, modelcontextprotocol.io), 서브에이전트(요약만 돌려주는 하위 에이전트), Spec-driven("무엇과 왜"를 먼저 정하고 "어떻게"는 나중에)가 하네스의 재료다.

vibe coding → agentic engineering: 코드를 직접 쓰지 않고 에이전트를 지휘·감독한다는 제안(Karpathy, 2026-02).

주석 AGENTS.md 코딩 에이전트용 지침 파일.주석 MCP AI 앱을 외부 도구·데이터에 연결하는 표준 규격.주석 서브에이전트 별도 맥락에서 일하고 요약만 돌려주는 하위 에이전트.

③ 엔지니어링 흐름

Ralph 루프: 루프는 쉽다

AI에게 한 번에 한 작업씩, 끝없이 반복해서 시키는 방법. 쉬운 만큼 안전 수칙이 필요하다.

원문 표기(Huntley)

while :; do cat PROMPT.md | claude-code ; done

claude-code는 원문 표기다. 도구마다 실제 CLI 명령이 다르고, Claude Code의 실행 명령은 claude다. 이대로 복사하지 말고 공식 문서를 확인한다.

Claude Code에서는 /loop 명령으로 같은 프롬프트를 반복 실행한다(간격 지정 또는 자동 조절).

경고

이대로 무한 반복하면 비용과 권한 문제가 생긴다. 끝없이 돌면서 비용이 쌓이고, 에이전트가 가진 권한으로 계속 변경한다.

작업

PROMPT.md에는 한 작업만 적는다

검증

반복마다 검증을 한 번 돌린다

상한

최대 반복 횟수와 비용 상한을 둔다

루프를 돌리는 것은 쉽다. 그 루프가 "완료"라고 말할 때 믿을 수 있는가가 이 강의의 질문이다.

주석 Ralph 루프 한 번에 한 작업씩 AI에게 반복해서 시키는 루프.주석 /loop 프롬프트나 슬래시 명령을 일정 간격으로 되풀이 실행하는 Claude Code 내장 명령.

④ 하네스

내 하네스: 허브앤스포크

사람이 목표를 정하고, 오케스트레이터가 일을 나눠 주고, 결과는 모두 되돌아온다.

작성과 검토는 다른 워커가 맡고, 같은 파일은 worktree로 나눠 한 레인만 만진다.

주석 서브에이전트 별도 맥락에서 일하고 요약만 돌려주는 하위 에이전트.주석 worktree 같은 저장소의 작업 폴더를 여러 개로 나눠 동시에 작업하는 git 기능.주석 CI 코드를 올릴 때 자동으로 빌드·검사하는 절차.

⑤ 내 개발 방식

내 개발 방식: 휴대폰에서 원격으로

휴대폰으로 맥미니의 에이전트를 부리고, 승인은 사람이 한다. 내 개인 환경이다.

Orca는 에이전트마다 작업 폴더(worktree)를 따로 줘서 여러 에이전트가 서로 안 부딪히게 하는 개발 환경이다(MIT).

주석 worktree 같은 저장소의 작업 폴더를 여러 개로 나눠 동시에 작업하는 git 기능.주석 agy Antigravity CLI의 명령어 이름.

에이전트에서 사례로

그래서 이제,
에이전트가 조용히 틀리는
방식을 내 기록으로 본다

조용한 실패는 연구에서도 보고되고 있다

구간3

에이전트가 조용히 틀리는 방식

25분 · 사례 1~4 · 한 장 요약 · 피드백 구조

맡겨도 되는지 알려면 어떻게 틀리는지부터. 네 가지 방식.

사례 1

사례 1 쉽게 말하면: 응시자 0명, 전원 합격

"전부 정상"이라는 말은 대상이 하나도 없어도 참이 된다.

쉽게 말하면

응시자가 0명인데 "전원 합격"이라고 나왔다. 검사는 거짓말을 한 게 아니다. 응시자가 없으면 불합격자도 없으니 "전원 합격"은 문장으로서 참이다.

PASS T03 all ArgoCD apps Synced+Healthy

실제로는 ArgoCD 앱 0개

1

검사는 "모든 앱이 Synced이고 Healthy인가?"를 확인했다.

2

그런데 배포가 막혀(이미지 못 받음, push 실패, 서비스 503) 앱이 하나도 없었다.

3

앱이 0개면 어긋난 앱도 없다. 그래서 검사는 PASS를 냈다.

4

단계 스크립트는 WARN: had issues, continuing...으로 계속 진행했다.

주석 ArgoCD·Synced·Healthy 깃에 적힌 설정대로 서버 상태를 맞춰 주는 배포 도구. Synced=설정과 실제가 일치, Healthy=ArgoCD가 리소스 상태를 보고 내린 판정(사용자 기능이 실제로 동작한다는 보장은 아님).주석 ImagePullBackOff / CrashLoopBackOff 프로그램 설치 파일(이미지)을 못 받아 와서 대기 / 켜졌다 꺼지기를 반복.주석 PASS / SKIP / FAIL 통과 / 건너뜀 / 실패.

사례 1

사례 1 무슨 일과 남길 문장: 개수의 하한

"전부 정상" 검사에는 대상 개수의 하한이 필요하다.

통과한 것

PASS T03 all ArgoCD apps Synced+Healthy

실제로는

Gitea 이미지를 못 받아(ImagePullBackOff) push 실패
서비스 503, ArgoCD 앱 0개

판별 기준·장치

앱 수를 먼저 세고, 예시 기준으로 10 미만이면 FAIL (narwhal regression-check T03)
기준값 10은 그 프로젝트의 예시이며, 내 프로젝트에선 내 기준을 정한다

any check phrased as 'all X are Y' needs a floor on the number of X — '모든 X는 Y다'로 쓴 검사에는 X의 개수에 하한이 필요하다

narwhal lessons-log L387 원문 발췌 · github.com/dasomel/narwhal/blob/main/docs/common/lessons-log.md#L387

남길 문장

"전부 정상"이라는 검사에는 개수의 하한이 필요하다.

주석 ArgoCD·Synced·Healthy 깃에 적힌 설정대로 서버 상태를 맞춰 주는 배포 도구. Synced=설정과 실제가 일치, Healthy=ArgoCD가 리소스 상태를 보고 내린 판정(사용자 기능이 실제로 동작한다는 보장은 아님).주석 ImagePullBackOff / CrashLoopBackOff 프로그램 설치 파일(이미지)을 못 받아 와서 대기 / 켜졌다 꺼지기를 반복.주석 회귀 테스트 고친 문제가 다시 생기지 않는지 확인하는 테스트.

사례 2

사례 2 쉽게 말하면: 실패해도 성공 도장

검사가 실패해도 성공이라고 도장 찍어 주는 한 줄. 그리고 문서에는 이미 고쳤다고 적혀 있었다.

쉽게 말하면

검사가 실패해도 성공이라고 도장 찍어 주는 한 줄이 있었다. 그런데 문서엔 이미 "고쳤다"고 적혀 있었고, 실제로 그 한 줄을 지우기까지 16일이 걸렸다.

markdownlint ... || true

끝의 || true 때문에 앞 명령이 실패해도 CI는 초록.

1

CI(자동 검사)가 푸시할 때마다 문서 검사(markdownlint)를 돌린다.

2

검사 줄 끝에 || true가 붙어 있어 실패가 성공으로 바뀐다.

3

CI는 계속 초록이라 아무도 문제를 못 알아챈다.

4

로그의 "fix" 칸이 먼저 쓰였고, 실제로 지운 건 16일 뒤였다.

주석 CI 코드를 올릴 때 자동으로 빌드·검사하는 절차.주석 || true 앞 명령이 실패해도 성공으로 취급하라는 셸 문법.주석 PASS / SKIP / FAIL 통과 / 건너뜀 / 실패.

사례 2

사례 2 무슨 일: CI는 초록, 로그는 "고쳤다"

로그의 "고쳤다"는 실제로 고친 시점과 달랐다.

통과한 것

CI 초록
lint.yml의 markdownlint 단계 끝에 || true

실제로는

모든 실패가 성공으로 바뀜

2026-09-08 로그의 "fix" 열이 먼저 쓰임2026-09-24 실제 제거 커밋

16일간 로그는 고쳐졌다고 말하는데, 워크플로는 그대로였다

남길 문장: 문서에 "고쳤다"고 쓴 것은 고친 것이 아니다.

함께 읽기: 블로그 「CI가 FAIL을 출력하고도 성공으로 보고할 수 있다」 cne.io.kr/ko/posts/echo-branch-false-green-detector/

주석 CI 코드를 올릴 때 자동으로 빌드·검사하는 절차.주석 || true 앞 명령이 실패해도 성공으로 취급하라는 셸 문법.

사례 2

사례 2 같은 유형: 조용히 통과하는 SKIP

필수 검사가 건너뛰고도 통과로 끝나면, 아무것도 검사하지 않은 것과 같다.

같은 유형

포털 체크아웃이 없으면 SKIP 후 exit 0: 비교 없이 PASS. 실제 main과 비교하자 즉시 FAIL
version-check.yml도 "not found → SKIP"으로 통과. 실제 원인은 K8s v1.35.5(VERSIONS.md)와 1.35.7(Vagrantfile) 불일치

판별 기준

이 검사가 FAIL을 낼 수 있는가? 실제 main과 비교해 확인한다 (R117, R117b)

SKIP이 있는 검사는 검사가 아니다

narwhal lessons-log L50 원문 인용

다시 정리

조용히 통과하는 SKIP은 검사가 아니다 — 정당한 조건부 SKIP은 눈에 띄게 알리고, 필수 검사라면 FAIL로 처리한다.

주석 PASS / SKIP / FAIL 통과 / 건너뜀 / 실패.주석 exit 0 프로그램이 "성공"으로 끝났다는 신호.주석 || true 앞 명령이 실패해도 성공으로 취급하라는 셸 문법.

사례 3

사례 3 쉽게 말하면: 조회가 실패하자 남의 값이 나왔다

실패를 알리는 대신, 미리 적어 둔 다른 사람의 값을 보여 주었다.

쉽게 말하면

내 사양을 물었는데 조회가 실패하자, 미리 적어 둔 남의 사양을 사실처럼 보여 주었다. 실패했다는 사실이 화면에서 사라졌다.

고정해 둔 값: Apple M4 Pro / 14 / 20 / 64GB

1

화면은 기기의 하드웨어 사양을 조회해 보여 준다.

2

조회가 실패하면 코드에 고정해 둔 값(하드코딩 폴백)을 대신 보여 주었다.

3

다른 기기 사용자에게는 남의 사양이 사실처럼 보였다.

4

수정: 실패하면 에러(Err)를 돌려준다.

주석 하드코딩·폴백 값을 코드에 고정해 적어 둠 / 실패했을 때 대신 쓰는 값.

사례 3

사례 3 무슨 일: 실패한 조회는 에러를 보인다

그럴듯한 기본값은 실패를 가린다.

통과한 것

화면에 하드웨어 사양이 정상 표시

실제로는

조회 실패 시 Apple M4 Pro/14/20/64GB를 하드코딩 폴백
다른 기기 사용자에게 남의 사양이 사실처럼 보인다
컨텍스트 목록 조회도 실패 시 이름을 지어냈다

판별 기준·장치

수정 후 실패하면 Err 반환
원칙: "Never fabricate state"(상태를 지어내지 마라, D22–D25)

papered over every failure with hardcoded Apple M4 Pro/14/20/64GB, so any non-M4-Pro machine would have been shown someone else's specs as fact — 모든 실패를 하드코딩된 값으로 덮어서, M4 Pro가 아닌 기기는 남의 사양을 사실처럼 보게 된다

kubemetal mistakes-log L64 원문 발췌 · github.com/dasomel/kubemetal/blob/main/docs/mistakes-log.md#L64

한 줄 정리

실패한 조회는 에러를 보여야지, 그럴듯한 기본값을 보이면 안 된다.

주석 하드코딩·폴백 값을 코드에 고정해 적어 둠 / 실패했을 때 대신 쓰는 값.

사례 4AI 작업자의 허위 완료 보고

사례 4 쉽게 말하면: 스스로 만점이라고 쓴 답안

작업자가 "다 했다"고 말한 것과, 실제로 다 된 것은 별개였다.

쉽게 말하면

시험 답안을 낸 학생이 답안지에 스스로 "만점"이라고 써 두었다. 채점해 보니 계산 오류가 있었고 문제 일부는 풀지도 않았다.

원문에서 AI 작업자의 허위 완료 보고가 명시된 것은 사례 4뿐이다.

1

AI 워커가 스스로 "P1~P4 완료"라고 보고했다.

2

QA(품질 검증)가 확인하자 주간 리포트의 Decimal(소수 계산) 처리에서 크래시가 났다.

3

동등성·멱등성 테스트 묶음(스위트)이 통째로 빠져 있었다.

4

그래서 완료 보고는 증거가 아니다. 증거는 실행 결과다.

주석 QA 품질 검증 담당. 결과물이 실제로 맞는지 확인한다.주석 멱등성 여러 번 실행해도 결과가 같음.

사례 4AI 작업자의 허위 완료 보고

사례 4 무슨 일: 작업자의 "완료"는 증거가 아니었다

완료를 말한 사람이 아니라, 실행 결과가 증거다.

통과한 것

AI 워커의 자체 완료 보고 "P1~P4 완료"

실제로는

QA가 주간 리포트의 Decimal 크래시를 발견
누락된 동등성·멱등성 테스트 묶음도 발견

판별 기준

원문은 이 사고를 "작업자의 완료 주장은 증거가 아니다"의 근거로 든다
같은 파일: 모델 로테이션이 조용한 no-op(rc=0, 출력 없음). 매번 같은 모델이 돌았다

a worker's own completion claim is not evidence — 작업자가 스스로 한 완료 주장은 증거가 아니다

개인 프로젝트 lessons-log KA:34 원문 발췌

남길 문장

작업자의 완료 선언은 증거가 아니다. 증거는 실행 결과다.

주석 no-op 아무 일도 하지 않는 동작.주석 exit 0 프로그램이 "성공"으로 끝났다는 신호.주석 멱등성 여러 번 실행해도 결과가 같음.

사례 1~4 요약

사례 1~4 한 장 요약: 통과 신호는 동작의 증거가 아니었다

틀린 곳은 달랐지만, 통과한 신호는 모두 동작의 증거가 아니었다.

무엇이 틀렸나	통과한 신호 → 실제로는
검사가 틀렸다 (사례 1·2)	PASS · CI 초록 → 앱 0개 · `\|\| true`가 실패를 성공으로
표시가 틀렸다 (사례 3)	화면에 정상 표시된 사양 → 조회 실패를 남의 사양으로 덮음
보고가 틀렸다 (사례 4)	"P1~P4 완료" 보고 → Decimal 크래시, 테스트 누락

공통점

PASS · Synced · CI 초록 · 화면 표시는 모두 신호였지, 동작이 아니었다.

그래서 다음은 피드백 구조(30장): 장애를 테스트로 바꾼다.

주석 CI 코드를 올릴 때 자동으로 빌드·검사하는 절차.주석 || true 앞 명령이 실패해도 성공으로 취급하라는 셸 문법.

피드백 구조: 장애를 테스트로 바꾼다

실제 운영 중인 구조. 장애 → 교훈 → 판별 기준 → 회귀 테스트로 이어 붙인다.

kubemetal·kube-ready-box: 작업 전에 mistakes-log를 읽도록 규정, CI 게이트로 확인

기록 원문: narwhal lessons-log · kubemetal mistakes-log

주석 회귀 테스트 고친 문제가 다시 생기지 않는지 확인하는 테스트.주석 변이 검사 일부러 틀린 입력을 넣어 검사가 실제로 잡는지 확인.

구간4

인간과 AI의 역할 분담

23분 · 사례→역할 · 사례 5 · 맡길 것/쥘 것 · 책임과 예방 · 지금의 흐름 · 앞으로

신호를 믿지 못한다면 누가 결정하나. 역할을 나누는 기준.

역할 분담

사례에서 역할로: 완료를 말하는 순간 결정은 사람의 몫

신호를 믿지 못한다면, 믿을지 말지는 누가 정하는가.

사례 1·2·3 · 검사·표시가 틀림

작성 주체가 원문에 없어 "AI와 협업한 프로젝트에서 나온 실패"로만 말한다
AI 탓으로 돌리지 않는다
기준은 사람이 정한다

사례 4 · AI가 "완료"라고 말했다

AI 작업자의 허위 완료 보고가 원문에 명시된 유일한 사례
그 말을 믿을지는 승인자가 정한다

사례 5 · 메인테이너

PR 병합은 메인테이너가 승인한다

이 구간은 그 자리를 본다

AI가 "완료"라고 말하는 순간, 결정은 승인하는 사람의 몫이다.

주석 PR 변경 병합 요청.

사례 5 · AI와 함께한 오픈소스 기여

사례 5: 같은 날 닫힌 PR과 병합된 PR

좋은 코드여도 저장소가 원하는 문제가 아니면 닫힌다. 수용 기준은 코드 밖에 있다.

egovframe-common-components · 2026-08-26

#1166 병합 없이 닫힘

순수 유틸 단위 테스트만 추가
샘플/공통 저장소의 관리 범위와 맞지 않아 닫힘 (원 발표자료 서술 기준, PR 댓글 원문은 미확인)

#1167 병합됨

파일 다운로드 헤더명 오타와 속성키 불일치 수정
리뷰 회신을 반영해 5개 테스트 사례 추가

"AI와 함께한"은 내가 AI 도구로 작업한 기여 활동 전반을 뜻한다. 이 두 PR 각각의 AI 사용 여부는 원 자료가 말하지 않아 단정하지 않는다.

한 줄 정리

좋은 코드여도 저장소가 원하는 문제가 아니면 닫힌다 — 수용 기준은 코드 밖에 있다

주석 PR 변경 병합 요청.

사례 5 · AI와 함께한 오픈소스 기여

사례 5: 확인한 것과 확인하지 못한 것을 적는다

통과했다고 말하기 전에, 못 한 것을 먼저 말한다.

#1167

헤더 문자열 테스트까지 확인
실제 HTTP 응답 호출은 테스트 범위 밖이라고 명시

#121 · 2026-06-16 병합

(egovframe-template-simple-backend)
Dockerfile·compose·Kubernetes 매니페스트의 YAML은 확인
실제 클러스터 E2E는 하지 않았다고 PR에 밝힘

한 줄 정리

사례 1~2의 조용한 PASS의 반대편: 통과했다고 말하기 전에, 못 한 것을 먼저 말한다

PR은 제안서처럼

무엇이 불편하고 왜 고쳤나
변경은 한 주제인가
어떤 명령·화면·테스트로 확인했나
확인하지 못한 부분은

주석 E2E 처음부터 끝까지 실제 흐름 확인.주석 PR 변경 병합 요청.

맡길 것과 쥘 것

AI는 초안과 반복을 맡고, 사람은 기준과 확인을 쥔다.

AI에게 맡겨도 되는 것	사람이 쥘 것
로그 수집, 가설 후보 나열, 수정안 초안	가설 배제 기준 세우기, "완료"의 증거 정의
반복 검증 실행	자동 적용 여부 (dry-run, 승인 지점)
테스트 초안 작성	테스트가 실제로 잡는지 확인 (변이 검사)

주석 변이 검사 일부러 틀린 입력을 넣어 검사가 실제로 잡는지 확인.주석 dry-run 실제로 바꾸지 않고 결과만 미리 보는 실행.

AI Agent 시대와 인간 개발자의 역할 — 답

역할 분담의 답: 책임은 사람이, 재발은 장치가

책임은 승인하는 사람이 지고, 재발은 장치가 막는다. 근거는 오늘의 두 사례.

책임 (accountability)

승인·배포 권한을 가진 사람과 조직에 있다
AI는 책임 주체가 될 수 없다

예방 (prevention)

장애를 판별 기준과 회귀 테스트로 바꾸는 개발자의 일
AI 시대에 사람의 일이 옮겨가는 곳

근거 1 · 사례 4

작업자의 보고를 승인 전에 검증해야 했다

근거 2 · 사례 5

PR을 병합할지는 메인테이너가 승인한다

남길 문장

책임은 승인하는 사람이 지고, 재발은 장치가 막는다.

다음: 오늘 밤 체크리스트(40장)

주석 회귀 테스트 고친 문제가 다시 생기지 않는지 확인하는 테스트.주석 PR 변경 병합 요청.

④ 역할 분담 · 지금의 흐름

채택은 늘었지만 신뢰는 따로, 생산성 증거는 엇갈린다

쓰는 사람은 늘었고 믿는 정도는 따로 움직인다. 증거가 엇갈릴 때는 한쪽 수치만 고르지 않는다.

에이전트 사용

31% → 59%

2025 → 2026-04 조사

AI 도구 호감

72% → 약 60%

2025 조사

METR

초기 2025 연구: 숙련 개발자가 AI를 쓰자 19% 느려졌다고 보고. 2026-02 업데이트: 선택 편향 때문에 설계를 바꾸는 중

DORA ROI 보고서

"AI는 증폭기". 신규 +35~40% · 레거시 ≤10% (2026-05 보도)

출처 URL (2026-10-05 확인)

METR: metr.org/blog/2026-02-24-uplift-update/
Stack Overflow: stackoverflow.blog/2026/09/30/getting-ready-for-2026-results-a-look-back-on-developer-survey-findings/
DORA(InfoQ 보도): infoq.com/news/2026/05/dora-roi-ai-assisted-dev-report/

주석 METR AI 도구의 개발자 생산성 영향을 연구하는 기관.주석 DORA 소프트웨어 개발·배포 성과를 조사하는 연구 프로그램.

④ 역할 분담 · 앞으로

앞으로의 개발 환경: 내 경험에서 보이는 것

예측이 아니라 내 경험에서 보이는 방향이다.

1

도구와 한도는 계속 바뀐다 → 한 도구에 기대지 않는 구성(7·10장, 세 CLI 병행)

2

에이전트가 맡는 일은 늘고, 검증과 승인은 사람 몫으로 남는다 → 개발자의 일은 코드 작성에서 기준·승인·재발 방지 장치로 옮겨간다(사례 4·5, 36장)

3

지금 시작할 것: 도구 하나로 작은 프로젝트에 AGENTS.md 10줄을 써 보고, '완료' 보고에 실행 증거를 요구하는 습관

주석 AGENTS.md 코딩 에이전트용 지침 파일.

한 문장 결론

에이전트에게는 많은 것을 맡길 수 있다. 그러나 오늘 고른 사례에서 반복된 패턴은 요란한 실패가 아니라 조용한 실패였고, '통과'를 믿을지는 사람이 정했다.

(326건의 유형별 집계는 하지 않았다. 오늘 사례는 골라낸 것이므로 일반화하지 않는다.)

그래서 개발자의 일은 '통과'를 믿지 않고 잡아내는 장치를 만들고, 승인의 자리를 지키는 쪽으로 옮겨간다.

마무리 5분

오늘 밤 체크리스트 3줄과 과제

내 프로젝트에 바로 적용할 수 있는 최소한의 점검.

체크리스트 3줄

"전부 정상" 검사에는 개수의 하한을 둔다.
필수 검사가 조용히 SKIP되면 FAIL로 처리한다.
완료 보고에는 실행 증거(로그·diff·테스트 출력)를 첨부한다.

과제

내가 겪은 장애·실수 1건을 4열로 적어 제출한다
장애 · 교훈 · 판별 기준 · 회귀 테스트
AI에게 초안을 정리시키되, 판별 기준이 실제로 잡는지는 직접 확인한다

주석 PASS / SKIP / FAIL 통과 / 건너뜀 / 실패.주석 회귀 테스트 고친 문제가 다시 생기지 않는지 확인하는 테스트.

부록

참고 자료 편

나중에 찾아보는 용도 · 강의 흐름과 따로 읽어도 됩니다

① 용어집(가나다순) · ② 사례 6 · 사례 5 숫자

부록

용어집 1 / 6 (가나다순)