GitHub CEO, AI 붐 속에서도 “수작업 코딩은 여전히 핵심”

• GitHub CEO Thomas Dohmke는 AI 도구 확산에도 불구하고 수작업 코딩 능력의 중요성을 강조함
• AI가 코드를 생성해도 개발자가 직접 수정 및 검토해야 효율적임을 주장
• 자동화만 의존할 경우 실질적인 비효율과 생산성 저해 위험이 있으며, "Vibe coding" 처럼 AI 코드 남용 시 품질과 보안 리스크가 증가함
• AI와 인간 개발자의 하이브리드 접근법이 가장 효과적임을 산업 트렌드와 사례로 뒷받침하며 설명
• 개발자 역할은 사라지지 않고, AI와 협업하며 전략적 문제 해결 및 설계 역량이 요구되는 방향으로 진화 중

---

GitHub CEO, AI 시대에도 수작업 코딩 중요성 강조

GitHub CEO Thomas Dohmke는 소프트웨어 개발 현장에서 AI 도구 활용이 확산됨에도 불구하고, 수작업 코딩 능력 유지의 중요성을 강조함

• “The MAD Podcast with Matt Turck”에 출연하여 개발자는 AI가 생성한 코드를 직접 수정하는 역량을 가져야 생산성 저하를 방지할 수 있음을 설명함
• 효과적인 워크플로우로서는 AI 도구가 코드를 생성해 Pull Request를 제출하면, 개발자가 스킬을 활용해 즉시 수정하는 접근법임
• 오로지 자동화 에이전트에 의존할 경우, 자연어로 단순한 수정을 설명하는 데 불필요한 시간을 소모할 수 있어 비효율 발생 위험이 언급됨
• Dohmke는 “프로그래밍 언어로 이미 직접 할 줄 아는 작업을 굳이 자연어로 설명하려 시도하는 게 가장 비효율적인 선택”임을 지적함
• OpenAI 공동창립자 Andrej Karpathy가 언급한 “vibe coding”은 AI 생성 코드에의 과도한 의존을 의미하는 용어로, Dohmke가 이에 대해서도 주의를 촉구함

인사이트 및 업계 동향

1. AI 코딩의 최적 해법은 하이브리드 전략

• Dohmke의 관점은 AI 자동화와 인간 프로그래밍 스킬의 결합이 최적임을 주장하는 업계 컨센서스와 일치함
• Deloitte 연구에 따르면 개발자들은 AI 도구를 주로 보일러플레이트 코드 작성을 위해 사용하지만, 인간의 최종 검토를 유지함으로써 10~20분 생산성 향상 효과를 얻음
• AI가 생성한 코드의 약 절반에는 부분적 오류가 있어, “신뢰하되 검증” 전략이 업계 표준으로 자리잡고 있음
• Google은 전체 코드의 25% 이상을 AI가 생성하지만, 여전히 인간 개발자의 적극적 리뷰와 개선 과정이 필수임을 경험함
• 이런 균형 잡힌 접근은 AI의 한계 인식과 함께 개발자의 전문성이 대체가 아닌 증강되는 방향으로 업계가 성숙해지고 있음을 반영함

2. 개발자 역할은 변모 중이며 사라지지 않음

• AI로 인해 프로그래밍 직업이 사라지기보다는, 개발자 역할이 순수 코더에서 AI 기반 개발 프로세스 관리자로 변화하고 있음
• 전문가들은 개발 직군이 AI 활용 제품 엔지니어와 고급 시스템 품질/보안 보장 아키텍트로 양분될 것이라 전망함
• 이 변화는 효과적인 AI 활용법, 전략적 문제 해결능력, 고수준 설계 역량 등 새로운 능력의 필요성을 의미함
• 소프트웨어 엔지니어 부족 현상과 함께 AI 도구의 주니어 개발자 지원 효과가 입증돼, 숙련 개발자에게도 새로운 성장 기회를 제공함
• 이는 과거 개발 도구와 추상화 기술 등장 때처럼, 인간의 창의성은 여전히 필요한 흐름임을 시사함

3. “Vibe coding”의 생산성-품질 딜레마

• “Vibe coding” 현상은 AI 생성 코드의 생산성 이점과 품질/보안 한계를 드러내는 트렌드임
• AI 도구는 빠른 프로토타이핑과 반복 개발을 지원하지만, 코드 품질 저하와 보안 리스크 우려도 증가시키는 결과임
• 실제 사례에서는 AI 코드의 미검증 사용에 따른 보안 취약점이 발생하기도 함
• 비전공 창업가 중심 스타트업 등에서는, AI 코드 남용이 기술 부채를 쌓아 장기적 성장 저해로 이어질 수 있음
• 대형 IT기업 경험상, 자동화와 엄격한 품질 관리의 균형이 AI 도입의 핵심으로, 스타트업에도 이 교훈이 중요함

[GN⁺]

Hacker News 의견

• 사람들이 왜 시스템의 본질적 복잡성에 대해 더 이상 이야기하지 않는지 매우 의문임
  Fred Brooks의 No Silver Bullet에서는 소프트웨어 엔지니어링의 진짜 어려움은 핵심적인 문제 공간을 이해하고, 명확히 하고, 모델링하는 데에서 온다고 지적함. 도구의 한계 같은 우발적 복잡성은 부차적임
  최근에는 AI 에이전트가 엔지니어 대신 자연어 프롬프트로 전체 코드베이스를 만든다는 이야기가 많음. 그런데 이 가정은 사양(specification) 문제를 이미 해결했다고 보는 착각임. 실제로는 모호한 아이디어를 상세하고 튼튼한 시스템으로 바꾸는 게 여전히 엔지니어의 핵심 역할
  누군가가 세부 명세를 제공하고 AI와 반복적으로 작업해서 소프트웨어를 만든다면, 사실상 AI로 우발적 복잡성을 없애는 것. 이는 개발자가 어셈블리에서 고급 언어로 전환한 것과 비슷함. 엔지니어를 대체하는 게 아닌 생산성을 높여줄 뿐임. 반복 작업의 비용을 줄이고 더 넓게 영향력을 확대할 기회도 생김
  만약 에이전트가 프롬프트만으로 제품을 만든다면, 누군가 이미 명확하게 시스템을 정의해 준 덕분임. 그리고 AI로 기존 제품만 복제한다면, 기술적 문제 해결이 아니라 유통이나 비용 경쟁으로 가는 것이고, 이는 엔지니어링 혁신이 아니라 비즈니스 혁신.
  내가 뭔가 놓치고 있는 부분이 있을까 궁금함

  • 사양(specification) 작업이 AI 등장 훨씬 전부터 소홀히 취급된 이유가 핵심임
    이해관계자(고객, 관리자)들은 예전부터 그냥 대충 감으로 코딩을 시켜왔음. 대충 설명하면 누군가가 기적적으로 그에 맞는 솔루션을 내주는 식임. 솔루션이 완전히 동작하는지 아무도 모름. 그냥 어느 정도 동작하는 것 같으니 넘어가는 경우가 많음
    대부분의 경우는 프로그래머가 도메인 지식을 기반으로 구체화함 (예: 올바른 폼 제출 페이지란 어떤 모습인지 본능적으로 알기 때문)
    이제 상대방이 AI로 바뀌었을 뿐, 이런 방식이 과연 그대로 반복될 수 있을지는 지켜볼 문제임

  • 본질적/우발적 복잡성 구분은 AI가 소프트웨어 개발 어디까지 맡을 수 있을지 생각하는 데 매우 중요한 통찰임
    많은 개발자들이 왜 AI로 대체되지 않을지 말로 설명은 못하지만, 본능적으로 느끼는 부분이 이 지점임
    실제로 나도 Claude 같은 에이전트에게 엄청 복잡한, 외부 비즈니스 로직이 얽힌 대형 코드베이스의 문제를 해결하려 시도해봤음. 하지만 AI는 비즈니스 요구나 맥락을 제대로 직감하지 못해서 비즈니스적인 코드 변경은 못함. 단순히 컨텍스트가 좁은 코드 변경이나 도와줄 수 있음. 즉, 우발적 복잡성만 처리 가능하고, 진짜 개발자의 역할인 실제 요구사항을 시스템으로 번역하는 데에는 한계가 있음
    덧붙이자면, 실제로 많은 개발자들이 해결하는 건 기술적 문제가 아니라 유통/시장 문제일 수도 있음. AI로 주니어를 대체하는 건 아직 불안함. 가장 큰 이슈는 AI가 자체적으로 자기 수정을 못 한다는 점임. 그럼에도 불구하고, AI 기반 사업체가 등장해 기존 비즈니스 비용을 낮추려는 시도는 계속될 것임. 그 변화가 좋을지 나쁠지는 일자리에서 밀려나는 사람 입장에서는 의미 없음

  • "내가 뭔가 놓치고 있나?"에 대한 답이 있음
    실제로 소프트웨어를 쓸 줄 모르는 개발자가 엄청 많음. 이들은 AI로 쉽게 대체될 것임
    예전 경력에서는 JavaScript로 일했고, 정말 놀라운 일을 하는 사람들은 취미로 개발을 해온 사람들뿐이었음. 회사에서는 대부분 사람들이 화면에 텍스트 띄우는 것도 힘겨워했음. 농담이 아님
    많은 사람들이 거대한 프레임워크에 도전했지만, 결국 복붙만 하다가 겨우 동작하게 만드는 수준임. 고급 복잡성을 해결한 척 하지만 거의 다 불필요한 작업이거나 코드 자랑임
    오리지널 앱을 만들거나, 문서 작성, 실제 사용성을 측정하는 역량이 거의 없음
    이것을 어떻게 해결하냐고? 법조인처럼 바 시험 같은 높은 기준을 도입해서, 기준을 못 넘는 사람은 과감히 배제하고, 주니어나 견습생으로만 채용해야 개발자 세대가 제대로 성장할 수 있음

  • ‘놓치는 부분’에 대한 쉬운 답은, 업계에 "No Silver Bullet"을 읽은 사람이 없다는 점임
    기술부채, 시스템 아키텍처에 대한 글을 쓴 사람들은 실제로 팀/비즈니스를 좌우하는 의사결정자들이 아니며, 그런 책들도 엔지니어에겐 선택사항임
    AI로 코딩 대체 이야기를 주도하는 사람들은, MVP 만드는 것과 10년간 코드베이스 확장 및 레거시 개선하는 것을 구분하지 못하는 경우가 많음
    예를 들어, 한 매니저는 하루에 3개 프로젝트에 각각 33% 시간 분배하자고 전형적인 잘못된 제안을 한 적이 있음. 직원 할당이나 시간 구조화는 관리자의 역량이어야 하는데, 결국 제대로 처리하는 건 엔지니어 몫임
    이제 그런 관리자들이 "AI에 모든 기술부채/테스트 해결시키자"고 제안하고, 정작 제대로 안 되면 설명하는 것도 엔지니어가 함
    복잡성 이야기는 실상 관리 부실 문제의 반복일 뿐임. 이미 대다수 경험 많은 엔지니어들은 본인 일이 간단한 프롬프트로 대체될 거라 믿지 않음
    우리가 진짜 이야기해야 할 화두는 "소프트웨어 엔지니어링은 관리 문제가 심각하고, AI가 그걸 더 부각시킨다"임

  • 많은 비개발자 혹은 학생들은 소프트웨어 개발에 복잡한 툴 사용법을 익혀야 한다고 느끼고, "명세만 잘 만들면 누구나 소프트웨어를 만들 수 있다"는 약속에 끌림 (명세 능력 자체가 매우 어렵고 지원 기술이 필요하다는 점은 쏙 빼놓고)
    예전 노코드도 이런 식이었고, 실제로 노코드 툴은 제한적이고, 기능이 강력할수록 더 복잡하고 전문적인 학습이 필요함
    LLM을 이용한 SWE 대체론도 결국 "시스템을 배우는 대신 자연어로 프롬프트 하면 모델이 알아서 툴을 써준다"는 버전임
    이렇게 보면 요즘 말하는 vibe coding이 사실상 이런 목표의 극치임 (다만 유지보수성 등 실질적 약점 존재)
    내가 보기에 매니저가 SWE를 없애고 싶어하는 이유 중 하나는 SWE와 제대로 소통하지 못해서임
    LLM을 사용하면 "너드(개발자)" 없이도 기계와 소통할 수 있으니 그 문제를 푼다고 보는 경향이 있음

• 프로그래밍 언어는 원하는 프로그램의 정밀한 명세에 적합한 매체임. 자연어는 결코 그런 수준의 명확성을 가지지 못함
  그래서 AI가 생성한 결과를 리뷰하고 편집하는 건 당연함. 때에 따라서는 변경 내용을 설명하는 것보다 직접 수정하는 게 오히려 더 쉬움
  Copilot이 오류율 증가시킨다는 독립 연구 결과들이 자연스럽게 신중한 태도를 퍼뜨린 요인 아닐지 궁금함
  AI를 파는 사람들은 인간 저자가 곧 필요 없어질 거라고 주장하는 경우가 많음

  • Transformer는 자동화 테스팅, 명세 확장, 신규 프로젝트 가속, 모르는 API 탐색, 초기 기능 구축, 코드 리뷰 등 다양한 일에 적용 가능함
    실제로 코드가 명세의 올바른 매체라 치더라도 Transformer는 자연어와 그 미디엄(코드) 사이의 자동화 인터페이스 역할을 함
    최근 Transformer는 방대한 지식 덕분에 코드 생성에 문제가 없음
    인간이 프로그래밍에서 자동화를 추구하듯, Transformer는 거대한 도약임
    미래 어느 시점에는 AI로 인한 프로그래머 대체가 현실이 될 수 있음 (과거 자동 직조기, 인쇄술, 전자 계산기가 인간 작업을 대체한 것처럼)
    다만 지금 당장, 또는 10년 안에 일어나진 않을 수도 있고, 앞으로는 환각(hallucination), 정확도, 도구화, 인프라 구축 등 과제가 남아 있음
    프로그래밍 일자리 유무는 도메인, 실력, 보상 기대치에 따라 달라질 수 있음
    AI 도구를 진지하게 받아들이고, 적응하는 게 중요함. 그렇지 않으면 퍼스널 컴퓨팅이나 인터넷 도입 시기처럼 변화에 뒤처질 우려 있음

  • AI의 의사창조성에는 한계가 있다고 봄
    모든 LLM 학습 결과가 다시 LLM 입력으로만 순환된다면, 새로운 아이디어 범위는 절대 넓어지지 않음
    인간은 계속해서 그 범위 밖을 넘나드는 창의성을 보임
    미래에는 LLM이 그 벽을 넘어설 수도 있겠지만, 지금으로선 ‘원숭이 타자기’와 크게 다르지 않음

  • 내 경험상 LLM은 스캐폴딩(발판 도구)처럼 활용했을 때 가장 효과적임
    내가 만들고 싶은 기능을 뇌내 덤프처럼 전달하고, 그러면 모델과 그 모델에 필요한 기본 컨트롤러를 만들어달라 요청함
    남은 것은 뷰와 실제 비즈니스 로직에만 집중하면 되어 업무 분담이 명확함

  • 과거 고급 언어가 처음 등장했을 때, 극초기에는 지금 LLM이나 자연어 코드 비판과 비슷하게 "메모리 직접 제어가 어려워서 정밀도가 부족하다"는 식의 비판이 있었던 걸로 앎
    문제는 자연어가 정밀성이 불가능하다는 게 아니라, 대부분 사람들이 정밀하지 않게 요구를 설명하거나, 본인이 원하는 바만 명확하고 실제 컴퓨터가 해야 하는 일을 제대로 설명하지 못한다는 점임
    그 결과, 엔지니어가 비즈니스 요구를 번역할 때 엄청 추측하거나, LLM이 그 역할을 하면서도 더 적은 맥락밖에 이해 못 하는 상황이 반복됨

  • AI의 최선 활용법은 내가 처음 보는 API나 귀찮아서 하기 싫은 기능에 막히지 않고 플로우 상태 유지하는 것임

• AI는 코드 전체에 공통 패턴을 빠르고 효율적으로 적용할 수 있지만, 본질적으로 '무엇을 하고 있는지 스스로는 모름'
  최근 경험을 공유하자면, 팝업 크기 계산과 위치 결정 관련 코드를 LLM에 리팩터링 시키려 했음
  하나는 "if", 하나는 "switch"로 작성했는데, LLM은 두 방식이 다르다는 점에서 전혀 유연하게 반응 못 하고, 명확히 설명해도 두 곳 모두 if 또는 switch로 통일해버림
  LLM은 이전 토큰의 패턴을 계속 유지하는 경향이 있음
  여기에선 큰 문제가 아니지만, 약간만 더 복잡한 상황에선 세밀함을 무시하고 표면상 그럴듯한 코드를 내놓음
  대신 작은 단위로 쪼개서 명확히 명령하면 LLM이 상당히 효율적임. 예를 들어, “m_StateStorage에 사이즈 저장 후 렌더 단계에서 적용” 같은 지시는 쉽게 수행함
  특히 Cerebras처럼 몇 킬로바이트짜리 코드도 빠르게 처리할 수 있는 모델과 함께라면, 내 생각을 실제 코드로 직접 입력하는 것보다 훨씬 빠름

  • AI라는 용어는 그 자체로 '인텔리전스'를 내포하니 어느 분야, 어느 수준까지 할 수 없다 단정할 수 없음
    결국 오늘날 평가하는 건 트랜스포머 모델의 현재 성능에 국한된 비판임
    이 업계는 워낙 급변하고 있기 때문에, 오늘의 한계가 한 달 뒤에 의미 없어질 수도 있음
    “LLM”도 엄밀히 말하면 모호한 표현임. 최신 트랜스포머 모델은 멀티모달이며 텍스트뿐만 아니라 여러 형태의 데이터를 다룸
    따라서 굳이 비판한다면, 어떤 모델/툴/패러다임을 구체적으로 지적해야 논의에 실효성이 있음

• “소프트웨어 엔지니어 부족” 및 “AI가 주니어 개발자에게 특히 도움이 된다”는 연구 결과에 대해
  내가 사는 세계선(현실)에서는 테크 취업 시장이 최악이고, AI는 오히려 주니어가 성장해야 할 곳에서 경험을 빼앗아 불리하게 작용함

• 최근 Claude로 재미있는 경험을 했음. Zed에서 “71번 줄 에러를 고쳐줘”라고 명령했더니 91번 줄에서 쓸데없는 포맷이나 바꿔줌

  1. 91번 줄엔 에러가 없었음,
  2. 더 중요한 건 내가 지정한 줄을 무시했다는 점임
     마치 LLM과 전화 게임하는 느낌이었음
     이렇게 간단한 수정도 직접 하는 게 빠름. 이 다른 경험으로 “LLM은 진짜 생각을 안 한다”는 느낌을 다시금 확인함

  • LLM이 라인 넘버 인식이 형편없음

  • 이런 경험으로 “LLM은 줄번호를 셀 수 없다”는 교훈을 얻음
    다음엔 “함수 XYZ에서 에러 고쳐줘”라거나 해당 줄을 직접 붙여넣어서 지시하면 더 나을 것
    그리고, 물론 LLM은 생각하는 게 아님. 단지 거대한 방정식일 뿐임

  • 이번 스레드엔 AI로 코딩 처음 해보는 사람들이 많아 보임

  • 오퍼레이터 실수일 수도 있음
    LLM에 제대로된 컨텍스트를 줘야 함. 라인 숫자는 부적합한 컨텍스트임

• 내 기준에서 소프트웨어 엔지니어의 역할은 요구사항을 소프트웨어로 바꾸는 것임
  소프트웨어는 단순히 코드가 전부가 아니고, 요구사항도 단순 자연어로만 주어지는 게 아님
  현시점, AI와 함께 일해도 내 속도가 AI보다 더 빠르지 않음 (단순 작업, 소규모 소프트웨어 제외)
  현재 AI는 내 기준에선 주니어/미드 레벨 개발자 감임
  최근 2년간 AI가 체감상 획기적으로 더 좋아지진 않았음

  • 대부분 요구사항은 명확하게 문서화되어 나오지 않음
    비즈니스 로직이 뭔지 아는 사람도 거의 없음
    그러다 보니, 소프트웨어 엔지니어가 직접 찾아가서 물어봐야 하는 상황이 잦음
    소프트웨어의 성장 방향과 어떻게 설계해야 그 확장성을 챙길 수 있을지 고민하는 경험과 직관도 요구됨
    LLM이 이런 역할을 일부라도 할 수 있을 거란 상상이 안 감

  • 명확한 요구 사항이 주어진 소프트웨어 프로젝트는 단 한 번도 본 적 없음
    프로젝트의 절반은 ‘진짜 원하는 게 뭔지 파악하는 일’임

  • LLM은 아직 주니어 레벨조차 못 미침
    혹시라도 현존 AI가 귀사 미드 레벨 개발자 수준이었다면, 그건 회사의 채용 문제임

• 컴퓨터의 가장 큰 장점 중 하나는 신뢰할 수 있고 재현성 높은 자동화임
  프로그래밍 언어 같은 형식 언어는 원하는 자동화 요구를 불명확함 없이 명확하게 전달할 수 있음
  자연어는 그만큼 정밀하지 못함
  프로그램의 진짜 근거(ground truth)는 결국 코드임
  인간이 프로그램의 동작을 정확히 통제하고자 한다면, 코드를 이해하고 수정할 수 있는 역량이 가장 중요함

• “매뉴얼(수동)”이라는 단어는 부정적 뉘앙스가 있음
  해당 기사에서 의도한 건 "인간 코딩이 여전히 핵심"임
  GitHub CEO가 정말로 "manual"이라는 단어를 쓴 건지 확실치 않음. 더 중립적이거나 정확한 단어 선택이 있는 기사 소스가 있으면 좋음
  인간 코딩을 “manual”로 폄하하는 것은 바람직하지 않음. 인간 개발자도 AI 외 다양한 자동화 툴킷을 사용함

  • “수동 사고”만큼이나 부정적 일 수 있음

  • “manual”의 부정적 의미는 새로 알게 됨
    요즘은 수동 작업에 그렇게까지 반감을 가지는지 궁금함

  • “manual coding”과 “human coding”의 구분이 뭔지 궁금함

• “AI 에이전트에만 의존하면 비효율적일 수 있다”
  예를 들어, 단순 변경을 자연어로 길게 설명하는 것보다 직접 코드 편집이 훨씬 빠른 경우가 많음
  따라서 AI 에이전트와의 적극적 상호작용이 최적의 워크플로우가 될 것임

  • 변경 내역을 자연어로 생각하다가, 입력하기도 전에 이미 내가 필요한 직접 변경 방안을 머릿속에서 떠올리는 경우가 많음
    컨텍스트가 많은 변경일수록 나 스스로 agent보다 더 빨리 수정하게 되는 것 같음

  • 얼마나 적극적인 상호작용이 괜찮은지 궁금함
    최근 에이전트 툴링 스타트업에 합류했는데, 내부적으로 이런 부분을 많이 논의함
    “솔직히 이거 잘 못하고 있어!”라고 에이전트에 지속적으로 피드백 주는 것은 괜찮다고 보지만, 어떤 부분은 피곤해질 수도 있음
    어떻게 생각하는지, 워크플로에 대한 상상이나 피드백이 추가로 궁금함

• AI는 아직 기대만큼 도달하지 못했음
  예를 들어, 나는 자주 잘못된 참조 자료나 명세 때문에 고생함. 이건 AI가 구식 데이터로 학습됐고, 실시간 업데이트 능력이 부족해서인 듯함
  현존 LLM과 GI 솔루션은 모든 단계(n-step)를 한 번에 풀려다가 오히려 효용이 떨어짐
  1단계~i단계 정도만 제대로 처리해줘도 인간 입장에서 훨씬 더 도움이 될 것
  아직 내가 원하는 완전 모듈형 AI(예: 내 github 스타일을 반영해서 a, b, c 리소스만 참고해서 문제 x 해결) 솔루션을 보지 못했음
  그리고, 문제를 순차적으로 탐색하며 중간중간 더 많은 질문을 던지고 대화하는 코딩 AI가 나오길 기대함

• AI와 코딩에 대해 다소 색다른 방향으로 의견을 말하는 CEO가 인상적이라고 느낌
  일반적으로 CEO나 투자자는 “전체 코드의 30% 이상을 AI가 쓴다”며 개발자 역할 축소를 예견하곤 하는데, 실제로는 같은 개발자들이 더 빨리 코드를 작성할 수 있게 도구를 쓰는 것뿐이라는 진단
  실제로 코드 작성 자체는 소프트웨어 개발 업무의 일부에 불과하다는 점 강조

  • 그는 맞는 이야기를 하고 있다고 보지만, 결국 ‘사람 중심 코드’ 사업에 있는 본인의 이해관계가 반영된 입장이라고 생각
  • GitHub 수익 모델이 개발자 수에 달려 있으니 이런 입장 취하는 것이 당연