Teaching in the Age of AI: Learning Goals and the Goals of Learning

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Teaching in the Age of AI: Learning Goals and the Goals of Learning를 중심으로, 학습 목표는 관찰 가능한 행동으로 작성한다. ‘테스트를 이해한다’보다 ‘중첩된 레코드 입력에 대한 속성 기반 테스트를 작성한다’처를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 학습 목표는 관찰 가능한 행동으로 작성한다. ‘테스트를 이해한다’보다 ‘중첩된 레코드 입력에 대한 속성 기반 테스트를 작성한다’처럼 수행 여부를 확인할 수 있어야 연습과 자료의 범위도 정해진다.
2. 결과물을 얻는 것과 이해하는 것은 다르다. 종이 위 코드 추론, 직접 구현, 소그룹 토론처럼 학습자가 사고 과정에 참여하는 활동이 필요하며, AI가 모든 코드를 대신 작성하면 이 과정이 사라질 수 있다.
3. 즉각적인 피드백은 반복 학습을 돕지만 정확성이 중요하다. 자동채점은 재시도를 지원하고, LLM은 제한된 코드 스타일 평가 등에 활용할 가능성이 있지만 잘못된 지적이 학습자를 오도할 수 있다.
4. AI로 코드 생성이 쉬워져도 검증 부담은 남는다. 코드 읽기, 정의 이동, 타입 확인, 테스트와 리뷰가 중요하며, 생성 과정에서 학습자가 일부를 직접 구현하도록 하는 방식도 탐색할 가치가 있다.
5. 제인 스트리트의 교육 개편은 과제 규모와 인지 부하를 조절하는 방향이다. 낯선 도구를 순서대로 도입하고, 빠른 코딩보다 테스트 품질·설계·요구사항 수집·동료 리뷰를 강조하면서 실제 운영 경험에 따라 과정을 수정한다.

🧩 배경과 문제 정의

• 소프트웨어 엔지니어이자 제인 스트리트 개발자 교육자인 에린의 경험은 프로그래밍 실무, 인지심리학, 교육 설계가 만나는 지점에 놓여 있다. 핵심 문제는 학습자가 도구를 작동시키는 수준을 넘어 원리를 이해하고 적용하게 만드는 방법이다.
• 코로나19로 인한 원격수업 전환은 접근성, 집중력, 상호작용을 동시에 확보해야 하는 과제를 드러냈다. 한 학습자에게 효과적인 수업 방식이 모든 학생에게 적합하지는 않았다.
• 피드백은 학습에 필수적이지만, 과제 제출 후 한참 지나 받는 평가는 활용도가 떨어질 수 있다. 자동평가와 LLM은 즉각적인 피드백을 지원할 가능성이 있으나, 무작위 재시도나 잘못된 지적이 학습을 방해할 위험도 있다.
• 기업에서도 새로운 언어 기능과 AI 도구를 배우는 지속적인 교육이 필요하다. 이를 담당하려면 교육 전문성과 실제 개발 환경에 대한 이해를 함께 갖춰야 한다.

🕒 시간순 섹션별 상세정리

1. 과학 문제를 푸는 경험이 프로그래밍과 교육 진로로 이어지다

• 에린은 고등학교 마지막 학년을 앞둔 여름, 뉴멕시코에서 6주간 수학·천문학·물리학과 파이썬을 배웠다. 망원경으로 관측한 소행성의 측정값으로 궤도를 계산하는 프로그램을 만들면서, 두렵게 느꼈던 프로그래밍이 자신에게 잘 맞는다는 사실을 발견했다. [00:43]
• 학교에 AP 컴퓨터과학 수업이 없어 거주지 제한이 없는 노스캐롤라이나 온라인 과정을 수강했다. 대학원 진학 전에는 같은 여름 과학 프로그램의 조교로 돌아가 연습문제를 만들고 이진 탐색 트리를 가르치며 교육 분야에서 일하고 싶다는 목표를 세웠다. [01:18]

2. 과학 계산의 역사는 오늘날의 컴퓨팅 기술과 연결된다

• 학부에서 수행한 소행성·혜성의 지구 충돌 시뮬레이션은 포트란으로 작성됐으며, 초기 원자폭발 시뮬레이션 코드에서 파생됐다. 두 현상의 물리학적 유사성이 서로 다른 연구 목적 사이에서 코드가 이어질 수 있는 배경이었다. [02:51]
• 오늘날 머신러닝의 경사하강법에 필요한 자동미분도 초기 포트란 시대로 거슬러 올라간다. 당시 일부 컴파일러는 1차 미분을 지원했지만, 미분한 프로그램을 다시 미분하는 작업에는 제약이 있었다. [03:14]

3. Foldit은 인간의 통찰과 자동화 도구의 상호보완을 보여준다

• 학부 마지막 해의 컴퓨터 그래픽스 수업에서 3차원 렌더링에 매료돼 대학원에 진학했다. 그러나 해당 분야가 성숙해 남은 작업이 주로 산업계에 있다는 점을 알게 됐고, 게임 설계와 컴퓨터과학 교육을 거쳐 Foldit 이용자의 문제 해결·협업·자동화 도구 활용을 연구했다. [04:10]
• Foldit에서는 인간이 단백질 구조를 전체적으로 보고 변형 방향을 제안하고, 컴퓨터가 구조를 반복적으로 조정해 낮은 에너지를 탐색했다. 생화학 배경이 없는 이용자들도 오랫동안 풀리지 않았던 단백질 문제 해결에 기여했으며, 이후에는 새로운 단백질 설계로 활동을 확장했다. [05:18]

4. 원격수업의 접근성은 인터넷 연결만으로 결정되지 않는다

• 교육을 주된 업무로 삼기 위해 미네소타의 칼턴 칼리지에 부임했고, 두 학기 대면수업 뒤 2020년 봄부터 네 학기를 온라인으로 가르쳤다. 원격 전환은 교사와 학생 모두에게 어려웠지만 새로운 교수법을 실험하는 계기도 됐다. [06:43]
• 처음에는 자신의 고등학교 온라인 수업을 본떠 영상 없이 읽기 자료와 연습문제로 수업을 구성했다. 인터넷 환경이 좋지 않은 학생도 참여할 수 있도록 한 선택이었지만, 자신에게 잘 맞았던 텍스트 중심 방식이 모든 학생에게 효과적이지는 않다는 피드백을 받았다. [07:47]

5. 거꾸로 수업은 함께 있는 시간을 상호작용에 배분한다

• 거꾸로 수업에서는 학생이 미리 녹화 강의를 보고, 수업 시간에는 연습문제나 토론을 수행한다. 에린은 실시간 수업에서 학생들을 소그룹으로 나누는 방식도 실험했다. [08:20]
• 거꾸로 수업은 코로나19 이전부터 존재했지만 원격 전환으로 활용이 확대됐다. 핵심은 수동적인 내용 수용을 사전학습으로 옮기고, 함께 있는 시간에는 개별 지도와 토론처럼 교사의 즉각적인 개입이 필요한 활동을 배치하는 데 있다. 에린은 상호작용과 설명을 혼합하는 방식에 도달했다. [08:57]

6. 현장 강의의 집중 효과와 능동적 학습을 함께 살린다

• 대면 강의에는 녹화된 최고의 강의로도 완전히 대체하기 어려운 현장감이 있다는 반론이 제기된다. 에린 역시 눈앞의 실시간 설명이 주의를 모으고 필기를 유도한다는 경험에 동의하지만, 한 시간 내내 듣기만 하면 집중력이 떨어진다고 보았다. [10:02]
• 강의 중 질문을 던지거나, 옆 사람과 이야기하게 하거나, 짧은 문제를 혼자 풀게 하면 학생이 자신의 이해를 점검할 수 있다. 필기 역시 내용을 처리하고 요약해 적는 활동이므로, 나중에 노트를 다시 보지 않더라도 이해에 도움이 될 수 있다는 설명이 나온다. [11:28]

7. 종이 위 코드 읽기는 무작위 수정 대신 실행 원리를 생각하게 한다

• 에린은 화면이 앞에 놓이면 집중하려는 학생조차 어려움을 겪는다고 보아 컴퓨터실 수업을 피하려 했다. 약 절반의 학생이 집중하지 못한다는 수치는 자신의 수업 관찰에 근거한 설명이다. [13:04]
• 종이나 칠판에 짧은 Scheme 프로그램을 적고 결과를 추론하게 하는 활동은 코드의 의미를 직접 생각하게 했다. 컴퓨터로 바로 실행할 수 있으면 무엇이 일어나는지 이해하기보다 원하는 결과를 만들어내는 데 몰두하기 쉽다는 경험이 드러난다. [13:24]

8. 강의 녹화는 결석 보완과 특정 개념 복습에 활용된다

• 녹화가 출석을 줄인다는 다른 강사들의 경험과 달리, 칼턴에서는 학생들이 대면수업에 계속 참여했다. 에린은 상호작용으로 현장 참여의 가치를 높이려 했으며, 녹화의 영향은 기관이나 강사에 따라 다를 수 있다고 보았다. [15:16]
• 영상 장비가 없는 교실에는 삼각대에 단 웹캠을 가져가 강의를 녹화하고 온라인에 게시했다. 녹화는 일정 때문에 결석한 학생의 보충학습을 지원했고, 질문에 답할 때 관련 설명이 있는 시점의 링크를 보내는 데도 쓰였다. [15:45]

9. 즉각적인 자동평가는 반복 시도와 숙달을 지원한다

• 자동채점하는 주간 객관식·빈칸 문제와 프로그래밍 과제 채점기를 활용해 학생이 곧바로 결과를 확인하게 했다. 제출 후 1~2주가 지나서야 받는 피드백은 이미 다른 주제로 넘어간 학생이 읽지 않을 수도 있다는 문제가 있었다. [16:28]
• 숙달학습은 다음 내용으로 넘어가기 전에 일정한 역량을 보이고, 피드백을 받으며 여러 번 시도하는 접근이다. 에린은 이를 전면적으로 적용하지는 않았지만, 자동평가 덕분에 반복 시도와 이해 개선을 더 많이 지원할 수 있었다. [17:18]

10. 숙달학습에도 이해의 지연과 학기 운영의 제약이 있다

• 고급 수학을 배울 당시에는 혼란스러웠지만 약 6개월 뒤 다른 사람에게 설명하면서 개념의 연결을 이해했다는 경험이 드러난다. 이는 해당 시점의 수행 능력과 충분히 무르익은 이해가 반드시 일치하지는 않는다는 쟁점으로 계속된다. [17:48]
• 초등 수학에서는 덧셈이나 긴 나눗셈을 익힌 뒤 다음 단원으로 넘어가도록 학습 속도를 조정할 수 있다. 그러나 대학 수업은 같은 수준의 속도 조절이 어려워 숙달학습을 더 제한된 범위에 적용해야 한다는 견해가 나온다. [18:30]

11. LLM 피드백은 범위를 좁힐 때 유망하지만 오탐을 관리해야 한다

• LLM에는 즉각적인 피드백을 제공할 잠재력이 있으며, 특히 코드 스타일처럼 평가 범위를 구조적으로 제한하는 활용이 유망하다고 보았다. 테스트 기반 자동채점과 린터에 더해 추가적인 코드 작성 기준을 안내할 수 있다는 구상이다. [20:15]
• 다만 실제 경험에서는 LLM이 문제없는 부분을 잘못 지적해 학습자를 오도하는 경우도 많았다. 따라서 학생에게 이런 한계를 주의 깊게 설명하거나 잘못된 피드백의 비율을 줄이는 방법이 필요하다고 보았다. [21:06]

12. 개발자 교육자는 실무와 교육을 절반씩 맡는다

• 에린은 형제 부부 가까이 살기 위해 브루클린으로 이주하면서 미네소타의 교수직을 계속하기 어려워졌다. 마침 제인 스트리트가 교육과 프로그래밍을 결합한 직무를 채용하고 있어, 소프트웨어 엔지니어로 전환하면서도 교육을 이어갈 수 있었다. [21:35]
• 제인 스트리트는 거래에 대한 사고방식뿐 아니라 외부에서 흔히 접하기 어려운 언어·개발 환경·도구를 가르치는 데 오랫동안 투자했다. 기존 실무자들의 교육에 더해, 교육 경험이 풍부한 전담 인력이 필요하다는 판단으로 직무를 만들었다. [22:25]

13. 교육 전문성과 개발 역량을 함께 갖춘 인재는 드물다

• 좋은 직무를 공고하면 적합한 지원자가 많이 올 것이라는 기대와 달리 채용은 어려웠다. 교육 경험이 많은 사람은 대체로 학계에 있고, 그 일을 좋아해 산업계로 이동하거나 일상적인 소프트웨어 개발을 업무의 큰 부분으로 삼으려 하지 않을 수 있다. [24:20]
• 이상적인 후보자는 교육 경험과 열정이 깊고, 실험하며 교수법을 개선하려는 동시에 전문 엔지니어로서도 신뢰할 만한 역량을 갖춰야 한다. 이런 조합은 드물지만 역할의 성과에는 만족하고 있으며, 내부 직원의 직무 전환과 외부 채용을 함께 활용하고 있다. [25:55]

14. OCaml의 변화와 AI 도구 확산이 전 직원 교육 수요를 만든다

• 전담 교육자의 가치는 교육을 지속적인 관심사로 유지하는 데 있다. 신규 입사자의 OCaml 입문뿐 아니라 언어 자체의 변화에 대한 기존 직원 교육, 새로운 AI 도구의 효과적인 사용법까지 교육 대상이 확대되고 있다. [26:48]
• 언어를 확장하고 개선할수록 추가로 가르치고 개선할 영역도 늘어나는 것으로 보았다. 이에 따라 프로그래밍 언어 기반이 탄탄한 OCaml 교육자 직무를 공고해 적합한 후보를 찾았고, 새로운 머신러닝 모델의 개발·학습을 이해하고 가르칠 교육자도 계속 찾고 있다. [27:40]

15. 특정 언어에 갇히지 않고 상황에 맞는 도구를 고르는 역량을 기른다

• 일반적인 개발자 교육에는 새 OCaml 기능뿐 아니라 사용이 늘어난 파이썬도 포함된다. 언어 수가 적으면 여러 코드베이스에 접근하기 쉽지만, 언어가 늘어나면 특정 언어에만 익숙한 전문화가 자연스럽게 생길 수 있다는 우려가 있다. [28:34]
• 지향점은 OCaml이나 파이썬만 다루는 개발자보다 여러 도구를 익히고 상황에 맞는 도구를 선택하는 소프트웨어 엔지니어다. 파이썬을 조금 아는 것과 능숙하게 사용하는 것 사이에는 실제로 배워야 할 내용이 있어, 오래 근무한 직원에게도 추가 교육이 필요하다. [29:12]

16. 교육 담당자를 현장 팀에 배치하는 조직 모델

• 디자이너를 여러 팀에 배치하듯 교육 담당자도 각 조직에 배치하는 방향을 예상한다. AI 지원 팀에도 교육 측면을 담당할 인력을 두고, 현장에 필요한 학습 자료를 제공하려 한다. [30:05]
• 분산 배치는 분야별 교육 수요에 대응하면서 교육 담당자의 기술 경험도 넓힐 수 있다. 모두 같은 부서에 있으면 경험하는 맥락이 비슷해져 교육의 기반이 빈약해질 수 있다. [30:43]

17. 개발 도구 팀의 역할과 Iron의 상반된 강점

• 도구·컴파일러 그룹의 편집기 팀은 VS Code, Emacs, Neovim과 코드 인덱싱 서비스, OCaml 언어 서버 등을 관리한다. Iron 확장 기능은 수작업으로 처리하던 변경 분할과 정리를 쉽게 하고, 변경들을 개별 리뷰가 가능한 연속된 관계로 구성한다. [31:18]
• Jane Street의 ‘기능’은 일반적인 개발 도구의 커밋이나 풀 리퀘스트에 가까운 단위다. Iron은 큰 변경을 작은 변경의 연속으로 나누는 스택형 풀 리퀘스트를 잘 지원하지만, 기존 차이 편집과 변경 이동 작업은 느리고 번거로웠다. [32:16]

18. 편집기를 개발 작업의 중심으로 삼는 이유

• 코드 리뷰와 버전 관리 등 주요 시스템과의 상호작용을 편집기 안에서 수행한다. 키보드로 작업을 이어갈 수 있어 여러 애플리케이션이나 페이지를 오갈 필요가 줄어든다. [34:38]
• Git 대신 Iron을 사용하는 등 내부 시스템의 특성이 달라 전용 통합 작업이 필요하다. 편집기 팀은 명령줄·브라우저·편집기에 흩어질 작업을 한곳에서 수행하도록 연결한다. [35:09]

19. 리뷰 중 직접 수정하는 협업 문화

• 리뷰 피드백은 별도 웹 화면 대신 편집기 안에서 정해진 형식의 특수 주석으로 작성한다. 이 초기 설계 선택은 편집기의 중심적 역할을 강화했다. [36:08]
• 동료의 변경을 검토하다가 수정 요청을 남기는 대신 직접 고칠 수도 있다. 이런 협업은 개발 방식의 중요한 부분이지만, 자신의 풀 리퀘스트를 다른 사람이 수정하는 데 익숙하지 않은 사람에게는 혼란스러울 수 있다. [36:36]

20. 대규모 코드와 내부 통합이 드러내는 성능 한계

• VS Code의 비교 알고리즘은 매우 큰 OCaml 파일의 변경을 처리할 때 심각한 성능 문제를 보인다. 큰 비교 화면이 멈춘 뒤 닫으면 차이 목록 전체가 작동하지 않아 다른 파일도 확인하지 못하는 문제가 있다. [38:10]
• Iron의 코드 표시 방식을 통합하면 버퍼와 URI에 대한 VS Code의 가정과 충돌해 내장 검색이 비정상적으로 동작하기도 한다. OCaml 언어 서버와 Merlin에서는 타입 조회·정의 이동을 위한 자료구조와 인덱싱 성능도 과제다. [39:05]

21. Python 노트북의 다양성과 코드 공유 문제

• 트레이딩·연구 인력의 주요 Python 인터페이스는 노트북이다. 제품마다 제약이 있고, 기존 제품을 대체하려던 새 제품에도 필요한 기능이 빠져 여러 종류를 함께 관리하게 됐다. [41:35]
• 노트북에 작성한 코드를 공유하려면 저장소의 Python 라이브러리로 옮겨 여러 노트북에서 가져다 쓸 수 있어야 한다. 이를 위해 노트북과 일반 Python 파일을 함께 편집하기 쉬운 환경이 필요하다. [42:31]

22. 자체 개발과 오픈소스 표준화 사이의 선택

• 자체 개발은 통합 환경을 통제하고 내부 요구에 맞출 수 있다는 장점이 있다. 노트북에서는 자체 인터페이스를 활용한 좋은 프로토타입이 있으며, 더 나은 경험을 제공할 수 있다는 낙관적 전망이 드러난다. [43:37]
• 반대로 Emacs에서는 25년 동안 쌓인 특수 설정을 표준 오픈소스 방식으로 대체하려는 작업에 투자해 왔다. 자체 구현과 표준화 중 어느 쪽을 택할지는 작업에 따라 달라진다. [44:34]

23. OCaml 확장과 편집기 언어 사이의 동시성 문제

• 여러 편집기의 내부 확장을 주로 OCaml로 작성하지만, 편집기 고유 언어도 일부 필요하다. Emacs에서는 Elisp와 OCaml 기반 Ecaml의 경계, 특히 비동기 작업의 책임 구분이 명확하지 않다. [46:08]
• 양쪽이 서로를 기다리는 교착 상태를 줄이도록 경계를 재설계하는 것이 장기 목표다. Emacs의 동시성 제약도 영향을 주며, 비동기 작업에 도움이 될 것으로 보는 가비지 컬렉터 변경은 당시 업그레이드 대상 버전에 준비되지 않았다. [47:06]

24. AI가 바꾸는 코드 작성과 남아 있는 편집기의 역할

• AI의 등장 이후에도 편집기를 개발자의 주요 작업 공간으로 삼는 방향은 유지된다. 새로운 작업 방식도 기존 방식처럼 편집기에서 자연스럽게 수행하도록 지원하려 한다. [48:51]
• 코드 작성 방식은 크게 달라질 수 있지만, 차이 검토·리뷰·코드 읽기와 이해는 계속 필요하다. 프롬프트로 대부분의 코드를 작성하는 엔지니어도 타입과 정의를 확인하는 등 편집기의 여러 기능을 사용한다. [49:19]

25. 사용 데이터로 AI 시대의 투자 우선순위 판단

• 지금 만드는 편집기 기능이 앞으로도 유용할지 불확실해졌다. 편집기와 OCaml 언어 서버의 사용 데이터를 개선해 실제 작업 방식의 변화를 파악하려 한다. [50:00]
• AI가 코드를 작성하면 API를 직접 찾아볼 일이 줄어 정의 이동도 감소할 것이라는 가설과 달리, 측정 데이터에서는 사용량이 조금 늘어난 것으로 보였다. 더 많은 코드를 읽고 이해해야 하기 때문일 가능성이 드러난다. [50:42]

26. 생성 비용 하락이 없애지 못한 검증 부담

• 그럴듯한 풀 리퀘스트를 만드는 비용은 거의 없어졌지만, 검증 비용은 그대로이거나 더 커졌을 수 있다는 진단이다. LLM이 만든 코드는 매끄럽고 좋아 보여도 심각한 결함을 포함할 수 있다. [52:02]
• 코드 읽기와 이해가 일부 측면에서 더 어려워진 만큼 이해를 돕는 도구에 투자필요가 있다. LLM의 설명 능력과 함께 정의 이동, 추론된 타입, 테스트 결과처럼 코드에서 직접 얻는 정보도 중요하다. [52:45]

27. 생성 도중 참여하게 하는 학습 방식

• Claude의 학습 출력 방식은 생성 도중 멈춰 사용자가 구현할 부분을 남긴다. 이를 직접 사용한 경험에서는 빈 부분을 채우기 위해 앞선 코드를 읽고 이해하면서 작업의 즐거움과 효과, 결과에 대한 이해가 높아졌다. [53:27]
• 완성된 코드에 설명을 덧붙이는 것뿐 아니라, 생성 과정의 상호작용을 설계해 최종 이해도를 높이는 방향을 탐색하려 한다. 전부 생성한 뒤 마지막에 읽는 방식이 최선인지에는 의문이 남는다. [54:32]

28. 코드 리뷰의 어려움과 자동화 속 교육 기능

• 직접 코드를 작성할 때는 오류를 고치며 이해와 머릿속 모델을 점진적으로 발전시킨다. 다른 사람의 코드를 리뷰할 때는 완성된 결과만 보고 그 모델을 새로 구성해야 하므로 더 어렵다. [55:34]
• AI가 만든 코드도 같은 이해의 어려움을 일으킨다. 따라서 적어도 일부 작업에서는 AI와 상호작용하는 방식을 바꿀 필요가 있다는 문제의식으로 계속된다. [56:03]

29. 시각화와 미리 준비된 설명으로 리뷰 지원

• 변경 내용을 이해하도록 맞춤형 도표를 만들어 리뷰 중 표시하는 방식이 가능해졌다. 모델의 설명 능력을 활용해 편집기 안에서 데이터와 코드 변경을 시각적으로 이해하도록 도울 수 있다는 구상이다. [56:54]
• 코드를 논리적 단위로 미리 나누고 각 부분의 설명을 준비해 두면 버튼 한 번으로 확인할 수 있다. 리뷰 중 매번 영역을 선택하고 모델 응답을 기다리는 부담을 줄일 수 있을 것으로 기대한다. [57:22]

30. AI 시대의 교육 과제로 이어지는 테스트 워크숍

• AI가 개발자의 코드 이해에 미치는 영향은 사람을 가르치는 방식의 문제와도 연결된다. 교육 프로그램 운영에서도 이 변화는 긴장을 일으키는 까다로운 과제다. [58:49]
• 경력 초기 엔지니어를 위한 워크숍은 소프트웨어 테스트 기법에 초점을 맞춘다. 속성 기반 테스트와 테스트 중 시간을 결정론적으로 제어하는 라이브러리 사용법을 다루며, 낯선 라이브러리를 어떻게 가르칠지가 구체적인 교육 과제로 등장한다. [59:21]

31. 직접 구현한 경험이 코드 평가의 기초가 된다

• 반복적인 기본 구조 작성은 모델에 맡길 수 있지만, 학습자가 문제를 고민하고 적어도 한 번 직접 구현하는 경험은 충분한 이해를 얻는 데 중요하다. 이후 다른 구현을 읽고 평가하더라도 이 경험이 판단의 토대가 된다. [1:00:17]
• 과거에 가르치던 작업 중 일부는 더 이상 직접 익힐 필요가 없을 수 있다. 다만 AI를 업무에 통합하는 방법과 유용한 결과·오해를 유발하는 결과를 구별하는 교육에는 아직 확정된 답이 없으며, 도구도 빠르게 변하고 있다. [1:01:06]

32. 손쉬운 정답 제공이 학습에 필요한 노력을 없앨 수 있다

• 생각 없이 도구로 결과물을 생성하는 것은 실제 문제이며, 내용을 이해하려는 노력은 여전히 학습의 핵심이다. 언제든 모든 문제를 대신 해결해 주는 도구가 있으면 이 과정이 사라질 수 있다. [1:01:58]
• 교육 효과를 위해 일부 자원을 제한해야 할 때도 있지만, 새로운 환경에서 무엇을 제공하고 무엇을 제한해야 하는지는 불분명하다. 이런 불확실성 속에서 한 세대가 교육받게 된다는 우려가 있다. [1:02:51]

33. AI 사용 여부보다 과제의 크기와 활동 간 연결이 중요하다

• 새 교육과정에서는 의미 있는 작업을 요구하다가 과제가 수업 시간에 비해 너무 커지는 문제가 반복됐다. 생성된 코드를 목적에 맞게 다듬는 데도 상당한 시간이 필요해 적절한 과제 규모를 찾는 추가 실험이 필요하다. [1:03:20]
• 일부 활동은 AI 도움 없이, 다른 활동은 AI와 함께 수행하는 교육 구조가 예상된다. 각 활동의 목표와 두 방식의 연결 방법은 앞으로 실험하며 찾아가야 한다. [1:04:15]

34. AI 튜터는 답을 대신 쓰기보다 사고를 도와야 한다

• 신입 교육에서 AI가 모든 코드를 작성하면 학습 효과가 사라지지만, 수료 후 일상적으로 사용할 도구를 교육에서 제외하는 것도 목표에 맞지 않는다. 이해를 확인하는 질문을 하거나 기본 구조만 제공하고 상당 부분을 학습자에게 맡기는 방식이 후보가 된다. [1:05:15]
• 막힌 부분에 힌트를 주되 코드를 대신 작성하지 않는 튜터는 학습자가 스스로 깊이 생각할 여지를 남긴다. [1:06:21]

35. 신입 부트캠프는 구현부터 운영까지 단계적으로 연결한다

• OCaml 부트캠프에서는 누적형 연습으로 작은 클라이언트·서버 애플리케이션을 만들고, 핵심 라이브러리를 익히며, 멘토의 코드 리뷰를 통해 제인 스트리트의 개발 방식을 접한다. 이어지는 운영 부트캠프에서는 배포·모니터링·설정을 배우며, 두 과정은 대략 입사 초기 2주에 해당한다. [1:07:42]
• OCaml 부트캠프의 초기 버전은 약 20년 전까지 거슬러 올라간다. 지속적인 개선으로 약 일주일에 해당 과정을 마치고 운영 교육으로 넘어갈 수 있게 됐으며, 최근 몇 년간 초기 부트캠프에는 매우 긍정적인 평가가 들어왔다. [1:08:27]

36. 도구의 필요성을 실제 문제 속에서 먼저 드러낸다

• 새로운 개념은 구체적인 애플리케이션이나 추가하려는 기능을 통해 도입한다. 도구부터 제시하고 사용처를 찾기보다, 현재 해결하려는 문제와 기존 방법의 한계를 먼저 이해하게 한다. [1:09:22]
• 필요한 순간에 도구를 소개하면 학습 흐름이 자연스러워지고, 도구에 대한 이해를 기본 원리와 연결하기 쉬워진다. 이 원칙이 입문 자료 개편의 큰 부분을 차지했다. [1:09:48]

37. 첫해 교육은 직무에 맞춰 선택하고 필요할 때 다시 학습한다

• 입사 첫해에는 테스트, 고성능 OCaml과 성능 분석, 시스템 디버깅, 고급 함수형 프로그래밍 등을 배운다. 웹 UI 라이브러리 Bonsai와 시장 데이터 시스템처럼 직무에 따라 필요성이 다른 전문 과정도 있다. [1:10:08]
• 신입 직원은 관리자나 팀원과 필요한 과정을 골라 첫해 학습 계획을 세운다. 교육 자료는 이후 실제 적용이 필요할 때 혼자서도 공부할 수 있도록 설계한다. [1:11:07]

38. 기업 교육은 개념을 실무 도구와 업무 경험에 연결한다

• 초기 교육 구상은 특정 기술을 통해 넓은 개념을 익히게 하는 것이었다. Bonsai에서는 증분 계산을, 시장 데이터에서는 복잡한 스트리밍 데이터 처리와 효율적인 프로토콜 설계를 배울 수 있지만, 이 구상은 기대만큼 성공하지 못해 실무 도구 중심으로 이동했다. [1:11:43]
• 대학 교육은 문제 해결, 모호함에 대처하기, 여러 해법 시도하기 같은 일반 역량도 길러야 한다. 반면 제인 스트리트에서는 이미 이런 역량을 갖춘 동료들이 일상 업무에서 복잡한 문제를 풀기 때문에, 교육에서는 바로 사용할 도구를 익히는 편이 더 적합할 수 있다. [1:13:02]

39. 학습 목표는 관찰 가능한 수행 능력으로 작성한다

• 테스트 교육을 만들 때 여러 사람의 노력이 분산되고 전체를 통합하기 어려웠다. 무엇을 달성하려는지 학습 목표로 명확히 하는 접근이 교육 설계를 정리하는 데 도움이 됐다. [1:16:15]
• 학습 목표는 “수업을 마친 학생은 무엇을 할 수 있는가”라는 형태의 동작 표현으로 작성한다. “속성 기반 테스트를 이해한다”는 모호하지만, 중첩된 레코드 입력을 대상으로 속성 기반 테스트를 작성한다는 목표는 수행 여부를 확인할 수 있다. [1:17:27]

40. 목표에서 연습과 자료를 도출하고 교육 자체를 평가한다

• 교육이 끝난 뒤 할 수 있어야 하는 일을 먼저 정하면, 수업에서는 그 일을 연습하게 하면 된다. 필요한 배경지식과 강의 자료를 정하고, 목표와 관계없는 코드는 미리 제공할 수 있다. [1:18:50]
• 평가의 주된 관심은 학생의 등급보다 교육 프로그램의 효과다. 학습자가 목표한 일을 실제로 할 수 있게 됐는지를 통해 교육이 유용한 것을 가르쳤는지 판단한다. [1:19:55]

41. 교육의 목적은 지식 전달을 넘어 학습자를 변화시키는 데 있다

• 학습 목표는 수업 구조를 정리하는 도구이면서, 교육을 통해 학생이 어떻게 달라져야 하는지를 묻는 틀이다. 교육 담당자 채용에서도 자신이 가르친 수업의 목적을 얼마나 구체적으로 생각했는지 살피는 데 유용하다. [1:20:25]
• 좋은 수업에는 교사의 열정, 아이디어, 전달력, 결과에 대한 관심도 중요하다. 목표를 명시하는 구조는 특히 처음 가르치는 사람이 작업과 생각을 정리하는 데 도움이 된다. [1:21:07]

42. 인지 부하를 줄이기 위해 낯선 도구를 순서대로 도입한다

• 동시에 받아들일 수 있는 새로운 요소에는 한계가 있다. 예전 OCaml 부트캠프에서는 언어, 낯선 편집기, 버전 관리와 코드 리뷰 시스템을 처음부터 함께 익혀야 했다. [1:22:58]
• 개편 후에는 Utop이나 브라우저에서 작은 코드를 실행하며 문법을 먼저 배우고, 이후 편집기와 버전 관리 활동을 도입한다. 각각의 준비 단계를 마친 뒤 도구들을 함께 사용하도록 순서를 나눴다. [1:23:39]

43. 상호작용하는 활동으로 학습 참여를 높인다

• 능동적 학습은 정보를 일방적으로 전달하는 대신 학습 활동을 최대한 상호작용하게 만드는 접근이다. 새로운 여름 인턴 교육에는 소규모 토론, 설계 활동, 이해관계자와의 의사소통 연습이 포함된다. [1:24:14]
• 학습자끼리의 상호작용은 교육의 중요한 구성 요소다. 학습과 기억에는 정보 전달뿐 아니라 심리적인 측면도 작용한다. [1:24:54]

44. AI 시대의 인턴 과제는 설계와 요구사항까지 포함한다

• AI 도구의 성능 향상으로, 4주짜리 프로젝트에서 하나의 정해진 과제를 수행하게 하는 기존 방식은 인턴 평가와 생산적인 업무 수행에 충분하지 않게 됐다. 프로젝트를 더 개방적으로 바꾸고 설계와 요구사항 수집을 포함할 계획이다. [1:25:27]
• 일정량의 좋은 코드를 작성하는 능력은 이전보다 평가 지표로서 중요성이 낮아졌다. 인턴이 새로운 과제에 대응하도록 회사의 문제 접근법, AI 사용 시 주의점, 효과적인 작업 방식과 사내 도구를 함께 가르쳐야 한다. [1:26:11]

45. 테스트·설계 검토·코드 리뷰를 인턴 교육에 강화한다

• 새 교육과정에는 데이터베이스 기반 애플리케이션에 대한 좋은 테스트 모음 작성이 포함된다. 단순한 문제를 넘어가면 모델의 첫 답이 충분하지 않으므로, 테스트는 모델에 결과의 정확성을 알려 주는 피드백 수단으로도 중요해진다. [1:27:34]
• 교육 투자를 늘리면서도 인턴이 대부분의 시간을 프로젝트에 쓰도록 균형을 잡아야 한다. 새 활동에는 좋은 설계 문서와 나쁜 설계 문서의 비교, 정규 직원이 이해관계자 역할을 맡고 인턴이 요구사항을 수집하는 연습이 포함된다. [1:28:10]

46. 코드 책임을 익히기 위한 과제 범위와 동료 학습

• 교육생들은 함께 살펴본 내용과 동의하지 않는 부분을 토론한 뒤, 각자 기능을 구현하고 서로의 코드를 리뷰하며 경험을 쌓는다. 이후에는 멘토와 실제 프로젝트에서도 리뷰할 기능을 전달받기를 기대한다 [1:30:04]
• AI가 생성한 코드를 그대로 받아들이는 것으로는 충분하지 않다. 교육생이 다듬을 수 있는 양보다 많은 코드를 요구하면 코드에 대한 책임을 가르치려는 목표와 충돌한다. 리뷰 과제도 기능이 지나치게 크고 문제가 많으면 핵심 문제를 찾기 어려워지며, 이는 인지 부하와 연결된다 [1:31:00]

47. 진도 경쟁과 빠른 코딩에서 충분한 학습과 테스트 품질로 전환

• 다음 운영에서는 과제 범위를 줄이고 강조점과 진행 속도를 조정필요가 있다. 빠른 교육생에게는 유익한 추가 활동을 제공하고, 느린 교육생에게는 핵심 학습에 집중하도록 해야 한다. 일정과 기대 수준도 정해진 진도를 따라잡기 위해 서두르기보다 중요한 내용을 충분히 학습하도록 설계해야 한다 [1:32:59]
• 여름 동안 교육과정은 기수마다 빠르게 수정됐다. 첫 기수에서는 멀티태스킹과 빠른 코딩을 지나치게 강조했으며, 이를 적절한 출발점이 아니었다고 판단했다. 앞으로는 모델이 세 가지 작업을 동시에 수행하는 능력보다 테스트와 고품질 테스트 모음 구축을 먼저 강조할 계획이다 [1:33:52]

48. 작업 지침을 발전시키되 AI 활용의 불확실성 유지

• 모델과 협업하는 여러 방식을 시도하고 작업을 주기적으로 검토필요가 있다. 다음 여름에는 경험과 아이디어가 더 성숙해질 수 있으며, 따라야 할 구체적인 작업 절차 등 지침을 추가할 가능성이 높다고 본다 [1:34:40]
• 현재는 시스템이 실패하는 방식과 주의할 점에 관한 정보는 있지만, 가장 효과적인 활용법에 관한 지침은 충분하지 않다. 소그룹 토론은 참여자들이 시도한 기법과 성공·실패 경험을 공유하는 수단이 된다 [1:35:22]

🧾 결론

• 교육의 성과는 전달한 정보량보다 학습자가 수업 이후 실제로 수행할 수 있는 일과 변화로 판단해야 한다.
• AI 사용 여부는 활동의 학습 목표에 맞춰 정해야 한다. 직접 구현하는 활동과 AI를 활용하는 활동을 연결하는 설계가 핵심 과제로 남는다.
• 과제는 학습자가 이해하고 다듬으며 책임질 수 있는 크기여야 한다. 생성 가능한 코드량이 교육생이 검토할 수 있는 양을 넘으면 교육 목표와 충돌한다.
• 기업 교육은 실제 문제와 도구를 연결하고, 이후 업무에서 다시 학습할 수 있는 자료와 지속적인 교육 체계를 갖출 필요가 있다.

📈 투자·시사 포인트

• 개발 도구 투자에서는 생성 속도와 함께 이해·검증에 드는 시간을 살펴볼 필요가 있다. 코드 탐색, 테스트, 리뷰 지원은 인터뷰에서 중요성이 커지는 영역으로 제시된다.
• 기능 투자 우선순위는 사용 데이터로 점검해야 한다. AI 도입 후 정의 이동이 줄 것이라는 예상과 달리 사용량이 조금 늘어난 것으로 관찰돼, 직관만으로 수요 변화를 판단하기 어렵다.
• 기업의 AI 도입에는 지속적인 교육 투자가 수반된다. 실무와 교육을 함께 담당하는 인력, 현장 팀의 학습 지원, 동료 간 경험 공유가 조직 차원의 대응 수단으로 제시된다.
• AI 튜터와 리뷰 설명 도구에는 활용 가능성이 있지만, 투자 판단에는 피드백 정확성과 실제 학습·검증 효과를 확인하는 과정이 필요하다. 자료는 특정 기업의 수익성이나 시장 규모를 제시하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• LLM 피드백의 오탐 빈도와 학습 효과는 정량적으로 제시되지 않았다. 제한된 평가 범위에서 유망하다는 견해를 검증된 보편적 효과로 해석해서는 안 된다.
• 정의 이동 사용량의 소폭 증가와 검증 비용에 관한 설명은 내부 관찰과 진단이다. 측정 기간·대상·비교 조건이 없어 다른 조직에 그대로 적용하기 어렵다.
• 인턴 교육 개편에는 계획, 운영 경험, 향후 수정 방향이 함께 포함돼 있다. 소그룹 토론에 대한 긍정적 평가만으로 장기 역량 향상까지 확인된 것은 아니다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 교육 목표를 ‘수료 후 학습자가 수행할 행동’으로 다시 쓰고, 대상 프로그램의 범위와 복잡도를 명시한다.
• 목표마다 직접 구현·설명·테스트·리뷰 중 확인 가능한 과제를 연결하고, 목표와 무관한 기본 코드는 미리 제공한다.
• AI 없이 사고해야 하는 활동과 AI를 활용하는 활동을 구분하고, 두 활동이 같은 역량을 어떻게 강화하는지 점검한다.
• LLM 피드백을 테스트·린터·멘토 검토와 대조해 잘못된 지적 사례를 모으고, 학습자에게 한계를 안내한다.

❓ 열린 질문

• AI가 대신할 수 있는 작업 중에서도 판단 능력의 토대를 만들기 위해 반드시 한 번은 직접 구현해야 하는 것은 무엇인가?
• 힌트와 질문을 제공하는 AI 튜터가 정답을 대신 작성하지 않으면서 학습자를 충분히 도울 수 있는 경계는 어디인가?
• 제한된 교육 시간 안에서 구현, 테스트, 설계, 코드 리뷰의 비중을 어떻게 배분해야 하는가?