코드 안 읽고 수만 줄 개발하는 법
코딩의 시대는 가고 '메이킹'의 시대가 왔다: LLM으로 수만 줄의 코드를 관리하는 법
"코딩 공부, 지금이라도 시작해야 할까요?"
출처: https://www.stavros.io/posts/how-i-write-software-with-llms/
실리콘밸리뿐만 아니라 전 세계 엔지니어링 커뮤니티에서 가장 많이 들리는 질문 중 하나입니다. 하지만 아키텍트의 관점에서 답하자면, 질문의 프레임부터 바뀌어야 합니다. 이제 우리는 '코드를 어떻게 작성할 것인가'가 아니라, '시스템을 어떻게 설계하고 통제할 것인가'를 고민해야 하는 시대에 살고 있습니다.
전통적인 코딩의 장벽은 무너졌습니다. 이제 LLM은 단순한 자동 완성 도구를 넘어, 수만 줄의 코드베이스를 함께 빌드하는 협업 파트너가 되었습니다. 엔지니어링 스킬이 사라진 것이 아니라, 더 높은 차원의 '설계 능력'으로 이동한 현재의 패러다임 전환과 그 구체적인 실천 전략을 공유합니다.
--------------------------------------------------------------------------------
1. 코딩 실력보다 '아키텍처 설계'가 훨씬 더 중요해진 이유
흔히 AI가 코드를 짜주니 엔지니어링 스킬이 무용지물이라 생각하기 쉽지만, 현실은 정반대입니다. 개별 코드 라인의 문법을 검토하던 에너지는 이제 전체 시스템의 구조를 판단하고 기술적 결정을 내리는 역량으로 전이되었습니다.
초기 LLM(davinci 모델 등) 시절에는 인간이 모든 코드 라인을 검토해야 했습니다. 하지만 현재의 Opus 4.6 수준에 이르러서는 함수 단위를 넘어 '전체 아키텍처 수준'에서의 검증만으로도 충분해졌습니다. 여기서 핵심은 **'잘못된 선택의 누적'**을 방지하는 것입니다. 특히 자신이 잘 모르는 도메인(예: 백엔드 개발자가 모바일 앱에 도전할 때)에서 아키텍처 가이드 없이 LLM에만 의존하면, 초기에는 빠른 결과물이 나오는 듯 보이나 결국 유지보수가 불가능한 **기술 부채(Technical Debt)**의 늪에 빠지게 됩니다.
"코드 작성 능력보다 시스템 아키텍처 설계와 올바른 선택을 내리는 엔지니어링 스킬이 훨씬 더 중요해짐"
결국 엔지니어링이란 초기 단계에서 발생하는 '나쁜 결정의 복리 이자'를 줄이는 과정입니다. 아키텍처를 장악하고 있다면 수만 SLoC(Source Lines of Code)의 복잡한 시스템도 낮은 결함률로 안정적으로 성장시킬 수 있습니다.
--------------------------------------------------------------------------------
2. 아키텍트-개발자-리뷰어: 모델을 '팀'으로 운영하는 다중 에이전트 워크플로우
하나의 모델에게 설계부터 구현, 검증까지 모두 맡기는 것은 위험합니다. 이는 모델 특유의 '자기 동의 경향(Self-agreement bias)' 때문입니다. 자신이 쓴 코드의 오류를 스스로 발견하기는 극히 어렵습니다. 따라서 실무에서는 모델을 아키텍트, 개발자, 리뷰어라는 세 가지 페르소나로 분리하여 다중 에이전트 체계를 구축해야 합니다.
- 아키텍트(Architect): 인간과 대화하며 시스템의 추상화 계층(Abstraction Layers)을 설계하고 전체적인 구현 로드맵을 수립합니다.
- 개발자(Developer): 아키텍트가 확정한 계획에 따라 엄격하게 코드 변경사항을 구현합니다.
- 리뷰어(Reviewer): 구현된 코드가 설계 의도에 부합하는지, 잠재적 결함은 없는지 독립적인 시각에서 비평합니다.
이러한 역할 및 권한의 분리는 결함률을 획기적으로 낮춥니다. 리뷰어 간에 의견이 불일치할 경우 아키텍트에게 에스컬레이션(Escalation)하여 최종 의사결정을 내리는 구조는 실제 실리콘밸리 소프트웨어 팀의 운영 방식과 매우 닮아 있습니다.
--------------------------------------------------------------------------------
3. 비싼 모델은 '계획'에, 가벼운 모델은 '구현'에: 모델 믹싱 전략
많은 개발자가 성능이 가장 좋은 모델을 코딩(구현)에 투입하곤 합니다. 하지만 소스 컨텍스트와 아키텍처의 논리는 다릅니다. 가장 비싼 '컴퓨트 자원'은 추론과 설계(Reasoning over system state)에 집중시켜야 합니다.
- Claude Opus 4.6 (아키텍트): 가장 높은 지능을 가진 모델을 아키텍트로 배치합니다. 인간과 약 30분간 딥다이브 대화를 나누며 파일 및 함수 레벨의 **상세 저수준 계획(Low-level plan)**을 수립하는 데 사용합니다.
- Claude Sonnet 4.6 (개발자): 계획이 명확하게 수립되었다면, 단순 구문 생성(Syntax generation)은 가성비가 좋은 모델에게 맡겨 토큰을 절약합니다.
- Codex 5.4 / Gemini (리뷰어): Codex 5.4처럼 꼼꼼하고 까다로운 모델을 리뷰어로 활용하여 Opus가 놓칠 수 있는 엣지 케이스를 잡아냅니다.
단순히 '똑똑한 모델' 하나를 쓰는 것보다, 각 모델의 강점을 믹싱하여 시스템의 상태 관리(State Management)를 지능적으로 제어하는 것이 진정한 아키텍트의 실력입니다.
--------------------------------------------------------------------------------
4. '승인(Approved)' 없이는 코딩 금지: 인간 주도의 철저한 제어
LLM 협업의 전형적인 실패 패턴은 모델이 문제를 이해했다고 착각하여 성급하게 코드를 수정하기 시작하고, 오류가 발생하면 "알겠습니다! 고치겠습니다"를 반복하며 시스템을 더 망가뜨리는 것입니다. 이를 방지하기 위한 두 가지 엄격한 통제 장치가 필요합니다.
첫째, 명시적 승인 단계입니다. 아키텍트 모델이 목표, 제약, 트레이드오프를 정리한 계획을 내놓았을 때, 인간이 **"Approved"**라고 확언하기 전까지는 절대로 구현에 착수하지 못하게 해야 합니다. 이 30분의 설계 대화가 프로젝트의 성패를 좌우합니다.
둘째, 수동 스킬 파일(Manual Skill File) 설정입니다. 하네스(Harness) 도구 내에서 에이전트의 지침을 LLM에게 스스로 쓰게 해서는 안 됩니다.
"LLM에게 스킬을 쓰게 하면, 누군가에게 '훌륭한 엔지니어가 되는 법'을 쓰게 한 뒤 그 지침을 돌려주며 '이제 훌륭해져라'라고 하는 것과 같음"
인간 아키텍트가 직접 엔지니어링 표준을 수작업으로 설정하고 가이드라인을 이식해야만, LLM이 자신의 한계 내에서 적당히 타협하는 것을 막고 높은 수준의 코드 퀄리티를 유지할 수 있습니다.
--------------------------------------------------------------------------------
5. 수천 개의 작은 불편을 해결하는 '나만의 AI 비서' 만들기
이 방법론을 통해 탄생한 실제 프로젝트들은 단순한 장난감이 아닙니다. 고도의 기술적 의사결정이 녹아 있는 실제 서비스들입니다.
- Stavrobot: 단순한 봇을 넘어 MIME 파싱과 SMTP 클라이언트를 결합한 지능형 비서입니다. 특히 @경계를 넘지 못하게 하는 정규식([^@]*)을 적용한 '와일드카드 이메일 화이트리스트' 설계는 보안과 편의성을 동시에 잡은 아키텍처적 결단이었습니다.
- Middle: 음성 메모를 웹훅으로 전송하는 하드웨어 연동 프로젝트로, 복잡한 통신 규약을 LLM과 함께 정의했습니다.
- Sleight of Hand: 초 단위로는 불규칙(500ms~1500ms 가변 틱)하지만 분 단위로는 정확한 예술적 벽시계입니다. 인간이 직접 구현하려면 매우 번거로운 '변동 로직'을 아키텍처 설계만으로 완성했습니다.
저자는 고백합니다. "대부분의 코드를 직접 읽은 적이 없지만, 내부 작동 방식과 아키텍처는 완벽하게 알고 있다." 이것이 바로 현대의 '소프트웨어 마스터리'에 대한 새로운 정의입니다.
--------------------------------------------------------------------------------
결론: 생산성의 새로운 정의와 우리에게 던져진 질문
이제 기술은 거창한 '유니콘 앱'을 개발하는 수단을 넘어, 개인의 삶에 존재하는 수천 개의 작은 불편함을 즉시 해결하는 커스텀 자산이 되었습니다. 수만 줄의 코드를 직접 타이핑할 필요는 없습니다. 하지만 그 코드들이 어떤 논리로 흐르는지, 어떤 아키텍처 위에 서 있는지 결정하는 것은 여전히 인간의 몫입니다.
기술적 진입 장벽이 낮아진 지금, 우리에게 남은 유일한 질문은 이것입니다.
"당신이 가진 수천 개의 소소한 불편함 중, 오늘 당장 LLM 아키텍트와 대화하며 해결하고 싶은 첫 번째 문제는 무엇인가요?"