▲

"외과의사"처럼 코딩하기

 (geoffreylitt.com)
3P by GN⁺ 7시간전 | ★ favorite | 댓글 1개
  • 인공지능이 개발자를 ‘관리자’나 ‘편집자’로 만든다는 통념에 반해, 저자는 ‘외과의처럼 코딩하기’ 라는 접근을 제안하며 핵심 작업에 집중하는 방식을 강조
  • 외과의가 보조 인력의 지원을 받아 수술의 핵심 부분에만 집중하듯, AI 도구를 통해 부수적 업무를 위임하고 개발자는 본질적 문제 해결에 전념
  • 주요 작업(예: UI 프로토타이핑)은 여전히 사람이 직접 수행하지만, 문서 작성·버그 수정·코드 탐색 등 반복 업무는 AI 에이전트가 처리
  • AI에게 단순 반복 작업을 맡김으로써 지위 계층 문제 없이 grunt work를 위임할 수 있고, 24시간 가용성 덕분에 심야나 점심시간에도 작업 지시 가능
  • 이러한 방식은 Andrej Karpathy의 ‘autonomy slider’ 개념과 연결되며, 작업의 자율성 수준에 따라 AI 활용 전략이 달라져야 함을 시사

외과의처럼 코딩하기: 핵심 개념

  • AI가 개발자를 매니저나 편집자로 만들 것이라는 일반적 예측에 반대하며, 외과의사(Surgeon) 처럼 일하는 방식을 제안
    • 외과의사는 직접 수술을 하지만, 지원팀의 도움으로 준비 작업과 부차적 업무를 처리받아 고유한 전문성이 필요한 핵심 작업에만 집중
    • 개발자도 AI를 보조 인력처럼 활용해 핵심 창의적 작업에 집중할 수 있음
  • 저자는 UI 프로토타이퍼로서 AI 도구를 활용해 의미 있는 작업에 100%의 시간을 투자하는 것을 목표로 함
    • AI가 처리할 수 있는 부수 업무를 위임함으로써 생산성 극대화

AI에게 위임 가능한 부수 업무들

  • AI가 충분히 수행 가능한 보조적 작업 목록들
    • 대규모 변경 전 코드베이스 관련 가이드 작성
    • 큰 변경 시도에 대한 ‘스파이크(spike)’ 코드 초안 생성
    • 명확한 사양이 있는 TypeScript 오류나 버그 수정
    • 현재 개발 중인 기능에 대한 문서 작성
  • 이러한 작업은 비동기적으로 백그라운드에서 실행 가능
    • 점심시간이나 야간에도 AI가 작업을 진행, 다음날 바로 검토 가능
  • 이를 통해 “준비된 수술실에 들어서는 외과의”처럼, 모든 준비가 끝난 상태에서 핵심 코딩에 집중할 수 있음

자율성 슬라이더(Mind the autonomy slider)

  • AI 활용 방식은 핵심 작업과 보조 작업 간에 큰 차이가 있음
    • 핵심 디자인·프로토타이핑은 여전히 사람이 직접 수행하며, 빠른 피드백 루프와 높은 가시성이 중요
    • 반면 부수 작업은 AI에게 장시간 자율적으로 맡기는 방식이 효율적
  • 장시간 무감독 세션에는 Claude Code를, 최근에는 Codex CLI를 선호함
  • 이러한 차이는 Andrej Karpathy의 ‘autonomy slider’ 개념과 유사
    • 자율성 수준에 따라 필요한 도구와 사고방식이 달라지며, 이를 혼동하는 것은 위험함

AI와 ‘소프트웨어 외과의 팀’ 개념

  • "소프트웨어 외과의사" 개념은 1975년 Fred Brooks의 "『The Mythical Man-Month』" 에서 Harlan Mills가 제안한 오래된 아이디어
    • 한 명의 ‘chief programmer’ 가 중심이 되어, ‘copilot’과 관리 인력이 지원하는 구조
  • 과거에는 이 보조 역할을 사람이 맡았지만, AI가 이를 경제적으로 실현 가능한 형태로 대체
  • 저자는 이 변화가 단순한 비용 절감 이상의 의미를 가진다고 지적
    • 지위 위계(status hierarchy) 문제를 완화함
    • 반복적이고 지루한 ‘grunt work’를 AI에게 위임함으로써, 팀 내 불균형한 업무 분배 문제 해소
  • AI는 24시간 가용하므로, 사람 인턴에게는 불가능한 야간 연구나 코드 분석 작업도 수행 가능

Notion과 ‘외과의처럼 일하기’의 확장

  • 저자는 자신이 근무 중인 Notion에서 이러한 접근이 실제로 구현되고 있다고 설명
    • 회사 차원에서 AI 코딩 도구 사용을 적극 지원하며, 코드베이스도 이에 맞게 설계
    • 특히 대규모 코드베이스에 새로 합류한 개발자에게 생산성 향상 효과가 큼
  • 제품 측면에서도 Notion은 프로그래머를 넘어 모든 지식 노동자에게 ‘외과의처럼 일하는 방식’을 확산하려 함
    • 핵심 목표는 핵심 업무를 위임하는 것이 아니라, 중요하지 않은 부수적 반복 업무를 식별·위임하여 가장 중요한 일에 집중하도록 돕는 것
▲
GN⁺ 7시간전  [-]
Hacker News 의견

  • 초보 외과의가 간호사나 마취과 의사가 실수를 막아줄 거라 믿고 수술을 시작하면 환자를 금세 죽일 수 있음
    수술팀이 필요하다고 해서 선임 외과의의 훈련이 불필요한 건 아님
    경험 없는 외과의가 “간호사가 메스를 건네주니까 굳이 배울 필요 없다”고 생각하는 게 문제임
    결국 환자를 희생시키며 배워야 한다면 그렇게 하겠지만, 그렇지 않다면 먼저 의대에 가야 함

    • 글쓴이가 자신을 “UI 프로토타이퍼이자 디자인 콘셉트를 만지는 사람”이라 밝히고, 동시에 AI 코딩 소프트웨어 회사에서 일한다고 함
      그래서 글 전반에 Dunning-Kruger 효과가 느껴짐(자신의 능력이 부족한 사람이 오히려 자신의 능력을 실제보다 훨씬 높게 평가하는 인지 편향)

  • 나는 오래전부터 소프트웨어 엔지니어라면 The Mythical Man-Month를 읽어야 한다고 주장해왔음
    최근 25년간 워터폴에서 애자일로의 전환처럼 개발 방식이 급격히 바뀌었음
    하지만 LLM 기반 개발(Codex, Claude Code 등)을 하다 보면 오히려 70~80년대식 개발 패턴으로 돌아가는 느낌임
    지금은 마치 대성당을 설계하듯 구조를 고민할 수 있고, 세부 구현은 위임할 수 있게 되었음

    • Brooks의 비유 중 수술팀 모델은 틀린 부분이 있음
      수술은 한 번에 한 사람만 작업하지만, 소프트웨어는 동시에 여러 사람이 손댈 수 있음
      오히려 스포츠 팀에 가깝고, 우리는 연습이나 코칭이 부족해서 완성도에 시간이 걸림
    • 70~80년대식 접근과 지금의 차이를 더 듣고 싶다는 질문이 있었음
    • 지금은 소프트웨어용 CAD, 즉 CASE(Computer Aided Software Engineering) 시대에 가까움
      코딩보다 설계에 집중할 수 있게 되었음
    • “대성당을 짓는 것처럼 설계만 하고 세부는 위임한다”는 말에 반박함
      실제로 고층 건물을 짓는다면 철강의 품질과 볼트의 출처까지 신경 써야 함
      그런 걸 무시하면 위험함

  • 이 비유는 문자적으로나 은유적으로나 잘못됨
    외과의는 단순히 일꾼이 아니라 수술 전체를 관리하는 관리자이며, 실제로는 마취과 의사가 가장 중요함
    또한 “단순 노동(grunt work)”이라는 개념 자체가 잘못된 시각임
    자신을 외과의로, 다른 사람을 보조 인력으로 보는 태도는 자기중심적 관점임

    • 상대는 Fred Brooks의 비유를 인용한 것이라 설명함
      Brooks의 “Chief Programmer” 개념처럼, 수석 개발자는 팀의 지원 덕분에 일할 수 있음
      글쓴이는 주니어를 단순한 하급 인력이 아니라 멘티로 보고 있음
      완벽한 비유는 아니지만, AI 코딩 도구에 대한 메시지는 존중할 가치가 있음
    • “마취과 의사가 더 중요하다”는 주장에 대해, 외과의 없이는 수술 자체가 불가능하다고 반박함
      역사적으로도 마취 없이 수술이 가능했음을 예로 듦
    • “AI 도구를 보조 인력으로 비유한 것”이지, 실제 사람을 낮춰본 게 아니라는 의견도 있었음
    • 다른 비유들도 종종 틀림
      예를 들어 프로그래머를 목수에 비유한 프레임워크 설명처럼, 실제 장인은 모든 부분을 완벽히 다듬지 않음
    • 수술에서 가장 중요한 사람은 누구냐는 논쟁에, 혼자서 자기 수술을 한 Leonid Rogozov 사례를 링크로 제시함

  • 이 비유가 마음에 들어서 앞으로 써볼 생각임
    또 다른 비유로 고전 화가의 작업실을 들 수 있음
    렘브란트나 루벤스는 제자들이 캔버스를 준비하고 일부를 채색했으며, 대가는 핵심 부분만 직접 그림
    반면 낭만주의 이후에는 예술가가 혼자 모든 걸 완성하는 이상이 생김
    어떤 프로그래머는 터너처럼 혼자 창작하고 싶어 하지만, 나는 렘브란트처럼 큰 그림을 그리고 세부는 AI나 주니어에게 맡기고 싶음

    • 하지만 소프트웨어의 결과물은 코드가 아니라 작동하는 제품임
      코드 품질이 좋아야 사용자 피드백에 빠르게 대응할 수 있음
      단순히 “빠르게 코딩하고 끝내는 것”이 아니라, 변경 비용을 줄이는 구조가 중요함
      렘브란트식 접근이 좋은 코드로 이어진다면 괜찮지만, 그 증거는 아직 부족함

  • 나도 Claude를 몇 달 써봤는데, 직접 코딩하는 게 더 효율적이라 느꼈음
    하지만 이번에 MySQL 8→9로 대규모 DB를 업그레이드하면서 Claude에게 문제 가능성이 있는 쿼리를 찾아달라 했더니, 놀랍게도 대부분 맞춤
    완벽하진 않았지만, 디버깅 시간을 크게 줄여줌
    LLM이 코드를 직접 쓰는 것보다, 리스크 포인트를 찾아주는 역할이 훨씬 가치 있다고 느낌

    • 나도 비슷한 경험이 있음
      오래된 코드베이스에서 스택 트레이스를 붙여주면 LLM이 초기 디버깅 방향을 제시해줌
      성능 문제를 고칠 때도 코드 경로가 동일한 결과를 내는지 검증시켜볼 수 있음
      아직 코드 작성은 자동완성 수준이지만, 효율은 확실히 올라감

  • Dan North의 Software Faster 발표가 떠올랐음
    “소프트웨어는 수술처럼, 문제를 해결하는 데 필요한 최소한만 하라”는 말이 인상적이었음
    그런데 이번 글은 그 철학과는 거리가 있음

    • 전임자는 “5분 절약하려면 파일 전체를 복붙하라”는 철학을 따랐음
      그래서 지금 나는 절단 수술을 자주 하는 외과의가 된 기분임

  • Chief Programmer Team 구조가 다시 유행하는 듯함
    이번엔 인간 대신 AI 에이전트가 팀에 포함된 형태임
    Fred Brooks의 아이디어가 다시 주목받는 중임

    • 글쓴이도 Brooks와 Harlan Mills를 직접 인용했다고 밝힘
    • 이런 구조가 더 인기를 끌지 않은 게 의외임
      10배 생산성 개발자(10x-er) 에게 유능한 팀을 붙이면, 회의나 Jira 관리에 낭비되는 시간을 줄일 수 있음
      고액 연봉을 주는 만큼, 그들의 시간을 최대한 가치 있게 써야 함

  • 자율성 스펙트럼, 혹은 위임 스펙트럼을 이해하는 게 AI 코딩 도구를 잘 쓰는 핵심임
    엔지니어들은 위임에 익숙하지 않지만, 창업자들은 이걸 더 빨리 체득하는 경향이 있음

  • “외과의는 중요한 일에 집중한다”는 표현에 대해, 실제로는 모든 지원 업무가 동등하게 중요하다고 지적함
    겸손하게 주변의 지원을 존중하고, 그들을 똑같이 서포트해야 함

답변달기