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

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

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 성능이 저하될 정도라면 제외해야 합니다), 그리고 해야 할 일에 대한 자신의 이해를 모조리 쏟아낸 브레인덤프가 그것입니다. 이러한 브레인덤프에는 특히 다음 내용이 담겨야 합니다.

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

그리 널리 알려지지 않았거나 자명하지 않은 특정 기술을 다룰 때는 문서 자체를 컨텍스트 윈도에 함께 넣는 것이 좋은 방법인 경우가 많습니다. 예를 들어 LLM이 아직 알지 못할 만큼 새로운 Redis 자료구조인 vector sets의 테스트를 작성할 때 저는 README 파일을 컨텍스트에 추가합니다. 이처럼 사소한 방법만으로도 LLM은 즉시 전문가 수준으로 vector sets를 다룰 수 있게 됩니다.

올바른 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가 결과물을 개선할 수 있다고 느낄 때만. 때로는 혼자 하는 것이 더 나을 때도 있습니다). 에이전트가 정말로 훌륭한 작업을 수행하게 되는 날이 오면, 제가 가장 먼저 전환할 것이고, 그때는 순전히 열정 때문에 혼자 코딩을 계속할 것입니다. 하지만 지금은 과장된 기대를 접어두고 AI를 가장 잘 활용해야 합니다. 즉, 주도권을 유지하는 것입니다. 그러나 또 다른 위험도 있습니다. 이념적 혹은 심리적인 거부감 때문에 LLM을 기피하다가 불이익을 쌓고, (말로 설명하기 어려운) LLM과 함께 일하는 데 필요한 광범위한 기술을 익히지 못하는 위험 말입니다. 아마도 이는 정말이지 "In medio stat virtus"(미덕은 중용에 있다)에 해당하는 경우일 것입니다.