교사의 업무를 AI와 함께 설계하기

1. AI에게 코드를 맡기면서 알게 된 것

ChatGPT가 처음 등장했을 무렵, 나는 웹 채팅창과 코드 편집기를 오가며 프로그램을 만들었다. 원하는 기능을 설명하고, AI가 준 코드를 복사하고, 실행하다 오류가 나면 그 메시지를 다시 붙여 넣었다. 답을 받아 고치고 실행하는 일을 반복했다. 긴 코드를 다루다 보면 앞서 설명한 조건이 빠지거나, 잘 되던 부분까지 바뀌어서 이전 작업을 다시 설명해야 했다.

그러다 Cursor 같은 도구를 사용하면서 작업 방식이 달라졌다. AI가 프로젝트 파일을 직접 읽고 수정하니 코드를 조각조각 옮기는 일이 줄었다. “학생이 문제를 풀고 답을 확인하는 화면을 만들어 줘”라고 요청하면, AI가 관련 파일을 찾고 코드를 고친 뒤 실행 결과를 살피며 오류를 다시 수정할 수 있었다.

파일을 한 번 고쳐 주는 코드 보조를 넘어, AI가 목표를 받고 확인 → 수정 → 실행 → 결과 관찰 → 재시도를 여러 단계로 이어 가는 방식을 에이전틱 코딩이라고 한다. 복사와 붙여넣기는 줄었고 작업 속도는 빨라졌다. 하지만 AI가 더 많은 일을 직접 처리할수록, 단순히 요청을 잘 쓰는 것만으로는 부족하다는 사실도 알게 되었다.

먼저 한 대화에 너무 많은 맥락이 쌓이는 불편이 생겼다. 대화가 길어지면 처음 정한 조건과 나중에 바꾼 결정이 뒤섞였다. 이미 버린 계획을 AI가 다시 꺼내거나, 지금 작업과 관계없는 오류 기록에 끌려가기도 했다. 교사가 동료에게 일을 맡길 때 최신 수업안과 필요한 자료를 골라 주듯, AI에게도 현재 목표·관련 파일·확정한 결정·실행 결과 가운데 지금 필요한 것만 전달해야 했다. 무엇을 언제 읽히고, 무엇을 기록하거나 제외할지 설계하는 일이 컨텍스트 엔지니어링이다.

그런데 필요한 정보만 추리는 것으로 끝나지 않았다. 성격이 다른 작업의 맥락이 계속 한곳에서 부딪히는 불편이 남았다. 활동지 내용을 검토하려면 교육과정, 학년 수준, 문항과 해설의 정확성이 중요하다. 같은 활동지를 A4 인쇄 화면으로 만들 때는 용지 크기, 여백, 글자 배치와 출력 결과를 봐야 한다. 한 대화에서 두 작업을 오가면 인쇄 오류와 CSS 수정 기록 사이에 내용 검토 기준이 묻히고, 화면을 고치다가 이미 확인한 원고까지 다시 바꾸는 일이 생길 수 있다.

그래서 단순히 맥락을 줄이는 데서 더 나아가 목적이 다른 작업은 작업 공간 자체를 나눌 필요가 생겼다. 내용 검토를 맡은 에이전트는 교육과정 자료와 원고를 보고, 인쇄 화면을 맡은 에이전트는 검토가 끝난 원고와 출력 조건만 받는다. 각자 수정할 범위와 결과 형식을 정하고, 확인된 원고를 다음 작업에 넘기는 순서도 정한다. 이렇게 둘 이상의 에이전트 작업을 구분하고 결과를 연결하는 구성이 멀티 에이전트 작업이다. 여러 에이전트를 쓰면 무조건 더 좋은 것이 아니라, 서로 다른 맥락과 담당 범위를 분명히 나눌 수 있을 때 효과가 있다.

작업을 나누자 또 다른 불편이 보였다. 담당을 설명했다고 해서 실제 행동 범위까지 저절로 제한되지는 않았다. 인쇄 화면 담당에게 “원고는 바꾸지 마”라고 말해도 파일 수정 권한이 그대로라면 확인을 마친 글까지 고칠 수 있다. 한 작업이 공유 파일을 지우거나 외부 전송 명령을 실행하면 다른 작업에도 영향을 준다. 그래서 수정 가능한 파일, 실행 전에 승인이 필요한 행동, 변경 전 기준점, 완료를 확인할 방법과 실패했을 때 멈추거나 복구할 절차가 함께 필요했다. 이렇게 지침·도구·권한·기록·검증·복구가 작동하는 환경을 설계하는 일이 하네스 엔지니어링이다.

세 개념은 실제 불편을 하나씩 해결하며 이어진다. 정보가 뒤섞이면 필요한 맥락을 선별하고, 서로 다른 맥락이 계속 충돌하면 작업을 나누며, 나눈 작업이 실제 파일과 명령을 다룰 때는 행동 범위와 검증 장치를 마련한다. 처음에는 이 흐름만 이해하면 된다. 각 용어를 누르면 구체적인 방법과 관련 IT 용어를 따로 확인할 수 있다.

AI에게 일을 맡기려면 목표만 말하는 것으로 끝나지 않는다. 필요한 맥락을 주고, 나눌 일을 정하고, 지켜야 할 경계와 확인 방법을 마련해야 한다.

흔히 바이브 코딩은 구현 세부를 일일이 작성하기보다 원하는 결과를 말로 설명해 코드를 만들어 가는 비공식적 방식을 가리킨다. 이 연수도 그 쉬운 출발점을 활용한다. 다만 “만들어 줘”라고 말하고 나온 결과를 그대로 쓰는 데서 멈추지 않는다. 교사의 업무를 설명하고, AI가 실제로 한 일을 살피고, 결과가 수업 목적과 안전 기준에 맞는지 판단하는 단계까지 연습한다.

2. 교사는 자기에게 필요한 것을 만들어 쓰는 사람이다

교사는 이미 많은 것을 직접 만들어 쓴다. 시중의 학습지를 우리 반 수준에 맞게 고치고, 평가표의 항목을 바꾸고, 여러 자료를 엮어 새로운 수업 활동을 구성한다. 완성된 자료가 있어도 내 수업에 맞춰 손보는 과정이 자연스럽다.

도구도 그렇게 생각해 볼 수 있다. 어떤 서비스의 입력 양식이 내 업무와 맞지 않거나, 꼭 필요한 기능 하나가 빠져 있을 때가 있다. 결과를 내려받은 뒤 다시 정리해야 한다면, 내가 원하는 형태의 초안을 바로 만들어 주는 작은 도구가 더 편리할 수도 있다.

서비스에 내 수업과 업무를 맞추기보다, 내게 필요한 도구를 직접 만들어 쓴다. 이 연수가 지향하는 것은 교사의 DIY다.

DIY는 필요한 것을 직접 만들거나 고쳐 쓴다는 뜻이다. AI는 교사가 가진 현장의 지식을 작업 절차와 프로그램으로 옮기는 일을 도울 수 있다. 어떤 정보가 필요하고, 무엇을 확인해야 하며, 어떤 결과가 실제로 쓸 만한지는 그 업무를 하는 교사가 가장 잘 안다.

요즘은 문서 요약, 문항 생성, 안내문 작성처럼 AI 기능을 내세운 웹서비스가 많이 나온다. 이 가운데 기존 대규모 언어 모델(LLM)에 업무용 지침과 화면을 붙여 구현할 수 있는 기능이 있다. LLM은 글을 읽고 요약하거나 새로운 문장을 생성하는 AI 모델이다. API는 프로그램끼리 요청과 응답을 주고받도록 정한 인터페이스다. 모델 제공자가 공개한 API를 사용하면 내가 만든 프로그램에서 모델에 요청을 보내고 응답을 받을 수 있다.

예를 들어 안내문 초안 도구는 행사 목적과 일정, 준비물을 입력받아 작성 지침과 함께 모델에 보내고, 돌아온 답을 정해진 양식으로 보여 줄 수 있다. 내가 필요한 것이 이런 작은 기능이라면 직접 구현해 볼 여지가 있다. 다만 웹브라우저나 학생용 프로그램에 API 키를 넣으면 비밀키가 노출된다. 실제 서비스로 운영하려면 서버에서 키를 보호하고, 사용자 인증과 호출 한도, 예산 한도, 기록·보존 정책을 관리해야 한다.

API 기반 서비스의 운영자도 모델 사용 비용을 부담한다. 그래서 월정액 상품에 월 생성 횟수나 크레딧 한도가 붙을 수 있다. API 사용료는 일반 채팅 구독과 별도로 책정되는 경우가 많고, 제공자에 따라 무료 할당량이나 체험 크레딧이 있을 수 있다. 계정과 요금 조건을 직접 확인해야 한다.

직접 만든 도구는 입력 항목과 작성 기준, 출력 양식을 내 뜻대로 정할 수 있고, 소량 사용에서는 여러 서비스를 구독하는 것보다 저렴할 수도 있다. 반대로 사용량이 늘면 비용이 더 커질 수 있고, 비밀키·사용량·데이터 처리 조건을 직접 관리해야 한다. 비용만이 아니라 유지 책임까지 비교한 뒤 선택해야 한다.

검색과 자료 연동, 보안과 협업까지 갖춘 서비스 전체를 만드는 일은 부담이 크다. 처음에는 내가 자주 쓰는 작은 기능 하나에 집중하면 된다. 내 업무에 필요한 만큼 만들고, 직접 써 보며 고칠 수 있다는 것이 DIY의 가치다.

3. 검증한 작업 절차는 스킬로, 반복할 사용자 기능은 앱으로

직접 만들어 쓴다고 생각하면 먼저 앱 화면을 떠올리기 쉽다. 그런데 교사의 개인 업무에서는 AI가 일하는 방법을 정리해 두는 것이 더 유용할 때도 있다. 자료와 요구가 매번 달라지고, 결과를 보며 방향을 조정해야 하는 일이 많기 때문이다.

활동지를 만든다고 해 보자. 단원과 학생 수준에 따라 설명의 길이, 문제의 난이도, 활동 방식이 달라진다. 처음 나온 결과를 보고 “이 문제는 아직 배우지 않은 개념을 쓰고 있어”, “계산 문제 하나를 줄이고 이유를 설명하는 질문을 넣어 줘”처럼 판단을 더하게 된다. 이런 작업은 AI와 대화를 이어 가며 처리하기 좋다.

다만 매번 같은 기준을 처음부터 설명하는 것은 번거롭다. 먼저 활동지 한 편을 실제로 완성하고 검토한 뒤, 다음에도 반복할 작업 절차, 참고 자료, 결과물 양식과 확인 기준을 묶어 둘 수 있다. 이 연수에서 AI 스킬은 이 묶음을 AI 도구가 다시 불러 쓸 수 있도록 정리한 지침 폴더를 뜻한다. Agent Skills 규격에서는 SKILL.md에 이름·설명·지침을 적고, 필요한 코드와 참고 자료를 함께 둔다. 구체적인 파일 구성은 스킬 실습에서 다룬다.

활동지 제작 스킬이라면 다음 내용을 담을 수 있다.

학년, 단원, 학습 목표와 수업 시간을 먼저 확인한다.
교사가 제공한 교육과정 자료와 활동지 양식을 참고한다.
개념 설명, 탐구 활동, 확인 문제 순서로 초안을 만든다.
문제와 해설을 점검하고, 근거가 부족하거나 교사의 판단이 필요한 부분을 표시한다.

이렇게 준비해 두면 새 단원의 자료를 주고 같은 절차로 작업을 시작할 수 있다. 이번 수업에 필요한 조정은 대화로 이어 간다. 내 경험과 기준이 쌓일수록 스킬도 함께 다듬어진다. 스킬을 등록하고 불러오는 구체적인 방법은 사용하는 AI 도구에 따라 달라진다.

반면 앱은 사용자에게 특정 기능을 제공하는 실행 가능한 프로그램이다. 다른 사람이 일정한 입력 방법과 처리 절차를 사용해야 하거나, 내가 같은 기능을 버튼이나 명령으로 반복하고 싶을 때 앱을 검토할 수 있다. 화면과 저장은 흔한 앱 기능이지만 필수 조건은 아니다.

내가 만든 AirClassSlide의 수업 실험도 사용자 화면이 필요한 사례였다. 수업 중 “프롬프트를 다시 보여 주세요”, “파일은 어디에 있나요”, “어떻게 제출하나요”라는 질문이 겹쳤다. 설명은 교사 화면에, 파일은 다른 곳에, 제출은 메일에 나뉘어 있었다. 그래서 학생이 자기 화면에서 프롬프트와 파일을 확인하고, 같은 수업 흐름 안에서 결과물을 제출하도록 구성했다.

AI와 반복할 작업 절차를 재사용하려면 스킬을, 사람이 사용할 정해진 기능을 제공하려면 앱을 검토한다. 둘은 서로 배타적인 단계가 아니며 저장 여부만으로 나뉘지도 않는다. 활동지 한 편만 완성하고 끝내도 되고, 스킬로 문제 초안을 만든 뒤 앱으로 학생에게 제공할 수도 있다.

활동지 제작과 학생의 학습을 이어 보면, 스킬과 앱이 맡는 자리가 보인다.

그림 1. 교사는 AI와 유연하게 자료를 만들고, 학생은 준비된 앱의 화면과 절차를 이용한다. AI의 초안과 학생에게 제공할 자료 사이에는 교사의 검토가 있다.

4. 역할·자료·목표에서 안전한 작업 기준으로

스킬과 앱을 만드는 출발점은 같다. 내 업무를 AI가 작업할 수 있을 만큼 구체적으로 설명하는 것이다. 이 연수에서는 먼저 역할·자료·목표 세 가지로 업무를 정리하고, 실제 작업 전에는 범위·금지 사항·완료 조건·검증 방법·승인할 행동까지 덧붙인다.

기준	내가 답할 질문	활동지 제작의 예
역할	AI가 어떤 일을 도울 것인가?	교사의 자료를 바탕으로 활동지 초안을 만드는 보조 역할
자료	무엇을 참고해야 하는가?	교육과정 발췌문, 기존 활동지 양식, 가상 예시와 파일 위치
목표	어떤 결과가 나오면 성공인가?	한 차시의 학습 목표에 맞는 활동과 확인 문제, 해설을 정해진 양식으로 작성

이 내용을 프로젝트 루트의 AGENTS.md에 적는 연습부터 한다. 이 프로젝트의 역할·자료·목표와 작업 제약을 정하는 최상위 기준 문서이며, 나중에 만드는 계획이나 설계 문서도 여기서 정한 기준을 따른다. OpenCode는 이 파일을 작업 지침으로 읽지만 도구마다 규칙은 다르다. 실습에서는 AI에게 적용한 기준을 설명하게 하고 직접 확인한다.

기준이 생기면 AI와 함께 계획을 구상한다. 빠진 자료, 먼저 만들 부분, 수정 가능한 파일, 완료 조건과 확인 방법을 정한다. 삭제·외부 전송·배포·결제처럼 영향이 큰 작업은 실행 전에 승인을 받도록 한다. 판단이 애매하면 AI가 임의로 정하지 않고 교사에게 질문하게 한다. 계획을 확인한 뒤 작은 작업 하나부터 시작한다.

완성된 파일을 받으면 직접 열어 본다. 앱이라면 실행하고 값을 넣어 본다. 잘못된 결과가 나오면 사용한 자료, 기대한 결과, 실제 결과를 설명해 수정 요청을 한다. 이 과정을 반복하면서 지침과 계획도 고쳐 나간다. AI가 파일 수정과 실행을 이어 가고, 사람이 기준과 결과를 확인하는 에이전틱한 작업 방식이다.

이 흐름을 그림으로 정리하면 다음과 같다. 한 번에 완성하려 하기보다 작은 실행과 확인을 반복한다.

그림 2. AI가 실행을 맡더라도 작업 기준과 결과 판단은 교사가 맡는다. 목표가 달라지면 작업 안내문도 함께 고친다.

앞에서 겪었던 작업 맥락의 누락과 의도하지 않은 변경을 떠올리면, 작업 범위와 복구 방법도 빼놓을 수 없다. 별도 작업 폴더나 Git 커밋으로 기준점을 남기고, 도구의 실제 권한과 승인 설정을 확인한다. Git은 기록된 파일 변경을 되돌리는 데 유용하지만 외부 전송, API 호출, 데이터베이스 변경, 추적하지 않은 파일 삭제까지 복구하지는 못한다. 비밀키는 Git에 넣지 않고, 외부에 영향을 주는 작업은 실행 전에 승인한다. 실습에는 가상 자료만 사용한다. 실제 학생 자료를 AI 서비스에 입력하거나 업로드하기 전에는 먼저 학교의 승인 절차와 적용되는 개인정보보호 기준을 확인한다. 가명 처리한 자료도 다시 개인을 알아볼 수 있다면 개인정보다. 허용된 경우에도 필요한 정보만 최소화하고, 서비스의 보존 기간·학습 사용 여부·삭제 절차·접근 권한을 확인한다. AI가 만든 정답과 인용도 원자료와 대조한다.

5. 이번 연수에서 시작할 일

작업 공간은 VS Code를 중심으로 구성한다. VS Code는 파일을 편집하고 프로그램을 실행하며 결과를 확인하는 작업실이고, OpenCode는 그 안의 파일과 명령을 다루도록 연결하는 AI 코딩 도구다. Cursor는 비슷한 작업 방식을 처음 경험한 사례이며, 이 연수의 실습 도구는 OpenCode다.

2편에서 작업 공간을 익힌 뒤, 다음 세 활동을 진행한다.

활동 1: 스킬 만들기 (3~6편). 기존 학습지를 읽고 새 활동지를 작성·검수·출력한다. 확인한 작업 절차를 스킬로 저장해 다른 자료에 다시 사용한다.
활동 2: 웹 자동화 (7편부터). AI와 크롬을 연결해 필요한 공문을 찾고, 새 결재 대기 내역이 있으면 알림을 받는다.
활동 3: 앱 만들기 (추후 추가). 웹 자동화 활동 이후에 다룬다.

모든 업무를 스킬이나 앱으로 만들 필요는 없다. 이 블로그와 학습 프로젝트의 실제 사례도 어떤 확장이 필요한지 판단하는 데 활용한다.

출발할 때 모든 기능을 정할 필요는 없다. 최근 반복한 수업·행정 업무 하나를 떠올리고 다음 세 문장을 채워 보자. 실제 학생 개인정보는 적지 않는다.

하고 싶은 일: 나는 __________하는 일을 줄이거나 개선하고 싶다.
참고할 자료: 이 일을 할 때 __________를 사용한다.
원하는 결과: 결과물을 __________가 사용하며, __________할 수 있으면 성공이다.

예를 들어 “단원별 활동지 초안 작성 시간을 줄이고 싶다. 교육과정 자료와 기존 활동지 양식을 참고한다. 내가 초안을 검토해 수업에 맞게 고쳐 쓸 수 있으면 성공이다”라고 적을 수 있다.

이 세 문장이 첫 작업의 출발점이다. 학습지를 우리 반에 맞게 고쳐 쓰던 것처럼, AI가 일하는 방법과 도구도 내 수업과 업무에 맞게 만들어 보자.

다음 글에서는 첫 활동지 작업을 준비할 폴더와 지침 파일을 직접 만든다.

참고 자료

Anthropic: 에이전트의 컨텍스트를 관리하는 방법 — 맥락 선별, 대화 압축, 결정 사항 기록과 하위 에이전트 구성
Anthropic: 멀티 에이전트 연구 시스템의 설계와 비용 — 분담의 효과와 토큰 사용량·조율의 부담을 다룬 연구 시스템 사례
OpenAI: 프롬프트 캐싱 — 반복 입력의 재사용과 비용 할인
OpenAI: 하네스 엔지니어링 — 에이전트가 작업할 환경, 문서와 피드백 체계의 설계
Agent Skills 규격 — 스킬의 지침 파일과 코드·참고 자료 구성