Recurse Center의 AI 입장글을 계기로, 인터넷에서의 건설적 담론 방식과 LLM을 학습에 사용할 때의 주의점, 그리고 추상화의 계단식 발전 속에서도 깊은 이해가 여전히 최고의 도구라는 점을 짚는다.
Recurse Center의 Developing our position on AI를 읽고 나서, 내 뉴스레터에 썼던 해당 항목이 길어져 별도의 블로그 글로 떼어 내기로 했다. 구체적인 결론을 넘어, 이 글은 인터넷과 우리의 삶에서 모두 지향해야 할 더 점잖고 사려 깊은 토론 방식을 제시한다고 생각한다.
나는 오래전부터 Recurse Center에 매료되어 왔다. 커리어 내내 그곳 출신들과 마주칠 때마다 늘 깊은 인상을 받았고, 지금까지 내가 읽은 것 중 아마도 가장 균형 잡히고 사려 깊은 AI와 소프트웨어 엔지니어링에 관한 견해가 Recurse에서 나왔다는 사실이 그리 놀랍지 않다.
나는 이 글이 조직 내에서 논쟁적인 이슈를 다루고, 그 이슈를 대중에게 쓰는 훌륭한 방식을 제시한다고 생각한다. 먼저, 모두의 말을 듣는다. 그다음, 이견을 인정하고 뉘앙스를 강조해 공통분모를 찾기 위해 노력한다.
목표는 매 순간 ‘정답’을 갖는 데 있지 않아도 된다. 사람들은 서로 다른 삶의 경험을 지니고 있고, 이는 종종 서로 다른 최상위 신념으로 이어진다. 하지만 그 헤드라인 너머로, 합리적인 사람들이 “2028년이면 모두 ASI가 구동하는 유토피아에 살 것이다”에서 “LLM이 우리의 담수를 다 빨아들이고 있다”에 이르기까지 무엇이든 말할 수 있는 영역에서도 놀랄 만큼 많은 공통분모가 있다.
이 글의 경우, 대부분의 사람들은 LLM을 사용해 새로운 것을 배우는 일 은 어느 정도의 주의를 요한다는 데 동의했다.
글의 이 단락은 특히 내게 깊이 와닿았다:
튜토리얼과 선생님은 당신을 어느 정도까지만 데려다 줄 수 있다. 결국에는 당신이 스스로의 정신적 구조를 세워야 한다. Stack Overflow는 유용한 자원이 될 수 있지만, 맹목적으로 따르거나 복붙하는 것은 학습에 별 도움이 되지 않는다. LLM을 생각 없이 사용하면 Stack Overflow보다 훨씬 멀리 갈 수 있지만, 같은 원칙이 여전히 통한다.
StackOverflow에 대한 비교는 LLM을 둘러싼 논의에서 반복적으로 등장한다. LLM이 혁명적으로 느껴질 수 있지만, 소프트웨어 개발 자원에서의 단계적 변화가 처음인 것은 아니다.
구글은 참고 자료를 찾기 위해 매뉴얼을 검색하고 훑어보는 기술을 거의 구식으로 만들었다. 오라일리는 여전히 존재하지만, 참고서적은 특정 작업에 초점을 맞춘 짧은 형식의 블로그 글에 비해 엔지니어 교육에서 차지하는 비중이 훨씬 작아졌다. 기술 문서의 네 가지 유형은 검색 엔진의 등장 이전에도 물론 존재했지만, 짧은 형식의 콘텐츠는 순위 기반 검색과 추천 알고리즘에서 더 번성한다.
StackOverflow는 많은 흔한 코딩 작업을 큰 사전 사고 없이도 해낼 수 있게 만들었다. 대부분은 StackOverflow 답변을 복붙하는 일을 유감스러운 지름길로 본다. StackOverflow는 틈새를 메웠지만, 깊은 이해의 필요를 없애지는 못했다.
소프트웨어 엔지니어링에는 항상 항공사 물류, 급여 처리, 도서관(책이 층층이 쌓여 있는 그곳이지, 프로그램에서 호출할 수 있는 미리 작성된 함수들의 모음이 아니다)의 조직과 유지보수처럼 ‘화이트칼라’ 인간 업무를 자동화하는 데 초점을 둔 요소가 존재해 왔다. 직업으로서의 프로그래밍도 여기에 예외가 아니었다 — 어셈블러는 프로시저로 점프하기 위한 메모리 오프셋 계산을 자동화했고, 가비지 컬렉터는 메모리 관리를 자동화했으며, 구글 검색은 RTFM의 의미를 바꿔 놓았다.
새로운 도구는 언제나 시스템에 대한 얕은 이해만으로도 코드를 더 쉽게 작성하게 만든다. Claude Code, Cursor 같은 도구들은 한때 C와 Java, Python이 그랬던 것처럼 프로그래밍을 자연어에 더 가깝게 가져오고 있다.
이건 좋은 일이다! 프로그래밍의 민주화가 계속될 것이고, 더 많은 사람이 컴퓨터와 대화하게 될 것이다. 하지만 이것이 근본적인 현실을 바꾸지는 않는다고 나는 생각한다. 가장 뛰어난 프로그래머는 가장 높은 추상화를 가장 넓게 쓰는 사람이 아니다. 언제나 더 깊은 수준에서 무슨 일이 일어나는지 파고드는 사람들이고 — 그런 이해는 프로그래머가 사용할 수 있는 어떤 도구든 더 능숙하게 다루게 한다.
