생성형 AI와 프로그래머의 역량

AI 지원 프로그래밍 환경에서 작업하면 프로그래머의 역량이 낮아질까?

꾸준히 발전하는 도구들

AI 지원 프로그래밍이 어떤 면에선 특별하지만, 어떻게 보면 프로그래밍의 역사에서 꾸준히 일어났던 도구의 개선 중 하나의 사례일 뿐이기도 하다.

내가 경험했던 변화들을 몇 가지 적어보면 이렇다.

서점 + 도서관 → 웹 검색
수동 컴파일 후 오류 메시지 읽기 → IDE에서 제공하는 문법 강조 및 실시간 정적 분석
API 외우기 + 레퍼런스 뒤지기 → IDE에서 제공하는 자동완성
수동 실행 후 여기저기 눌러보기 → 자동화된 인수 테스트와 단위 테스트
수동 실행 후 여기저기 눌러보기, 단위 테스트 → 타입 추론과 정적 타입 검사 (타입 시스템은 단위 테스트를 완전히 대체한다기보다 상보적 관계에 가깝다)
웹 검색, 코드 입력과 수정 → 깃헙 코파일럿, Cursor

피드백 간극은 계속 좁아지고, 인간의 지각, 추론, 기억 등 인지 과정은 점진적으로 외재화되고 있다. 갑자기 이렇게 된 건 아니고 애초에 인간이 도구를 쓰기 시작한 시점부터 시작된 흐름이다.

도구를 안써야 진짜 개발자라는 주장

어떤 도구를 안써야 진정한 개발자라는 종류의 주장은 꾸준히 있어 왔다. 손코딩을 해야 진짜라거나, 자동완성을 쓰면 안된다거나, 웹 검색을 쓰면 안된다거나 등등. 이런 주장의 가장 최신 버전은 “깃헙 코파일럿을 안써야 진짜 개발자”라는 주장인데, 과거의 주장들과 별반 다를 바는 없어 보인다.

이런 주장에는 크게 두 가지 문제가 있는 것 같다.

첫째, “인간의 능력”이라는 어떤 추상적인 덩어리가 있는데 그게 도구를 쓸수록 나빠진다는 잘못된 가정. 하지만 능력이라는 건 하나의 덩어리도 아닐 뿐 아니라 어떤 도구를 어떻게 쓰는지에 따라 어떤 능력은 오히려 높여줄 수도 있다. 예를 들어 깃헙 코파일럿을 쓰면서 기억력은 나빠질 수 있지만 내 의도를 코드에 더 명확히 표현하는 능력이나 다른 이(AI)가 제안한 코드를 읽고 빠르게 이해하는 능력은 더 높아질 수 있다.

둘째, 도구와 분리된 인간 고유의 능력을 측정할 수 있고 그게 진정한 능력이라는 잘못된 가정. 종이, 화이트보드, 컴퓨터 등이 없이 인간이 머리 속으로 얼마나 코드를 잘 짤 수 있는지를 기준으로 측정한 능력치에 무슨 의미가 있겠나. 환경과 격리된 진공 상태의 사람의 능력이 아니라, 사람과 환경과 도구가 결합된 전체 시스템의 능력을 봐야 한다.

뭘 안써야 진정한 개발자라는 주장은 어쩌면, 내가 지금 익숙하게 쓰고 있는 도구까지는 써도 되는 도구고 나한테 아직 생소한 도구는 쓰면 안되는 도구라는 식의 편협한 생각을 그럴듯한 다른 말로 표현한 것에 불과하다고 생각한다. (변주로는 내가 쓰는 기술보다 더 신기술을 쓰면 힙스터고 더 오래된 기술을 쓰면 퇴물이라는 주장이 있다.)

물론 어떤 훈련의 수단으로 의도적인 제약을 가해보는 게 때론 유익할 수는 있다고 믿는다. 예를 들어 새 프로그래밍 언어를 배울 때 머리 속으로 능동적으로 고민하면서 차근차근 코딩을 해보고 싶을 때가 있는데 깃헙 코파일럿이 후루룩 정답을 적어버리면 오히려 학습에 방해가 될 때가 있다. 이런 경우엔 잠시 코파일럿을 꺼둔다. 반대로, 도구에 극도로 의존하는 훈련을 하는 게 유익할 때도 있다. 예를 들어 코파일럿의 한계를 알아보기 위해(또는 의도를 잘 드러내는 훈련을 하기 위해) 나는 최대한 자연어로만 명령을 내리고(또는 의도를 표현하고), 코파일럿이 제안한 코드만으로 프로그래밍을 진행하는 연습을 해보면 여러모로 유익하다.

생성 AI를 쓰면 성적이 낮아진다는 연구

생성 AI를 써서 공부한 그룹이 시험을 더 잘봤지만 이후에 AI를 못쓰게 했더니 애초부터 안썼던 그룹보다 오히려 성적이 낮아졌다는 연구(Generative AI can harm learning)가 있다. 하지만 공학도들에서 공학계산기를 갑자기 빼앗거나, 개발자들에게서 자동완성 기능을 갑자기 꺼버려도 마찬가지 현상이 관찰될 게 뻔하다는 점에서 이는 별로 놀랄 일도 아니고 우려할 일도 아니라고 생각한다.

결국 전체 인지 과정 중 뭘 머리 안에서 처리하고 뭘 머리 밖 외재화된 도구(종이, 계산기, IDE, AI, …)에서 처리하는 게 좋을지를 잘 선택할 문제이고, 옛날부터 있던 문제의 연장이다. 도구가 점점 발달하면서 선택권이 늘어날 뿐.

뭘 안써야 한다는 식의 생각보다는 어떤 맥락에서 어떤 도구를 어떤 식으로 서로 엮어서 쓰면 좋을지 고민을 하는 게 훨씬 유익하다고 본다.

초보자에겐 해롭고 전문가에겐 이롭다는 주장

본인이 잘 아는 분야에서 LLM을 쓰면 이롭지만 전혀 모르는 분야에서 쓰면 해롭다는 주장도 있다. LLM이 당면한 일을 빨리 끝내게 도와주긴 하지만 학습엔 방해가 된다는 것.

LLM이 무조건 좋다거나 나쁘다는 류의 주장보다야 나은데, 여전히 여러모로 문제가 있다고 생각한다.

일단 본인이 잘 아는 분야에서도 이상하게 쓰면 해로울 수 있고 전혀 모르는 분야에서도 잘 쓰면 이로울 수 있다. LLM을 썼더니 학습에 방해가 되는건, 학습에 방해가 되는 방향으로 썼기 때문.
게다가 LLM이 초보자에겐 해롭고 전문가에겐 이롭다는 주장은 자칫 초보자-전문가 사이의 격차를 더 벌릴 가능성이 있다는 점에서도 문제적이다. 초보자와 전문가가 각각 LLM을 어떤 상황에서 어떻게 쓰면 유익하고 해로운지를 논하는게 훨씬 이롭다고 생각한다. 여기에서 “유익”이란 1) 당장의 성과를 높이기, 2) 미래 성과를 높이기 위해 역량을 높이기, 이 두 가지 모두를 고려한 유익함을 말한다.
LLM이 학습에 방해가 된다는 주장을 들으면 “아, 이 사람은 학습을 중시하는구나” 싶은 생각이 들지만 다른 한편으로는 “그 생각을 깊게 체화하지는 못했나?” 싶은 의구심도 든다. 주어진 일을 빨리 끝내는 용도로만 LLM을 쓸 뿐, 학습을 돕는 용도로 쓸 방법에 대해선 고민을 충분히 안했다는 뜻이니까.

2024년 10월에 발행된 한 메타 연구에 따르면 인간이 AI보다 잘하는 일에 AI를 붙여주면 인간 혼자 할 때보다 결과가 더 좋았으나, AI가 인간보다 잘하는 일에 인간을 붙여주면 AI 혼자 할 때보다 결과가 더 나빴다고 한다. 저자들은 인간이 AI보다 전반적으로 잘하는 경우에라야 AI의 제안을 수용할지 여부도 더 잘 판단할 수 있기 때문일 것으로 추측한다. 그러니까 인간이 AI보다 못하는 상황에선 AI를 의심할 타이밍에 의심 안하거나(overreliance), AI의 제안을 수용할 타이밍에 고집을 부리거나(underreliance) 한다는 얘기.

여기까지만 읽으면 AI를 쓰는 게 “초보자에겐 해롭고 전문가에겐 이롭다”는 주장이랑 부합하는 것 같지만 사실은 그렇지 않다. 동일한 연구에서의 또다른 흥미로운 부분은 인간이 AI보다 잘하는 일이건 못하는 일이건 간에, 인간이 혼자 하는 것보다는 AI랑 같이하는 게 대체로 더 나았다는 점이다. 특히 유한한 선택지 중 고르는 종류의 일이 아니라 열린 상황(콘텐츠 생산 등)에서는 더욱 그러했다. 해당 연구에서 코딩에 대해 직접 언급하고 있지는 않지만 굳이 분류하자면 코딩은 닫힌 의사결정 상황보다는 열린 콘텐츠 생산 상황에 더 가깝다.

개인적 경험 1

옛날엔 개발자가 프로그램을 손글씨로 작성하고 오퍼레이터가 천공카드에 구멍을 뚫어 컴퓨터에 입력했다고 한다. 난 이 시절을 겪지 않았지만 어릴 적 집에 컴퓨터가 없었던 탓에 주중엔 공책에 코딩하고 주말에 동네 컴퓨터 학원에서 입력해보거나(1987년), 상가에 전시된 컴퓨터에 입력해보곤 했다(1992년, 영풍문고 지하). 아무튼 키보드는 있던 시절이었다.

프로그램 작성과 실행 사이의 간극이 약 일주일 정도 됐기 때문에 코딩을 극도로 주의해서 했던 경험은 장점이었다. 요즘은 문법 하이라이팅, 자동완성, 편집기와 통합된 실시간 정적 분석, 자동 단위 테스트, 라이브 새로고침, AI의 실시간 수정 제안 등 피드백 고리가 극도로 짧아진 덕에 수시로 실수를 해도 순식간에 바로잡을 수 있어서 마치 실수를 하지 않은 것과 별 차이가 없어져 버렸는데(결함비용증가), 그래서인지 예전에 비해 조심을 덜 하고 실수를 더 많이 하게 됐다.

교육적인 면에서 어떤 실수는 이롭고 어떤 실수는 시간 낭비에 가깝기 때문에 잦은 실수가 무조건 좋거나 나쁘다고 말하긴 어렵다. 다만 강제로 피드백 간극이 길기만 했던 과거에 비하면 내 의지로 간극을 조정할 수 있는 지금 상황이 더 좋다고 말할 수는 있겠다.

개인적 경험 2

AI의 도움을 받아 ZenPDF라는 맥OS 앱을 만든 경험 메모(2024-09-28).

언어(Swift), 프레임워크(SwiftUI), 플랫폼(macOS), 개발 환경(Xcode) 모두 거의 아무 것도 모르면서 제법 그럴듯한 결과물을 만드는 경험이 생소하고 재미있다. 새로운 걸 시작할 때의 두려움을 상당히 줄여준다게 AI 지원 프로그래밍의 큰 장점 중 하나인 것 같다.

단점은 개발을 잘 못하는 팀장과 팀원이 일할 때 생기는 문제와 유사하다. 팀장은 지시를 정확하게 못하고 팀원은 결과물을 정확하게 못만들고 팀장 “느낌적인 느낌으로” 검토하고 피드백 하기를 반복. 초반에 일이 되긴 되는데 품질은 점점 낮아지고 어떤 코드가 왜 있는지 아무도 모르는 상황이 되어 간다.

결국 시작은 이렇게 하더라도 문서를 차분하게 읽으며 문법과 프레임워크를 어느 정도 익힐 필요가 있다. “일단 만들어보기”와 “차분히 공부하기”를 반복적으로 오간다는 점에는 차이가 없는데, AI 덕에 “일단 만들어보기” 단계가 상당히 수월해진다는 차이가 있어 보인다. 보폭이 커진 느낌.

결론

“생성 AI를 쓰면 역량이 낮아지나?”라는 질문보다는 “어떻게 하면 역량을 높이는 방향으로 생성 AI를 쓸 수 있을까?”라는 질문이 더 유익해보인다. 참고: