AI 보조 프로그래밍에 대한 진솔한 도발과 LLM을 둘러싼 흔한 반론에 대한 실제 개발자의 솔직한 답변.
이미지: Annie Ruygt
AI 보조 프로그래밍에 대한 진솔한 도발.
요즘 업계 기술 임원들은 LLM(대규모 언어 모델) 도입을 강요하고 있다. 그건 나쁜 전략이다. 하지만 그들의 입장을 이해할 수는 있다.
내가 아는 가장 똑똑한 몇몇 사람들은 AI가 한때 NFT 열풍처럼 곧 사라질 유행이라는 확고한 믿음을 가지고 있다. 사실 내가 그들에게 딱히 반박하지 않은 이유는, 그들이 나보다 똑똑하기 때문이기도 하다. 하지만 그들의 논거는 진지하지 않으며, 반박할 가치가 있다. 매우 뛰어난 사람들이 LLM이 이미 더 잘하는 일을, 그저 고집 때문에 계속 하고 있다.
만약 LLM의 모든 발전이 오늘 멈춰버린다고 해도, LLM은 내 경력에서 두 번째로 중요한 사건으로 남을 것이다.
중요한 한계: 나는 LLM이 소프트웨어 개발에 미치는 영향만 이야기한다. 예술, 음악, 글쓰기? 나는 할 말이 없다. 오히려 그 분야 회의론자들의 주장에 공감하는 편이다. 하지만 내 분야에 대해선 믿지 않는다.
본인 소개: 나는 1990년대 중반부터 소프트웨어를 만들어왔다. 박스 포장된 C 코드부터 시작했다. Alexandrescu 책에 혹해 C++로 무모한 시기도 겪고, 루비와 파이썬으로 툴 만들기도 많이 했다. 커널 작업도 조금, 서버 사이드 C, Go, Rust도 꽤 해봤다. "진지한 개발자"라 할 만한 경험은 충분하다. 설령 낮은 티어일지라도.
† (또는 재수없게도, 2년 전 Copilot 쓰던 시절)
먼저 출발점부터 맞추자. 6개월 전에 코드용 LLM을 써보려고 하다 실패했다면, 지금 진지하게 LLM 보조로 코딩하는 사람들이 하는 일을 한 것이 아니다.
현재 LLM과 함께 코딩하는 사람들은 '에이전트'를 활용한다. 에이전트는 스스로 코드베이스를 살펴보고, 파일을 직접 작성하고, 빌드 도구를 돌리고, 코드를 컴파일하고, 테스트를 실행하고, 결과에 따라 반복한다. 또한:
실제 코드 작업을 "수행"하는 에이전트 내의 코드는 AI가 아니다. 이는 안심할 만하다. 신기하게도, 매우 단순한 시스템 코드다. Makefile처럼 프로그래밍의 현실을 연결한다. 효과적인 코딩 에이전트는 주말 동안에도 만들 수 있다. 진짜 강점은 "빌드⋅린트⋅테스트 하네스 구조화"를 어떻게 생각하고 다루느냐이지, o3나 Sonnet이 얼마나 고도화됐는지와는 무관하다.
ChatGPT 창에 뭔가 요청하고 그 결과(망가진 코드)를 에디터에 붙여 넣는 것? 그건 AI 붐을 외치는 사람들이 하는 방식이 아니다. 그럼 서로 대화가 어긋나는 건 당연하다.
LLM은 여러분이 평생 작성해야 할 지루한 코드의 상당 부분을 대신 쓸 수 있다. 그리고 거의 모든 프로젝트의 대부분 코드는 지루하다. LLM은 여러분이 구글링해야 할 내용을 대폭 줄여준다. 스스로 찾아본다. 중요한 건, LLM은 지치지 않는다; 관성에 면역이다.
만들고 싶었지만 못 만들었던 무언가를 떠올려보라. 첫 스텝을 잡으려 애썼다. 새 언어에 사랑에 빠진 상태였으면 코딩을 벌써 시작했을지 모른다. 하지만 아니었으니, 하루, 1년, 혹은 평생 미뤘다.
나는 새로운 프로젝트의 온갖 회계 처리, 구글링, 의존성 문제만 떠올려도 혈압이 오른다. LLM에게 이 모든 걸 알아서 하라고 지시할 수 있다. 실제로, LLM은 딱 "거의 다 돌아가는 지점"까지 뚝 떨어뜨려 준다. 개발자는 코드만 조금씩 만지면 곧바로 결과가 개선된다. 바로 그 도파민 때문에 코딩하는 것이다.
단점도 있다. 때로는 정말 귀찮고 복잡한 걸 해야 한다. 하지만 하고 싶지 않다. 그래서 유닛 테스트만 리팩터링하며 '진짜 일' 하고 있다고 스스로를 속인다. LLM은 그 모든 유닛 테스트를 리팩터하라고 딱 시킬 수 있다. 에이전트는 VM 안에서 몇 시간이고 테스트를 만지작거리다가 나중에 PR을 들고 나타난다. 내 말을 들으면 알겠지만, 이렇게 하면 '진짜 일'만 더 하게 된다.
코드 보는 법 모르는 유튜버인가? 코드를 못 읽나? 그렇다면 날카로운 지적. 아니면, 대체 뭐가 문제인가?
main에 머지하는 코드는 언제나 책임져왔잖아. 5년 전에도, 내일도 그렇다. LLM을 쓰든 안 쓰든 마찬가지다.
LLM과 뭔가를 만들었고 누군가가 그 위에 의존할 거라면? 코드를 읽어라. 실제로 더 하게 될 것이다. 5~10분 투자해서 자신의 스타일로 뜯어고치게 된다. LLM이 지역 스타일에 적응하기 시작하긴 했지만, 완전히 되진 않았다.
사람들은 LLM이 만든 코드를 '확률적'이라고 투덜댄다. 천만에. 그건 코드다. Yacc 출력물이 아니다. 파악 가능하다. LLM이야 확률적일 수 있지만, 중요한 건 LLM이 아니라 결과물이 이해 가능한가, 가드레일이 제대로 작동하는가이다.
남이 쓴 코드 읽기는 당연한 일이다. LLM이 낸 반복적인 지루한 코드를 소화 못한다면: 스킬 문제다! 인간이 마감 전에 내놓는 카오스를 어떻게 감당하려는가?
† (50~70kloc의 컨텍스트 윈도우 덕분에)
지난 한 달간 나는 Gemini 2.5를 주력으로 쓴다 †. LLM이 내놓는 그대로 머지되는 일은 거의 없다. 최신 모델로 피쳐+머지까지 원샷하는 스킬이 있겠지만, 난 신경 쓰지 않는다. 코드를 만지고, 바보 같은 주석 지우며 혼자 키득거리는 게 좋다. 어차피 줄 단위로 쭉 읽게 되어 있다.
헛소리가 문제라면, 그건 프로그래밍 언어의 문제다.
에이전트는 린트하고, 컴파일하고, 테스트를 돌린다. 만약 LLM이 근거 없는 함수 시그니처를 만들면, 에이전트가 오류를 본다. 그걸 LLM에 다시 넘기면 "아 맞다, 내가 지어낸 거구나" 하고 다시 시도한다.
이 과정은 에이전트가 남기는 코스 오브 쏘트 로그를 직접 볼 때만 존재를 자각한다. 보지 마라. 나는 Zed 에이전트 모드를 좋아한다. 유저가 딴 짓 하게 내버려두다가, 끝나면 알림을 준다.
아직도 헛소리가 중요한 환경은 있을 것이다. 하지만 "헛소리(hallucination)"는 누가 LLM 활용을 제안하면 반드시 나오는 첫 반론이다. 실제로는 (거의) 해결된 문제임에도 말이다.
인턴 한 명이 월 2만원이면 충분한가? Cursor.ai가 그 정도다.
시니어 개발자의 임무 중 하나는, 인간이든 대수적이든 더 못하는 개발자를 생산성 있게 만드는 것이다. 에이전트 잘 쓰는 것도 결국 프롬프트, 인덱스, 그리고 (특히) 툴링 등 자신만의 별도 엔지니어링 프로젝트다. LLM이 형편없는 코드를 낸다면, 당신이 그렇게 두는 것이다.
† (그리고 앞으로 직접 써야 할 Bash 코드는 전부 100% 이거다)
아마도 현재 혼란의 상당 부분은 누가 무슨 일을 하는 것이냐에 있다. LLM은 요즘 타이핑, 구글링, 테스트 케이스†, 에디트-컴파일-디버그 루틴을 많이 한다. 하지만, 세계에서 클로드 중독에 가장 심한 개발자조차, 여전히 큐레이션, 판단, 안내, 방향 제시는 스스로 한다.
솔직히 말하자, 인간의 첫 번째 완성본도 그리 훌륭하지 않다.
Brainfuck 툴체인 갖추는 것도 쉽지 않다. 인생은 얄루미늄 사이딩 업계 같이 고달프다.
† (그리고 아마 맞다; 러스트 커뮤니티는 툴링을 매우 중시한다)
LLM 회의론의 많은 부분은 사실 LLM 문제라기보다 사람의 투사(Projection)다. "LLM이 코드를 못 쓴다"는 말엔 사실 "LLM이 러스트 코드는 못 쓴다"는 의미가 담겨 있다. 타당하다! 사람들은 LLM이 잘 지원하는 언어에 맞춰 언어를 고른다. 러스트 개발자라면 그 쪽 지원을 강화하면 된다 †.
나는 주로 Go를 쓴다. Go 언어 설계자들이 업계에서 LLM이 가장 잘 읽는 언어를 목표로 했다곤 생각지 않는다. 그런데 실제로 그렇게 되었다. 적당한 타입 안전, 풍부한 표준 라이브러리, 반복적 관용적 코딩을 중시하는 문화. LLM이 생성하기에 최적이다.
덧붙이자면, 나도 러스트 좀 쓴다. 좋아한다. LLM과 러스트 조합이 안 맞는다면 이해한다. 하지만 그게 전부라면, 서로 같은 주장을 하는 게 아니다.
정교한 일본 목공예를 좋아하는가? 손도구와 사시모노 조인트? 나도 그렇다. 하지만 그건 취미다.
† (목공 덕후 친구들에 비하면 나는 하수다)
집 지하실에 기본적인 목공소가 있다 †. 테이블 하나 직접 만들 땐 만족감이 크다. 작업대나 그릴용 테이블이라면 내가 만든다. 하지만, 단순히 앉을 자리용 탁자가 필요하다면? 그냥 산다.
프로 소프트웨어 개발자는 사람들의 실질적 문제를 코드로 해결하는 게 본업이다. 우리는 직장에서 장인이 아니다. 스티브 잡스는 틀렸다. 조각의 안 보이는 밑바닥을 깎을 필요는 없다. 논리 보드 배선이 아름답게 돌려도 아무도 신경 안 쓴다. 우리가 만든 게 오래간다면, 그 코드베이스가 예뻐서가 아니다.
사실, 현실은 다르다. 함수를 꼭 깔끔하고 유려한 함수형 표현까지 다듬고 있다면, 의심부터 해야 한다. 잔업(yak-shaving)이다. 진짜 일은 집중을 소진시켰고, 지금 만드는 건 자가위안일 뿐이다.
그리고 바로 이런 거야말로 LLM이 잘하는 분야다. 온갖 허드렛일을 해치우고 진짜 중요한 판단과 가치에 집중할 길을 열어준다.
커리어 중∼후반에 오니, 평범함의 소중함을 알겠다. 꼭 필요할 때 거의 힘 안 들이고 틀어 쓸 수 있다면 얼마나 좋은가.
우리 모두는 평균적인 코드를 쓴다. 보통의 코드는 그 자체로 괜찮다. 모든 코드가 똑같이 중요하지 않다. 평균적인 코드도 필요한 부분이 있다. 무작위 유닛 테스트 하나에 최대치를 들인다? 뭔가 잘못된 거다. 팀 리드가 바로잡아야 한다.
개발자들은 코드 자랑에 진심이다. LLM이 "천장의 질"을 낮춘다고 걱정한다. 그럴 수 있다. 하지만 동시에 "바닥의 질"은 올린다.
Gemini의 바닥은 내 것보다 높다. 내 코드는 예쁘다. 하지만 그만큼 철저하지는 않다. LLM이 내놓는 코드는 반복적이다. 내가 만든 코드는, 너무 clever하게 DRY만 신경 쓰다 바보같은 꼬임도 있다.
모든 측면에서 LLM 코드가 평균적이지 않다. 알고리즘 트릭 가방이 인간보다 더 크다: radix 트라이, 위상정렬, 그래프 축소, LDPC 코드 등. 인간은 rsync를 낭만화한다(Andrew Tridgell도 논문 썼다!). LLM에겐 SQL join 만큼이나 별 일 아니다.
아무튼, 만에 하나 LLM이 늘 평범한 코드만 낸다고 해도, 그 자체로도 이미 크나큰 혁신이다. 인간이 써야 할 평균치 코드를 줄여주기 때문이다.
전혀 신경 안 쓴다.
똑똑한 실무자들은 AI/VC 언론 플레이에 속이 뒤틀린다. 이해 못 할 일도 아니다. 그러나 그건 논거가 아니다. 뭔가 효과가 있든 없든, Jensen Huang이 뭐라 해도 바뀌지 않는다.
오픈소스도 뺏어갔다. 예전엔 돈 주고 데이터베이스 샀다.
우리는 본질적으로 남의 일을 자동화하는 분야다. "생산성 향상"이라 부르는, 바로 그거다. 즉, 더 적은 인원이 동일한 일을 한다는 뜻이다. 여행사나, 증권 바닥 중개인, 음반가게 점원이나 암실 기술자와 최근에 얘기해본 적 있나?
이 논점이 나오면, 자유지상주의 VC가 오히려 "등불지기, 창의적 파괴, 새로운 일자리"를 외친다. 그럴 수도 있다. 하지만 나는 무감각하다. LLM 이후 우리가 더 나아질지 전혀 모른다. 오히려 더 나빠질 수도 있다.
LLM이 많은 소프트웨어 개발자를 대체할 가능성은 충분하다. 그건 우리가 잘난체할 일이 아니다. 지난 30년 기술이 사라뜨린 수많은 직업만큼, 우리의 직업도 그저 같은 위험에 노출되어 있을 뿐이다. 우리는 미국 동부 항만노동자가 아니다. 혼자서 진보의 시계를 멈출 순 없다.
인공지능은 시각예술가에게 어마어마하게 — 그리고 아마 부당하게 — 위협적이다. 예술계에 있지 않다면 실감하기 힘들다.
대부분은 예술가가 참신함을 추구하는 모습만 상상한다. 그러나, 미디어 커버나 박물관 전시, 모션그래픽, 게임 에셋 등 의뢰를 받아 쏟아내는 실무 작품이 평범하다.
LLM은 관련 업계 품질 기준을 어렵지 않게 — 심지어 너무나 손쉽게 — 넘는다. 인간 창작물과 충분히 비슷한 모작을 대량 양산하는 것이 가장 능하다. 내 가족 중에 시각 예술가가 있다. LLM 이야기를 꺼낼 수가 없다. 그들이 틀렸다고 생각하지 않는다.
한편 앞에서 말한 개발자들은 공공 리포지터리에서 가져온 듯한 코드 조각에 분개한다. 라이선스는 어떻게 할 거냐고? 변호사라면 말을 아낀다. 단, 소프트웨어 개발자가 이 카드라면? 이런 걱정은 그냥 집어넣기를 권유한다. 지적 재산권(IPR)에 가장 무심한 집단이 개발자다.
평범한 개발자에겐 스타워즈, Daft Punk 모두가 퍼블릭 도메인이다. 개발자의 주요 문화 활동은 어떤 식으로든 미디어 공유 사이트 운영에 불편한 저작권 보호 정책을 무시하는 것. 그러다 정책으로 막히면 편법으로 우회한다. TV 신작 상영 창 따위 지키려는 자를 비웃는다.
이걸 콕 집어 비판하면 누군가 나타나 LibreWolf에서 The Expanse 보는 게 얼마나 힘든지 TED토크 한판 해줄 것이다. 뻔하다. IPR 따위 안 믿는다. 그러면 LLM의 IPR에도 딴지 걸지 마라. 그대로 부메랑 될 뿐.
전부 궤변이다. LLM은 코드를 우리보다 더 깊이 소화한다. 활자체 디자이너가 글자 획 하나 하나에 도덕적 권리를 주장할 수 없다면, 빨강-검정 트리에도 집착하지 말라.
며칠 전 글을 쓰기 시작하며, LLM 보조 프로그래밍의 현주소를 설명하는 단락을 썼다. 하지만, LLM 기술은 블루피쉬살보다도 유통기한이 짧다. 이 글 읽는 사이에도, 모든 게 바뀌었다.
요즘 젊은 개발자들은 단순한 에이전트만 쓰지 않는다; 비동기 에이전트를 쓴다. 이들은 아침에 일어나는 즉시, LLM이 해야 할 13가지 일을 시키고 커피 마시고 TPS 리포트 쓰고 치즈 사러 갔다 온다. 그 사이 13개의 PR이 생긴다. 3개는 바로 버리고 재지시한다. 5개는 신입 개발자처럼 피드백 받고, 5개는 머지된다.
"지금 로켓연료에 빨대 꼽고 산다," 라는 친구가 있다. "AI에 올인하지 않는 팀 동료들은, 그냥 멈춰있는 것 같다" 라고 한다. 뻥이 아니다. 샌프란시스코베이 근처에서 일하는 것도 아니다. 거짓말할 이유가 없다.
물론 아직 LLM에 온전히 맡길 수는 없다. 운영 환경 접근권을 LLM에 주진 않는다. 하지만 내가 장애 조치 대응하다 4o — o4-mini가 아니라, 4o! — 에 로그 전문을 먹여봤더니, 우리 팀이 몇 달 째 골머리 앓던 LVM 메타데이터 손상 이슈를 즉석에서 찾아내기도 했다. 내가 오픈서치 로그, 허니콤 트레이스 추적을 LLM 에이전트보다 더 잘하냐? 결코 아니다.
내 친구들이 좌절하는 걸 보면, 나는 급진주의자도 아니고, 미래주의자도 아니다. 나는 합리적 통계주의자다. 복잡한 시스템과 제도, 평균회귀의 느릿함을 믿는다. Go랑 파이썬 코드를 쓴다. 쿨에이드 마시는 광신자는 아니다.
하지만 지금 뭔가 실제로 일어나고 있다. 가장 똑똑한 내 친구들이 무시해버리고 있다. 내가 당신을 설득할 수도, 못 할 수도 있다. 하지만 이젠 나쁜 논쟁거리엔 마침표를 찍을 때다.
여기서는 당신 의견에 동의한다. 나는 Simon Willison만 읽어도 충분하다. 그런데 하루 종일, HN(해커뉴스) 메인에 LLM 관련 소식이 산더미다: 사소한 모델 업데이트, LLM 스타트업, 튜토리얼, 그리고 LLM 비판까지. 피곤하다!
하지만 AI는 "믿기 힘들 정도로" 중요한 것도 사실이다. 2008년 스마트폰이 받던 주목만큼, 혹은 그 이하이지만 인터넷이 받았던 것과 비슷한 주목을 받고 있다. 그 정도면 딱 적당하다.
아마 1년 안에 더 뚜렷해질 것이다. "확률적 앵무새", "vibe coding" 같은 쿨한 척 비웃음은 현실과 자주 부딪히며 오래 못 갈 거다. 나는 이 사람들을 조롱하지만, 사실 그들이 나보다 똑똑하다는 것도 안다. 그들이 이런 허세기를 벗기면, 앞으로 코딩 에이전트는 지금보다 훨씬 강력해질 것이다.
