LLM 시대에 프로그래밍의 즐거움 유지하기

거대 언어 모델(LLM)의 부상은 개발자들에게 역설적인 상황을 만들어냈습니다. 생산성은 향상될 수 있지만, 코드를 통해 생각을 표현하는 행위라는 프로그래밍의 본질적인 즐거움이 AI가 생성한 '쓰레기(slop)'를 검토하는 지루한 작업으로 대체되는 경우가 많기 때문입니다.

'바이브 코딩(Vibe Coding)'의 위험성과 기술 퇴화

LLM이 생성한 코드에 과도하게 의존하면 코드베이스와 프로그래머의 인지 능력 모두가 저하됩니다. 개발자가 직접 코드를 작성하는 것을 멈추고 에이전트가 전체 파일을 생성하도록 의존하게 되면, 인간이 읽기 어렵고 오직 다른 에이전트들만이 유지보수할 수 있는 'LLM 황무지'를 만들 위험이 있습니다.

코드베이스를 넘어선 인간의 비용은 기술 퇴화입니다. 커뮤니티 구성원들이 지적했듯이, 작은 프로젝트를 설계하거나 프로그래밍 언어로 깊이 있게 사고하는 능력은 LLM에 아웃소싱하는 순간 빠르게 사라질 수 있습니다.

"저 자신에게도 이런 일이 일어나는 것을 보았습니다. 갑자기 아주 작은 프로젝트의 아키텍처를 계획하는 데 어려움을 겪게 된 것이죠... Claude에게 여러 아이디어를 요청하고 제 경험을 바탕으로 최선의 것을 선택했을 때, 저는 바로 그 기술을 연습하고 있었던 것이었습니다. 처음부터 스스로 해결책을 생각해내는 기술을 연습하고 있었던 게 아니었죠." — @handle

지속 가능한 워크플로우: 인간 중심의 AI 지원

전문적인 성장과 개인적인 즐거움을 유지하기 위한 가장 효과적인 워크플로우는 함께 계획하되, 코딩은 혼자 하는 것입니다. 이 모델에서 LLM은 부수적이고 지루하며 반복적인 대량 작업을 처리하고, 인간은 구현에 대한 주도권을 유지합니다.

1. 계획 및 기록을 위한 LLM 활용

LLM에게 "이 기능을 만들어줘"라고 요청하는 대신, 자연어 기록 도구로 활용하세요.

• 도메인 전문가와의 대화를 실행 가능한 할 일 목록으로 변환합니다.
• 테스트 결과를 결함 수정을 위한 구조화된 계획으로 정리합니다.
• 컨텍스트 윈도우 손실을 방지하기 위해 계획 항목을 Markdown 파일로 추적합니다.

중요 규칙: LLM이 중요한 아키텍처 결정을 내리게 하지 마십시오. 결정 지점에 도달하면 반드시 당신에게 방향을 묻도록 강제하십시오.

2. 연구 및 탐색을 위한 LLM 활용

에이전트를 사용하여 정보를 수집하되, 그 결과를 절대적인 사실로 받아들이지 마십시오. AI 연구의 목표는 "Let Me Google That For You"와 같은 마찰을 제거하는 것이지, 개발자의 도메인 이해도를 대체하는 것이 아닙니다.

• 에이전트에게 리소스 링크를 제공하도록 요구하십시오.
• 이상한 제안은 에이전트에게 어떤 특정 리소스가 그 주장을 뒷받침하는지 물어 검증하십시오. 이는 종종 모델이 스스로 환각을 발견하도록 유도합니다.
• 검색 엔진과 병행하여 연구함으로써 에이전트만큼 혹은 그보다 더 잘 도메인을 이해하고 있는지 확인하십시오.

3. 주도적인 코더로서의 인간

"먼저 계획하고, 에이전트가 코딩하게 하라"는 유혹을 거부하십시오. 대신 LLM이 코드베이스를 조사하고 필요한 수정 지점을 식별하며 잠재적인 위험 요소를 경고하게 하되, 실제 코드는 당신이 작성하십시오. 이 접근 방식은 다음과 같은 이점을 제공합니다.

• 주도권: 코드베이스의 정확한 상태를 항상 파악할 수 있습니다.
• 조기 발견: 에이전트가 한 시간 동안 결함 있는 솔루션을 생성한 후가 아니라, 구현 단계에서 잘못된 계획을 인식할 수 있습니다.
• 기술 유지: 코딩 능력을 계속해서 연마할 수 있습니다.

자동화된 검토 주기 구현

품질을 보장하기 위해, 계획을 포함한 모든 LLM 생성 결과물은 자동화된 검토 주기 없이는 수락되어서는 안 됩니다. 이는 '생성자(generator)' 에이전트가 작업을 수행하고 '판별자(discriminator)' 에이전트가 이를 검토하는 생성적 적대 신경망(GAN)과 유사합니다.

이 주기는 특히 다음 상황에 유용합니다.

• 코드 리뷰: 별도의 에이전트를 사용하여 직접 작성한 코드에서 버그나 누락된 부분을 찾습니다.
• 계획 검증: 검토 에이전트를 사용하여 논리적 허점을 찾아냅니다(예: 7단계가 되어서야 작성되는 함수를 2단계에서 요구하는 계획).

기술적 및 정신적 제약 관리

토큰 소진 처리

토큰 제한은 구매 부족이 아니라 서비스 중단으로 간주해야 합니다. 작업이 중단되는 것을 방지하기 위해 오프라인에서 작업할 수 있는 구체적인 할 일 목록을 유지하십시오. 이를 통해 '테크노 봉건 영주(technofeudal lords)'들이 접근을 제한할 때도 독립적으로 가치를 창출할 수 있습니다.

'LLM 횡설수설' 피하기

LLM이 생성한 텍스트를 과도하게 소비하면 정신적으로 지칠 수 있습니다. 정신 건강을 보호하기 위해 원시 LLM 출력물의 소비를 제한하고, 높은 수준의 비전과 아키텍처 논의를 위해서는 인간 간의 소통을 우선시하십시오. 완전히 생성된 PR 본문을 동료에게 보내는 것은 도구의 출력물일 뿐 진정한 소통이 아니므로 피하십시오.

직업의 미래에 대한 관점

커뮤니티 토론은 개발자들이 코딩 자동화를 바라보는 방식에 깊은 분열이 있음을 보여줍니다.

• 취미주의자 관점: 프로그래밍이 전문직에서 대장장이나 악기 제작자와 같은 취미로 전환되고 있다고 주장합니다. 경제적으로는 비효율적일지라도 개인적으로는 충만함을 준다는 것입니다.
• 효율성 관점: 주된 목표는 비즈니스 문제를 해결하는 것이며, LLM이 그 과정을 가속화한다면 코드를 타이핑하는 '장인 정신'은 불필요한 감상적 애착일 뿐이라고 주장합니다.
• 하이브리드 관점: 일상적인 작업(특정 불변성을 가진 도메인 클래스 생성 등)에는 작고 빠른 모델을 사용하면서도, '에이전트 스웜'의 오버헤드를 피하기 위해 아키텍처의 고삐를 단단히 쥐는 방식으로 성공을 거두는 이들이 많습니다.