소켓 프로그래밍의 전설이 던진 질문
C 언어로 네트워크 프로그래밍을 공부해 본 분이라면 'Beej's Guide to Network Programming'을 한 번쯤 거쳐 가셨을 거예요. 1990년대부터 지금까지 무료로 공개되어 전 세계 개발자들의 소켓 프로그래밍 입문서 역할을 해온 전설적인 문서거든요. 그 저자인 Beej(브라이언 홀)가 'Making(만들기)'이라는 제목의 에세이를 올렸는데요. AI가 코드를 다 짜주는 시대에 우리가 뭔가를 '직접 만든다'는 행위가 어떤 의미를 갖는지 정면으로 파고드는 글이에요.
결과물이 목적인가, 과정이 목적인가
에세이의 핵심 질문은 의외로 단순해요. '당신은 왜 만드나요?' 결과물이 필요해서라면, 이제 AI에게 시키는 게 합리적인 시대가 됐어요. 프롬프트 몇 줄이면 웬만한 CRUD 앱 정도는 뚝딱 나오니까요. 그런데 여기서 짚어야 할 게 하나 있어요. 만드는 사람들 중 상당수는 결과물 그 자체보다 '만드는 과정'에서 의미를 찾는다는 거예요.
목공 비유가 딱 맞는데요. 의자가 필요하면 이케아에서 사는 게 훨씬 싸고 빠르잖아요. 그런데도 주말마다 나무를 자르고 대패질을 하는 사람들이 있거든요. 그 사람들에게 완성된 의자는 사실 부산물이에요. 진짜 얻고 싶은 건 내 손으로 뭔가를 빚어내는 경험, 그 과정에서 조금씩 늘어나는 실력, 그리고 완성했을 때의 성취감이거든요. 프로그래밍도 마찬가지라는 게 이 글의 이야기예요. 수십 년간 가이드를 쓰고 가르쳐온 Beej에게 코딩은 단순히 소프트웨어를 얻는 수단이 아니라, 만들기라는 행위 그 자체가 주는 기쁨이었던 거죠.
고생이 사라지면 배움도 사라진다
여기서 학습 이야기로 이어지는데요. 프로그래밍 실력이 언제 늘었는지 떠올려 보세요. 아마 잘 짜인 코드를 구경할 때가 아니라, 밤새 버그랑 씨름하고, 문서를 뒤지고, 스택오버플로를 헤매다가 마침내 '아, 이거였구나!' 하는 순간이었을 거예요. 그 고생스러운 과정이 바로 실력이 쌓이는 지점이거든요. AI에게 답을 받으면 결과는 빨리 나오지만, 그 과정에서 생겨야 할 근육은 안 생겨요. 헬스장에서 기계가 대신 바벨을 들어주면 운동이 안 되는 것과 같은 이치예요.
그렇다고 AI를 무조건 배척하자는 러다이트 선언이냐 하면, 그건 아니에요. 도구로서의 유용함은 인정하되, 쓰기 전에 스스로에게 물어보라는 거예요. '지금 나는 결과물이 필요한 건가, 아니면 만들기 자체가 목적인가?' 회사 업무처럼 결과가 중요한 상황이라면 AI를 적극 활용하는 게 맞을 수 있어요. 하지만 배우려고 시작한 공부, 즐기려고 시작한 사이드 프로젝트에서까지 AI에게 다 맡겨버리면, 정작 얻고 싶었던 걸 놓치게 된다는 거죠.
지금 이 논쟁이 뜨거운 이유
이 에세이가 나온 타이밍이 절묘한데요. 요즘 개발 커뮤니티에서는 이른바 '바이브 코딩(vibe coding)' — AI에게 대충 의도만 말하고 나오는 코드를 깊이 검증하지 않고 쓰는 방식 — 을 둘러싼 논쟁이 한창이거든요. 한쪽에서는 생산성 혁명이라고 하고, 다른 쪽에서는 자기가 짠 코드를 이해하지 못하는 개발자 세대가 나올 거라고 걱정해요. 특히 주니어 개발자들이 기본기를 쌓을 기회 자체가 사라지고 있다는 우려가 커지고 있고요. Beej처럼 수십 년간 직접 만들고, 그 지식을 무료로 나누는 삶을 살아온 사람의 목소리라서 더 무게감 있게 다가오는 것 같아요.
우리에게 남는 질문
한국 개발자들에게도 남 얘기가 아니에요. 취업 준비생이라면 AI로 포트폴리오를 찍어내고 싶은 유혹이 크겠지만, 면접에서 '이 코드 왜 이렇게 짰어요?'라는 질문에 답하지 못하면 의미가 없거든요. 실무자라면 반복 작업은 AI에게 맡기되, 새로운 개념을 배울 때만큼은 직접 부딪혀 보는 식으로 자기만의 기준을 세워두는 게 좋아요. AI를 쓰느냐 마느냐의 이분법이 아니라, '언제 쓰고 언제 안 쓸지'를 스스로 정하는 게 진짜 실력인 시대가 된 거죠.
정리하면, 이 에세이는 AI 시대에 만들기의 의미를 다시 묻는 글이에요. 여러분은 어떠세요? 코딩이 결과물을 위한 수단인가요, 아니면 만드는 과정 자체가 즐거움인가요? 그리고 그 답에 따라 AI를 쓰는 방식도 달라져야 할까요?
🔗 출처: Hacker News