AI 시대에 컴공을 선택한 용사들에게 - [잡담]

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI를 잘 쓰는 능력이 커질수록 컴퓨터과학의 기초와 직접 구현 경험은 오히려 더 중요해지는가?==

• 프로그래머의 고점은 AI 도구 사용법이 아니라 기초 개념과 구조를 이해하는 데서 나온다.
• 학습 단계에서는 AI가 대신 작성한 코드를 소비하기보다 직접 코딩하고, 에러와 설계 문제를 몸으로 겪어야 한다.
• 회사가 AI 시대에 사람을 뽑는 이유는 AI가 낸 결과를 검증하고, 잘못된 결과에 최종적으로 책임질 사람이 필요하기 때문이다.
• 프롬프팅·컨텍스트·하네스·그래프 엔지니어링은 유용한 도구이지만, 기초를 대신하는 새로운 마법은 아니다.

발표자는 현업 프로그래머와 학생의 학습 단계를 분리한다. 이미 구조와 원리를 이해한 사람이 AI를 활용하는 것은 생산성을 높이는 방법이지만, 기초를 배우는 사람이 AI에 구현을 맡기면 실수·디버깅·설계·환경 설정에서 얻을 경험을 건너뛰게 된다. 따라서 학생은 불편하더라도 작은 프로그램부터 직접 만들고, AI가 사라져도 코드를 읽고 고칠 수 있는 수준을 먼저 확보해야 한다. 그 뒤 고학년이나 실무 단계에서는 AI를 적극적으로 활용해 포트폴리오와 실제 시스템을 빠르게 만들되, 결과를 이해하고 책임지는 역할은 사람이 계속 맡아야 한다.

---

1. AI 시대에 공부하는 프로그래머의 출발점

AI를 쓰는 방법보다 무엇을 이해한 채 쓰는지가 먼저라는 주장이다.

1.1. 학생의 불안과 AI 의존

1. AI로 개발하며 공부하는 학생의 고민

   1. 거의 모든 것을 AI에게 맡기는 감각: 한 컴공 학부생이 AI로 개발하면서 부딪히며 공부하고 있지만, 이렇게 공부하는 것이 맞는지 모르겠다고 질문한다.
   2. 도구가 학습을 대체하는 불안: 코드를 직접 이해하고 작성하기보다 AI에게 일을 넘기는 느낌이 커지면서, 자신이 실제로 무엇을 익히고 있는지 불안해한다.

2. 대학원과 AI 활용 능력에 대한 질문

   1. 대학원 진학: 발표자는 대학원을 무조건 권하지 않으며, 더 공부하거나 연구하고 싶은 주제가 있을 때 선택하라고 답한다.
   2. AI 활용 능력 평가: 기업이 AI를 잘 쓰는 사람을 찾는다고 해도, 면접관·실무진·대표가 실제로 AI 활용을 깊게 이해하고 평가하는지는 별개의 문제라고 본다.

1.2. 직접 코딩을 해야 하는 학습 단계

1. 학습 중에는 AI를 잠시 끄라는 권고

   1. 기초를 익히는 단계: 학부생이라면 우선 AI를 쓰지 않고 직접 개발해 보는 편이 낫다고 말한다.
   2. 작은 불편의 교육 효과: 세미콜론 하나를 빠뜨려 두세 시간을 헤매는 경험처럼, 작고 귀찮은 오류를 직접 해결해야 다음에 같은 실수를 예방할 감각이 생긴다.

2. 기초 개념과 AI 활용의 차이

   1. 자료 구조·알고리즘의 이해: 자료 구조와 알고리즘을 알고 AI를 쓰는 것과, 모른 채 AI가 만든 코드를 복사하는 것은 결과가 크게 다르다.
   2. 구조화된 패턴의 한계: AI는 이미 구조화되고 반복되는 영역에서는 강하지만, 시스템의 구조·기능 경계·설계 선택처럼 창의적인 판단이 필요한 부분에서는 약하다.

---

2. 코드를 읽는다는 것과 시스템을 설계한다는 것

AI가 코드를 써도 사람은 코드가 선택한 구조와 이유를 설명할 수 있어야 한다.

2.1. 코드 한 줄보다 로직과 아키텍처를 읽기

1. 발표자의 현재 검토 방식

   1. 코드 자체보다 구조를 본다: 현업에서 AI를 활용해 만든 워크플로우를 검토할 때 모든 코드를 한 줄씩 읽기보다 어떤 구조와 아키텍처를 만들었는지 먼저 본다.
   2. 기술 선택의 이유를 확인한다: 특정 기술을 썼다면 왜 그 기술을 선택했는지, 실제 시스템으로 어떻게 동작하는지를 확인한다.

2. 학생에게 요구하는 기준

   1. 처음에는 한 땀 한 땀 작성: 기초를 공부하는 학생은 처음부터 코드를 직접 짜며 구조와 개념을 익혀야 한다.
   2. AI가 쓴 로직을 설명: AI가 만든 코드를 줄마다 완벽히 기억하지 못하더라도, 어떤 로직과 구조를 사용했으며 왜 그런 선택을 했는지는 설명할 수 있어야 한다.

2.2. TypeScript와 시스템 순서의 사례

1. 언어 선택 질문

   1. TypeScript를 쓴 이유: 다른 언어로도 만들 수 있는데 왜 TypeScript를 선택했는지 설명할 수 있어야 한다.
   2. 문법 암기가 아닌 설계 판단: 핵심은 TypeScript라는 답을 외우는 것이 아니라, 프로젝트 조건과 구조에 비춰 선택의 이유를 말하는 것이다.

2. 아키텍처 순서의 질문

   1. 구현 순서: 시스템을 특정 순서로 설계했다면 왜 그 순서가 필요한지 설명해야 한다.
   2. 기능의 과잉과 부족: 어떤 기능을 넣고 뺄지, 무엇이 과하고 무엇이 필요한지, 성능상 이점과 분리 가능성을 어떻게 판단했는지까지 알아야 한다.

---

3. AI를 학습 보조로 쓰는 방법

AI를 완전히 금지하자는 말이 아니라, 학습자의 사고와 손을 대신하게 만들지 말자는 주장이다.

3.1. 가이드형 학습과 일부러 낮은 모델 쓰기

1. 바로 코드를 주지 않는 AI

   1. 단계별 질문: AI가 정답 코드를 즉시 써 주는 대신 단계별로 질문하고, 학습자가 직접 완성하도록 안내하는 가이드형 학습을 활용할 수 있다.
   2. 발표자의 유보: 발표자도 이 방식을 직접 많이 써 보지는 않았지만 학습에는 도움이 될 수 있다고 본다.

2. 구린 모델 모드라는 농담 섞인 제안

   1. 에러를 더 많이 만들기: 일부러 성능이 낮은 모델을 써서 오류가 더 많이 나게 하고, 그 결과를 디버깅하는 방식이다.
   2. 디버깅의 경험치: 발표자는 귀찮고 힘들어도 직접 디버깅하는 것만큼 실력을 빠르게 올리는 방법은 없다고 말한다.

3.2. AI가 사라져도 작업할 수 있는가

1. AI 의존성과 독립성

   1. AI 없이도 완성할 수 있어야 한다: AI가 갑자기 사라져도 지금 만든 시스템을 직접 작업할 수 있는 수준이어야 한다.
   2. 코드는 언어다: 프로그래밍 언어는 한국어·영어처럼 로직과 구조를 전달하는 언어이므로, AI가 쓴 코드를 읽고 이해하지 못한다면 프로그래머라고 부르기 어렵다고 말한다.

2. 학습 단계와 실무 단계의 구분

   1. 학습자의 직접 구현: 학생은 코드 한 줄을 왜 그렇게 썼는지 이해하고, 직접 구현하면서 머릿속에 구조를 남겨야 한다.
   2. 현업의 AI 활용: 충분히 이해한 뒤에는 AI를 써도 되며, 이때는 생성 속도보다 구조·아키텍처·검증 능력이 실력을 가른다.

---

4. 과제와 기초 개념을 건너뛰면 생기는 구멍

직접 구현의 목적은 타이핑 속도가 아니라, 설계·실패·검증의 연쇄를 경험하는 데 있다.

4.1. 교수의 과제와 직접 구현의 기준

1. AI를 쓰지 않고 해야 하는 과제

   1. 교수가 요구한 구현: 교수님이 명확한 구현 과제를 냈다면 학생은 직접 잡고 직접 구현해야 한다.
   2. 난이도의 구체화: “다음 주까지 게임을 만들어 오라”는 말만으로는 범위가 넓다. 구글 공룡 게임처럼 쉬운 게임도 있고, 같은 게임이라는 이름 아래 난이도 차이가 크므로 구현 기준을 구체화해야 한다.

2. 네트워크와 하위 계층의 예시

   1. 통신 구현: HTTP와 소켓 통신처럼 서로 다른 방식이 있고, 그 원리를 직접 구현해 보는 과제가 있을 수 있다.
   2. 더 낮은 계층의 필요: 평소에는 기계어를 볼 일이 없어 보여도 멀티스레드 버그처럼 깊은 문제가 생기면 어셈블리나 더 낮은 계층을 봐야 할 때가 있다.

4.2. 기초가 상위 문제를 받치는 방식

1. 추상화 아래를 이해해야 한다

   1. 왜 이렇게 동작하는가: 하위 계층과 원리를 모르면 상위 코드가 왜 그런 결과를 내는지 설명하기 어렵다.
   2. 깊이 내려가는 문제 해결: 어떤 문제는 더 깊은 개념까지 내려가야 해결되며, 하루아침에 AI에게 물어본다고 모두 해결되는 것은 아니다.

2. 초보자의 튜토리얼 단계

   1. 모르는 것을 모르는 상태: 학생은 무엇이 어려운지와 자신이 무엇을 모르는지조차 모르는 단계에 있을 수 있다.
   2. 난이도 판단도 경험이다: 게임의 튜토리얼처럼 처음에는 어려운 것과 쉬운 것을 구분하지 못하는 것이 정상이며, 직접 부딪히며 기준을 만들어야 한다.

---

5. 발표자의 전공 선택과 경험치

기초를 공부하는 과정은 처음부터 계획된 최적화라기보다, 작은 선택과 반복 경험으로 이어지는 경우가 많다.

5.1. 네트워크를 선택해 서버 프로그래머가 된 이야기

1. 그래픽스와 네트워크 사이의 선택

   1. 게임을 좋아했지만 그래픽스가 무서웠다: 게임을 좋아했기 때문에 그래픽스 수업을 들어야 했지만, 그래픽스가 2D라는 사실이 막연히 무섭게 느껴졌다.
   2. CMD 창이 익숙해서 네트워크로 갔다: 네트워크 수업은 CMD 창에서 작업한다는 이유가 익숙해서 선택했고, 그 선택을 따라가다 서버 프로그래머가 됐다.

2. 지나고 나서 보이는 기준

   1. 그래픽스는 생각만큼 무섭지 않았다: 시간이 지난 뒤에는 그래픽스도 결국 개념의 조합이며, 당시의 두려움이 실제 난이도와 같지는 않았다고 회고한다.
   2. 계속 공부해야 구분된다: 어떤 것이 쉽고 어려운지, 어떤 계층을 더 봐야 하는지는 기초 공부와 경험이 쌓여야 구분된다.

5.2. 버그와 반복 구현은 경험치다

1. 전설적인 프로그래머에게 들은 조언

   1. 많이 해 봐야 한다: 발표자가 잘하는 프로그래머들을 만나 물었을 때 돌아온 공통된 답은 많이 해 보고 많이 부딪혀 보라는 것이었다.
   2. 차이는 사례의 축적: 뛰어난 사람은 특별한 마법을 가진 것이 아니라, 더 많은 사례를 겪고 각 상황에서 어떻게 대응했는지를 축적한 사람에 가깝다.

2. AI가 빼앗을 수 있는 기회

   1. 버그를 겪을 기회: AI가 모든 오류를 대신 수정하면 학습자가 실제로 부딪히고 해결하는 기회를 잃는다.
   2. 불편하지만 빠른 성장: 직접 코딩은 느리고 귀찮지만, 발표자 경험상 실력을 가장 빠르게 올리는 방법이다.

---

6. 오목 과제로 배운 설계·검증·책임

발표자의 자료 구조 수업 경험은 직접 구현이 왜 강력한지 보여주는 중심 사례다.

6.1. 매주 이론 뒤에 이어진 코딩

1. 수업의 강도

   1. 주 2회 수업: 첫 수업은 이론을 배우고, 두 번째 수업은 바로 그 주제의 코딩을 했다.
   2. 중간고사 때 절반이 F: 수업이 매우 어려워 중간고사만 가도 절반이 F를 받을 정도였지만, 발표자는 그 강도가 실력을 급격히 올렸다고 회고한다.

2. 인터넷 없이 직접 해결

   1. 집에서 예습·테스트: 과제가 무엇인지 미리 알고 공부하고, 집에서 직접 작성하고 테스트한 뒤 과제 현장에 갔다.
   2. 현장에서는 로컬로 작성: 과제를 할 때 인터넷을 끊고 로컬 환경에서 메인 함수부터 직접 코드를 작성했다. 일주일 내내 코딩만 해야 할 정도로 부담이 컸다.

6.2. 작은 게임에서 드러나는 많은 판단

1. 오목 구현의 단계적 확장

   1. 초기 구현: 처음에는 작은 게임부터 시작해 오목판을 만들고, 흑돌·백돌을 조작하는 기능을 구현했다.
   2. 승패 검사: 다음 단계에서는 다섯 개의 돌이 놓였는지, 가로·세로·대각선 승리 조건을 어떻게 검사할지 구현했다.

2. 구조와 유지보수의 문제

   1. 메모리 관리: 게임 상태와 돌의 정보를 메모리에 어떻게 관리할지 결정해야 한다.
   2. 규칙과 확장성: 3-3 금지 같은 규칙을 넣을지, 넣는다면 코드 구조를 어떻게 바꿀지, 나중에 유지보수하기 쉽게 기능을 어떻게 분리할지 고민해야 한다.

3. 반복의 효과

   1. 기능이 몸에 남는다: 매주 비슷한 핵심 기능을 반복해서 작성하다 보니 나중에는 오목판과 판정 함수를 눈을 감고도 짤 수 있을 정도로 익숙해졌다.
   2. 과제의 연쇄성: 한 주의 구현을 제대로 못 하면 다음 주 과제에도 영향을 주므로, 실수하거나 막혀도 다음 주 전까지 어떻게든 해결해야 했다.

6.3. 복사한 코드는 이해를 보장하지 않는다

1. 자료 구조 수업의 실패 사례

   1. 남의 코드를 보고 이해했다고 착각: 다른 학생의 코드를 그대로 보고 “아, 이렇게 하는구나”라고 생각해도, 직접 작성하려고 하면 코드가 나오지 않는다.
   2. 막히는 순간이 다르다: 직접 고민하지 않았기 때문에 메모리를 어떻게 관리할지, 어느 상태에서 오류가 나는지, 구조를 어떻게 바꿀지 막히면 해결하지 못한다.

2. 이론과 테스트의 차이

   1. 성능 주장의 한계: 어떤 기술이 더 좋고 최적화될 것이라고 말로 설명할 수는 있지만, 직접 테스트하고 검증하면 예상과 다른 결과가 나올 수 있다.
   2. 직접 구현의 필수성: 이론을 알아야 하지만, 실제 결과를 확인하려면 직접 코드를 짜고 실행해 봐야 한다.

---

7. AI 시대에 사람을 뽑는 이유: 최종 책임

AI의 생산성보다 중요한 회사의 질문은 결과가 잘못됐을 때 누가 판단하고 책임질 것인가다.

7.1. AI 활용 능력을 평가하는 사람도 완전히 알지 못한다

1. 현실적인 평가의 불확실성

   1. 면접관과 실무진: 회사가 AI 활용 능력을 평가한다고 해도 면접관과 실무진이 AI를 깊게 이해하고 있다고 단정하기 어렵다.
   2. CEO도 마찬가지: 대표와 CEO 역시 AI 생산성이 좋아진다는 사실은 알아도, 실제로 어떻게 활용해야 하는지는 모를 수 있다고 말한다.

2. AI 활용 스킬의 위치

   1. 힘든 과정을 건너뛰는 치트키: AI 활용 스킬은 지금까지 사람이 힘들게 하던 과정을 건너뛰게 해 주는 치트키와 비슷하다.
   2. 치트키만 쓰는 게임의 위험: 치트키로 연습하다가 정작 치트키 없이 플레이해야 하는 순간이 오면 아무것도 못 할 수 있다.

7.2. AI가 잘못했을 때 책임질 사람

1. 최종 검증자의 부재

   1. 고민의 삭제: AI에게 메모리 관리, 승패 판정, 구조 선택을 모두 맡기면 그런 문제를 직접 고민할 기회를 잃는다.
   2. 책임의 공백: AI만 활용하고 기초를 모르면 AI가 잘못 짰을 때 최종적으로 검증할 사람이 없어지는 문제가 생긴다.

2. 채용 이유에 대한 농담 섞인 결론

   1. AI가 무슨 짓을 하면 책임져라: 발표자는 “AI 시대에 당신을 뽑는 이유는 AI가 무슨 짓을 저지르면 책임질 사람이 필요하기 때문”이라고 농담 섞어 말한다.
   2. 책임을 위한 기초: 책임지려면 AI의 결과가 왜 잘못됐는지, 어떤 구조가 문제인지 이해해야 하므로 결국 기초 공부가 필요하다.

---

8. AI 가격·고용·시장 변화에 대한 가정

AI가 항상 싸고 항상 접근 가능하다는 전제에만 의존하면 조직과 개인 모두 취약해질 수 있다.

8.1. 가격이 오르면 드러나는 의존성

1. AI 비용의 변화 시나리오

   1. 현재의 싼 가격: 지금은 AI를 비교적 싸게 쓸 수 있지만, 어느 순간 가격이 두세 배 오를 수 있다.
   2. 회사가 멈추는 위험: AI 사용을 전제로만 코드를 만들던 회사는 가격이 오르면 운영이 어려워질 수 있다.

2. 사람의 기본 역량

   1. 코드를 못 짜는 프로그래머: AI 없이는 코드를 작성하지 못하는 사람이 늘면 비용 변화에 조직이 취약해진다.
   2. 도구가 없어도 작업하는 사람: AI가 없어도 직접 작성할 수 있는 사람은 비용·정책·서비스 변화에 덜 흔들린다.

8.2. 코딩 테스트 부활이라는 과장된 가정

1. 사람이 다시 더 싸지는 경우

   1. 비용 역전: 사람을 고용하는 것이 AI를 사용하는 것보다 싸지는 상황이 오면 기업의 선택이 바뀔 수 있다.
   2. 코딩 테스트의 재등장: 그때 기초가 없는 사람은 다시 코딩 테스트와 직접 구현 앞에서 어려움을 겪을 수 있다는 가정이다.

2. 발표자의 거리 두기

   1. 가능성에 대한 농담: 실제로 이런 상황이 올지는 모르며, 오지 않기를 바란다는 태도도 함께 드러낸다.
   2. 핵심은 현재의 기초: 미래 예측보다 지금 AI가 없어도 기본적인 코드를 만들고 검증할 수 있는 역량을 갖추는 일이 중요하다.

---

9. AI 업계의 호들갑과 실제 변화

AI 도구의 이름이 바뀌는 것과 프로그래밍의 본질이 바뀌는 것은 구분해야 한다.

9.1. OpenAI와 Anthropic도 활용법을 완전히 알지는 못한다는 주장

1. 연구와 활용의 차이

   1. 모델 성능 개선: OpenAI와 Anthropic 같은 회사는 모델을 고도화하고 성능을 개선하는 일은 잘한다.
   2. 업무 활용의 불확실성: 그러나 그 모델을 어떤 업무 흐름으로 조합해 가장 잘 활용할지는 이 회사들도 완전히 알지 못한다고 발표자는 말한다.

2. 커뮤니티에서 나오는 사용법

   1. 현장 기능의 출처: Codex나 Claude 계열 도구에서 보이는 기능도 커뮤니티가 먼저 만들고 검증한 아이디어를 참고하는 경우가 많다고 본다.
   2. 모두가 배우는 단계: AI를 연구하는 사람과 실무에서 평가하는 사람 모두 새로운 활용법을 따라 배우는 단계라는 의미다.

9.2. 프롬프팅·컨텍스트·하네스·그래프 엔지니어링

1. 3~5년이라는 변화의 시간감

   1. 현재의 워크플로우가 지속될 기간: 발표자는 지금과 같은 AI 워크플로우를 익히고 활용하는 시기가 3~5년 정도 남았을 수 있다고 추측한다.
   2. 그 이후의 표준화: 시간이 지나면 지금은 특별해 보이는 활용 방식이 모두가 아는 표준 시스템이 될 수 있다.

2. 이름이 바뀐 오래된 프로세스

   1. 프롬프팅: 처음에는 사람이 프롬프트를 잘 써야 한다고 했지만, 이제는 AI가 프롬프트를 대신 만들기도 한다.
   2. 컨텍스트: 컨텍스트 엔지니어링도 중요한 표현이 됐지만, 핵심은 필요한 정보를 적절히 주는 오래된 문제와 맞닿아 있다.
   3. 하네스와 그래프: 하네스는 스크립트로 프로세스를 강제하는 방식이고, 그래프 엔지니어링은 사람이 예전부터 하던 업무 프로세스를 AI에 옮긴 것이라고 설명한다.

3. 호들갑과 본질의 구분

   1. 이름이 바뀐다고 본질이 바뀌지는 않는다: 새로운 용어가 등장해도 기초적인 시스템 설계·프로세스·검증의 문제는 남아 있다.
   2. 잡기술은 주변부다: 발표자는 프롬프트·하네스·그래프 같은 잡기술도 쓸모는 있지만, 기초를 제대로 하는 것이 메인이고 도구 활용은 사이드 이슈라고 정리한다.

---

10. 학년별 학습 전략과 환경 설정

학생의 학년과 목표에 따라 직접 구현과 AI 활용의 비중을 조절하라는 실천안이다.

10.1. 3학년 전까지와 4학년 이후

1. 저학년의 직접 코딩

   1. 3학년 전까지: 3학년 전까지는 AI를 쓰기보다 노가다에 가깝더라도 직접 코딩하고 구조를 만들어 보는 것을 권한다.
   2. 기초의 체화: 이 시기의 목표는 빠른 결과가 아니라, 코드와 구조가 머릿속에 남고 오류를 스스로 해결할 수 있게 되는 것이다.

2. 고학년의 적극적 활용

   1. 4학년과 포트폴리오: 4학년쯤에는 AI를 적극적으로 활용해 프로젝트와 포트폴리오를 만들 수 있다.
   2. 전제 조건: 단, AI에게 맡긴 결과를 이해하고 구조적 선택을 설명할 수 있다는 전제가 필요하다.

10.2. 개발 환경도 직접 설정하기

1. 환경 설정의 교육 효과

   1. 언어와 플랫폼의 차이: C 계열 언어, Java, Python 등 언어가 달라지면 개발 환경을 설정하는 방식도 달라진다.
   2. 안드로이드 환경의 난이도: 안드로이드와 모바일 개발 환경을 구성하는 일은 상당히 복잡하며, 이런 과정도 AI에게 전부 맡기지 말고 직접 해 보라고 말한다.

2. 왜 필요한지 확인하기

   1. 검색과 정보 탐색: 환경 설정에 필요한 정보가 무엇인지 직접 검색하고, 각 단계가 왜 필요한지 확인해야 한다.
   2. 구조 설계 능력: 환경 구성과 시스템 구조 설계를 직접 경험하면, 나중에 AI가 설정한 결과를 검증할 기준이 생긴다.

---

11. 대학원에 가야 하는가

대학원은 취업을 피하는 장소가 아니라, 분명한 연구 목적이 있을 때 선택하는 과정이라는 관점이다.

11.1. 진학의 기준

1. 공부하고 싶은 것이 있을 때

   1. 명확한 관심: 더 깊이 공부하거나 연구하고 싶은 분야가 있을 때 대학원에 가는 것이 맞다.
   2. 회피성 진학 금지: 취업이 힘들거나 결정을 미루고 싶어서 대학원에 가는 것은 좋은 선택이 아닐 수 있다.

2. 학벌과 목표의 구분

   1. 학벌 세탁도 목표일 수 있다: 학벌을 바꾸고 싶다는 목적 자체도 하나의 목표이므로, 목표가 분명하다면 그 목적을 숨길 필요는 없다.
   2. 목표가 없을 때의 기회비용: 아무 관심도 없이 대학원에 가는 것이라면 그 시간에 일을 하며 사회 경험을 쌓는 편이 낫다고 말한다.

11.2. 석사와 박사의 역할

1. 석사는 연구하는 방법을 배우는 과정

   1. 지식 전달보다 연구 방법: 석사는 수업에서 많은 지식을 일방적으로 배우는 과정이라기보다, 어떻게 연구하고 논문을 쓰는지 익히는 과정에 가깝다.
   2. 스스로 공부하는 단계: 교수는 주제와 방향성을 안내할 수 있지만, 세부적으로는 학생이 스스로 공부하고 연구해야 한다.

2. 박사는 자기 연구를 만드는 과정

   1. 자신만의 연구: 박사 과정은 자신만의 연구를 만들고 더 큰 연구로 발전시키는 단계다.
   2. 방향성의 뒷받침: 본인이 공부하고 연구하고 싶은 방향이 받쳐 줄 때 대학원 진학이 의미를 갖는다.

---

주요 발언 모음

“프로그래머의 고점은 결국 기초에서 나와요.”

“일부러 구린 AI 모델을 써 가지고 에러가 더 많이 나게 해서 디버깅을 더 많이 할 것 같아요.”

“AI가 없으면 아무것도 못 하게 된다 그러면 사실 좀 크죠.”

“직접 해 보면, 이거만큼 빠른 게 없어요. 느리고 힘든데 성장만큼은 빨라요.”

“AI 시대에 당신을 뽑는 이유는 AI가 무슨 짓을 저지르면 책임질 사람이 필요하기 때문이에요.”

“3학년 전까지는 그냥 노가다로 직접 코딩해 보세요. 4학년쯤에는 AI를 열심히 활용해 보세요.”

“대학원은 더 공부하고 싶은 게 있을 때 가세요. 회피성으로 가는 건 좋지 않은 것 같아요.”

핵심 데이터 & 수치

• 33분 45초: 전체 영상 길이이며, 학부생의 AI 학습법부터 기초·과제·취업·대학원까지 이어지는 잡담형 상담이다.
• 2~3시간: 세미콜론 하나를 빠뜨린 초보자가 에러를 해결하는 데 쓸 수 있는 시간의 예시다. 발표자는 이 불편한 경험이 학습으로 남는다고 본다.
• 주 2회: 이론 수업 1회와 즉시 코딩하는 수업 1회로 구성된 자료 구조 수업의 리듬이다.
• 중간고사 절반 F: 해당 수업의 높은 난이도를 보여주는 발표자의 회고다.
• 3학년 전 / 4학년: 저학년에는 직접 구현을, 4학년 이후에는 AI 활용과 포트폴리오를 더 적극적으로 하라는 권고의 기준이다.
• 3~5년: 현재의 AI 워크플로우가 특별한 기술처럼 유통되는 기간에 대한 발표자의 추측이다. 예측이며 검증된 전망은 아니다.
• 두세 배: AI 사용 가격이 오를 수 있다는 가정에서 제시한 예시다. 실제 가격 전망이 아니라 의존성 위험을 설명하기 위한 시나리오다.

결론 및 시사점

1. AI를 학습 중인 학생은 먼저 작은 프로그램을 직접 만들고, 에러·메모리·자료 구조·알고리즘·환경 설정을 스스로 겪어야 한다.
2. AI에게 코드를 요청하더라도 결과의 로직, 아키텍처, 기술 선택, 구현 순서를 자신의 말로 설명할 수 있어야 한다.
3. 가이드형 학습처럼 AI가 바로 답을 쓰지 않고 질문으로 이끌게 하는 방식은 보조 수단으로 활용할 수 있다.
4. AI가 만들어 준 코드를 복사하는 것과 직접 구현해 테스트하며 이해하는 것은 전혀 다르다.
5. 회사는 AI가 낸 결과를 그대로 소비하는 사람이 아니라, 결과를 검증하고 잘못된 결과에 책임질 사람을 필요로 한다.
6. AI의 프롬프트·컨텍스트·하네스·그래프 활용은 기초 위에서 생산성을 높이는 도구이지 기초의 대체물이 아니다.
7. 저학년에는 직접 코딩하고, 고학년에는 AI를 활용해 포트폴리오와 실제 시스템을 만들되 검증 능력을 유지해야 한다.
8. 대학원은 취업 회피가 아니라 명확한 공부·연구 목표가 있을 때 선택해야 한다.

핵심 요약 (40줄)

1. AI 시대에도 프로그래머의 고점은 도구 사용법보다 컴퓨터과학의 기초에서 나온다.
2. 컴공 학부생이 AI로 거의 모든 개발을 맡기며 공부하는 방식이 맞는지 고민할 수 있다.
3. 기초를 배우는 단계에서는 AI를 끄고 직접 개발해 보는 시간이 필요하다.
4. 세미콜론 하나를 빠뜨려 두세 시간 헤매는 작은 고생도 다음 실수를 줄이는 경험이 된다.
5. 자료 구조와 알고리즘을 알고 AI를 쓰는 것과 모르고 코드를 복사하는 것은 크게 다르다.
6. AI는 구조화된 반복 작업에는 강하지만 시스템 구조와 창의적인 설계에는 한계가 있다.
7. AI가 쓴 코드도 어떤 로직과 아키텍처를 만들었는지 설명할 수 있어야 한다.
8. TypeScript 같은 기술을 선택한 이유와 구현 순서를 말할 수 있어야 한다.
9. 기능의 과잉·부족, 성능 이점, 분리 가능성은 사람이 판단해야 하는 설계 문제다.
10. AI가 바로 코드를 주지 않고 질문으로 이끄는 가이드형 학습을 활용할 수 있다.
11. 일부러 낮은 성능의 모델을 써서 더 많은 오류를 디버깅하는 방법도 학습 방식이 될 수 있다.
12. 발표자는 직접 디버깅하는 경험만큼 빠르게 실력을 올리는 방법은 없다고 본다.
13. AI가 사라져도 코드를 읽고 시스템을 직접 완성할 수 있는 독립성이 필요하다.
14. 프로그래밍 언어는 로직과 구조를 전달하는 언어이므로 AI 코드를 전혀 이해하지 못하면 곤란하다.
15. 학생 과제는 단순히 결과물을 제출하는 일이 아니라 설계·실패·검증을 경험하는 과정이다.
16. 게임 과제는 범위가 넓으므로 구현 난이도와 기준을 구체적으로 정해야 한다.
17. 네트워크와 멀티스레드 같은 문제는 하위 계층의 개념이 없으면 해결하기 어려울 수 있다.
18. 발표자는 그래픽스가 무서워 CMD 작업이 익숙한 네트워크 수업을 택했고 서버 프로그래머가 됐다.
19. 무엇이 쉽고 어려운지 구분하는 능력도 기초 공부와 경험이 쌓여야 생긴다.
20. 잘하는 프로그래머와의 차이는 마법보다 더 많은 사례를 직접 겪은 경험의 축적에 가깝다.
21. AI가 오류를 모두 대신 해결하면 사람이 부딪히며 배우는 기회를 잃을 수 있다.
22. 자료 구조 수업은 주 2회 이론과 코딩을 이어 붙였고 중간고사에서 절반이 F일 만큼 강했다.
23. 인터넷을 끊고 로컬에서 매주 직접 코딩한 경험이 발표자의 실력을 크게 올렸다.
24. 오목 하나를 구현해도 메모리, 돌 배치, 승패 판정, 대각선과 수직 조건을 설계해야 한다.
25. 3-3 금지 같은 규칙을 넣을지와 유지보수 가능한 코드 구조를 정하는 일도 학습이다.
26. 남의 코드를 보고 이해했다고 느끼는 것과 직접 처음부터 작성할 수 있는 것은 다르다.
27. 성능과 최적화에 대한 말은 직접 테스트와 검증을 거치기 전까지 가설에 불과할 수 있다.
28. AI만 활용해 기초를 건너뛰면 AI가 잘못했을 때 최종 검증하고 책임질 사람이 사라진다.
29. 회사가 AI 시대에 사람을 뽑는 이유는 AI가 저지른 결과에 책임질 사람이 필요하기 때문이다.
30. AI 가격이 두세 배 오르면 AI에만 의존한 조직과 개발자의 취약성이 드러날 수 있다.
31. 사람이 다시 더 싸지는 상황에서는 코딩 테스트와 직접 구현 능력이 재평가될 가능성도 있다.
32. OpenAI와 Anthropic도 모델 성능 개선과 실제 업무 활용법을 모두 완전히 아는 것은 아니다.
33. 프롬프팅, 컨텍스트, 하네스, 그래프 엔지니어링은 새 이름을 얻은 오래된 프로세스의 측면도 있다.
34. AI 도구의 이름과 업계의 호들갑이 바뀌어도 기초·설계·검증의 본질은 크게 달라지지 않는다.
35. 현재의 AI 워크플로우가 표준화되기까지 3~5년이 남았다는 말은 발표자의 추측이다.
36. 3학년 전까지는 직접 코딩하고 4학년쯤부터 AI를 활용해 포트폴리오를 만드는 전략이 제안된다.
37. 언어·모바일 개발 환경 설정도 AI에게 맡기지 말고 필요한 이유를 찾아 직접 해 보는 편이 좋다.
38. 대학원은 취업 회피가 아니라 더 공부하고 연구하고 싶은 목표가 있을 때 가야 한다.
39. 석사는 연구 방법과 논문 작성법을 배우고 박사는 자신만의 연구를 만드는 과정에 가깝다.
40. AI 시대의 경쟁력은 AI를 많이 쓰는 사람이 아니라 AI의 결과를 이해하고 책임지는 사람에게 있다.