AI 때문에 컴공 교육이 흔들린다는 글에 나온 얘기들

우선 OpenProcessing에서 사이드 프로젝트를 하고 있다니 좋네. 동기가 생기고 계속 배우게 되는 프로젝트를 이어가길 바람. 우리도 학습 경로에서 길을 잃어본 적 있음. AI가 나오기 전에도 컴공 공부가 벅찬 순간은 있었고. 너무 걱정하지 마, 극복할 수 있을 거임.

컴공 학위가 배움의 끝이었던 적은 없음. 결국 자신이 얼마나 쏟아붓느냐의 문제였지. 연습한 것을 배우게 되고, 대학은 그런 연습을 하기 좋은 장소임. AI 도구를 최적화하든, CPU 캐시를 이해하든, GPU에서 픽셀을 다루든, 분산 컴퓨팅 원리를 공부하든 언젠가는 더 잘 생각하고 일하는 데 도움이 될 거임. 호기심을 잃지 마.

학생과 교사 양쪽에서 이런 얘기를 점점 더 자주 들음. 교육 현장 전체가 AI를 생산적으로 활용하는 방법을 아직 못 찾아서 답답해하는 것 같음. 나도 직장에서 AI로 어떻게 공부할지 고민 중임. 우리 직장은 AI를 전면적으로 도입한 상태거든.

AI 코딩 때문에 우리가 게을러지고, 예전처럼 한 줄씩 검토하기엔 코드가 너무 많이 나온다는 건 다들 인정함. 에이전트 팀으로 수백만 줄을 만들어서 검토할 엄두도 못 내는 사람들도 있음. 품질을 높이고 복잡성을 낮게 유지할 방법은 아직 모르니, 테스트를 많이 작성하게 하고 문제가 생겨도 고치기 쉽기를 바라는 상황임. 에이전트가 언젠가는 전체 아키텍처도 더 잘 다루겠지만 아직은 아님.

또 다른 아이러니는 과제량이 늘었다는 점임. 사람이 난도를 조절한 예전 과제는 LLM에 너무 쉬워서 교사들이 학생이 시간을 들이도록 난도를 높이는데, 그러다 보면 사람이 직접 풀기엔 너무 어려워짐. 과제 설계에서 작은 실수만 나도 필요한 시간과 노력이 크게 늘어날 수 있고.

끔찍하게 들리지만 문제의 원인은 이 학교 교직원이라고 봄. 예전에는 사람이 한 번은 제대로 생각해서 과제를 만들고 학과의 다른 사람들도 승인했는데, 이제는 한 번이라도 읽어보는지 의심스럽다는 내용이 나옴. 오류가 넘치고 마감 1~2주 전에야 수정되는 경우도 있다는데, 이건 받아들일 수 없음.

AI로 과제와 학습량을 만들면서 자기 일을 제대로 하지 않는 교수라면 징계하고, 개선하지 못하면 교체해야 함. 제목을 보고 AI가 컴공 학위의 가치를 떨어뜨리는 내용인 줄 알았는데, 실제로는 교직원들이 AI를 제대로 다루지 못해 교육과정이 무너지는 이야기였음.

나이 든 사람의 푸념처럼 들릴 수도 있지만, 컴공 학위가 뭘 위한 건지 물어볼 필요가 있음. 코딩을 가르쳐서 업계에 바로 취직할 수 있게 만드는 건가? 아니면 데이터와 코드를 생각하는 법을 가르치는 건가? 전자라면 AI가 문제일 가능성이 크고, 후자라면 중립적이거나 어느 정도 도움이 될 수도 있음.

나는 컴공 졸업생을 40년 동안 채용해 왔는데, 데이터 처리 시스템이 뭔지 이해하는 최근 졸업생의 비율이 확실히 줄어든 것 같음. 물론 모든 교육과정이나 젊은 개발자가 나쁘다는 얘기는 아님.

업계의 나이 든 사람들에게도 책임이 있음. 유행 분야에 돈이 몰리면 최근 도구를 알고 저렴하게 일할 젊은 사람들을 잔뜩 뽑아 놓고 제대로 성장시키지는 않음. 그러고는 대학에 가서 왜 졸업생들에게 그때그때 필요한 걸 안 가르쳤냐고 불평하지.

AI가 학위를 망치는 것처럼 보일 수는 있음. 하지만 대학에서 업계로 이어지는 과정에 원래 있던 문제들을 더 이상 무시하기 어렵게 만든 건지도 모름.

맞는 말이기도 하고 아니기도 함. 학위가 특정 도구를 익히는 데만 목적이 있었던 건 아니라는 데 동의함. 물론 회사에서 쓰는 도구를 똑같이 가르치는 더 ‘실용적인’ 교육을 주장하는 사람도 많이 봤지만.

그렇다고 기초만 배우는 것도 아님. 제대로 된 엔지니어링 관행처럼 현장에서 쓰려면 애써야 하고 경력 후반에야 중요해질 수도 있는 부분을 깊이 배울 수 있음. 그런 배움과 달리 얻기 어려운 폭넓은 지식이 컴공 졸업생에게 이점을 준다고 생각함. 물론 사람마다 다르고 그 이점은 금방 따라잡힐 수도 있지만.

댓글 중에 글을 읽지 않은 사람이 누군지 쉽게 보임. 이 이야기의 진짜 문제는 교직원임. 정신 차리고 수업에 필요한 자료와 과제에 생성형 AI를 무분별하게 쓰는 걸 멈춰야 함. 자기 일을 하라는 얘기임.

AI 관련 지침이 3개월마다 바뀐다는 부분에서도, 학생의 배움보다 상사에게 AI 대응을 보여주는 일이 우선인 관료적이고 행정 위주의 구조가 느껴짐.

‘AI로 배우는 가장 좋은 방법은 직접 작업한 뒤 같은 작업에서 AI가 자신보다 훨씬 잘하는 걸 보고 요령을 배워 다시 해보는 것’이라는 주장에 근거가 있나? 지금 해커뉴스 첫 페이지에는 그와 모순되는 내용도 올라와 있음.

나는 클로드에게 내가 더 깊이 이해하고 싶은 기술을 가르치도록 했음. 구체적으로는 코시넬 시맨틱 패치를 배우고 싶어서 적용할 만한 곳을 찾아주되 답은 알려주지 말라고 했음. 대신 내가 직접 패치를 만들 수 있게 차근차근 안내해 줌.

웨슬리 크러셔가 아이가 없는 행성으로 납치됐다고 해보자. 그들은 몸은 쇠약해지고 있었지만 기술은 연방보다 뛰어나서 남의 아이들을 데려와야 했음. 웨슬리에게 레이저 조각칼을 주고 머릿속에 그린 대로 나무를 조각하라고 가르침.

웨슬리가 ‘이건 예술이 아니잖아요! 내가 조각하는 것도 아닌데요!’라고 불평하자, 납치한 스승은 말했음. ‘아니다, 웨슬리. 예술은 네 머릿속에 있고 도구는 그저 일을 할 뿐이란다.’

웨슬리는 모든 즐거움이 사라진 데 화가 나서 완벽한 나무 돌고래를 벽에 던졌음. 그래도 그 행성에서 평생 완벽한 레이저 조각 돌고래를 만들며 살았음. 그게 일이었고 상사는 어쩔 수 없다고 했으니까. 한동안은 선택하고 통제하는 기분을 느끼려고 밤마다 아이스크림 막대로 작품을 만들었지만, 결국 포기하고 늙을 때까지 마리오 카트만 했다고 한다.

서로 다른 언어, 프레임워크, 라이브러리와 AI 에이전트로 같은 기능을 여러 버전 구현해 보는 방법이 있음. 그러면 코드만 보고 테스트 시나리오를 상상하는 것보다 결과를 비교하는 차등 테스트가 쉬워짐. 퍼징이나 실제 운영 데이터를 이용한 섀도 실행으로 차이를 일찍 발견할 수도 있고.

서로 다른 구현체 두 개의 결과가 달라지면 에이전트가 한쪽의 버그인지 명세가 불분명한 건지 판단하게 하는 거임. 버그를 고치거나 명세를 명확히 하면 어느 쪽이든 이득임.

의도와 구현이 어긋나는 문제는 별개인데, 나는 프로젝트 기간 동안 사용자가 남긴 메시지를 전부 기록하는 방식을 생각함. 중간 요약이나 이미 어긋난 코드가 아니라 원래 사람의 메시지에서 출발해 각 에이전트가 독립적으로 의도를 파악하게 하는 거지.

좋은 생각이긴 한데, 내가 일하는 곳은 코드베이스가 크고 저수준이라 다른 언어나 스택을 쓰기가 쉽지 않음. 우리가 소프트웨어, 하드웨어, 컴파일러, 드라이버까지 스택 자체를 만들거든.

그래도 여러 에이전트를 쓰거나 서로 반박하게 하는 리뷰는 가끔 함. 에이전트는 사람이 놓친 예외 상황 테스트를 더 꼼꼼히 찾아내는 편임. 대신 설계상의 가정과 조건을 충분히 이해하지 못해 실제로는 일어날 수 없는 일을 지나치게 복잡한 환경에서 테스트하거나, 반대로 흔한 기본 사용 사례는 충분히 테스트하지 않는 게 흔한 문제임. 실제 사용 흐름을 잘 모르니까.

사실 LLM이 나오기 전에도 사람들에게 똑같이 불평했음. 우리도 논리적 커버리지를 챙기려고 너무 영리하게 굴다가 지루하고 쉬운 부분을 무시하곤 하니까. 사용자보다 엔지니어처럼 생각하는 거지.

기존 지식을 배우는 데 필요한 노력 없이 그 지식에 기반해 일반적인 문제를 풀어주는 도구가 있다는 건 교육 자체와 정반대 아닌가? 유용한 도구가 아니라는 말은 아님. 하지만 AI에게 버블 정렬을 짜달라고 한다고 버블 정렬을 배우는 건 아니잖아. 목적은 코드를 만드는 게 아니라 어떻게, 왜 그렇게 하는지 배우는 거였음.

나는 일자리는 더 위험해졌지만 배움의 기회는 역대 최고라고 생각함. 아주 능숙한 개인 교사를 24시간 이용할 수 있으니까. AI에게 가르쳐 달라고 요청하는 노력을 들이면 실제로 가르쳐줄 수 있음.

어떤 때는 간단한 배시 스크립트만 필요하고 배시를 배울 생각은 없으니 구현을 크게 신경 쓰지 않고 실행함. 하지만 업무용 자바 코드 작성을 도와달라고 할 때는 결과를 검토하고 이해가 안 되는 부분을 물어봄. 그러면 예전의 건조하거나 부실한 문서를 읽는 것보다 훨씬 잘 가르쳐줌. 결국 어떻게 쓰느냐에 달렸음.

일자리나 돈 때문에만 컴공을 한다면 처음부터 잘못 생각한 거임. 나는 이 일을 45년 했는데, 해마다 새로운 기술이 모든 걸 바꿔놓을 거라는 무서운 이야기가 있었음. 변화를 받아들이고 적응하는 재미를 찾아야 함. 컴퓨터과학은 가만히 있어도 되는 분야가 아님. 돈만 보고 하는 거라면 다른 일을 하는 게 나음.

‘AI를 못 쓰게 되면 어떻게 할 건지, 얼마나 기억에 남았는지 궁금하다’는 질문에 대해선, 현실적으로 AI가 작동하지 않는 상황은 그리 큰 문제가 아닐 것 같음. 네트워크가 끊겼을 때처럼 그냥 일을 멈추겠지.

진짜 위험은 직원으로서의 가치임. AI 덕분에 아이언맨처럼 느끼고 일할 수 있을지 몰라도, 힘든 일을 슈트가 다 하고 더 저렴한 사람도 그걸 입으면 꽤 잘할 수 있다면 높은 급여를 어떻게 유지할 거임? 우리 중 누구도 자리가 보장된 건 아니잖아.

나도 에이전트가 선생님처럼 힌트만 주고 직접 타이핑하게 하는 방식을 더 진지하게 해보려 했음. 그런데 직장에서 시간을 내기도 어렵고 자제력도 필요함. 몇 번 어설프게 시도했다가 반복적이고 이해하기 쉬운 부분은 에이전트에 맡기게 되고, 그러다 보면 어느새 어려운 부분도 맡기고 있더라.

또 해보고 싶은 건 각자 자리에서 에이전트와 대화하는 대신, 여러 사람이 함께 설계를 논의하고 에이전트가 듣고 질문하면서 실시간으로 코드를 작성하는 방식임. 그런 회의를 몇 번 해봤는데 혼자 바이브 코딩할 때보다 훨씬 좋았음. 다 같이 설계를 진행하면서 검토하니 혼자였으면 잘못 들어섰을 길도 피할 수 있었고, 코딩과 리뷰를 한 번에 하면서 참석자 모두가 설계를 납득할 수 있었음.

나는 직장에서 AI를 많이 씀. 바이브 코딩을 하는 건 아니고, 무엇을 시킬지 아주 의도적으로 정함. 질문하면서 정말 많은 걸 배울 수 있다는 생각에 신나다가도, 배우는 것 중 상당수가 이제 내게 별로 필요하지 않은 특정 기술 지식이라는 걸 깨닫곤 함.

그렇지만 시스템을 만드는 데 중요한 건 원래 코딩 자체가 아니었음. 잘 작동하고 변경하기 쉬운 구조로 시스템을 구성하는 지혜가 중요하지. AI는 아직 이 부분을 정말 못함. 반면 반복문이나 조건문은 아주 잘 짜는데, 사실 그건 쉬운 부분임.

우리 대학은 원래부터 과제 설계가 완벽하진 않았음. 첫날부터 아무것도 안 가르쳐 놓고 어셈블리 과제를 시켰거든. 실습 안내서에는 ‘1학년 프로그래밍 수업에서 배운 게 도움이 될 겁니다’라고 적혀 있었음. 알고 보니 원래 2학년 과목이었는데 별 이유도 없이 내용은 그대로 둔 채 1학년 첫 학기로 옮긴 거였음.

다른 대학이나 과목에서도 비슷한 경험을 했음. 네덜란드에서 겪은 일이라 다른 나라는 다를지 모르겠지만, 내 경험으로는 가르치기보다는 이미 아는 사람을 걸러내는 제도에 가까웠음. 절반 넘게 1학년에 탈락하고 5년 동안 다시 등록하지 못하는데도 그게 정상이고 받아들일 만한 일로 여겨졌음.

대학을 고르는 친구에게 ‘실제로 뭔가 가르쳐줄 거라고 기대하지는 마’라고 말했는데, 교육기관에 대해 할 말로는 참 씁쓸하지. 그래도 나는 대학이라는 개념을 좋아하고, 프로젝트를 비롯해 즐거웠던 경험도 많았음. 다른 대학 강의를 유튜브로 보면서 실제로 배우는 즐거움을 느끼기도 했고.

대학 학위에 대한 여러 기대와 별개로, 결국 학위는 취업의 첫 문을 열고 직장 생활을 할 기초를 마련하는 역할이라고 봄. 빠르게 변하는 컴공 분야에서는 학교에서 배운 기술이 현장에 갈 때쯤 달라져 있거나 이미 낡아 있는 일이 예전부터 있었음.

배운 내용을 깊이 파고들지, 학점을 얻는 데 필요한 만큼만 할지는 지금도 예전에도 개인에게 달렸다고 생각함. 과거에는 AI로 답을 바로 얻을 수 없었으니 우연히라도 깊이 배우게 될 가능성이 좀 더 컸겠지만, 도구를 어떻게 쓰느냐에 따라 지금도 깊이 배울 수는 있음.

지금 컴공 학생들에게 해주고 싶은 조언임.

1. 자퇴하지 말고 학위는 받아라. 취업이나 연구, 종신직 등에선 여전히 학력이 중요한 신호로 작용함.
2. AI에 노동을 맡기되 생각까지 맡기진 마라. AI의 능력은 분야별로 들쭉날쭉하고 결과도 확률적이니 명확한 제약을 둬야 함. 숲 전체의 지도는 머릿속에 두고, AI가 잘하는 범위에서 나무를 만드는 데 도움을 받는 식으로.
3. 요구사항을 명세로 옮기고 검증하는 것까지 포함해 소프트웨어 전체를 다루는 역량을 길러라. 전체 시스템을 보는 엔지니어가 되는 거임.
4. 마케팅, 영업, 회계, 법률 같은 사업 지식도 AI를 활용해 배워두면 1인 사업을 하는 데 도움이 됨.
5. 여러 분야를 넘나드는 지식과 깊이를 함께 쌓아라.
6. 학교 교육이 배움 자체를 방해하게 두지 마라. AI에게 질문을 주고받으며 배우되 적절한 제약을 걸어라.
7. 무엇이든 스스로 노력해서 배우는 일을 멈추지 마라.

좀 냉정한 의견인데, 생활비만 벌고 싶어서 하는 거라면 이 분야는 맞지 않음. 소프트웨어 엔지니어링은 단순한 일자리가 아니라 커리어임. 면접만 통과하는 데 집중한 뒤 법적 보호에 기대 자리를 유지하면서, 진짜 열정 있는 사람에게 갈 수 있었던 자원을 차지하는 사람이 너무 많음.

내 세대가 꽤 잘되는 걸 보고 급여를 좇아 들어온 거라고 생각함. 나는 처음부터 모든 기술이나 이상적인 급여를 가지고 들어온 게 아니라 문제를 해결하겠다는 태도로 시작했음. 지금의 ‘혼란’은 오래전에 일어났어야 할 시장 조정일지도 모름. 비추천 수를 보면 이 의견이 얼마나 반감 살지 알겠지.

정책이 계속 바뀌어서 답답한 건 이해하지만 대학 입장도 생각해 봐야 함. 보통 대학은 산업 변화가 일어나면 몇 년간 지켜보고 실험하면서 어느 정도 통하는 방법을 찾은 뒤 교육과정에 반영할 시간이 있었음. 그런데 이번 변화는 대학의 사업 자체를 위협하니, 일단 뭔가 급하게 했다가 빨리 바꾸더라도 대응해야 한다는 압박을 받는 거지.

AI는 대학의 사업 모델과 학위 가치를 위협할 수 있고, 지금은 학위가 좋은 일자리를 얻을 가능성을 높여주지 못하면서 그 가치도 깎이고 있음. 직장에서도 AI 활용 정책이 일관되지 않음. 토큰을 많이 쓰라는 분위기였다가 효율적으로 쓰라는 분위기로 바뀌기도 하고, 고객 기밀정보를 모델에 넣으면 법적 문제가 생길 수 있다는 경고를 받으면서도 최대한 빨리 일하라는 압박을 받음.

결국 기획, 설계, 코딩, 테스트, 검토, 유지보수 같은 소프트웨어 개발 과정에서 사람과 여러 에이전트가 각각 무슨 역할을 할지 불확실한 상황임. 학생들은 이미 AI 사용이 습관이 된 채 대학에 들어오고, 교사들은 예전부터 부정행위를 어떻게 찾아내고 처벌할지도 고민해 왔고.

글을 읽어도 학교가 정확히 뭘 가르치려는 건지 모르겠음. 예전 과제가 어땠는지 모르니 ‘작업량이 세 배가 됐다’는 주장도 평가하기 어려움. 내 교육 경험과 비교해서 작업량이 합리적인지도 알 수 없고.

또 ‘3천 단어짜리 과제에 제출물이 15개나 돼서 겉핥기만 한다’고 하는데, 어떤 종류의 컴공 수업에서 3천 단어짜리 과제를 요구하는지도 궁금함.

학생에게 하고 싶은 말은, 더 좋은 아이디어가 있다면 들려달라는 거임. 그렇지 않으면 AI를 소재로 한 또 하나의 대학 행정 불평처럼 들림. 적어도 학교는 통하는 방법을 찾으려 하고 실수하면 바꾸려는 것 같음. 아직 누구도 정답을 모름.

그리고 모든 대학생에게 조언하자면, 나는 컴공 학위에서 많이 배웠지만 인문학 수업에서도 예상 밖의 가치를 얻었음. 사람마다 다르겠지만 주니어부터 아키텍트, 관리자, 임원, 창업자까지 일해보니 인문학 필수과목의 도움이 해마다 커졌고, 큰 팀을 책임지게 된 뒤에는 필수적이었음. 다시 대학에 간다면 그런 수업을 더 신중히 고르고 더 많이 배우려 할 거임. ‘교육에 AI를 어떻게 쓸 것인가’야말로 어떤 전문성이 필요한지 생각해볼 좋은 사례 아닌가?

새로 배운 컴퓨터과학 지식으로 뭘 하고 싶은 건데? 다음 구글을 만들 건지, 동네 보험회사에서 보험금 청구 업무를 처리할 건지에 따라 다르지. 대학원에 가고 싶다면 학위 없이 독학만 하는 건 좋지 않은 길이고. 소프트웨어가 어떻게 작동하는지 알아서 세상을 더 잘 이해하고 사회에 더 충실히 참여하고 싶은 거라면? 그건 나도 반박 못 하겠음.

나는 AI로 컴퓨터과학을 독학하는 데 회의적임. AI 자체가 컴퓨터과학을 가르치는 건 아니거든. AI 모델의 결과물을 보다가 뭔가 배운다면 그건 일종의 부수 효과에 가까움. 아마 우리가 생각하는 ‘컴퓨터과학’부터 꽤 다른 것 같음.

내가 생각하는 컴퓨터과학은 범용 컴퓨터를 다루는 응용수학의 한 분야에서 표기법, 절차, 증명을 체계적으로 탐구하는 거임. AI한테 ‘러스트로 피보나치 수열을 계산하는 함수 만들어줘’라고 한다고 해서 피보나치 수열이 어디서 나왔는지, 재귀가 무엇이고 왜 어떻게 도입됐는지, 프로그래밍 언어의 어휘 요소가 실제 수열을 만들어내는 추상적 절차와 어떻게 대응하는지 알게 되진 않음.

일부러 쉽게 반박할 수 있는 단순한 예를 든 거긴 함. 그런 식으로 ‘컴퓨터과학을 공부’하는 거라면 말리진 않겠지만, 스스로에게 큰 도움이 되진 않을 것 같음. 반대로 ‘추상 팩토리 패턴을 구현한 예제 코드를 만들고 각 함수가 패턴과 어떤 관계인지 설명해줘’라고 하면 꽤 괜찮은 설명을 얻을 수도 있음. 요즘 에이전트는 충분한 맥락을 유지하니 예제가 불분명할 때 질문도 할 수 있고.

평가 문제에는 해법이 있다고 생각함. 학생 성적의 대부분을 대면 평가로만 산정하는 거임. 일부 교사는 시험을 다시 볼 기회도 주고.

가르치는 일도 어렵지만 그건 원래 어려웠음. 여러 이유로 올해의 학생들과 다음 해의 학생들은 완전히 다르니까. 유능한 행정 담당자만 있다면 괜찮다고 봄. 이런 일까지 포함해서 우리가 선택한 직업이니까.

대학에서 컴퓨터과학을 가르치고 있고 그전에는 업계에서 20년 일했음. 상황이 정말 어렵다. 원래도 4년 뒤 시장이 어떨지 예측하는 건 힘들었는데, 1년 전에는 한 달 뒤도 예측하기 어려웠음. 이것저것 가르칠 수는 있는데 그게 맞는 내용인지 누가 알겠어?

지금은 조금 안정돼서 한 78개월 앞은 보이는 느낌임. 시니어와 주니어 채용 수요 차이를 보면 시장이 원하는 건 주니어와 시니어 사이의 전문성이라는 것도 보이고. 적어도 앞으로 78개월은 그럴 것 같음. 다만 그 격차를 4년 교육에 어떻게 채워 넣느냐가 문제지.

최대한 격차를 메우려고 해야겠지만, 언젠가 시니어가 너무 귀해져서 비용이 감당 안 되면 상대적으로 저렴하고 역량 있는 주니어를 뽑는 편이 나아질 수도 있음.

아직 답 없는 질문도 많음. 예를 들어 코딩 실력은 얼마나 중요할까? 직접 코딩하지 않는 시니어들에게 의사결정에 코딩 전문성이 얼마나 필요한지 물어보면 답이 제각각임. AI로 코딩하는 시니어들이라면 더 그렇고. 코드를 읽을 줄 아는 게 중요한지만 물어봐도 의견이 갈릴 거임. 시스템 차원에서 생각하는 능력을 어떻게 가르칠지도 문제고. 대학은 전통적으로 그런 능력을 가르치진 않았음.

‘20년 넘게 일하면서 매일 배우고, 최근에는 AI 덕분에 더 많이 배우고 더 빠르고 깊게 일한다’는 말은 좋지만, AI 때문에 앞으로 그런 일을 직업으로 할 기회 자체를 잃는 사람도 많을 거임.

‘AI가 사람이나 교육을 대체하는 게 아니라 이해하고 기억할 수 있는 수준을 높여준다’고만 할 수도 없음. 이미 AI 이전부터 어려웠던 취업시장을 더 힘들게 하고 일자리도 줄이고 있으니까. 게다가 많은 사람이 그 자체로 즐겼던 코딩이 ‘AI들의 프로젝트 관리자’ 역할로 바뀌는 걸 괜찮게 여긴다고 해도 말이지.

해법은 전자기기 없이, 참고자료도 보지 않는 평가를 치르는 거임. 시험이 이해도를 제대로 측정하는지는 논쟁의 여지가 있지만, 자연과학 분야에서는 우리도 그렇게 전환했음. 대학은 결국 큰 변화를 마주할 거임. 많은 학위가 경제적으로 수지가 맞지 않고 지금의 교육 방식으로 가르치기에도 적합하지 않다고 생각함.

AI가 저렴한 교육 모델을 끝냈다고 생각함. 500명이 듣는 신입생 강의도, 한 반 32명씩 하루 6개 반을 가르치는 방식도 더는 통하지 않을 거임.

남는 건 옥스퍼드와 케임브리지식 소그룹 교육임. 학생 4~10명이 미리 읽고 공부한 뒤 일주일에 몇 번 지도교사와 만나 토론하고 지도를 받는 방식. 이미 이렇게 하는 학교도 많지만 경험하는 학생은 적음. 비싸기 때문이지. 지도교사는 최소한 같은 분야 졸업자여야 하고 대학원 학위가 필요한 경우도 많으며, 교육도 받아야 함.

나는 이게 사실상 유일한 길 같아서 더 안타까움. 저렴한 대형 주립대도 남겠지만 AI 때문에 교육 수준이 떨어져 졸업생의 가치를 인정받기 어려워지고, 비싼 소규모 대학에서는 최소한의 교육을 보장받게 될 수 있음. 결국 빈부 격차가 더 커지는 거지.

가르치는 데에는 교사와 학생 사이에 다른 기준이 적용되기도 함. 고등학교와 대학에서 계산기 사용이 금지된 수업, 연습문제, 시험이 기억남. 목표가 숫자로 된 답을 얻는 게 아니었으니까. 그건 어디까지나 덤이었음.

동의함. 내 경우 학위는 프로그래밍과 이산수학의 기초를 가르쳐준 것 외에는 경력에 도움이 되지 않았음. 학점이 낮아서 졸업 직후 소프트웨어 엔지니어로 취업하지도 못했고, 스스로 길을 찾아 지금은 성공적으로 일하고 있음. 대학을 나올 때는 쉬운 리트코드 문제도 버거웠음.

지금까지 올 수 있었던 건 인맥을 쌓아 운이 따를 기회를 만든 것과, 대학을 떠난 뒤 한참 지나서 생긴 평생 학습에 대한 열정 덕분이라고 생각함.

내가 하지도 않은 주장을 반박하고 있음. 글에서 말하는 건 교수들이 AI로 과제를 만든 뒤 확인하지 않는다는 거임. 그래서 학생들이 AI가 만든 틀린 과제에 몇 주를 쓰다가 나중에 수정 공지를 받는다는 거고.

AI를 제대로 쓰는 건 문제가 아님. 자기 일을 AI에 시키고 확인도 안 한 채 학생들에게 떠넘기는 게 문제지. 왜 이걸 그렇게 열심히 옹호하는지 모르겠음. 어떤 환경에서든 AI가 만든 결과물을 검증하지 않고 다른 사람에게 넘겨서 확인을 그 사람의 일로 만드는 건 받아들이기 어려움.

당신도 사정을 다 아는 건 아니지만, 어느 쪽이든 그게 학생들의 문제가 되어서는 안 됨. 사람들은 자기 일을 해야 함. AI가 대충 만든 결과물을 학생이나 동료에게 그냥 넘기는 건 받아들일 수 없음.

행정 쪽에서 무슨 일이 벌어지고 있을지 학생들이 감당할 일이 아님. 학생들은 교육을 받으려고 큰돈을 내고 있고, 대학은 조직 전체로서 자기 일을 해야 함. 교직원이 압박받는다는 말로 모든 걸 변명할 수는 없음. 학생들이 비용을 내는 만큼 받아들일 만한 수준의 교육이 제공돼야 함.

AI로 이것저것 배울 수 있으니 일자리 상실은 걱정하지 않는다는 사람이 많음. 그런데 앞부분이 뒷부분과 거의 모순되는 것 같음. AI가 어떤 걸 충분히 잘 가르칠 수 있다면 그걸 직접 구현하는 것도 충분히 잘할 가능성이 높으니까.

예전에는 같은 지식을 가진 다른 사람들과 경쟁했고, 수요가 많은 기술이라면 오히려 시장을 키우는 데 도움이 되기도 했음. 하지만 AI는 사실상 무한히 활용할 수 있음. AI가 가르친 일을 직접 수행할 수 있다면, 개인적인 즐거움을 제외한 그 기술의 가치는 0에 가까워진다고 봄.

소프트웨어 엔지니어로 약 5년 일했고 시니어가 됐음. AI가 등장했을 때 이미 엔지니어였다는 점에서 운이 좋았다고 생각함. 나는 원래 코드의 단순함과 명확성을 추구해서 리팩터링에 많은 노력을 들였고, 좋은 오픈소스 코드도 자주 살펴봤음.

그런데 솔직히 지금 AI가 짠 코드가 사람 코드보다 나쁘다고 생각하지 않음. 내 생각에는 대다수 사람의 코드가 현재 오퍼스 5.5보다도 품질이 떨어짐. 기본적인 SOLID 원칙이나 패턴도 제대로 못 쓰고, 객체지향을 추구하다 추상화만 지나치게 하거나 머신러닝을 쓰려다 엉망으로 만들기도 함.

AI 코드가 걱정되냐고 묻는다면 동료가 짠 코드는 정말 믿을 수 있냐고 되묻고 싶음. 문제의 본질은 같음. 강력한 종단 간 테스트와 AI를 활용한 탐지에 의존하는 게 낫다고 봄.

소프트웨어 엔지니어링에서 학위는 면접에는 필요해도 실제 업무에선 선택 사항인 경우가 많음. 뭘 아느냐보다 뭘 처리할 수 있느냐가 중요하지. 경력 없는 사람들에게는 정말 불리한 상황이고, 엔지니어 자리는 줄면서 많은 경험을 요구하는 자리가 될 것 같음.

기술 업계 사람들이 ‘항상 배워야 한다’는 말을 좋아하는데, 그럴 때마다 뭘 배우라는 건지 궁금함. 다음 프로그래밍 언어, 다음 웹 프레임워크, 다음 프런트엔드 도구, 다음 파이썬 패키지 관리 도구, 다음 리눅스 배포판을 계속 배우라는 건가?

이런 끊임없는 교체에 지쳤음. 대부분의 도구는 서로 충분히 다르지도 않고 용도도 크게 다르지 않은데 기술직이 종종 이런 일의 반복처럼 느껴짐. 한 도구로 기본 작업에 익숙해지면, 같은 일을 딱히 더 낫지도 나쁘지도 않은 방식으로 해내는 완전히 다른 도구로 전부 갈아타는 거지. AI로 새 도구를 만드는 비용이 줄어들면 이런 현상이 더 심해질 것 같음.

2010년대와 팬데믹 기간에 온라인 교육이 크게 확대된 걸 생각하면 특히 와닿음. 대면 교육이 잘 맞지 않는 사람들에게 온라인 교육은 정말 큰 도움이 됐음. 하지만 AI 때문에 제출물만 보고 실제로 배웠다고 믿기 어려워져서 비동기 온라인 교육이 크게 흔들리고 있음. 대면 평가도 AI에 맞춰 바꿔야 하고.

나는 커뮤니티 칼리지에서 프로그래밍 입문, 자료구조, 이산수학을 가르치는 교수인데 생성형 AI 때문에 스트레스가 큼. AI 반대론자는 아니지만, 학생들이 대놓고 AI로 대충 만든 결과물을 부정행위로 제출하는 날에는 챗GPT가 원망스럽기도 함.

배울 것이 늘어나는 방향은 폭과 깊이 두 가지임. 새 도구가 새로운 용도를 추가하지 않는 경우가 많다는 건 동의하지만, 기존 도구가 작동하는 방식에도 깊이와 미묘한 차이가 많음.

구현 세부사항을 다 이해해도 기존 도구가 특정 작업을 하기에 불편할 수 있고, 예전에는 드물었던 용도가 흔해지기도 함. 그래서 새 도구와 용어가 생김. 경험이 적은 개발자들은 새로운 도구를 기준으로 이해할 테니 그들과 소통하려면 알아야 하고, 반대로 경력 내내 더 경험 많은 개발자의 글도 따라잡아야 함.

그럼 왜 표준화해서 이 순환을 끝내지 않느냐고? 너무 일찍 혁신을 멈추게 될 테니까. AI 학습 데이터는 오래될 수 있어도 인간의 지식까지 그래서는 안 됨. 목표는 기존 코드와 새 코드를 계속 개선하는 거임.

최근 사례를 하나 들겠음. 듀얼 소켓 젠 시스템에서 희소 전문가 모델의 일부를 CPU로 넘기는 작업을 하고 있음. 이 프로세서에는 여러 CPU 다이가 있고, L3 캐시와 메모리·PCIe 연결을 포함한 구조가 있음. 듀얼 소켓 사이를 잇는 연결망도 있고. 이 물리적 구조를 파악해서 작업을 배치하면 가진 시스템의 성능을 최대한 끌어낼 수 있음.

델 등은 캐시와 메모리 버스의 최대 처리량을 오랫동안 측정해 왔고 나도 그 수치에 도달하거나 넘어섰음. 하지만 L3 캐시에서 데이터가 밀려나고 유지되는 방식은 제대로 분석하거나 문서화한 사람이 없었음. 그래서 퍼징, 특허 조사, 성능 분석을 조합해 작동 방식을 파악하고 내 소프트웨어 구성에 맞췄음.

이게 쓸데없는 유행 따라가기일까? 이 하드웨어는 주류 환경에서는 이미 오래전에 구식이 됐음. 직업적으로 도움이 될지는 시간이 지나봐야 알겠지만, 나는 배우는 걸 좋아해서 재밌었음.

참고로 경력 5년에 ‘시니어’라는 것도 문제의 일부라고 생각함. 직함에 무게를 둔다면 이제 막 중급에 편안하게 자리 잡을 정도의 경력인데.

내가 그 젊은 사람 중 하나임. 최근 컴공을 졸업했는데, 나는 학위의 핵심이 수학과 컴퓨터과학의 폭넓은 개념을 배워서 이 분야의 여러 주제를 스스로 생각할 수 있게 되는 거라고 봤음. 취업률에 맞춰 교육과정을 짜야 한다고 생각하지도 않음. 그런데도 학위의 가치는 크게 줄었다고 느낌.

업계 유행을 전부 따라가진 않아도, 추가로 조금만 공부하면 컴공 관련 어떤 분야든 배울 수 있을 만큼은 배우리라고 생각했음. 취업 보장은 없어도 유용하고 폭넓게 쓸 수 있는 지식을 얻어서, 거기에 노력을 더하면 기술직으로 이어갈 수 있으리라는 기대는 있었던 거지.

그런데 내 눈에는 AI가 특정 분야 하나만 자동화한 게 아니라 나 같은 사람이 경력을 시작할 수 있는 거의 모든 입구를 막아버린 것처럼 보임. 이미 취업한 사람들도 지식의 빈틈을 AI로 메우라는 권유를 받으면서 기초 지식은 점점 덜 평가받고 있고.

학위를 직업훈련으로 보는 것과, 졸업 후 학계 밖에서도 핵심 역량이 어느 정도 쓸모 있기를 기대하는 건 다른 얘기임.

평가 체계가 좀 다를 수도 있음. ‘시니어’라는 말도 흥미로운데, 직함이 실제 능력을 반영하는 건 아니니까. 경력 20년인 시니어 엔지니어가 함수 두 개짜리 파일을 5천 줄 넘게 작성하는 것도 봤고, 중학생 때 프로그래밍을 시작해서 대학 졸업 직후 세계적인 오픈소스 프로젝트에 기여하는 사람도 봤음. 그래서 나는 직함보다 능력에 집중하고 싶음. 물론 나도 그렇게 뛰어난 사람은 아니지만.