개발자들 사이에는 코드를 그 자체로 즐기는 사람과, 컴퓨터가 실제로 뭔가를 하게 만드는 일을 즐기며 코드를 그 수단으로 보는 사람이 있다. AI 코딩 도구는 내가 컴퓨터가 일을 하게 만드는 데 도움을 줬다.
2025 • 12월 • 19 TL;DR: 개발자들 사이에는 갈림이 있다—어떤 이들은 코드를 그 자체로 쓰는 걸 좋아하고, 또 다른 이들(나 같은)은 컴퓨터가 뭔가를 하게 만드는 걸 좋아하며 코드는 그 목적을 위한 수단으로 본다. AI 코딩 도구는 내가 컴퓨터가 뭔가를 하게 만드는 데 도움을 줬다.
사진: Lorenzo Herrera, Unsplash
David Celis는 "Writing Code Is Fun"에서 이렇게 말한다:
나는 코드를 쓰는 게 재미있어서 소프트웨어 엔지니어가 됐다. 어려운 문제를 곱씹고, 우아한 해법을 설계하고, 내가 만든 것들이 처음으로 동작하는 걸 보는 것… 이런 순간들은 모두 깊이 만족스럽다. 그런데 내가 왜 세상에 그런 것들을 AI에게 넘겨주겠는가?
내가 올해 LLM으로 코드를 생성하는 데 많은 시간을 쓰고 있다는 건 딱히 비밀도 아니다. 내 직장과 업계 전반이 그 방향으로 밀어붙이고 있고—그냥 빠져나올 여유가 없다고 느낀다.
그런데 문제는, 이게 내겐 재미있고 보람찬 경험이었다는 점이다. 난 이걸 너무 크게 떠들려고 하진 않았다. 이건 도구이고, 나는 구독료를 내고 있고, 그저 정상적으로 굴려고 한다. 누가 이런 걸 쓰도록 설득해서 돈을 챙기는 것도 아니다.
하지만 그런 건 제쳐두고, 코드 생성이 소프트웨어 개발에 접근하는 방식에서 컴퓨터 만지는 사람들 사이의 갈림을 더 부각시키고 있다는 느낌이 점점 강해지고 있다.
대학 시절, 컴퓨터 과학과 수학 수업에서 이런 갈림을 기억한다. 우리 중 일부는 증명과 알고리즘을 그 자체의 가치로 파고드는 데 정말 신나 했다. 또 일부(나 같은)는 실용적 적용에 의해서만 동기가 생겼다.
선형대수는 특히 떠오른다. 반쯤은 정리와 증명 시험에서 늘 만점을 받았지만, 나는 행렬곱 같은 걸 3D 공간에서 도형을 회전시키는 데 어떻게 쓰는지—즉 비디오 게임 그래픽을 위해 어떻게 쓰는지—이해하고 나서야 비로소 제대로 흡수했다.
이건 딱 잘라 나뉘는 구분도 아니고, 가치 판단을 하려는 것도 아니다. 이건 오히려 벤 다이어그램에 가깝고, 기술과 퍼즐 풀이의 초점이 어디로 향하느냐에 따른 스펙트럼의 이동이다.
어떤 사람들은 Lisp만 봐도 미소 짓고, Ruby의 세련된 문법과 그 결과로 나오는 더 시적인 코드를 즐긴다. 그들은 Zachtronics의 EXAPUNKS 같은 게임에서, 작은 로봇들이 최소한의 사이클로 작업을 완료하도록 코드 골프 경쟁을 즐길지도 모른다.
또 다른 사람들은 코드를 목적을 위한 수단으로 본다—그들은 일을 끝내기 위한 유닉스 파이프의 투박한 루브 골드버그식 조립체에 미소 짓거나, Factorio에서 이것저것을 서로 연결해 무언가를 만들며 몰입한다.
요컨대: 나는 컴퓨터가 뭔가를 하게 만드는 게 재미있어서 소프트웨어 엔지니어가 됐다. 코드를 쓰는 건 그 목적을 위한 수단일 뿐이다.
그건 내가 8살이었을 때, Commodore 64에서 6502 어셈블리에 처음 빠져들었던 때부터 그랬다. 나는 특별히 우아함을 감상하진 않았고, 그저 어셈블리로 구현한 Bresenham의 선 알고리즘이 BASIC보다 고해상도 그래픽에서 훨씬 빠르게 선을 그려준다는 게 좋았다. (또다시 비디오 게임 이야기다.)
물론 나는 우아함과 깔끔한 코드에 대한 큰 감사함이 있다. 하지만 내 일상적인 초점은 그것이 가능하게 해주는 것들이다. 우리의 일이 끊김 없이 돌아가게 해주나? 고장 나는 게 줄어서 밤에 더 편히 잘 수 있나? 지속적으로 운영해야 하는 관점에서 일을 해낸다면, 플라톤적으로 이상적인 형태에 못 미치는 무언가가 프로덕션에 나가도 나는 마찬가지로 기쁘다.
내 경험상, AI 코딩 도구를 쓰는 건 확실히 내가 더 빠르게 움직이도록 도와줬다. 또한, 어떤 경우엔 내가 아예 움직이게도 해줬다. 과제 착수에 드는 정신적 비용을 마주한 뒤, 시작조차 못 했을 일들이 있었기 때문이다.
Simon Willison은 이에 대해 많이 써왔다:
이 기묘한 새로운 AI-강화 현실에서 내가 가장 흥분하는 건, 그것이 내 프로젝트들을 더 야심차게 만들 수 있게 해준다는 점이다.
숙련 개발자인 내게 ChatGPT(그리고 GitHub Copilot)는 "알아내는" 데 드는 시간을 엄청나게 줄여준다. Bash에서 for 루프를 쓰는 것부터 JavaScript에서 크로스 도메인 CORS 요청을 어떻게 하는지 기억해내는 것까지—이젠 굳이 찾아볼 필요도 없고, 그냥 프롬프트를 주면 80% 정도는 정답을 준다.
이건 단지 생산성을 높이는 데 그치지 않는다. 프로젝트에 시간을 투자할 가치가 있는지에 대한 내 기준 자체를 낮춰준다.
최근에는 Claude의 도움으로, 수년 동안 위시리스트에만 있던 몇 가지 도구를 띄워봤다—예컨대 RSS 피드를 읽는 내 데일리 드라이버인 feedspool-go, 크로스 포스팅을 위한 feed-to-mastodon, 그리고 내 북마크와 글을 Markdown으로 내보내는 각종 유틸리티들 같은 것들이다.
또한 예전에 에너지가 완전히 바닥나서 멈춰 있었던 프로젝트들도 다시 손대기 시작했다. 예를 들면 Mastodon 백업을 위한 fossilizer와 이 블로그 자체 같은 것들.
이 모든 경우에서, 코드를 쓰는 건 동작하는 도구를 갖는 것보다 훨씬 덜 재미있었다.
하지만 AI 코딩 도구는 개발의 다른 측면들에서도 강제 함수 역할을 했다. 예전에는 바로 코드로 들어가 즉흥적으로 치고 나갔다면, 이제는 산문을 쓰는 데 더 많은 시간을 쓴다—무엇을 만들고 싶은지 설명하고, 문서를 다듬는다.
또한 테스트, 린팅, 자동화된 품질 관리를 설정하는 데도 더 많은 시간을 쓴다. 알고 보니 이런 것들을 코드 생성 에이전트의 루프에 빡빡하게 통합할 수 있고, 그것들은 가드레일처럼 작동해 매운 자동완성이 필요한 일을 처리하면서도 방향을 바로잡게 해준다.
나는 컴퓨터가 뭔가를 하게 만드는 게 좋다. 그리고 내가 아주 게으르기 때문에, 내가 안 해도 되게끔 컴퓨터가 뭔가를 하게 만드는 것도 좋다. 하지만 나는 또한 아주 피곤하기 때문에, 그것들이 잘, 그리고 믿을 수 있게 일을 하도록 만드는 것도 좋다.
AI 코딩 도구에 대한 내 경험은, 그것들이 내가 게으르고 피곤해도 많은 일을 해내도록 도와줬다는 것이다. 그리고 그건 내겐 재미있지만, 그 재미가 모두에게 보편적이진 않을 수 있다.
