숭실대 특강 후기: AI Agent 시대, 사람은 무엇을 쥐어야 하나

2026년 10월 14일, 숭실대학교 소프트웨어특강2에서 「AI Agent 시대와 인간 개발자의 역할」을 발표했습니다. 이 글은 그 발표 내용을 강의 뒤에 혼자 읽어도 이해되도록 다시 정리한 것입니다.

발표자료 바로 보기 · 모바일에서는 좌우 스와이프나 화면 가장자리 탭으로 넘기고, 우상단 버튼으로 전체 화면을 쓸 수 있습니다.

먼저 답부터

발표는 결론을 먼저 말하는 데서 시작했습니다.

• 에이전트에게 맡길 것: 초안 작성, 반복 검증 실행, 조사와 탐색
• 사람이 쥘 것: 목표와 기준, 승인, 재발 방지 장치

그리고 한 문장으로 줄이면 이렇습니다. 책임은 승인하는 사람이 지고, 재발은 장치가 막는다.

여기서 책임과 예방은 다른 말입니다. 책임(accountability)은 승인·배포 권한을 가진 사람과 조직에 있고, AI는 책임 주체가 될 수 없습니다. 예방(prevention)은 장애를 판별 기준과 회귀 테스트로 바꾸는 개발자의 일이며, AI 시대에 사람의 일이 옮겨가는 곳이라고 봅니다.

나는 AI를 이렇게 써 왔다

도구 이름보다 쓰는 방식이 달라진 과정입니다.

1. ChatGPT: 이미지를 지브리 스타일로 바꿔 보는 흥미 위주 사용
2. Perplexity: 검색하고 복사·붙여넣기
3. Claude Pro: Claude Code로 에이전트 개발 시작. 토큰이 적어 힘들었지만 이때부터 CLI로 개발했습니다.
4. Gemini Pro: Gemini CLI에서 Antigravity CLI로 옮기며 적응
5. Claude Max 5x: 본격 개발. 여러 오픈소스를 만들고 eGovFrame에도 기여
6. ChatGPT Plus 무료 이용권: Codex CLI로 에이전트끼리 팀을 이뤄 서로 보완하게 사용

AI에게 맡기는 일이 "받기"에서 "고르기"를 거쳐 "시키기"로 커진 셈입니다. 한 가지 배운 점은 한도와 조건이 시간이 지나며 바뀐다는 것이었고, 그래서 지금은 세 CLI를 함께 쓰는 구성을 합니다. 이 여정은 제 경험이며 일반화하지 않았습니다.

에이전트는 챗봇과 무엇이 다른가

챗봇은 질문을 받아 답을 돌려주고, 판단과 실행은 사람이 합니다. 에이전트는 목표를 받아 파일 읽기·수정, 명령 실행, 검색 같은 도구를 스스로 고르고 호출하고, 결과를 보고 다음 행동을 정합니다. 그래서 더 많은 일을 맡길 수 있지만, 같은 이유로 조용히 틀릴 수도 있습니다.

발표에서 다룬 기초 개념은 네 가지였습니다.

• 모델 고르는 두 기준: 프런티어냐 오픈웨이트냐(누가 만들었나), 로컬이냐 클라우드냐(어디서 돌리나). 모델 이름은 계속 바뀌니 기준만 기억하면 됩니다.
• 엔지니어링 흐름: 프롬프트 엔지니어링(한 번의 질문) → 컨텍스트 엔지니어링(모델에 들어가는 토큰 전체) → 하네스 엔지니어링(도구·문서·검증·루프를 설계). 같은 실수를 반복하지 않게 일하는 틀을 만드는 쪽으로 무게가 옮겨갑니다.
• Ralph 루프: AI에게 한 번에 한 작업씩 끝없이 시키는 방법입니다. 쉬운 만큼 안전 수칙이 필요합니다. 그대로 무한 반복하면 비용이 쌓이고, 에이전트가 가진 권한으로 계속 변경하기 때문입니다. 작업은 하나만 적고, 반복마다 검증을 돌리고, 상한을 둡니다.
• 허브앤스포크 하네스: 사람이 목표를 정하고, 오케스트레이터가 일을 나눠 주고, 결과는 모두 되돌아옵니다. 작성과 검토는 다른 워커가 맡고, 같은 파일은 worktree로 나눠 한 레인만 만집니다. 린터, CI, 회귀 테스트 같은 결정적 강제 장치가 바닥을 받칩니다.

저는 휴대폰에서 Tailscale로 맥미니에 연결해 에이전트를 부리고, 승인은 사람이 하는 방식으로 개발합니다. 에이전트를 원격·병렬로 굴릴수록 승인 지점이 중요해진다는 점이 이어지는 사례의 복선입니다.

조용한 실패 사례 네 가지

여기서부터가 본론입니다. 제 프로젝트의 lessons-log와 mistakes-log에서 골라 온 네 건입니다. 모두 요란하게 터진 실패가 아니라, 통과 신호가 떴는데 실제로는 동작하지 않았던 경우입니다.

사례 1. 응시자 0명, 전원 합격

검사 한 줄이 PASS T03 all ArgoCD apps Synced+Healthy라고 했는데, 실제로는 ArgoCD 앱이 0개였습니다. 이미지를 받지 못해(ImagePullBackOff) push가 실패하고 서비스가 503이었던 겁니다. "모든 앱이 정상인가"라는 문장은 앱이 하나도 없어도 참입니다. 검사가 거짓말을 한 게 아니라 문장이 그렇게 생겼습니다.

단계 스크립트는 WARN: had issues, continuing...으로 계속 진행했습니다. 장치는 단순했습니다. 앱 개수를 먼저 세고 기준 미만이면 FAIL로 처리합니다. 원문 교훈은 이렇습니다. "모든 X는 Y다"로 쓴 검사에는 X의 개수에 하한이 필요합니다.

사례 2. 실패해도 성공 도장을 찍는 한 줄

문서 검사(markdownlint) 줄 끝에 || true가 붙어 있었습니다. 앞 명령이 실패해도 CI는 초록입니다. 더 곤란했던 점은 로그의 "fix" 칸에는 2026-09-08에 이미 고쳤다고 적혀 있었는데, 실제로 그 한 줄을 지운 커밋은 2026-09-24였다는 겁니다. 16일 동안 로그는 고쳐졌다고 말하는데 워크플로는 그대로였습니다.

같은 유형이 더 있었습니다. 필수 검사가 대상이 없으면 SKIP 하고 exit 0으로 끝나서, 비교도 하지 않고 PASS가 되는 경우입니다. 실제 main과 비교하게 바꾸자 바로 FAIL이 나왔습니다. 문서에 "고쳤다"고 쓴 것은 고친 것이 아니고, SKIP이 있는 검사는 검사가 아닙니다. 이 패턴을 잡는 도구 이야기는 CI가 FAIL을 출력하고도 성공으로 보고할 수 있다에 따로 적었습니다.

사례 3. 조회가 실패하자 남의 값이 나왔다

하드웨어 사양을 조회해 보여 주는 화면이 있었는데, 조회가 실패하면 코드에 고정해 둔 값(Apple M4 Pro / 14 / 20 / 64GB)을 대신 보여 주었습니다. 다른 기기 사용자에게는 남의 사양이 사실처럼 보입니다. 컨텍스트 목록 조회도 실패하면 이름을 지어냈습니다. 실패했다는 사실이 화면에서 사라진 겁니다.

수정은 실패하면 에러(Err)를 돌려주는 것이었고, 원칙은 "상태를 지어내지 마라(Never fabricate state)"입니다. 그럴듯한 기본값은 실패를 가립니다.

사례 4. 작업자가 스스로 쓴 "만점"

AI 워커가 "P1~P4 완료"라고 보고했는데, QA가 확인하니 주간 리포트의 Decimal 처리에서 크래시가 났고 동등성·멱등성 테스트 묶음이 통째로 빠져 있었습니다. 같은 파일에는 모델 로테이션이 조용한 no-op이었던 기록도 있습니다. 반환 코드는 0이고 출력은 비어 있어서, 로테이션이 매번 같은 모델을 돌렸습니다.

원문은 이 사고를 근거로 "작업자가 스스로 한 완료 주장은 증거가 아니다"라고 적습니다. 증거는 실행 결과입니다.

네 건의 공통점

틀린 곳은 달랐습니다. 사례 1·2는 검사가, 사례 3은 표시가, 사례 4는 보고가 틀렸습니다. 하지만 PASS, Synced, CI 초록, 화면 표시는 모두 신호였지 동작의 증거가 아니었습니다.

이 사례들은 제 기록에서 골라낸 것입니다. 성공 사례나 사람이 짠 코드와 비교한 것이 아니라서 "AI는 원래 조용히 틀린다"는 일반화의 근거가 될 수 없습니다. 사례 1~3은 원문에 작성 주체가 적혀 있지 않아 "AI와 협업한 프로젝트에서 나온 실패"로만 말했고, AI 작업자의 허위 완료 보고가 원문에 명시된 것은 사례 4뿐입니다.

장애를 테스트로 바꾸는 구조

그래서 저는 실패를 기록으로 끝내지 않고 이렇게 이어 붙입니다.

장애 → 교훈 → 판별 기준 → 회귀 테스트

narwhal의 lessons-log에는 2025-01-27부터 2026-09-26까지 326건이 쌓여 있습니다. 조치 열에 "어떻게 구별하나"를 적고, 회귀 검사 설명 끝에 (YYYY-MM-DD)로 장애와 연결합니다. 여기에 일부러 틀린 입력을 넣어 검사가 실제로 잡는지 확인하는 변이 검사를 짝으로 둡니다. kubemetal과 kube-ready-box는 작업 전에 mistakes-log를 읽도록 규정하고 CI 게이트로 확인합니다.

326건을 유형별로 집계하지는 않았습니다. 오늘 고른 사례가 골라낸 것이라, 숫자로 일반화하지 않으려는 의도입니다.

사례 5. 오픈소스 기여에서 본 수용의 기준

AI와 함께한 오픈소스 기여에서도 같은 질문이 보입니다. 여기서 "AI와 함께한"은 제가 AI 도구로 작업한 기여 활동 전반을 뜻합니다. 아래 두 PR 각각에 AI를 썼는지는 원 자료가 말하지 않아 단정하지 않습니다.

• 같은 날 닫힌 PR과 병합된 PR (2026-08-26, egovframe-common-components): #1166은 순수 유틸 단위 테스트만 추가했다가 저장소 관리 범위와 맞지 않아 병합 없이 닫혔고(원 발표자료 서술 기준, PR 댓글 원문은 확인하지 못했습니다), #1167은 파일 다운로드 헤더명 오타와 속성키 불일치를 고치고 리뷰 회신을 반영해 테스트 5개를 더해 병합됐습니다. 좋은 코드여도 저장소가 원하는 문제가 아니면 닫힙니다.
• 확인한 것과 못 한 것을 적는다: #1167은 헤더 문자열 테스트까지만 했고 실제 HTTP 응답 호출은 범위 밖이라고 밝혔습니다. egovframe-template-simple-backend #121(2026-06-16 병합)은 YAML까지 확인했고 실제 클러스터 E2E는 하지 않았다고 PR에 적었습니다. 조용한 PASS의 반대편입니다. 통과했다고 말하기 전에 못 한 것을 먼저 말합니다.

eGovFramework 조직에 낸 제 PR은 485건이고, 병합 222건, 병합 없이 닫힘 263건, 열림 0건입니다(2026-10-05 GitHub 검색 기준, 병합 비율 약 46%는 계산값). 이 숫자만으로 AI 효과를 말할 수는 없습니다. AI를 쓴 PR과 쓰지 않은 PR의 병합률을 비교하지 않았고, 건수는 목표가 아니라 경험의 배경입니다. 다만 AI로 속도를 높여도 병합 여부는 메인테이너가 정한다는 점은 분명합니다. 기여 이야기는 표준프레임워크 기여를 시작하며에 더 자세히 적었습니다.

맡길 것과 쥘 것

AI가 "완료"라고 말하는 순간, 믿을지 말지는 승인하는 사람의 몫입니다. 사례 4에서는 작업자의 보고를 승인하기 전에 검증해야 했고, 사례 5에서는 PR을 병합할지를 메인테이너가 승인했습니다.

지금의 흐름과 앞으로

쓰는 사람은 늘었지만 믿는 정도는 따로 움직이고, 생산성 증거도 엇갈립니다. 발표에서는 한쪽 수치만 고르지 않고 이렇게 나란히 놓았습니다.

• 에이전트 사용 31%에서 59%로(Stack Overflow, 2025 → 2026-04 조사), AI 도구 호감은 72%에서 약 60%로(2025 조사)
• METR의 2025년 초기 연구는 숙련 개발자가 AI를 쓰자 19% 느려졌다고 보고했고, 2026-02 업데이트에서는 선택 편향 때문에 설계를 바꾸는 중이라고 밝혔습니다.
• DORA ROI 보고서(2026-05 보도)는 "AI는 증폭기"라고 했고, 신규는 +35~40%, 레거시는 최대 +10%라고 전합니다.

모두 2026-10-05에 확인한 출처이고, 예측이 아니라 제 경험에서 보이는 방향만 정리하면 세 가지입니다. 도구와 한도는 계속 바뀌니 한 도구에 기대지 않는 구성이 필요하고, 에이전트가 맡는 일은 늘어도 검증과 승인은 사람 몫으로 남고, 그래서 개발자의 일은 코드 작성에서 기준·승인·재발 방지 장치로 옮겨갑니다.

오늘 밤 체크리스트

강의를 마치며 남긴 최소한의 점검 세 줄입니다.

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

과제로는 내가 겪은 장애나 실수 한 건을 장애, 교훈, 판별 기준, 회귀 테스트의 4열로 적어 보라고 냈습니다. AI에게 초안을 정리시켜도 되지만, 판별 기준이 실제로 잡는지는 직접 확인해야 합니다.

한 문장 결론

에이전트에게는 많은 것을 맡길 수 있습니다. 그러나 오늘 고른 사례에서 반복된 패턴은 요란한 실패가 아니라 조용한 실패였고, '통과'를 믿을지는 사람이 정했습니다. 그래서 개발자의 일은 '통과'를 믿지 않고 잡아내는 장치를 만들고, 승인의 자리를 지키는 쪽으로 옮겨갑니다.

에이전트 지침을 어떻게 짧게 유지하는지가 궁금하다면 AGENTS.md를 길게 쓰는 게 답이 아니었다도 함께 읽어 보세요.