Gemini 2.5 PRO 같은 프론티어 LLM은 다양한 주제에 대한 방대한 이해도와 수천 줄의 코드를 단 몇 초 만에 파악하는 능력을 바탕으로 프로그래머의 역량을 확장하고 증폭시킬 수 있다. 문제를 명확하게 설명할 수 있고, LLM과 협업하는 데 필요한 끊임없는 대화를 기꺼이 받아들일 수 있다면 다음과 같은 놀라운 성과에 도달할 수 있다:

1. 사용자에게 도달하기 전에 코드에 직접 만든 버그를 제거하는 것: 나는 Redis의 Vector Sets 구현에서 이를 경험했다. 결국에는 모든 버그를 없앴겠지만, 상당수는 Gemini / Claude의 코드 리뷰 덕분에 즉시 제거됐다.
2. 특정 아이디어가 어떻게 동작할지 더 빠르게 탐색하는 것. LLM에게 일회용 코드를 작성하게 해 최대한 빨리 테스트함으로써 해당 솔루션이 실제로 더 빠른지, 충분히 좋은지 등을 확인하는 방식이다.
3. LLM 안에 인코딩된 박사급 지식과 자신의 직관, 경험, 설계 감각을 결합하는 페어 디자인 활동에 참여하는 것. 이 과정에서 LLM은 때로는 어리석은 경로를, 때로는 놀랍도록 훌륭한 아이디어를 제안한다. 인간인 당신의 역할은 국소 최적해와 실수에서 벗어나고, 당신의 디지털 친구가 어떤 인간보다도 더 많은 다양하고 특정한 지식을 갖고 있다는 사실을 활용하는 것이다.
4. 명확한 명세에 따라 코드의 일부를 작성하게 하여 작업을 가속하는 것.
5. 자신의 전문 분야에서 멀지만 인접한 기술(예를 들어 Amiga 데모를 위한 68000 어셈블리 코딩)을 LLM을 마음의 특정 부분을 확장하는 도구로 활용해 다루는 것. 자신이 갖지 못한 지식을 위해서다.

1년 반 전 나는 “LLMs and programming in the first days of 2024”라는 글을 썼다. 그때도 이미 LLM이 유용하다고 느꼈지만, 지난 1년 반 동안 이들이 이룬 발전은 완전히 판도를 바꿔 놓았다. 하지만 그 능력을 제대로 활용하려면 LLM과 상호작용하는 인간이 특정한 자질을 갖추고 특정한 관행을 따라야 한다. 이제 그에 대해 알아보자.

대부분의 경우 바이브 코딩을 거부하라

지금 이 시점에서 LLM은 훌륭한 증폭기이지만 형편없는 원맨밴드다. 테스트나 수백 줄짜리 작은 유틸리티처럼 LLM에게 모든 코드를 맡기는 게 말이 되는 작은 일회성 프로젝트는 여전히 있다. 하지만 (뒤에서 설명하겠지만) 엄격한 감독 하에 코드베이스의 일부를 작성하게 하고 개발 속도를 눈에 띄게 높이는 것 — 혹은 과거에 쓰던 같은 시간 안에 더 많이, 더 잘 개발하는 능력, 내가 하고 있는 방식이다 — 은 성공적으로 해낼 수 있는 반면, 만만치 않은 목표를 혼자 맡기면 필요 이상으로 크고 복잡하며 국소 최적해의 선택으로 가득하고 여러모로 차선인, 취약한 코드베이스를 만들어내는 경향이 있다. 게다가 당면한 작업이 일정 수준 이상으로 복잡해지면 그냥 완전히 실패해 버린다. 내일은 이 모든 게 달라질 수도 있지만, 지금 매일 LLM과 함께 코드를 작성한 경험에 비추어 볼 때 최고의 작업 품질은 인간+LLM이라는 공식으로 달성된다고 강하게 믿는다. 인간과 LLM이 함께할 때 인간만 있을 때보다 더 생산적이라고 믿지만, 여기에는 큰 전제가 하나 붙는다. 바로 그 인간이 뛰어난 소통 능력과 LLM 경험을 갖추었을 경우다. 효율적으로 소통하는 능력이 LLM을 활용하는 핵심 요소다.

충분한 컨텍스트를 제공하라

LLM과 함께 코드 구현이나 수정에 대해 고민하는 것이 목표라면 LLM에게 광범위한 정보를 제공해야 한다. 논문, 대상 코드베이스의 큰 부분(가능하다면 코드베이스 전체, 단 컨텍스트 윈도가 너무 커져 LLM 성능이 저하될 정도라면 제외), 그리고 해야 할 일에 대한 자신의 이해를 모두 쏟아낸 브레인 덤프가 그것이다. 그러한 브레인 덤프에는 특히 다음 내용이 포함되어야 한다:

• 좋아 보일 수 있지만 실제로는 좋지 않은 해결책에 대한 힌트와, 그것이 왜 차선일 수 있는지에 대한 설명.
• 인간이 아직 완전히 구체화하지 못했더라도 매우 유망해 보이는 잠재적 해결책에 대한 힌트. LLM은 종종 이를 활용해 올바른 경로를 찾을 수 있다.
• 무엇을 해야 하는지에 대한 명확한 목표, 우리가 요구하는 불변 조건, 심지어 코드가 가져야 할 스타일. 예를 들어 LLM은 불필요한 의존성으로 가득한 Python 코드를 작성하는 경향이 있지만 프롬프트를 통해 이 문제를 줄일 수 있다. 내 경험상 C 코드는 훨씬 더 나은 편이다.

그리 널리 알려지거나 자명하지 않은 특정 기술을 다룰 때는 문서 자체를 컨텍스트 윈도에 추가하는 것도 종종 좋은 생각이다. 예를 들어 LLM이 아직 알지 못할 정도로 새로운 Redis 자료구조인 vector sets에 대한 테스트를 작성할 때 나는 README 파일을 컨텍스트에 넣는다. 이런 사소한 트릭만으로도 LLM은 즉시 전문가 수준으로 vector sets를 다룰 수 있게 된다.

올바른 LLM을 사용하라

가장 유명한 LLM이 가장 좋은 LLM은 아니다. 코딩 작업은 주로 다음 모델들로 수행해야 한다:

• Gemini 2.5 PRO
• Claude Opus 4

내 경험상 Gemini 2.5 PRO는 의미론적으로 더 강력하다. 더 복잡한 버그를 찾아내고 더 복잡한 문제에 대해 추론할 수 있다. Claude Opus는 때로는 새로운 코드를 작성하는 데 더 뛰어날 수도 있고(그렇지 않을 때도 있다), 사용자 인터페이스가 더 쾌적하며, 일반적으로 복잡한 문제에서는 설계 공간에 대한 당신의(인간의) 이해를 넓히기 위해 최소 두 개의 LLM을 두고 서로 오가며 논의할 필요가 있다. 하나만 골라야 한다면 Gemini 2.5 PRO를 선택하라.

사용할 LLM에 대한 근본적인 요구사항은 다음과 같다. 에이전트나 코딩 에이전트가 통합된 에디터 같은 것은 사용하지 말라. 당신이 원하는 것은 다음과 같다:

• 항상 가장 유능한 모델, 즉 프론티어 LLM 자체에게 모든 것을 보여주는 것.
• LLM에게 코드/컨텍스트의 일부만 보여주는 모든 종류의 RAG를 피하는 것. 이는 LLM의 성능을 망가뜨린다. LLM이 답변을 생성할 때 무엇을 볼 수 있는지는 당신이 통제해야 한다.
• 터미널에서 LLM 웹 인터페이스로 코드를 직접 옮기며 항상 루프에 참여하는 것. 이는 당신이 모든 과정을 따라가고 있음을 보장한다. 당신은 여전히 코더이지만, 증강된 코더다.

결론

혼자 코딩할 수 있는 에이전트에 대한 관심이 크지만, 지금 당장은 LLM을 명시적인 방식으로 사용하고 루프 안에 머무름으로써 소프트웨어 개발자로서의 영향력을 극대화할 수 있다. AI가 발전함에 따라 이는 미래에 필연적으로 바뀔 것이고, 결국 많은 코딩 작업은 AI 혼자서 더 잘 수행하게 될 것이다. 그 미래에는 인간이 무엇을, 어떻게 만들지를 결정하게 되며, 이는 여전히 결정적으로 중요하다. 하지만 우리는 아직 그곳에 도달하지 않았다. 바로 지금 이 순간, 통제권을 쥐는 것이 LLM을 활용해 가능한 가장 날카로운 코드를 만들어내게 해준다. 필요할 때는 최소한으로, 요구될 때는 복잡한 아이디어를 활용하는 코드 말이다.

그 과정에서 많은 것을 배우면서(그렇다, 책이나 동료에게서 배우듯 LLM에게서도 배울 수 있다. 가능한 교육 형태 중 하나이자 새로운 형태다) 기존에는 자신의 지식과 전문성의 경계에 있던 일들도 해낼 수 있게 될 것이다. 그럼에도 만들어진 모든 결과물은 당신의 코드와 제품에 대한 구상을 따를 것이며 높은 품질을 유지하고 LLM이 도입한 오류와 결함 때문에 무작위로 실패하지 않을 것이다. 또한 작성된 모든 코드와 그 설계에 대해 강한 이해도를 유지하게 될 것이다.

가끔은 에이전트가 무엇을 할 수 있는지 시험해 보는 것이 현명하다. 하지만 그들이 당신만큼 잘하지 못한다고 느껴질 때마다 터미널로 돌아와 AI의 도움을 받아 코딩하라(그것이 당신의 결과물을 개선할 수 있다고 느껴질 때. 때로는 혼자 하는 것이 더 나을 때도 있다). 에이전트가 정말 훌륭한 작업을 해내는 시점이 오면, 내가 가장 먼저 전환할 것이고, 그때는 순수히 열정으로 혼자 코딩을 계속할 것이다. 하지만 지금은 과장된 기대를 접어두고 AI를 가장 잘 활용하자. 즉, 통제권을 유지하는 것이다. 그러나 또 다른 위험도 있다. 이념적 혹은 심리적인 거부감 때문에 LLM을 기피함으로써 불이익을 쌓고(그리고 LLM과 함께 일하는 데 필요한, 말로 설명하기 어려운 방대한 기술들을 익히지 못하는) 위험이다. 어쩌면 이는 정말로 “In medio stat virtus” — 중용에 미덕이 있다는 — 경우일지도 모른다.