시각장애인 교사의 바이브 코딩/에이전틱 엔지니어링 실전기: 수업용 미니게임 제작부터 조직 운영까지 AI로 자동화하기
김헌용 · 신명중학교 영어 교사, 함께하는장애인교원노동조합 위원장
이 글은 2026년 4월 3일 한국시각장애교육재활학회 춘계 세미나 발표 원고를 바탕으로 작성하였습니다.
발표 슬라이드 보기
들어가며: Claude Code와 만나다
나는 시각장애가 있는 영어 교사이자 함께하는장애인교원노동조합의 위원장으로 AI를 학교 및 조합 업무에 활용하는 방법을 탐색해 왔다. 시중에 나와 있는 AI 도구는 다양하지만, 성능이나 스크린 리더 접근성 면에서 Anthropic의 Claude는 늘 첫 번째 선택지였다. 나는 2025년 7월즈음부터는 월 100 달러의 맥스 플랜을 사용하고 있다. 이제 Claude는 수업 자료를 만들거나, 조합의 각종 문서를 정리할 때 없어서는 안 되는 도구가 되었다.
그런데 지난 해 8월 말부터는 Claude Code를 사용하기 시작하면서 AI 활용의 영역이 문서 작업에서 소프트웨어 개발로 한 층 더 확장되었다. Claude Code는 채팅창이 아니라 내 컴퓨터의 터미널에서 돌아가는 AI 코딩 에이전트다. 파일을 읽고, 코드를 쓰고, 실행하고, 에러가 나면 스스로 고친다. 내가 "수업에 쓸 단어 퀴즈 게임을 만들고 싶어"라고 말하면, Claude Code가 코드를 작성하고 실행 가능한 파일을 만들어 준다. 이런 식으로 프레젠테이션 슬라이드, 수업용 미니게임, 데이터베이스가 붙은 풀스택 웹앱까지 — 코드를 한 줄도 직접 짜지 않고 만들게 되었다. 올해 1~2월에는 사용량이 너무 늘어서 한시적으로 월 $200 티어까지 올려야 했을 정도다.
주변에서는 "대체 AI를 가지고 뭘 하는 거야?"라고 묻는 사람들이 많다. 이 글은 그 질문들에 대한 나름의 답이다. 이 글을 읽기에 앞서 Claude Code가 무엇인지, 사용하기 위해 어떤 환경이 필요한지 같은 기본적인 내용이 궁금한 분들은 장교조 내 실무 연수를 위해 작성한 강의안을 참고하길 바란다.
이 글에서 다루는 두 가지 핵심 개념인 바이브 코딩과 에이전틱 엔지니어링에 관해 먼저 간략히 정리한다.
먼저, 바이브 코딩(Vibe Coding)은 2025년 2월 OpenAI 공동창립자 Andrej Karpathy가 만든 말이다. 자연어로 AI에게 원하는 것을 설명하면 AI가 코드를 만들어 주고, 결과물이 괜찮으면 그냥 쓰는 방식이다. 코드가 어떻게 생겼는지는 신경 쓰지 않는다. 자연어로 코딩이 가능해졌다는 것은 곧 개발자가 아닌 사람도 소프트웨어를 만들 수 있게 되었다는 뜻이다. 바이브 코딩의 초점은 산출물, 그러니까 내가 원하는 앱, 게임, 웹페이지가 의도에 맞게 만들어지느냐에 있다.
에이전틱 엔지니어링(Agentic Engineering)은 정확히 1년 뒤인 2026년 2월, Karpathy가 다시 내놓은 후속 개념이다. 그의 설명을 빌리면, "'Agentic'인 이유는 99%의 시간 동안 코드를 직접 작성하지 않기 때문이다. 당신은 코드를 작성하는 에이전트를 오케스트레이션하고 감독한다. 'Engineering'인 이유는 거기에 기술과 과학과 전문성이 있기 때문이다."
Karpathy의 개념을 내가 AI를 활용하는 방식으로 재해석하자면, 에이전틱 엔지니어링이란 개별 앱 하나를 만드는 것이 아니라, AI 에이전트를 활용해 업무의 워크플로우나 시스템 전체를 설계하고 자동화하는 행위다. 바이브 코딩의 초점이 산출물에 있다면, 에이전틱 엔지니어링의 초점은 과정 자체에 있다. 여기서 필요한 것은 코딩 지식이 아니다. 내 업무가 어떤 흐름으로 이루어지는지에 대한 이해, 그리고 내가 사용하는 AI 에이전트가 무엇을 잘하고 어디서 실수하는지에 대한 명확한 인식이다. 그 이해를 바탕으로 여러 에이전트, 스크립트, API, 때로는 물리적 환경 자체를 조율하고 재구성하는 것이 에이전틱 엔지니어링이다.
이 글에서 소개하는 다섯 개의 프로젝트를 분류하면, 바이브 코딩 사례 세 가지와 에이전틱 엔지니어링 사례 두 가지이다. 이 둘은 단순히 난이도가 다른 것이 아니라, 서로 다른 층위의 작업이다. 바이브 코딩 프로젝트는 "만들어 줘"에서 시작해 비교적 짧은 시간 안에 결과물이 나오고, 개발과 디버깅, 배포 과정이 단순하다. 반면 에이전틱 엔지니어링 프로젝트는 시스템을 설계하고 구축하는 것 자체가 도전이며, 그렇게 만든 도구나 워크플로우가 실제로 효과가 있는지 검증하기도, 조직 안에서 확산시키기도 쉽지 않다.
이 글에서는 이 두 가지 층위의 작업이 어떻게 다른지, 그리고 각각이 학교 업무와 노동조합 업무에 어떻게 적용될 수 있는지를 보여 주려 한다. 수업 30분 전에 "만들어 줘"로 시작한 미니게임부터, 학교 및 노조 업무에서 범용적으로 사용할 수 있는 한글 문서 처리 스킬을 개발하고 고도화한 과정, 노동조합의 에이전트 시스템 및 업무 자동화 스킬 구축 과정까지. 이 글이 AI를 채팅 도구를 넘어 업무에 사용하고자 하는 분들께 시행착오를 기록한 일종의 '체험기'로서 도움이 되길 바란다.
1. 수업용 미니게임: 학습지 한 장이 게임이 되다
Word Bomb · Story Detective · Grammar Potion Lab
첫 번째 사례는 전형적인 바이브 코딩 프로젝트다.
수업 시작 전에 별 생각 없이 출판사에서 제공한 영영풀이 학습지를 검토하다가 학생들이 재미있게 학습할 수 있는 게임으로 바꿔 보고 싶어졌다. 어떤 게임으로 만들지에 대한 아이디어도 없이 Claude Code에 물어 보았다. 이 학습지를 어떻게 하면 학생들이 재미있게 학습할 수 있겠느냐고. Claude Code는 몇 가지 게임 아이디어를 제안했고, 그 중 정해진 시간 안에 단어를 맞히지 못하면 폭탄이 터지는 콘셉트가 가장 박진감 넘칠 것 같았다.
그렇게 Word Bomb이 탄생했다. 영어 정의를 듣고 4지선다로 단어를 맞추는 게임이다. 게임 아이디어가 단일 HTML 파일 앱으로 완성되기까지 걸린 시간은 단 30분이었다. 공강 시간에 뚝딱 만들 수 있는 정도의 난이도이고, 실제로 나도 공강 시간을 이용해서 만들었다. 이후 수업을 하면서 발견된 버그들은 차차 수정했지만, 첫 번째 버전만으로도 학생들의 몰입을 이끌어내기에는 충분했다.
그런데 한 가지 유쾌한 버그가 발생했다. 영어 단어 중 laugh의 오디오가 단어 발음이 아니라 진짜 웃음소리로 생성된 것이다. 초기 버전에서는 단어 발음 음성을 구현하지 않았는데 이후 Gemini API를 사용하여 발음을 추가하는 과정에서 잘못 생성된 것이었다. 그것도 모르고 수업 중 발음을 재생했다가 AI의 기괴한 웃음소리가 흘러나오자 교실은 한바탕 웃음바다로 변했다. 학생들은 "AI가 실수를 할 수도 있구나!" 하면서 오히려 흥미를 보였고, 이후 내가 AI로 앱을 만들 때마다 "실수를 꼭 하나씩 넣어 달라!"며 보챌 정도였다.
한편, HTML 단일 파일로 작성된 앱의 가장 큰 장점은 역시 단순성에 있다. 문서 구조가 단순하니 AI 에이전트도 빠르게 제작 및 수정할 수 있고, HTML 파일 규칙을 아는 사용자라면 수동으로 개입하기도 편하다. 뿐만 아니라, GitHub 연동 없이 바로 로컬에서 브라우저로 열 수 있어 개발 지식이 거의 없는 사용자들도 첫 번째 바이브 코딩 프로젝트로 도전하기에 가장 적합하다.
Word Bomb으로 지루한 학습지 풀이가 게임이 되자 교실 분위기가 완전히 달라졌다. 나는 이 경험에서 자신감을 얻어 본격적인 게임 두 개를 더 만들었다.
-
Story Detective — 교과서 읽기 지문을 탐정 테마로 재구성한 독해 퀴즈
-
Grammar Potion Lab — 문법 규칙을 연금술 테마로 풀어낸 게임
Word Bomb과 달리 이 두 게임은 몰입감을 높이기 위해 음성, 이미지, 사운드 효과를 풍부하게 사용하기로 결정했다. 영어 발음은 앞선 앱에서 실수가 있긴 했지만 압도적 자연스러움을 자랑하는 Gemini TTS API로 생성하고, 게임 내 이미지도 Gemini Image API로 생성하기로 했다. 효과음은 ElevenLabs MCP로 만들었다. Claude Code 하나만으로는 불가능한 일이었고, 여러 AI 도구를 조합하여 지시해야 했다. 바이브 코딩이라 해서 반드시 도구 하나만 쓰는 것은 아니다. Claude Code는 메인 코딩 에이전트로 다양한 도구를 사용할 수 있으므로 그 기능을 십분 활용하는 것이 최종 결과물의 품질을 높이는 좋은 방법이다.
Story Detective는 교과서 읽기 지문을 탐정 스토리로 재구성한 독해 퀴즈 게임이다. 학생이 "탐정"이 되어 지문 속 단서를 찾아가며 문제를 풀도록 설계했다. 교과서 본문을 그대로 쓰되 테마만 바꾸는 방식이라, 수업 내용과 자연스럽게 연결된다는 장점이 있었다.
Grammar Potion Lab은 문법 규칙을 연금술 테마로 풀어낸 게임이다. 학생이 "마법사 견습생"이 되어 문법 재료를 올바른 순서로 조합하면 포션이 완성되는 방식으로, 학습지의 문법 설명을 게임 안에서 자연스럽게 반복 학습하게 된다. 그런데 이 게임에서 한 가지 시행착오가 있었다. 처음 만들어진 버전에서는 학습지의 문법 설명 중 일부만 선택적으로 게임에 포함되어 있었다. 게임만 진행하기에는 전혀 문제가 없었지만, 수업 중 화면을 띄워 놓고 학습지 순서에 맞춰 진행하기에는 어려움이 있었다.
그래서 학습지 전체를 1:1로 대응시키는 동기화 작업이 필요했다. 이 동기화 과정이 이 프로젝트에서 가장 까다로웠던 부분이다. 게임의 "포션 레시피"는 학습지의 문법 설명과 글자 하나, 순서 하나까지 정확히 일치해야 한다. 그래서 AI에게 세 번 검증을 시켰지만, 결국 AI가 잡아내지 못했다. 데이터의 정확성은 AI에게만 맡겨서는 안 되고, 반드시 교사가 직접 검증해야 한다는 교훈을 얻을 수 있었다.
2. Pick Me: 동료 교사의 주문으로 앱을 제작하다
Pick Me 데모
두 번째 사례 역시 바이브 코딩이다. 다만 미니게임과 다른 점이 하나 있다. 이번에는 내가 아닌 다른 사람의 주문으로 시작되었다는 것이다.
지난 해 11월, 동료 교사가 이런 요청을 했다. 수업 중에 학생을 무작위로 뽑고 싶은데, 성별 인원을 지정할 수 있었으면 좋겠고, 교사가 미리 특정 학생을 당첨자로 정해놓을 수 있으면 좋겠다고. 이 세 가지 요구사항을 Claude Code에게 전달하면서, "시각적으로 화려하면서도 접근성을 갖춘 형태"라는 방향을 덧붙였다. Claude Code는 Three.js로 3D 애니메이션을, Web Audio API로 에셋 없이 코드만으로 효과음을 합성하는 방식을 제안했다. 기술 선택은 AI가 했고, 내가 한 것은 방향을 정한 것이다. 이렇게 해서 룰렛, 로또, 낚시 세 가지 테마를 갖춘 3D 앱이 3일 만에 완성되었다.
바이브 코딩에서 한 가지 강조하고 싶은 점이 있다. 시각장애인인 내가 이 앱을 직접 사용해야 했기에, ARIA 레이블, 키보드 내비게이션, 고대비 색상은 첫 프롬프트부터 포함시켰다. 경험상 "접근성을 고려해 줘"라고 AI에게 지시하면 놀라울 정도로 잘 구현해 준다. 접근성 구현이 어려운 것이 아니라, 그동안 우선순위에서 밀려났을 뿐이다. 바이브 코딩이 비개발자에게 소프트웨어 제작의 문을 열어 준 것처럼, 접근성 역시 "말로 요청할 수 있는 시대"가 되면 더 이상 미뤄둘 이유가 없다.
하지만 이 앱에서도 AI의 한계를 보여주는 에피소드가 있었다. 올해 새 학기가 되어 앱을 일부 업데이트하는 과정에서 Claude Code가 버그를 만들어냈다. 함수를 분리하는 과정에서 studentKey라는 함수의 본문을 return studentKey(s) — 자기 자신을 호출하는 코드로 잘못 작성하여 선발 버튼을 누르는 순간 무한 재귀가 발생해 앱이 멈추는 버그가 생긴 것이다. 그것을 검증하지 않고 수업에서 이 앱을 실행시켰다가 작동하지 않아 민망한 순간이 찾아왔다. 앞선 미니게임의 데이터 검증 실패와 같은 패턴이었다. AI는 코드를 잘 만들지만, 자기가 만든 결과를 검증하는 데는 취약하다. "맞습니다"라고 말해도 실제로 맞는지는 사람이 확인해야 한다.
그 디버깅 과정을 제외하면 Pick Me는 매우 성공적인 프로젝트였다. 초기 버전이 3일 만에 완성되었고, 이번 학기 들어 거의 매 수업 시간마다 사용하고 있다. 학생들은 걸핏하면 "'픽미'하시죠?"라며 수업 중 이 앱을 통한 뽑기를 즐거워 한다.
3. 자리표 앱: 바닐라 HTML 앱에 데이터베이스를 붙이다
세 번째 사례는 바이브 코딩에서 시작해 풀스택 앱으로 성장한 프로젝트다. 앞선 두 프로젝트가 단일 HTML 파일로 완결되는 구조였다면, 이 앱은 데이터베이스와 서버 API, 배포 인프라까지 붙은 구조로 확장되었다. 무작위로 학생들의 자리를 바꾸는 단순한 목적에서 시작했지만, 실제 교실에서 운영하면서 시행착오가 무척 많았다.
자리표 앱의 시작은 아주 소박했다. 2025년 8월, Claude의 Artifact 기능으로 만든 자리표였다. JavaScript 배열에 학생 이름이 하드코딩된 HTML 한 장짜리 앱이었다. 내 첫 번째 바이브 코딩 프로젝트였는데, 작동하는 앱이 나오자 감탄이 절로 나왔다. 디자인도 깔끔해서 교실에서 학생들에게 보여주기에 전혀 손색이 없었다.
그런데 앱을 업데이트하는 과정에서 시행착오가 이어졌다. 가장 까다로웠던 것은 키보드 접근성이었다. 자리표에는 학생 뷰와 교사 뷰를 전환하는 반전 기능이 있다. 교사가 교실 앞에서 학생들을 바라보는 시점과 학생이 칠판을 바라보는 시점은 좌우가 반대이기 때문에, 양쪽 모두를 지원해야 했다. 그런데 이 반전 기능에서 버그가 속출했다. 화면상의 글자가 좌우로 뒤집혀 보이거나, 화면에서는 정상적으로 반전되었는데 스크린 리더는 반전 전 상태를 그대로 읽어주는 식이었다. 시각장애인인 내가 직접 스크린 리더로 테스트하며 하나씩 잡아 나가야 했고, 이 과정이 꽤 지난했다. 시각적 반전은 결국 완벽하게 작동하게 만들었지만, 스크린 리더로 교사 뷰의 반전된 자리표를 읽게 하는 기능은 현재까지 구현하지 못하고 있다.
다음 시행착오는 데이터베이스 확장이었다. 올해 새 학년을 맡으면서 이전 데이터를 아카이빙하고 새 데이터를 로딩해야 했다. 게다가 작년까지는 나 혼자 로컬에서 쓰는 앱이었지만, 올해부터는 업무보조 선생님과 내가 바뀐 자리를 동시에 실시간으로 확인할 수 있어야 했다. 그래서 Supabase로 데이터베이스를 붙이기로 했다.
데이터베이스를 연동한 지 얼마 되지 않아 에러가 떴다. "학기 목록 로드 실패: 500." 원인을 찾아보니 코드 문제가 아니었다. 내 다른 프로젝트에도 같은 Supabase 계정을 쓰고 있었는데, 무료 플랜의 프로젝트 개수를 초과하자 데이터베이스가 자동으로 일시정지된 것이다. 대시보드에서 Resume 버튼을 누르니 복구되었지만, 데이터베이스 서비스 무료 플랜의 한계를 체감할 수 있었다.
배포 과정에서도 뜻밖의 에러를 만났다. HTML 파일일 때는 GitHub Pages로 간단히 배포할 수 있었지만, 풀스택 앱이 되면서 Vercel이라는 배포 플랫폼을 사용해야 했다. 그런데 배포 명령을 실행하자 Error: 김헌용 @ vercel is not a legal HTTP header value라는 메시지가 떴다. 내 이름의 한글이 HTTP 헤더의 허용 범위를 벗어난다는 것이다. 국제화를 표방하는 플랫폼에서 한글 이름이 에러를 일으킨 것이 실망스럽긴 했지만, 사실 개발 과정에서 언어 인코딩 문제는 그리 드문 일이 아니라는 점에서 놀랍진 않았다. 다행히 원인도 우회 방법도 Claude Code가 찾아주었다.
실제 사용 과정에서 발견한 문제도 있었다. 업무보조 선생님이 좌석 배치용 CSV를 업로드했는데, 형식 선택 드롭다운이 "명렬"로 되어 있어 CSV 전체가 이름 목록으로 잘못 파싱된 것이다. "1분단-좌, 1분단-우"가 학생 이름으로 들어갔다. 이 또한 Claude Code가 다양한 형식의 데이터에서 실제 학생 이름만을 추출하도록 패치를 적용하여 해결해 주었다.
자리표 앱이 남긴 교훈은 분명했다. 앱을 만드는 것과 운영하는 것은 전혀 다른 문제다. 데이터베이스를 붙이고 배포하고 다른 사용자와 공유하는 과정, 다시 말해 앱이 풀스택으로 진화하는 과정에서는 바이브 코딩만으로는 감당하기 어려운 영역에 진입하게 된다. 앱을 만들 때는 AI가 대부분 해결해 주지만, 운영할 때는 사용자가 직접 환경을 이해하고 판단해야 하는 순간이 자주 찾아온다. 앱 바깥의 환경 — 데이터베이스 정책, 배포 플랫폼의 제약, 실제 사용자의 행동 패턴 — 까지 알아야 한다.
4. HWPX-Automation: 악명 높은 한글 문서 작업을 자동화하다
HWPX-Automation GitHub
여기서부터는 에이전틱 엔지니어링의 영역이다. 개별 앱을 만드는 것이 아니라, 반복되는 업무의 워크플로우 자체를 설계하고 자동화하는 작업이다.
학교에서는 모든 공문이 한컴오피스의 HWP/HWPX 형식으로 온다. 서식을 채워 넣어야 하는 경우도 많다. 시각장애인 교사로서 이 작업은 특히 부담이 크다. 한컴오피스의 서식 문서는 복잡한 표 구조가 많아서, 화면낭독기로 셀을 하나씩 탐색하며 채워 넣는 데 상당한 시간이 걸리기 때문이다.
처음에는 이걸 하나의 Python 스크립트로 해결하려 했다. 그런데 금방 깨달았다. HWPX 포맷은 XML 기반의 ZIP 아카이브인데, 그 구조가 워낙 복잡하고 함정이 많아서 단일 스크립트로는 불가능하다는 것을. 게다가 한글(HWP) 파일은 자체 바이너리 형식이라 또 다른 변환 도구가 필요하다.
그래서 이 프로젝트의 방향을 바꿨다. 하나의 완벽한 도구를 만드는 대신, Claude Code에게 여러 오픈소스 도구를 조합하여 사용할 수 있는 '지침'을 주자. Claude Code에는 스킬(Skill)이라는 시스템이 있다. 특정 업무의 절차와 규칙을 마크다운 파일로 정의해 두면, Claude Code가 관련 작업을 할 때 자동으로 그 지침을 참조한다. 바이브 코딩이었다면 "한글 문서 편집 앱을 만들어 줘"라고 했을 것이다. 에이전틱 엔지니어링에서는 접근이 다르다. "한글 문서를 다루는 방법을 가르쳐 줄 테니, 앞으로 내가 한글 문서 관련 작업을 지시하면 이 방법을 따라 해"라고 하는 것이다. 앱이 아니라 AI 에이전트가 따라 할 수 있는 워크플로우를 만드는 것이 목표이기 때문이다.
이렇게 만들어진 HWPX-Automation 스킬은 여러 오픈소스 도구를 하나의 워크플로우로 연결한다. HWP 파일이 들어오면 먼저 HWPX로 변환하고, 변환된 파일의 내부 구조를 편집한 뒤, 한컴오피스가 정상적으로 열 수 있도록 마무리 손질을 한다. 표의 특정 셀에 데이터를 채워 넣고, 문서 안에 이미지를 삽입하고, 서식을 다듬고, 한컴오피스 충돌을 일으키는 요소를 수정하고 검증하는 것까지 한 번에 처리된다. 내가 "이 공문 서식 채워 줘"라고 말하면, Claude Code가 이 워크플로우를 따라 알아서 처리하는 것이다.
이 스킬을 구축함에 있어 내가 내린 가장 중요한 결정은, 스킬 앞단에 "HWP이면 HWPX로 먼저 전환"이라는 단계를 추가함으로써 HWP 형식을 과감하게 포기했다는 것이다. 학교 현장에서는 여전히 HWP 형식이 많이 사용되지만, 관행적으로 그렇게 하는 것일 뿐 HWP를 고집할 이유는 전혀 없다. HWP는 독자적인 바이너리 형식이라 AI 에이전트가 내부를 들여다볼 수 없지만, HWPX는 XML 기반의 공개 구조여서 코드로 읽고 쓸 수 있다. 사람이 사용하는 지침이라면 굳이 필요 없는 단계였겠지만, AI 에이전트가 사용하는 지침이므로 스스로 처리할 수 있는 형식으로 입력을 통일하는 것은 이 스킬의 범용성을 높여주는 핵심적 단계였다.
linesegarray와의 사투
이 스킬을 만드는 과정에서 가장 힘들었던 것은 HWPX 파일의 손상 문제였다. Claude Code가 HWPX 문서를 편집할 때마다 한컴오피스에서 "파일이 손상되었습니다"라는 에러가 떴다. 표에 행을 추가하는 단순한 작업, 때로는 글자 하나만 바꾸는 작업에서조차 파일을 깨뜨렸다. 나로서는 원인을 알아낼 길이 없었다. 그저 Claude Code에게 계속 테스트해서 원인을 좁혀보라고 할 수밖에. 그러자 Claude Code가 가설을 세우고 검증하며 범인 찾기를 시작했다.
Claude Code는 HWPX 안의 구성 요소를 절반씩 제거하면서 어떤 요소가 손상을 일으키는지 좁혀가자고 했다. 그때부터 Claude Code가 테스트를 할 때마다 내가 hwpx 파일을 열어 손상됐는지 손상되지 않았는지 확인하고 결과를 알려주는 '무한 루프 지옥'이 시작됐다. 그렇게 수십 페이지 문서를 계속 절반씩 줄여가며 문제가 일어나는 지점을 추적한 끝에 단 하나의 원인을 특정해낼 수 있었다.
범인은 linesegarray라는 요소였다. 각 문단의 줄바꿈 위치를 추적하는 요소인데, 텍스트를 한 글자라도 수정하면 이 위치값이 틀어지고, 한컴오피스가 이를 "손상"으로 판단하는 것이었다. 해결책은 의외로 단순했다. 이 요소 전체를 삭제하면 한컴오피스가 파일을 열 때 자동으로 재계산한다. Claude Code가 오픈소스 프로젝트의 소스코드를 분석하여 이 요소가 필수가 아닌 선택적 항목임을 확인해 줬고, 삭제해도 안전하다는 것이 입증되었다. 어떤 공개 프로젝트도 이 문제를 문서화하지 않았기에, 우리가 직접 찾아낸 셈이다.
이 디버깅 과정에 2~3일이 걸렸다. 하지만 HWPX 파일이 정상적으로 열리는 것을 확인한 순간, 희열과 안도감이 동시에 밀려왔다. 돌이켜 보면 이 과정에서 가설을 세우고, 요소를 제거하고, 안전성을 입증할 근거를 찾아온 것은 모두 Claude Code였다. 내가 한 일은 파일을 열어서 "이번엔 손상됐다", "이번엔 열린다"를 알려주는 것뿐이었다. 에이전틱 엔지니어링에서 사람이 늘 설계자이고 AI가 늘 실행자인 것은 아니다. 디버깅처럼 코드 지식이 필요한 국면에서는 역할이 자연스럽게 뒤바뀐다. 중요한 것은 누가 주도하느냐가 아니라, 사람과 AI가 각자 할 수 있는 일을 맡아 문제를 함께 풀어간다는 것이다.
가장 큰 linesegarray 문제가 해결되었지만 자잘한 버그는 계속 발견됐다. Pandoc으로 변환하면 따옴표 안의 텍스트가 통째로 사라지는 버그, 빈 표 셀이 있으면 한컴오피스가 에러 없이 즉시 종료되는 버그, 표의 행을 복제할 때 구조가 미세하게 다르면 손상으로 판단되는 버그 — 이런 에지 케이스가 끊임없이 나타났다. 나는 하나씩 해결할 때마다 그 해결 과정을 스킬의 트러블슈팅 가이드에 기록하도록 했다.
에이전틱 엔지니어링의 산출물은 앱이 아니라 이런 축적된 지식과 워크플로우 자체다. 한 번 해결한 문제는 스킬에 기록되어, 다음에 같은 상황을 만나면 AI가 자동으로 올바른 방법을 선택한다. 이 점이 바이브 코딩과 가장 다르다. 바이브 코딩에서는 매번 새로운 대화를 시작하지만, 에이전틱 엔지니어링에서는 과거의 경험이 시스템에 축적되어 다음 작업을 더 잘 수행하게 만든다.
이렇게 만들어진 HWPX-Automation은 처음에는 단순 도구들의 느슨한 집합이었지만, 현재는 파싱부터 빌드까지 하나의 워크플로우에서 처리하는 통합 스킬로 발전했다. 그리고 이 스킬은 학교와 노동조합 업무를 가리지 않고 하루에도 몇 번씩 사용하는 유용한 자원이 되었다.
5. 장교조 업무 자동화: AI 중앙집행위원회를 설계하다
앞서 제시한 HWPX 스킬은 하나의 문서 형식을 자동화하는 워크플로우였다. 그렇다면 이런 스킬을 여러 개 모아서 조직의 업무 전체를 자동화하면 어떨까? 다섯 번째 사례는 조금 더 대담한 에이전틱 엔지니어링 적용 시도였다. HWPX 스킬이 하나의 문서 형식에 대한 워크플로우였다면, 이번에는 조직 전체의 업무 체계를 AI 시스템으로 재구성한 프로젝트다.
1인 실무자의 현실
함께하는장애인교원노동조합(장교조)은 소규모 노동조합이다. 상근 사무국 직원 없이 현직 교사들이 교직과 노조 업무를 병행한다. 위원장인 나 혼자서 회의록 작성, 회계 관리, 법령 모니터링, 조합원 안내, 블로그 게시 — 이 모든 것을 처리해야 했다.
바이브 코딩으로 이 문제를 해결하려면 어떻게 할까? 아마 "회계 관리 앱을 만들어 줘", "회의록 작성 도구를 만들어 줘"처럼 업무 하나하나에 대해 개별 앱을 요청하게 될 것이다. 하지만 실제로 필요한 것은 그게 아니었다. 이 업무들이 어떤 흐름으로 이루어지고, 어떤 순서로 처리되며, 서로 어떻게 연결되는지를 파악한 뒤, 그 전체를 하나의 시스템으로 자동화하는 것이 필요했다.
이 문제를 해결하기 위해 내가 설계한 시스템이 AI 중앙집행위원회다. 지난 2월, Claude Code에게 이렇게 말했다:
"나는 장교조 위원장 김헌용이야. 장교조 중앙집행위원회의 업무를 효과적으로 처리하기 위하여 5개의 Subagents를 만들고, AI 중앙집행위원회를 구성하고 싶어."
발상은 단순했다. 우리 노조의 실제 조직 구조를 AI 시스템에 그대로 매핑하자는 것이었다. 사무총장, 정책실장, 소통실장, 재정국장, 수석 부위원장 — 각 Agent가 실제 조직의 부서처럼 폴더를 관리하고 업무를 수행한다. 이후 연대 업무가 늘어나자 연대국장 Agent를, 교원 고충상담 업무가 생기자 고충상담사 Agent를 추가했다. 현재 7개 Agent가 운영되고 있다. 이 구조를 설계할 수 있었던 것은 코딩을 알아서가 아니다. 노조가 어떤 부서로 구성되어 있고, 각 부서가 어떤 업무를 담당하고, 어떤 업무가 서로 연결되어 있는지를 내가 알고 있었기 때문이다. 에이전틱 엔지니어링에서 가장 중요한 역량은 결국 자기 업무에 대한 이해다.
설계 과정에서 기술적 제약도 발견했다. 처음에는 "위원장 Agent가 나머지를 총 지휘하게 하자"고 구상했다. 그런데 막상 만들어 보니 Subagent는 다른 Subagent를 호출할 수 없었다. 그래서 설계를 수정했다. 나 자신이 직접 지휘자 역할을 맡고, 복합 업무에는 여러 Agent를 동시에 투입하는 팀 방식을 병행하기로 했다. 도구의 제약을 발견하고 그에 맞게 설계를 조정하는 것 — 이것이 에이전틱 엔지니어링에서 코딩 에이전트의 한계에 대한 인식이 필요한 이유다.
스킬은 일상적 업무 과정에서 진화한다
현재 17종의 스킬이 운영되고 있다. 공식 문서 변환, 회의록 작성, 재정 보고, 블로그 게시, 이메일·문자 발송, 법령 모니터링, 조례 비교 분석, 공문 수신 및 발신, 17개 시도교육청 인사관리기준 비교 등. 노조 운영에 필요한 상당수의 반복 업무가 스킬화되어 있다.
이 17종은 한 번에 만들어진 것이 아니다. 매일 업무를 처리하면서 하나씩 만들고, 쓰면서 고치고, 새로운 필요가 생기면 추가했다. 이 과정이 바로 에이전틱 엔지니어링이다. 결과물인 17개 스킬 목록이 중요한 게 아니라, 그것들을 만들고 조율하고 재구성해 나가는 과정 자체가 핵심이다.
내가 가장 많이 한 작업은 스킬 간의 구조 조정이었다. 법령조사 스킬과 편의지원 조례 분석 스킬이 겹치는 부분이 있어 통합을 검토했지만, 범용 법령 검색과 17개 광역시도 조례 비교는 사용 맥락이 달라서 분리를 유지했다. 이메일 발송과 수신도 합칠지 검토했는데, 보내는 것과 받는 것은 용도와 위험도가 다르다는 판단에 따라 역시 분리했다. 블로그 업로드의 경우, 중집위 스킬, 총회 스킬, 조례 비교 스킬 등 여러 스킬에 블로그 게시 절차가 중복되어 있는 것을 발견하고, 블로그 업로드를 별도 스킬로 분리한 뒤 나머지 스킬이 그것을 참조하도록 바꿨다. 중복을 줄이면서도 각 스킬의 독립성을 유지하는 구조다.
이런 판단들에는 공통점이 있다. AI는 기술적으로 가장 깔끔한 방안을 제시하지만, 조직 안에서 이 스킬들이 실제로 어떻게 쓰일지를 아는 것은 나다. 스킬을 통합할지 분리할지는 코딩 문제가 아니라 업무 설계의 문제이고, 그 판단은 업무를 직접 수행하는 사람이 내려야 한다.
총회 스킬: 9개 세션의 결정화
가장 큰 스킬인 총회 스킬의 탄생 과정이 에이전틱 엔지니어링의 특성을 잘 보여준다. 처음부터 총회 스킬을 만들겠다고 계획한 것이 아니었다. 2월 한 달간 정기총회를 준비하면서, 결산 검증, 결산 보고서, 사업 보고서, 감사 보고서, 사업계획서, 조합비 인상안, 선거인 명부, 자료집 통합, 총회 당일 운영 — 9개 세션에 걸쳐 각 업무를 하나씩 처리했다. 그때는 그냥 눈앞의 일을 하나씩 해치운 것이었다.
총회 준비 중간쯤부터 이 과정을 스킬로 정리해야겠다는 생각이 들었다. Claude Code에게 각 단계가 끝날 때마다 스킬에 반영하도록 지시했다. 끝나고 돌아보니, 이 9번의 경험이 하나의 재사용 가능한 워크플로우로 깔끔하게 정리됐다. Claude Code는 전체 총회 준비 과정을 14개 섹션의 총회 스킬로 결정화했다. D-35부터 D+2까지의 전체 라이프사이클 — 자료집 편찬, 투표 운영, SMS 발송, 후속 처리까지 — 이 하나의 스킬에 담겨 있다. 내년 총회부터는 "총회 준비해 줘" 한 마디면 35일간의 워크플로우가 자동으로 전개된다.
이 과정에서 보이는 것처럼, 에이전틱 엔지니어링은 처음부터 거창한 설계도를 그려놓고 시작하는 것이 아니다. 매일의 업무를 AI와 함께 처리하면서, 그 경험을 축적하고, 어느 시점에 "이건 재사용할 수 있겠다"고 판단하여 워크플로우로 정리하는 것이다. 바이브 코딩이 "지금 필요한 것을 지금 만드는 것"이라면, 에이전틱 엔지니어링은 "지금 한 일이 다음에도 쓸 수 있도록 시스템에 남기는 것"이다.
나오며
다섯 개의 프로젝트를 돌아보면서 느낀 것들을 정리해 본다.
바이브 코딩은 생각보다 강력하다. 공강 시간에 게임을 만들고, 3일 만에 3D 앱을 완성하고, 학기 중에 필요한 도구를 즉석에서 만들어 쓸 수 있다. 자연어로 코딩이 가능해진 덕분에, 개발자가 아닌 사람도 자기가 필요한 소프트웨어를 직접 만들 수 있는 시대가 열렸다. 다만 AI가 "맞다"고 보증해도 틀릴 수 있고, 코드 리뷰가 오히려 버그를 만들기도 한다. 산출물의 최종 검증은 사용자의 몫이라는 점은 꼭 기억해야 한다.
에이전틱 엔지니어링은 그보다 느리고 까다롭다. 며칠 동안 매달려서 linesegarray라는 하나의 원인을 가까스로 추적하고, 7개 Agent의 역할 경계를 조정하고, 17개 스킬의 통합과 분리를 판단하는 일은 "만들어 줘" 한 마디로 되는 작업이 아니다. 내 업무가 어떤 흐름으로 이루어지는지를 이해하고, 내 도구가 무엇을 잘하고 어디서 실수하는지를 알아야 한다. 하지만 한 번 구축한 워크플로우는 매년, 매학기 반복해서 쓸 수 있다. 바이브 코딩이 "지금 필요한 것을 지금 만드는 것"이라면, 에이전틱 엔지니어링은 "한 번 설계해서 오래 쓰는 것"이다.
이 두 층위는 배타적이지 않다. 자리표 앱처럼 바이브 코딩으로 시작해 풀스택 앱으로 성장하는 경우도 있고, 총회 스킬처럼 매일의 작업 경험이 축적되어 하나의 워크플로우로 결정화되는 경우도 있다. 바이브 코딩으로 시작하는 것을 두려워할 필요가 없다. 중요한 것은 "만들어 줘"로 충분한 상황과 시스템을 설계해야 하는 상황을 구분하는 감각이고, 그 감각은 직접 해봐야 생긴다.
마지막으로, 시각장애인 교사로서 한 가지만 덧붙인다. 이 글에서 소개한 모든 작업, 게임 기획, 접근성 설계, 문서 포맷 디버깅, 조직 업무의 시스템화에서 시각은 필요하지 않았다. 필요했던 것은 내 수업을 이해하는 것, 내 조직을 이해하는 것, 그리고 내 도구의 가능성과 한계를 아는 것이었다. 시각장애가 가로막는 것은 화면을 보는 일이지, 시스템을 설계하는 일이 아니다.
참고 자료 및 링크
