AI 시대, 교사는 코딩 대신 ‘비결정성 통제 시스템’을 설계한다

기술이 우리의 일터에 깊숙이 들어올수록 “내 일의 본질은 무엇인가”라는 질문은 더욱 날카로워진다. 인공지능이 코드 작성이라는 개발자의 핵심 업무를 빠르게 자동화하면서, 소프트웨어 개발자 사회는 지금 격렬한 정체성 위기를 겪는다. 이 논의는 멀리 떨어진 타인의 이야기가 아니다. 정보의 생산과 전달을 넘어, 학습 경험을 설계하고 인간 성장을 촉진하는 우리 교사들에게도 똑같이 적용되는 거울이다.

본질이 흔들리는가, 깊이가 변하는가

챗GPT 같은 거대언어모델(LLM)은 자연어 지시만으로 수백 줄의 코드를 순식간에 생성한다. 과거에는 빈 화면 앞에서 코드를 빠르게 타이핑하는 능력이 개발자의 핵심 경쟁력이었다. 그러나 지금은 AI가 기본적인 구현 지식과 방법을 제공한다. 이는 “내가 직접 코드를 작성하지 않아도 개발이라 할 수 있는가?”라는 근본적인 질문을 던진다.

AI는 개발자의 일에서 반복적이고 예측 가능한 부분을 빠르게 흡수한다. 과거의 개발 지식은 단순히 기술 목록이 아니라, 당대 개발자들이 문제를 해결하고 새로운 추상화 계층을 만들어낸 과정이었다. 기계어, 어셈블리어, 객체지향, 프레임워크 모두 하위 계층의 복잡성을 감추기 위해 등장했다. 이 역사를 이해하면, 개발자의 역할 변화가 이번이 처음이 아님을 깨닫는다.

우리 교육 현장도 마찬가지다. AI가 기본 학습 자료를 생성하고, 개별 학생의 수준에 맞는 문제지를 만들어주는 시대가 온다. 이때 “내가 직접 모든 콘텐츠를 만들어야 교사인가?”라는 질문에 직면한다. 문제는 코딩을 ‘손가락으로 글자를 입력하는 행위’로 보는지, 아니면 ‘문제 해결을 위한 지능적 사고 과정’으로 보는지에 달린다. 본질은 후자이며, 이 본질은 결코 흔들리지 않는다. 깊이의 방향이 달라질 뿐이다.

디테일을 채우고, 추상화로 감추기

개발자의 본질적 역할은 모호한 요구사항의 디테일을 구체화하고 이를 재사용 가능한 형태로 추상화하는 능력에 있다. 기획 단계에서는 제품의 큰 목적과 방향을 제시하지만, 실제 구현에 필요한 모든 조건을 명시하지 않는다. 예를 들어 ‘학생 닉네임 수정 기능’이라는 간단한 요구사항에도 다음과 같은 복잡한 디테일이 숨어 있다.

조건 유형	세부 내용
입력 유효성	빈 문자열 허용 여부, 특수문자/이모지 처리 방식, 길이 제한
오류 처리	네트워크 오류 시 동작, 응답 지연 시 처리, 서버 에러 메시지
사용자 경험	수정 중 화면 이동 시 동작, 오류 메시지 위치/표현 방식, 로딩 인디케이터
보안/윤리	욕설/비속어 필터링, 개인정보 보호(닉네임 마스킹)

개발자는 이런 빈틈을 논리적인 규칙과 예외 처리로 완결된 시스템 동작으로 전환한다. 한 번 해결한 문제는 함수, 모듈, 라이브러리, 프레임워크 등으로 포장하여 반복 작업을 줄인다. 이것이 추상화이며, 추상화는 반복되는 내부 동작을 감추고 외부에서 필요한 기능만 노출하는 과정이다. 견고한 추상화가 쌓이면 새로운 계층이 형성되고, 상위 계층의 개발자는 하위 구현을 모두 알지 못해도 작업할 수 있다.

교사의 역할도 다르지 않다. 교육과정의 ‘성취 기준’은 추상적인 목표다. 교사는 이를 구체적인 수업 활동, 평가 루브릭, 학생 피드백으로 전환하며 디테일을 채운다. 잘 설계된 수업 모듈이나 평가 도구는 다른 교사가 재사용할 수 있는 ‘추상화된 교육 솔루션’이다. 교사의 전문성은 바로 이 추상화 능력, 즉 복잡한 교육 현장의 요구를 구조화하고 재사용 가능한 형태로 만들어내는 데 있다.

AI는 새로운 추상화 계층, 그 비결정성의 그림자

AI는 기존에 개발자가 직접 처리하던 코드 작성과 반복 구현을 빠르게 수행하며 새로운 추상화 계층으로 등장했다. 마치 레고 블록처럼, AI는 코드를 빠르게 조립한다. 그러나 AI가 코드를 생성한다고 해서 요구사항 해석, 구조 설계, 품질 검증, 운영 책임까지 자동으로 해결되는 것은 아니다. 오히려 구현 비용이 낮아지면서, 생성된 코드를 조립하고 검증하는 비용의 중요성이 부각된다.

가장 중요한 문제 하나는 AI 코드 생성의 비결정성이다. 전통적인 프로그램은 동일한 입력에 대해 예측 가능한 동일한 출력을 반환한다. 그러나 AI는 동일한 요청에도 맥락이나 무작위성에 따라 서로 다른 코드와 판단을 내놓을 수 있다. 이는 AI가 대규모 리팩터링을 수행했을 때, 기능은 작동하더라도 변경된 코드의 정확성 검토, 삭제된 코드의 불필요성 판단, 새로운 부작용 발생 가능성, 유지보수와 배포 책임이라는 근본적인 문제가 남는다는 의미다. AI는 생산성을 높이지만, 결과의 안정성과 책임은 제공하지 않는다.

교육에서 AI의 비결정성은 더 큰 그림자를 드리운다. 학생에게 제공된 AI 생성 콘텐츠가 사실 오류를 포함하거나, 특정 관점에 편향될 수 있다. AI가 학생 데이터를 분석해 학습 경로를 추천할 때, 그 추천이 ‘왜 그렇게 내려졌는지’ 설명하기 어렵다. 이는 곧 책임 소재의 불분명함으로 이어진다. AI의 놀라운 생성 능력 뒤에 숨은 불확실성을 통제하지 못하면, 교육의 핵심 가치인 신뢰와 공정성이 무너진다.

지시가 독이 되는 앵커링 효과

많은 이들이 AI에게 더 좋은 결과를 얻기 위해 프롬프트를 상세하게 작성하는 데 집중한다. 그러나 세부 지시가 오히려 AI의 성능을 제한할 수 있다. 원문 필자는 접근성 UI 사이드 프로젝트에서 AI만으로 개발을 시도하며 이를 경험했다. 초기에는 AI에게 구체적인 구현 방법을 제시했지만, AI는 제시된 방법에 고착되어 예외 처리를 반복적으로 추가했고, 코드는 복잡해졌다. 더 적절한 표준 방식은 뒤늦게야 적용되었다.

이 사례는 사용자가 제시한 초기 방법이 AI의 판단을 제한하는 ‘앵커’로 작용할 수 있음을 보여준다. 마치 문제 해결의 실마리를 너무 일찍 던져주면 AI의 광범위한 탐색 능력을 스스로 묶어버리는 셈이다. 따라서 해결 방법과 코드 구조를 지나치게 지시하기보다 다음을 제공하는 것이 훨씬 효과적이다.

구분	과거 방식 (세부 지시)	미래 방식 (목표 위임)
초점	어떻게 구현할 것인가	왜 필요한가, 무엇을 달성해야 하는가
정보 제공	특정 알고리즘, 코드 패턴, 함수 호출 순서	문제의 배경과 목적, 현재 시스템의 맥락, 반드시 만족해야 할 결과
제약 조건	구현 시 사용해야 할 라이브러리/프레임워크	변경해서는 안 되는 제약 조건
AI의 역할	지시를 따르는 단순한 코드 생성기	문제 해결을 위한 자율적인 에이전트

AI의 성능이 높아질수록 세부 절차를 직접 지정하는 방식보다 목표 중심의 위임이 효과적이다. 이는 교사가 학생에게 과제를 줄 때도 적용된다. 특정 풀이 방식을 강요하기보다, 문제의 맥락과 달성해야 할 목표를 명확히 제시하고 학생 스스로 해결 방안을 탐색하도록 유도하는 것이 더 깊이 있는 학습을 이끌어내는 방식이다. AI를 다루는 역량은 곧 학생들을 교육하는 역량과 맞닿아 있다.

하나의 작업 하나의 산출물, AI와의 TDD

LLM은 한 번의 응답에서 처리할 수 있는 출력량과 사고 범위가 제한된다. 테스트 작성과 구현을 동시에 지시하면 최종 목표인 코드 완성에 자원이 집중되어 테스트 품질이 낮아질 수 있다. 마치 교사가 학생에게 ‘보고서 작성’과 ‘발표 준비’를 동시에 지시하며 ‘두 가지 모두 최고 수준으로’라고 요구하면, 둘 중 하나 또는 둘 다 허술해지는 것과 같다.

원문 필자는 테스트 주도 개발(TDD) 방식을 AI에게 적용하며 다음과 같이 작업을 분리했다.

• 레드(Red): 실패하는 테스트만 작성 (기능 정의)
• 그린(Green): 테스트를 통과하는 최소 구현 작성 (기능 구현)
• 리팩터(Refactor): 테스트를 유지하면서 코드 구조 개선 (코드 품질 향상)

각 단계의 산출물을 하나로 제한하면 AI가 중간 절차를 생략하거나 형식적으로 처리하는 문제를 줄인다. 이는 프롬프트 설계의 핵심이 행동을 장황하게 설명하는 것이 아니라, 한 번의 작업에서 생성해야 할 결과물을 명확하게 정의하는 것임을 의미한다. 교사에게 이 원칙은 ‘한 번의 프롬프트로 완벽한 수업 계획서를 기대하지 말라’는 교훈을 준다. AI에게는 수업 목표 정의, 활동 아이디어 구상, 평가 문항 생성 등 작은 단위의 작업을 단계별로 지시하고, 각 단계의 산출물을 명확히 지정해야 한다.

새로운 프로그래밍 언어가 된 마크다운과 스킬

명세, 테스트, 구현, 검증, 커밋 작업을 각각의 스킬로 분리하고 이를 파이프라인으로 구성하는 과정은 함수와 모듈을 설계하는 것과 유사하다. 각 스킬은 입력, 출력, 제약 조건을 가지므로 함수와 같이 작동한다. 여기서 중요한 것은 스킬과 규칙을 기록한 마크다운 문서는 단순 설명서가 아니라 AI의 행동을 결정하는 ‘실행 규칙’으로 기능한다는 점이다.

이는 기존 소프트웨어 설계 원칙과도 연결된다. 하나의 스킬에 하나의 책임만 부여하는 단일 책임 원칙(SRP), 지식과 규칙을 별도 파일로 분리하는 모듈화, 핵심 스킬을 변경하지 않고 외부 지식 파일로 확장하는 개방-폐쇄 원칙(OCP) 등이 모두 적용된다. 개발 플랫폼이 통합 개발 환경(IDE)에서 마크다운 문서로 바뀌었을 뿐, 작업을 분해하고 연결하는 행위는 여전히 프로그래밍이다.

이 관점은 교사들에게 시사하는 바가 매우 크다. 우리 교사들의 암묵적인 전문성, 즉 수업의 노하우, 학생 지도의 원칙, 평가의 철학은 그동안 주로 개인의 경험 속에 머물렀다. 이제 우리는 이 암묵지를 마크다운 같은 형태로 명확히 문서화하고 ‘스킬’로 정의해야 한다. 예를 들어 ‘동기 유발 스킬’, ‘그룹 토론 운영 스킬’, ‘형성 평가 피드백 스킬’ 등으로 추상화하고, 각 스킬의 입력(학생 반응, 수업 주제), 출력(다음 질문, 활동 지시), 제약 조건(시간, 자원)을 명시하는 것이다. 이는 단순 기록을 넘어, AI가 우리의 전문성을 학습하고 재구성할 수 있는 새로운 ‘교육 프로그래밍 언어’를 창조하는 일이다. 우리의 수업 설계 방식과 판단 과정까지 추상화하는 작업이 시작된 것이다.

예측 불가능성을 가두는 결정적 하네스

AI가 생성한 결과를 다른 AI에게 검증시키는 것만으로는 충분한 신뢰성을 확보하기 어렵다. 시스템의 출력이 올바른지를 판단하려면 명확한 정답 기준, 즉 오라클(Oracle)이 필요하다. 비결정적인 AI가 검증 기준까지 임의로 생성하면 올바른 결과를 잘못 수정하거나 검증 기준을 왜곡할 가능성이 농후하다.

따라서 AI 산출물 검증 기준은 가능한 한 결정적인 도구로 구성해야 한다. 원문에서 제시된 도구들은 다음과 같다.

영역	결정적 도구	교육 현장 적용 예시
코드 품질	컴파일러, 타입 검사기, 린터, 정적 분석	AI 생성 평가 문항의 명확성 및 오류 검사기, 학습 목표 부합도 검사 루브릭
기능 검증	자동화된 테스트	사전 정의된 평가 기준을 통한 AI 생성 피드백 점수화, 학생 답안 샘플을 통한 AI 채점 정확성 검증
구조/데이터	스키마 검사	AI 생성 교육 콘텐츠의 정보 구조 유효성 검사, 데이터 형식 표준 준수 여부
운영 관리	성능·보안 기준, 승인 절차, 변경 범위 제한	AI 기반 학습 관리 시스템의 보안 프로토콜, AI 활용 콘텐츠의 사전 교사 승인 절차, AI 수정 가능 콘텐츠 범위 제한

이처럼 ‘하네스(Harness)’는 AI가 작업 과정에서 오류를 누적하거나 범위를 벗어나지 못하도록 단계별로 배치하는 검증 장치다. 작업 단계를 분리하는 파이프라인, 단계별 입출력 형식, 자동 테스트, 실패 시 중단되는 검증 게이트, 변경 가능한 파일과 범위 제한, 사람의 승인 및 리뷰 절차 등이 하네스의 주요 구성 요소다. 하네스는 한 단계의 작은 오류가 다음 단계에서 확대되는 것을 방지한다.

교사들은 이러한 하네스 엔지니어링 역량을 키워야 한다. AI가 생성한 학습 자료, 평가 문항, 피드백 등 교육적 산출물을 어떻게 신뢰할 수 있게 만들 것인가? 정답은 AI 스스로의 검증에 맡기는 것이 아니다. 명확한 평가 루브릭, 동료 교사의 검토, 그리고 우리의 비판적 사고라는 ‘결정적 도구’를 AI 결과물에 적용해야 한다. 예를 들어 AI가 만들어낸 개별화된 학습 경로를 바로 적용하기보다, 그 추천의 근거와 적절성을 교사들이 함께 검토하는 ‘협력적 검증 게이트’를 구축해야 한다. 예측 불가능한 AI의 출력을 안정적인 교육 시스템 안에 묶어두는 능력이 미래 교사 전문성의 핵심이 된다.

교사 전문성은 사라지는가 이동하는가

AI는 단순한 코드 작성과 반복 구현을 빠르게 자동화한다. 이는 교사에게서도 콘텐츠 제작, 정보 전달 같은 단순 반복 업무의 비중을 줄일 것이다. 그러나 제품 수준의 결과, 즉 실제 학생 성장을 이끄는 교육을 위해서는 여전히 다음 역할이 필요하다.

기존 개발자 역할 (코딩)	미래 개발자 역할 (AI 에이전트 통제)	미래 교사 역할 (AI 교육 환경 설계)
코드 작성	문제와 목표 정의	학습 목표 정의 및 재정의
개별 기능 구현	시스템 구조 설계	학습 경험 구조 설계
디버깅 및 오류 수정	작업 단계와 산출물 분리	AI 활용 학습 활동 단계 및 결과물 명확화
라이브러리/API 활용	AI 에이전트 간 흐름 조율	다양한 AI 도구 간 학습 흐름 조율
코드 테스트	검증 기준과 하네스 구축	AI 생성 콘텐츠/피드백 검증 시스템 구축
배포 및 유지보수	운영 결과에 대한 최종 책임	AI 활용 교육 결과에 대한 최종 책임

개발자의 업무가 직접 코드를 입력하는 비중이 줄고, AI가 생성한 코드를 시스템으로 조직하고 통제하는 방향으로 변화하는 것처럼, 교사의 업무도 직접 지식을 전달하는 비중이 줄고, AI가 생성한 학습 경험을 설계하고 통제하는 방향으로 변화한다.

미래 교사의 핵심 역량은 명확하다.

• 문제를 정확하게 정의하고, 학습 목표를 명료하게 설정하는 능력
• 목표와 맥락 중심으로 AI에게 업무를 위임하고, 그 과정에서 부족한 질문을 던질 수 있는 능력
• 복잡한 학습 경험 설계를 작은 산출물로 분해하여 AI를 활용하는 능력
• 다양한 AI 스킬과 에이전트를 파이프라인으로 구성하여 학습 과정을 조직하는 능력
• 결정적인 검증 기준을 설계하고, AI가 생성한 결과물의 품질과 안전성을 판단하는 능력
• 비결정적 결과의 위험을 통제하는 ‘교육 하네스’를 구축하는 능력
• AI가 생성한 결과를 이해하고 최종 책임을 질 수 있는 기술적 깊이

AI는 교육의 본질을 제거하기보다, 교사가 다뤄야 할 추상화 계층을 변화시킨다. 이전 교사가 지식과 수업 활동의 디테일을 처리했다면, 미래 교사는 AI의 행동과 출력에서 발생하는 디테일을 처리해야 한다. 콘텐츠를 생성하는 비용은 낮아지지만, 검증, 조립, 운영, 통제의 중요성은 더욱 커진다. 교사의 본질은 단순히 가르치는 행위 자체가 아니라, 학습의 디테일을 발견하고, 이를 추상화하며, 신뢰할 수 있는 시스템으로 구성하는 능력에 있다.

현장의 ‘우리’는 무엇을 설계해야 하는가

AI가 보편화될수록 ‘무엇을 할 것인가’라는 질문은 ‘무엇을 하지 않을 것인가’만큼 중요해진다. 무분별한 AI 도입이 아닌, 전략적 활용을 위해서는 AI가 만들어낼 수 있는 결과물에 대한 명확한 상한선과 하한선을 정의하는 것이 먼저다. 우리 교육 현장에서 AI가 자동 생성하는 것은 어디까지 허용하고, 그 이상은 반드시 인간 교사의 판단과 개입이 필요하다고 단언할 것인가? 이 기준을 설계하는 것이 우리 교사들의 최우선 과제이다. 이 설계 과정은 책상에 앉아 홀로 고민하는 것이 아니다. 점심 식사 자리에서 AI가 만든 수업 자료의 ‘수상한 부분’을 함께 짚어보는 5분, 혹은 학년 메신저에 ‘이런 프롬프트로 얻은 결과는 위험하다’는 한 줄 후기를 남기는 작은 시도에서 시작된다. 동료들과의 꾸준하고 구체적인 대화와 관찰만이 현장의 ‘결정적 하네스’를 만든다.

출처

• 원문: 테오(teo). AI 시대의 프로그래머 — 코드 생성에서 비결정성 통제로의 역할 전환. https://velog.io/@teo/we-programmer
• 경유: GeekNews. https://news.hada.io/topic?id=30711