GitHub Copilot은 정말 개발자 생산성을 높였나

• 약 1년간 GitHub Copilot을 무료로 사용한 뒤 접근 권한이 사라지자 실제 효용을 되돌아봤고, 개인 프로젝트에서는 Copilot 없이 개발할 때 더 생산적이었다고 판단함
• Copilot은 잘 맞으면 반복 코드와 보일러플레이트를 빠르게 채워 주지만, 주 사용처인 picom에서는 대규모 코드베이스 이해보다 단순 패턴 작성에 주로 쓰였음
• picom은 X11 compositor이고 글쓴이가 메인테이너로 참여하는 프로젝트라, 일반적인 학습 사례와 잘 맞지 않는 독특한 코드베이스라는 제약이 있었음
• 가장 큰 불편은 어떤 작업을 맞힐지 알기 어려운 예측 불가능성과, 제안까지 보통 2~3초 이상 기다려야 하는 속도였음
• 현재 Copilot에는 비용을 지불할 만큼의 생산성 향상이 없지만, 더 똑똑해지거나 몇 배 빨라지면 평가는 달라질 수 있음

---

개인 프로젝트에서 Copilot이 잘 맞았던 순간

• Copilot은 약 1년 동안 무료로 사용할 수 있었고, 사용에 익숙해진 뒤 접근 권한이 사라지면서 Copilot 없는 개발 방식에 다시 적응해야 했음
• 잘 작동할 때는 머릿속 코드를 바로 화면에 써 주는 듯한 마법 같은 경험을 줬고, 보일러플레이트 코드를 직접 작성할 때의 불편함도 더 크게 느껴졌음
• 다만 순수한 생산성만 보면 Copilot이 없는 편이 더 나았음
• 이 사용 경험은 개인 프로젝트에 한정됨
  • 직장 업무에는 Copilot을 사용하지 않음
  • 생성형 AI의 도덕성, 저작권, 오픈소스 코드 학습과 기업 이익 문제는 다루지 않음
• 대부분의 개인 개발 시간은 picom에 쓰임
  • picom은 X11 compositor이며, 글쓴이는 메인테이너임
  • X11이 사실상 수명 종료에 가까워지고 Wayland로 이동하는 상황에서, 특정 데스크톱 환경에 묶이지 않은 compositor로는 picom이 거의 유일한 선택지라고 봄
• picom에는 로깅 시스템, 문자열 처리 함수, 정렬처럼 일반적인 구성요소가 있지만 전체 구조는 꽤 독특함
  • Copilot이 학습 중 비슷한 프로젝트를 봤을 가능성이 낮아, 코드베이스 전체를 추론하는 용도로는 잘 맞지 않았음
  • 실제 활용은 반복 코드 작성과 보일러플레이트에 주로 머물렀음
• 유용했던 예시는 단순하고 지루한 코드였음
  • 이스케이프 문자 파싱 코드에서 \t 이후의 분기 작성
  • enum을 문자열로 매핑하는 코드
  • 공통 패턴을 가진 글루 함수 작성
• 반복적이고 재미없는 코드를 대신 처리해 주는 점은 프로그래밍을 재미있게 유지하는 데 분명히 도움이 됨

생산성을 깎아먹은 예측 불가능성과 속도

• 첫 번째 문제는 예측 불가능성임
  • Copilot은 맞을 때 매우 유용하지만, 어떤 작업을 맞히고 어떤 작업을 틀릴지 미리 알기 어려움
  • 1년 동안 사용하면서 처음보다 판단은 나아졌지만, 세부적인 작동 방식을 완전히 파악하지는 못함
  • 사람이 할 수 있을 것처럼 Copilot의 능력을 추정하면 쉽게 빗나감
  • 예를 들어 주석 기반으로 한 함수를 잘 작성했다고 해서, 비슷해 보이는 다른 코드도 잘 작성하리라 기대하기 어려움
  • 인간과의 상호작용에서 쌓은 직관은 AI에 그대로 적용되지 않으며, 실제로 시도하기 전에는 성공 여부를 확실히 알기 힘듦
• 두 번째 문제는 속도임
  • C 언어 서버로 사용하는 clangd는 타이핑보다 빨라 제안이 사실상 즉시 나타남
  • clangd 제안이 도움이 되지 않아도 기다릴 필요가 없어 개발 흐름이 끊기지 않음
  • Copilot은 제안을 받기까지 보통 최소 2~3초를 기다려야 했음
  • 큰 코드 덩어리를 작성하려 할수록 대기 시간은 더 길어짐
  • 기다린 뒤에도 사용할 수 없는 코드가 나오는 경우가 많아, 주석 지시를 다듬어 다시 시도할지 일부만 받아들이고 나머지를 직접 작성할지 매번 판단해야 했음
  • 이런 왕복 과정은 자주 발생하지 않더라도 개발 시간을 낭비함
• 현재 시점에서는 Copilot이 생산성을 높여 주지 않으므로 비용을 지불할 생각이 없음
• GitHub이 1년 무료 제공으로 사용자를 중독시키려 했다면, 이 경우에는 실패한 셈임
• Copilot이 조금 더 똑똑해지거나 현재보다 몇 배 빨라지면 평가는 달라질 수 있음

[GN⁺]

Hacker News 의견들

• 10여 년 전 .NET 개발자였을 때 Microsoft가 .NET 앱의 새 데이터 처리 방식으로 Entity Framework를 내놓았고, 특히 지연 로딩이 마음에 들었음
  데이터베이스에서 메모리 구조로 직접 로드하지 않아도 시스템이 자동으로 해준다는 약속이었지만, 가끔 이유 없이 채워지지 않았고 technet 깊숙한 곳에서 “이 플래그로 로드 여부를 확인하고 필요하면 수동 로드하라”는 작은 주석을 찾았음
  결국 EF를 믿을 수 없으니 데이터를 전부 수동 로드해야 한다는 뜻이었고, 지금 코딩용 AI가 딱 그 위치라고 느낌. 틀리는 비율이 충분히 높아서 전부 직접 검토하고 고쳐야 하니 처음부터 직접 하는 편이 나아 보임
  참고로 EF는 그 뒤 많이 발전했고 지금은 지연 로딩을 믿을 수 있다고 하지만, 그때 Windows를 버리고 Linux로 갈아탄 뒤 Go를 배우기 시작했음. Go는 마법 없이 말한 대로만 동작해서 아직도 좋아함

  • ORM은 화려한 쿼리 도구로만 써야 제대로 쓸 수 있다고 배웠음
    쿼리를 만들고 데이터를 가져오거나 갱신한 뒤, 데이터를 별도의 비즈니스 객체로 옮겨야 함. ORM 엔티티를 객체 바다 전체에 공유해두면 안 됨
  • 이번 달에도 EF가 데이터베이스에서 클래스 필드를 채워야 하는데 안 채우는 문제를 디버깅해야 했고, 아직도 불안정해 보임
    EF를 선택한 직장에서 나중에 후회하지 않은 곳을 본 적이 없음. 신뢰성 문제, 마이그레이션 지옥, 끔찍한 성능 중 하나가 따라왔음
    “데이터베이스를 메모리 안의 열거 가능 컬렉션처럼 다룰 수 있게 해준다”고 하면 개발자들이 정말 그렇게 쓰고, 왜 성능이 엉망인지 의아해함. EF가 싫음
  • EF에서 지연 로딩은 실수였음. foreach 루프에서 지연 로딩 속성이 데이터베이스에 N+1 쿼리를 만들면서 성능이 망가진 앱이 많았음
    개발 환경에서는 50~100행과 로컬 SQL이라 괜찮다가, 운영에서는 수천 행과 별도 Azure SQL 때문에 터졌음. DbContext가 해제된 뒤 지연 로딩 속성에 의존해도 답이 없었음
    예전 EF에서는 지연 로딩을 꺼서 개발자가 초기 쿼리에서 .Include()로 관련 엔티티를 가져오지 않으면 항상 예외가 나게 했음. 데이터베이스 질의는 속성 getter 뒤에 숨어 있지 말고 명시적이어야 함
    다행히 EF Core에서는 Microsoft가 이를 깨닫고 기본값을 꺼놨고, .Include를 현명하게 쓰고 지연 로딩을 피하면 EF도 꽤 괜찮은 ORM임
  • 지금도 진지한 용도로 EF를 쓰면 어느 정도 직접 도와줘야 하지만, 그렇게 하는 건 꽤 쉬운 편이고 특정 동작 방식을 EF에 알려주는 것보다 직접 코드를 짜는 쪽이 더 빠르거나 쉽다고 보지는 않음
    EF를 전반적으로 좋아하진 않음. 특히 모델 빌더가 그것을 쓰는 다른 .NET 라이브러리와 상호 운용되지 않는 점과 .NET이 뒤에서 하는 마법이 마음에 들지 않음
    그래도 .NET Core 이후의 EF는 여러 언어의 ORM 중 꽤 나은 편이고, 개인적으로는 Rust의 diesel 같은 것을 더 선호하지만 C#을 써야 할 때는 EF도 같이 쓰는 편임
  • 생산성보다 더 중요한 건, 즐거운 활동이 확률적 난장판으로 바뀐다는 점임
    하려는 일을 설명하고 잘 되길 바라야 하며, 몰입과 도전감 대신 짜증과 좌절만 남음

• GitHub Copilot은 운영 코드에는 거의 쓸모없다고 봄. 지난 1년간 디버깅한 최악의 미묘한 버그들은 모두 Copilot이 쓴 코드에 있었음
  그럴듯해 보이지만 매우 미세한 실수를 하고, 반복적인 코드에서 주변 문맥을 복사해 조금 바꾸는 정도는 가능함
  테스트 코드는 다름. 테스트는 종종 공식화되어 있고 given/when/then 식으로 표준화되어 있어서, 첫 테스트 케이스를 쓰면 Copilot이 추가 케이스를 만들거나 FeatureUnderTest_Scenario_ExpectedOutcome 같은 메서드명만 보고 구현을 제공할 때가 있음
  Copilot Chat에서는 가치를 찾지 못했음

  • 테스트 코드도 코드임. 다른 코드만큼 부담이 되므로 의미 있게 만들어야 함
    반복적이고 공식화되어 보인다면 그걸 다음 리팩터링 기회로 삼아야지, 거의 복사본을 계속 찍어내는 건 좋은 답이 아님
  • Github Copilot은 상용구 코드에는 꽤 훌륭하지만, 그보다 복잡해지면 반반임
  • 자동화 테스트는 LLM이 진짜 생산성과 전반적 코드 품질을 높일 수 있는 영역이라고 봄
    실제로 아무것도 테스트하지 않는 테스트도 많이 생기겠지만, 좋은 입력을 주면 테스트를 생성하고 갱신하는 데 도움이 될 수 있음. 문서화도 기대가 큰 영역임
    아이콘 디자이너는 이미지 생성 AI로 꽤 좋은 결과를 빠르게 얻을 수 있게 되어 안됐다는 생각도 듦
    프로그래밍 자체에서 LLM이 정말 유능한 조력자가 될지는 모르겠음. 사소한 작업은 도울 수 있지만, 코드로 비즈니스 가치를 만드는 실제 작업에는 도움이 안 될 때가 많음
    그래도 많은 사람이 동작은 하지만 품질은 낮은 코드를 쓸 수 있게 해주는 건 큰 이점임. Power Apps로 꽤 유용한 것을 만들다가 규모가 커지면 더 견고한 소프트웨어로 대체되는 일도 봤고, 사무실 주변의 작은 개인 업무를 돕는 Python 프로그램도 개인 가치를 만들고 있음
  • Copilot은 스캐폴딩성 지루한 코드에 매우 유용함
    문제 해결에도 가끔 도움이 되지만, 요청을 매우 정확하게 하고 직접 안내해야 함
  • Supermaven이 Copilot보다 상당히 낫다고 느낌
    지연 시간이 거의 즉각적이고 결과가 대부분 한두 줄로 제한되어 성공률이 높음. 반면 Copilot은 내게 쓸모없다 못해 작업 흐름을 해치고 일을 더 어렵게 만들었음

• GitHub은 내부 연구를 근거로 코딩 속도가 55% 향상됐다고 홍보하지만, 그 연구는 참가자가 미리 작성된 프롬프트를 붙여넣고 출력 확인을 하는 능력을 측정한 것임: https://github.blog/2022-09-07-research-quantifying-github-c...
  Facebook에서 Copilot류 도구를 시험한 연구에서는 참가자가 기여한 코드의 8%가 제안에서 왔지만, 코딩 속도 향상은 약속하지 않았음: https://arxiv.org/abs/2305.12050
  개인적으로는 기계가 생성한 제안을 검토하는 시간이 개발자 시간을 자주 잡아먹음. 다만 LLM 전반에 대한 비판은 아니고, 잘 알려진 언어와 프레임워크로 새 프로젝트를 시작할 때 ChatGPT는 꽤 좋았음

  • LLM 보조가 꼭 더 빠르진 않지만, 체력 소모가 적어서 덜 지치게 한다고 느낌
  • 회사에서 “최상급” LLM 기반 자동완성을 제공받고 있음
    처음에는 진짜 자동완성이 아니라는 걸 몰라서 큰 고통이었고, Intellisense 같은 적절한 자동완성과 달리 환각 함수가 많이 나왔음. 난독증이 조금 있어서 그럴듯하지만 틀린 완성을 찾아내기가 특히 어려웠고, 당시 린터와 타입 검사도 느려서 저장이나 실행 때만 돌았음
    그래도 지난 1년 동안 크게 나아졌고 나도 익숙해졌음. 최근 문맥 편향이 있어서 코드 곳곳을 오가며 수정할 때 좋고, 좋은 변수명을 보상하며, 주석에 무엇을 왜 하는지 쓰면 도움이 됨
    UI는 바뀌었으면 함. LLM 제안임을 나타내는 완전히 다른 색이 필요하고, 가능하면 신뢰도도 보여주면 좋겠음. 제안을 수락하는 키도 달라야 하며 부분 선택까지 되면 더 좋음
  • 코딩 속도는 정말 형편없는 지표임. 빠르게 코딩할 수 있어도 생산적이거나 올바르다는 뜻은 아님
    느리더라도 제대로 쓴 코드가 전체 속도를 높임. 그 속도에는 몇 달 또는 몇 년 뒤의 리팩터링까지 포함되어야 함
    엉망인 코드도 겉보기엔 멋지고 버그가 없을 수 있지만, 과설계되어 바꾸기 어렵다면 제품 수명주기 후반에 변경 시간이 길어지거나 개발이 멈출 수도 있음
    AI가 AI 없이도 작성했을 코드를 더 빨리 만들게 돕는다면 좋겠지만, 실제로 그렇게 보지는 못했고, AI가 만든 코드가 개발자 스스로 만들었을 아이디어보다 더 나았던 적도 없음
  • 마지막 문장이 핵심임. 데이터베이스 스키마를 말로 설명하면 Laravel 마이그레이션, 모델, 컨트롤러와 정책, 폼 요청까지 거의 완벽하게 받을 수 있음
    10~20분 안에 V1을 만든 다음 실제 로직을 처리하면 됨
  • Copilot이 프로그래머에게 얼마나 도움이 되는지에 대해 신뢰할 데이터를 줄 마지막 주체는 GitHub임
    시나리오와 지표를 자신들에게 가장 좋은 숫자가 나오도록 기울였을 게 뻔함
    결국 맥락에 달렸음. 반복 코드나 상용구, 잘 알려진 프레임워크와 언어에서 새 프로젝트를 시작할 때는 속도를 높일 가능성이 큼
    프로그래머 본인도 변수임. 문제 영역, 언어, 프레임워크에 대한 익숙함뿐 아니라 개인의 성격과 코딩 스타일도 중요함

• “국소 최댓값”에 도달한 느낌임
  AI가 언젠가는 도달하겠지만, 현재 패러다임은 점점 스팸과 허접한 클립아트에나 유용해 보임
  그래도 모두가 뭔가 유용한 일이 생기길 바라며 말도 안 되는 투자금을 쏟아붓고 있음. 투자자 계층이 투자 대상의 기술적 현실과 얼마나 동떨어져 있는지 잘 보여줌
  수십억 달러를 태우면서 더 부자가 된다고 생각하지만 실제로는 더 가난해지고 있음. 그래도 H100은 더 사겠지

  • 지난 2년 동안 Copilot, ChatGPT, Claude 3 Opus 같은 도구를 실제로 유용하게 써왔음
    내가 과대광고와 반짝이는 도구에 쉽게 속아 2년 동안 존재하지 않는 이점을 상상한 멍청이이거나, 아니면 거기에 뭔가가 있는 것임
  • 최근 Sam의 언어가 전성기 SBF의 언어와 우울할 만큼 비슷해 보여 걱정됨
    자기 사업이 차지할 수 있는 시장이 사실상 전 인류이며 정부가 자금을 댈 것이라는 식의 가짜 지성적 수사를 늘어놓음: https://twitter.com/tsarnick/status/1789107043825262706
    공간의 주요 인물들이 지난 1년간 말투를 어떻게 바꿨는지만 들어봐도, 우리가 국소 최댓값이나 정체기, AI 겨울에 매우 가까운 것 같음
    현실적으로 AI는 놀라울 만큼 비싸고, 정말 터무니없이 비쌈. Microsoft는 1,000억 달러짜리 AI 중심 슈퍼컴퓨터 “Stargate”를 짓고 있음: https://www.tomsguide.com/ai/meet-stargate-the-dollar100-bil...
    그 돈은 AI 서비스 판매가 아니라 Windows, Office, Azure, M365 같은 오래되고 지루하며 검증된 사업에서 나옴. Xbox는 눈앞에서 죽어가고, 기존 사업은 돈은 잘 벌지만 성장하지 않음. AI가 투자자에게 높은 주가수익비율을 정당화해야 하는 상황임
  • 투자자들의 수익률 모델은 더 다르고 미묘하다고 봄
    예전에는 모든 것이 온프레미스에서 적당한 비용으로 돌아갔지만, 이후 화려한 프레임워크와 마이크로서비스, 분산 시스템 같은 패러다임에 대규모 투자가 들어갔고, 이제는 예전 몇 MHz 장치에서 돌던 기본 기능도 거대한 클라우드가 필요해졌음
    실제 수익률은 모델 자체에서 나오지 않음. 모델은 혹시 승자를 만들 경우를 대비한 도박이고, 진짜 수익은 사람들이 비싼 하드웨어를 빌려 모델을 활용하려는 클라우드에서 나옴
    반짝이는 스타트업 하나에 100만 달러를 넣으면 다른 스타트업도 유니콘이 되려 경쟁하며 비슷하게 지출하고, 그동안 클라우드 사업자와 GPU 공급업체는 같은 투자자들에게 배당할 돈을 벌며 웃고 있음
  • 생성형 AI를 “AI”라고 부르는 명명 자체가 과대광고이고 실망을 부른다고 봄
    투자자에게는 세계에서 가장 비싼 텍스트·오디오·시각 자동완성이라고 부르는 것보다 훨씬 흥미롭겠지만, 현재 세대는 실제로 그에 가까움
    우리가 패턴을 찾고 맞추는 생물이기 때문에 마법처럼 느껴질 수 있음. 원하는 패턴을 직관하는 듯 보이면, 완벽하지 않아도 다른 인간과 추론하는 것처럼 느껴짐
    인간에게도 너그럽지 않게 말하면, 많은 일상 대화와 상용구 작성은 자동조종에 가깝고 복잡한 추론에 진지하게 관여하지 않은 채 기대되는 패턴으로 답함. 하지만 그것이 인간 지능의 지능은 아님
    기업 과대광고 기계는 이것을 해법으로 포장하지만, 이제는 사람들이 이 기술에 대해 중요한 질문만 묻는 지점으로 가고 있음. 특정 작업 X를 해주는 제한된 자동완성에 얼마를 낼 것인가
  • 이 밈을 잘못 쓰고 있거나, 아니면 밈 자체가 말이 안 됨

• 인턴과 일하는 건 즐거움. 배우는 모습이 보이고 항상 새로운 실수를 하며, 훈련에 들인 노력의 보상이 있음
  정규직으로 전환되어 내 업무를 덜어줄 수도 있음. 하지만 LLM에서는 그런 느낌이 없음
  실력은 인턴 수준인데 배우지 않음. 일을 맡길 수도 없고, 관리 노력은 비슷하게 듦
  나는 인턴을 관리하려고 이 일을 하는 게 아니라 문제를 풀려고 이 일을 함. 인턴 교육은 현재의 내가 미래의 나에게 지불하는 비용임
  책에서 인터넷 검색이나 StackOverflow로 넘어간 것과도 다름. 즉각적인 이익도 주지 않고, 내가 기여한 것이 미래에 내게 돌아오지도 않음. 규모를 만들기 위한 공유-동일조건 분위기가 보이지 않음
  더 빠르고 효율적으로 만들어주는 도구를 원함. 그래야 임금을 계속 올릴 수 있음. AI가 내 훈련으로 배우는 걸 볼 수 있거나, 들인 노력에서 이득을 볼 수 있다면 다를지 모르지만 지금은 LLM 훈련의 이익을 위해 내가 비용을 내는 셈임

  • 비슷하게 봄. LLM을 쓰고 출력을 고치는 것이 그냥 코드를 작성하는 것보다 빠르다는 주장에는 아직 설득되지 않음
    “코드를 읽는 것이 쓰는 것보다 어렵다”는 말은 어디 갔나. 인턴이나 아주 주니어 개발자는 몇 달이나 몇 년 뒤 업무를 늘리는 대신 줄여줄 희망이 있음
    LLM은 정말 반복적이거나 상용구 작업에 쓰는 경우가 아니라면, 미묘한 오류를 찾는 데 너무 많은 시간을 써서 가치가 떨어짐. 게다가 직접 무언가를 만드는 것보다 훨씬 덜 재미있음
  • 인턴 비유가 맞다고 봄
    문제는 외주를 줄 때 항상 소통 비용이 든다는 것임. 인간 인턴처럼 전체 프로젝트를 LLM에 맡길 수는 없고, 아주 작은 하위 작업을 하나씩 넘기는 식임
    인간 비유로는 어깨너머에 서서 함수 하나씩 쓰라고 지시하는 것에 가까움. 작고 순수한 함수에는 엄청 빠르지만, 그 외에는 혼란스러워함
    그런 방식이 더 빠른 프로그래밍인지는 모르겠음. 머릿속에서 문제를 작은 함수로 매끄럽게 분해할 수 있고 그 방식으로 풀 수 있다면 가능할지도 모름
    다만 나는 Copilot 자동완성보다 ChatGPT를 더 큰 메타 질문에 훨씬 자주 쓰고 있음

• 경험상 Github Copilot은 매끄러운 자동완성에 유용함
  하지만 새 기능인 Github Copilot Chat은 GPT-4보다 눈에 띄게 뒤처지고, 코드를 ChatGPT에 복사해 붙여넣는 쪽이 훨씬 나은 성능을 냄
  둘 다 생산성에는 분명 도움이 되며, 특히 익숙하지 않은 프레임워크나 라이브러리로 코드를 생성할 때 좋음
  새 라이브러리로 작은 프로그램의 골격 코드를 만들기에는 훌륭하지만, 현재 형태로는 약 80%까지만 데려다줌. 나머지 20%를 완성하려고 프롬프트와 몇 시간 씨름하느니 직접 마무리하는 편이 훨씬 쉬움

  • 개발 속도를 높이지 않는다는 말도 맞을 수 있음. 핵심 이점은 속도가 아니라 개발자의 인지 부하를 AI로 넘긴다는 데 있음
    우리는 결과를 확인하고 검토하면 됨. 속도를 극적으로 올리지 않더라도 개발자가 더 오래 생산적으로 남는 데 도움을 줌
  • 내 경험도 정확히 그랬음. 자동완성과 상용구에는 훌륭하지만, StackOverflow식 질문에는 들쭉날쭉함
    실제로 무엇을 하려는지 아주 기본적인 이해가 필요한 질문을 하면 보통 완전히 빗나감. 그 경계에 닿으면 혼란스러워지고 순환하기도 해서, 언제 내려놓을지 배우는 것도 사용법의 일부였음
  • 이상함. 내가 알기로 Copilot Chat은 GPT-4임. 아니면 3.5로 돌리는 건가
  • 나도 비슷했음. 익숙한 Django에서는 큰 도움이 안 되지만, 덜 익숙한 프론트엔드에서는 많이 도움이 됨

• 가치 제안을 잘 모르겠음. 무언가를 쓰는 데 1초를 아끼면 제대로 됐는지 확인하는 데 10초를 씀
  작성 과정을 빠르게 하는 건 암달의 법칙 때문에 어느 정도 낭비임
  Copilot 같은 도구가 검증과 리뷰를 어떻게 빠르게 하는가. 예를 들어 같은 일을 하는 C 프로그램은 Go 프로그램보다 검증이 더 어려움
  기업 환경에서 검증에 쓴다고 해도 그 결과를 확신할 수 있나. 개인적으로는 너무 의심이 많고, 더 많은 사람이 그래야 한다고 봄

  • 과대광고와 그것을 미는 사람들을 조심해야 함. 특히 팔 물건이 있는 주체라면 더 그렇다
    합리적인 범위에서는 열린 마음을 유지하되, 모든 걸 버리고 뱀기름을 사기 전에 자신의 경험과 기본적인 추론을 믿어야 함
  • 사람들은 상용구 코드처럼 보여야 하는 것을 가끔 뱉어낸다는 이유로, 그것이 신뢰 가능하고 유용하다고 믿는 함정에 빠짐
    생성된 코드가 신뢰 가능하다고 더 많이 가정할수록 환각이 코드베이스에 몰래 들어올 가능성이 커져서 매우 위험함
    직접 쓰지 않았기 때문에 코드가 실제로 무엇을 하는지에 대한 좋은 정신 모델도 없음
    Copilot에 의존하는 코드베이스는 결국 버그가 드러났을 때 아무도 시스템을 디버깅할 능력이 없는 재난을 나중으로 미루는 셈 같음
  • 혼란스러움. 코드를 쓸 때 “xyz를 하는 for 루프를 쓰고 싶다”고 생각함
    Copilot이 내가 원하는 걸 했는지 아닌지 아는 게 왜 어려운지 모르겠음

• 이 문장이 논의에서 중요하다고 느낌: “나는 본업에는 Copilot을 쓰지 않고, 개인 프로젝트에만 쓴다”
  Copilot을 믿지 못하거나 생성 코드가 마음에 들지 않아 안 쓰는 사람들은 엄격한 코딩 표준이 있는 전문 업무 환경에서 쓰려는 경우일 가능성이 큼
  취미나 사이드 프로젝트에서는 Copilot이 엄청난 시간 절약 도구임. Python 사이드 프로젝트에서 정말 많은 시간을 아껴줌
  메서드명 뒤에 """만 입력하고 잠깐 멈추면 꽤 괜찮은 docstring을 생성하고, 보통 파일 안의 기존 스타일도 따라함
  테스트 작성은 들쭉날쭉하지만 좋은 출발점을 주고, 운이 좋으면 생각하지 못한 테스트 시나리오도 제안함
  기본 함수나 메서드 만들기에도 좋음. 나는 기억력이 나빠 CSV 읽기·쓰기나 딕셔너리 순회 같은 기본 Python 코드도 문서를 자주 보는데, Copilot은 def open_csv_file을 입력하고 잠깐 멈추는 것만으로 좋은 결과를 줄 때가 많음
  기존 코드에 타입 힌트를 추가할 때도 :를 입력하고 멈추면 거의 항상 올바른 타입 힌트를 주고, 함수 닫는 괄호 뒤에 공백을 누르면 반환 타입 힌트도 거의 맞춤

  • 회사가 비용을 내줘서 본업에서만 Copilot을 씀
    밤이나 주말에 개인 프로젝트를 코딩할 때는 Copilot이 아쉽고 직접 결제할까 고민 중임. 모든 걸 믿지는 않지만 가끔 얼마나 많이 맞히는지 놀라움
    다만 내 사유 코드를 AI 훈련에 쓰지 않게 하려면 “Business” 요금제에 월 19달러를 내야 해서 개인적으로는 정당화하기 어려움
  • 글쓴이임. 글에서 더 명확히 말했어야 했는데, 본업에서 쓰지 않는 주된 걱정은 저작권임
    오픈소스 프로젝트에서 일하기 때문에 저작권 있는 코드를 실수로 코드베이스에 커밋하고 싶지 않음

• 코딩용 AI 물결에는 아직 흥미가 안 생김. vim을 배우고 유일한 도구로 쓰기 시작한 뒤로 코드 작성 자체가 병목이 아니었기 때문임
  무엇을 쓸지, 코드를 어떻게 조직할지가 이 일의 정말 어려운 부분이고, 다른 사람이 쓴 것 또는 AI가 쓴 것을 리뷰할 때는 그걸 제대로 하지 못함
  사람들이 시간을 아끼려고 상용구 코드를 쓰는 데 이 도구들을 실제로 쓰는지 궁금했고, 그렇다면 말은 됨
  Vim은 모든 반복 작업 시간을 줄여 생산성을 크게 높였고, 일관적이며 신뢰할 수 있음. 물론 배우기는 매우 어려움
  같은 문제를 푸는 완전히 다른 접근일 수도 있음

  • 나도 같음. 대부분의 시간은 도메인, 제약, 처리 흐름을 생각하는 데 씀
    메서드나 클래스, 특정 사용법을 기억해내는 건 Dash 오프라인 문서, PDF 매뉴얼, 라이브러리 페이지를 미리 열어두는 조합으로 빠르게 처리함
    Vim에서는 코드를 복사해 붙여넣으면서도 코드에 대한 완전한 통제권이 있고, 버퍼 모델 덕분에 VSCode의 탭 모델처럼 단일 파일 하나가 아니라 생각 중인 모든 것을 앞에 둘 수 있음. 상용구는 병목이 된 적이 없음
    변수와 속성, 함수와 클래스, 모듈과 파일 등 내가 다뤄야 하는 모든 것에 대한 감을 갖고 싶음. 내가 쓰지 않은 것이라면 소스 코드를 검토했거나 라이브러리 평판을 믿는 등 이유가 있어야 함
    IDE는 내가 원하는 자동완성, 자동 임포트, 심볼, 함수 시그니처와 클래스 속성 정보를 이미 제공해왔음
    환각일 확률이 0이 아닌 ChatGPT 결과를 보기보다 라이브러리 문서와 코드 예제를 잠깐 읽는 편을 택하겠음
  • 상용구 논리를 이해하지 못하겠음. 주요 프레임워크는 이미 10년 넘게 상용구 생성기를 갖고 있었음
  • 내게 Copilot은 Vim의 자연스러운 확장처럼 느껴짐
    Vim은 코드 편집에 세계 최고이고, Copilot은 코드 생성에 놀라울 정도로 뛰어남

• “기능”을 많이 만들기 위해 쓰지는 않지만, 지루한 일을 없애는 데는 정말 좋음
  상용구, 이미 코드에 있는 값으로 해시를 구성하는 일 같은 것들이 영혼을 갉아먹는 작업임
  며칠 전 새 Rails 프로젝트용 Dockerfile을 만들고 있었는데, 찾아보는 대신 그냥 Copilot이 만들게 했고 95% 정도 맞았음