Vibes won't cut it — Chris Kelly (Augment)

AI-Assisted Engineering Talk #8/27

프로덕션 소프트웨어 엔지니어링은 코드 생성이 아니라 안전한 변경이옵니다. AI가 코드의 30%를 쓴다 해도, 거대 프로덕션 시스템에서 아키텍처와 인프라 결정은 이미 내려져 있어 자유도가 매우 좁습니다. Chris Kelly는 ‘AI-ready 코드베이스’의 5조건이 사실은 좋은 SE 위생과 같다는 것을 직접 시인하며, 코드 리뷰가 에이전트 시대의 핵심 역량이라는 도발을 던집니다.

핵심 주장

AI 종말론은 프로덕션 무경험에서 나온다

“내년 이맘때 우리 절반은 사라질 것” 같은 종말론은 거대 프로덕션 시스템을 다뤄본 적 없는 사람들의 추측이옵니다. Meta 엔지니어가 광고 플랫폼 버튼 하나에 6개월을 쓰는 이유—그것이 바로 실제 시스템의 복잡성이지요. 15년 전 DevOps·클라우드 전환 때도 동일한 종말론이 있었으나, sysadmin들은 더 가치 있는 일로 이동하며 임금이 올랐습니다. 트랙터는 농장을 없애지 않고 일의 형태를 바꿨을 뿐이옵니다.

코드는 산출물, 결정이 직업이다

건축가의 직업이 청사진 그리기가 아니듯, SE의 직업은 코드 생성이 아니라 수천 개의 결정이옵니다. “어떤 소프트웨어를 만들지, 어떤 패키지를 가져올지”—이 결정의 craft가 엔지니어의 본질이며, LLM이 코드 생성에 능하다는 사실과 SE가 결정에 능하다는 사실은 다른 차원이옵니다. Jeff Atwood의 “가장 좋은 코드는 코드 없음"이 말해주듯, ‘AI가 X% 코드를 썼다’는 자랑이 아니라 부채 증가율이옵니다.

LLM은 결정하지 않는다, 패턴만 생성할 뿐이다

“LLMs don’t make decisions. They generate text. They generate patterns.” 어느 규모를 넘어가면 시스템에 패턴이 없어집니다—Bob만 아는 idiosyncrasy, Jane이 6년 전 작성하고 떠난 모듈. 모든 프로덕션에는 이런 snowflake가 존재하며, 패턴 매칭은 거기서 멈춥니다. 결정은 인간이 해야 하옵니다.

AI-ready 코드베이스는 SE 위생과 같다

Chris의 처방: 문서화된 표준, 재현 가능한 개발 환경, 빠른 로컬 테스트, 명확한 경계, 명확하게 정의된 태스크. 그가 직접 인정합니다—“이건 그냥 좋은 SE처럼 들린다.” AI 도입의 진짜 전제는 새 도구가 아니라 위생이며, 위생이 부족한 팀은 AI 도구를 사도 결과가 나오지 않습니다.

컨텍스트가 AI 코드 생성의 1순위다

“At Augment we believe that context is like the most important part of all AI generation in code.” 모델 품질이 아니라 코드베이스에 대한 정확한 이해가 출력 품질을 결정합니다. 사람이 막히는 환경에서는 AI도 막힌다는 사실을 받아들여야 하며, 별도의 AI용 워크플로우를 만들 것이 아니라 인간 엔지니어에게 좋은 환경이 곧 AI에게도 좋은 환경이옵니다.

““The best code is no code at all.” Jeff Atwood — Chris Kelly가 인용하며, AI가 많이 생성할수록 시스템이 나빠진다는 역설을 강조” ## 두 세계의 대비

결과 동작만 보고 진행

AI가 모든 코드를 쓰도록 두고, 출력이 동작하는지만 확인합니다. 코드 자체를 보지 않고 검토·편집을 생략합니다. 검증을 “결과 동작"이라는 단일 채널에 의존시키는 방식이옵니다.

다축 검증 표면

99.99% 가용성, 수천 사용자, 기가바이트 데이터. 코드의 미묘한 결정 하나가 사고로 직결됩니다. 새벽 2시 장애에서 vibes는 버그를 진단하지 못합니다—누군가 코드를 읽어야 하옵니다.

AI 시대의 엔지니어링 실천

코드 리뷰 = 핵심 역량

에이전트가 더 많은 코드를 쓰는 미래에, “남의 코드를 읽고 좋은지 나쁜지 말하는 능력"이 SE의 핵심 역량이 됩니다. leetcode는 LLM이 잘하는 영역이고, 코드 리뷰는 LLM이 못하는 검증 영역이옵니다.

Rules 파일 + Plan Markdown

프로젝트 시작 시 stack·가이드라인을 적은 rules 파일을 만들어 항상 컨텍스트에 첨부합니다. LLM에게 markdown plan을 쓰게 하고 직접 편집한 뒤 다시 컨텍스트로 두고 agent를 돌리는 Create→Refine 루프이옵니다.

“다름"과 “나쁨"을 분리

LLM이 내가 쓰지 않을 스타일로 코드를 쓴다고 해서 나쁜 코드는 아닙니다. 동료도 다르게 씁니다. 스타일 교정은 linter·rule system에게 맡기고, 검토자는 “기능이 옳은가"에 집중합니다.

인간과 같은 도구를 AI에게도

AI는 정확히 같은 일(코드 작성)을 하므로 인간과 같은 도구가 필요합니다. “한 번에 완벽한 코드” 기대는 인간에게도 비현실적이며, 테스트·린터·반복은 AI에게도 동일하게 필요합니다.

리뷰 도구의 혁신이 급하다

현재 코드 리뷰 도구는 “파일 A 변경, 파일 B 변경"을 알파벳 순으로 보여줄 뿐입니다. 변경의 의미적 그룹·논리적 흐름을 보여주지 못합니다. Chris의 직설: “frankly suck.”

““AI talks like a human but is actually a machine.” Chris Kelly — LLM이 “파일을 스캔했다"고 사과하는 것은 학습된 의인화 텍스트일 뿐, 실제 동작이 아님을 경고” ## 검증된 인사이트

💡 [Insight 1] 코드 리뷰 도구 부재가 에이전트 자율성의 율속(律速)이다

Chris가 “코드 리뷰 도구는 frankly suck"라고 지적한 현실과 ‘자율성 ≡ 검증 표면의 함수’라는 누적 명제를 결합하면: 에이전트가 더 많은 코드를 쓰는 미래에 코드 리뷰 도구가 의미적 그룹·논리적 흐름을 보여주지 못한다면, 검증 표면이 자율성 수요를 따라가지 못해 광폭 자율성을 접는 압력이 되돌아옵니다. 즉 코드 리뷰 도구의 설계 수준이 이 시대 SE 투자 우선순위 1순위가 되어야 하며, 그 이전에는 ‘더 자율적인 에이전트’가 아니라 ‘더 좋은 검증 표면’이 지렛대가 되옵니다.

💡 [Insight 2] AI 도입 ROI는 SE 위생을 초과하지 못한다

Chris의 자발적 시인(“AI-ready 5조건은 그냥 SE처럼 들린다”)과 Microsoft Collaborating with Agents의 ‘환경 청결성 ↔ ROI: R²≈0.40’ 데이터를 결합하면: AI 도구가 만들어낼 수 있는 효과의 상한은 팀의 위생 수준으로 제약됩니다. 위생이 낮은 팀이 AI를 먼저 도입하는 것은 우선순위 역전이옵니다. 표준·재현 환경·테스트 자동화 투자가 AI 도구 투자보다 먼저여야 도구 투자가 돌아옵니다. AI 자체가 위생을 만들 수도 있으나, 그 수준도 ‘검증 표면 부재 시 음 ROI’가 설정한 천장에 갇힙니다. ## 다른 영상과의 교차점

• Factor 3 ‘컨텍스트 윈도우 직접 소유’와 Chris의 “컨텍스트가 AI 코드 생성의 1순위” 명제가 직접 결합됩니다. Augment가 회사 차원에서 같은 명제를 실무 확언한 것으로, ‘context engineering’ 카테고리 명명의 근거이옵니다.
• 같은 Augment에서 나온 두 강연입니다. 영상 3의 ‘코드베이스는 텍스트가 아니다’, ‘Chat=가설/Agent=검증’ 명제를 Chris는 “LLM은 패턴만 생성하고, snowflake는 패턴 매칭으로 해결되지 않는다"로 한 단계 더 구체화합니다. 일관된 진화이지 모순은 없습니다.
• Scarlett의 의인화 비판과 Chris의 의인화 트랩 경고가 만납니다. LLM이 “파일을 스캔했다"고 사과하는 학습된 마스킹은, Scarlett이 말한 “라벨이 곧 멘탈 모델"의 실제 동작 예시이옵니다. 출력 텍스트와 실제 동작을 분리해 의심하라는 두 강연의 결론은 동일합니다.
• Microsoft의 환경 청결성-ROI 상관관계(R²≈0.40)는 Chris의 “AI-ready = SE 위생” 명제에 정량적 뒷받침을 제공합니다. 위생이 없으면 AI 도구가 ROI를 만들지 못한다는 동일한 결론을 양쪽이 독립적으로 도달한 것이옵니다.
• ‘검증 표면 부재 시 AI 자율성은 음의 ROI’라는 인사이트에, Chris는 코드 리뷰 도구의 구체적 한계(“lex 정렬 file diff”)를 지적하여 검증 표면이 왜 부재한지를 도구 설계 수준에서 설명합니다.

가장 좋은 코드는 코드 없음이옵니다. AI가 더 많은 코드를 생성할수록, 정작 엔지니어에게 필요한 역량은 코드를 쓰는 것이 아니라—코드를 읽고 판단하는 것으로 옮겨가고 있습니다.