LLM 시대에도 프로그래밍을 계속 즐기는 법

코딩은 사람이 맡고, LLM에는 계획 정리, 조사, 검토 등 주변 작업을 맡기는 방식으로 프로그래밍의 즐거움과 적당한 생산성 향상을 함께 추구할 수 있음 코드베이스에 대한 이해와 주도권을 유지하려면 직접 코드를 계속 작성해야 함. 모든 구현을 에이전트에 넘기면 코딩 실력이 약해지고, 생성된 코드에서 문제를 찾기도 어려워짐 LLM과 함께 계획하되 중요한 결정은 직접 내리고, 조사도 병행해야 함. 에이전트에는 판단 대신 다음 작업과 수정할 위치, 주의점, 관련 자료를 준비하게 함 생성된 코드뿐 아니라 계획에도 자동 검토 주기를 적용하고, 코딩 위임은 정리 작업이나 위험이 낮은 리팩터링에 제한하는 편을 권함 토큰 소진에도 계속 일할 수 있는 작업 목록을 남겨야 함. 생성 텍스트의 과도한 소비를 피하고, PR 등 사람 사이의 소통은 직접 작성하는 편을 권함 프로그래밍의 즐거움과 주도권 지키기 AI 번아웃, 일자리 상실에 대한 불안, 프로젝트와 자신의 코드 품질에 대한 실망 속에서도 프로그래밍을 즐길 방법이 필요함 대형 기술 기업의 최첨단 LLM에는 중대하고 정당한 윤리적 우려가 있지만, 여기서 다루는 범위는 일하는 방식임 Sean Mcmullen의 소설 Souls in the Great Machine에서는 사람들이 부품으로 참여해 거대한 계산 장치를 구성함 컴퓨터 위에서 인간이나 초인처럼 행동하는 LLM은 겉으로는 반대처럼 보이지만, 개발자가 소프트웨어 제작의 주체에서 기계의 톱니바퀴로 밀려난다는 점에서는 닮아 있음 명세를 받아 LLM에 입력하고, 공급자가 줄인 토큰 할당량에 매달리는 작업 방식은 피하고 싶은 미래임 Haskell로 생각을 표현하는 과정 자체가 즐거움의 원천일 수 있으며, 코드 생성은 그 즐거움을 위협할 수 있음 언어마다 이런 즐거움의 정도가 다르다는 가정은 언어별 애호가들이 LLM 보조 개발의 미래를 다르게 보는 이유를 일부 설명할 수 있음 목표는 생산성이 크게 오른 것처럼 보이면서 즐거움을 잃는 것이 아니라, 직접 코딩하는 즐거움을 유지하며 생산성을 적당히 높이는 것임 LLM을 전혀 쓰지 않는 선택도 괜찮음 실제 생산성 향상이 필요하거나 팀, 회사, 업계의 LLM 도입 흐름에서 뒤처지고 싶지 않다면 다른 활용법을 찾을 수 있음 코드를 계속 직접 작성해야 하는 이유 코드베이스의 주도권을 지키려면 적어도 일부 코드는 직접 작성해야 함 모든 코드를 생성하게 두면 결국 코딩 에이전트만 다루기 편한 코드베이...