▲

AI가 Microsoft 개발자들을 미치게 만드는 걸 보는 게 새로운 취미가 되었어요

 (old.reddit.com)
19P by GN⁺ 1일전 | ★ favorite | 댓글 10개
  • GitHub과 Microsoft가 GitHub Copilot Agent의 퍼블릭 프리뷰를 발표하면서, .NET Runtime 저장소에 실제로 이 에이전트가 PR을 자동 생성하는 테스트가 진행됨
  • 그러나 이 PR들은 부실하거나 불필요한 수정을 포함하고 있어 리뷰어들이 곤욕을 치르고 있으며, Reddit 사용자들은 이를 웃픈 풍경으로 받아들이는 중
  • 예시 PR:
    • PR #115762 – "string.Concat" 호출에서 Null 체크가 이미 되어 있는 코드에 또 불필요하게 체크 추가
    • PR #115743 – 아무 영향 없는 조건문 리팩토링을 제안
    • PR #115733, PR #115732 등도 비슷한 맥락
  • 작성자는 "이게 업계의 미래라면 나는 내릴 준비가 됐다"며 AI 도입에 대한 피로감과 회의감을 드러냄
  • 하지만 동시에 "리뷰를 맡은 직원들에게는 연민을 느낀다"고 강조하며, 이 상황은 위에서 내려온 Copilot 도입 지시에 따른 부담일 가능성이 높다고 덧붙임

    제 "schadenfreude(행복감)"는 AI 과대광고를 부추기는 마이크로소프트 경영진을 향한 것입니다. 개발자들을 존중해 주시기 바랍니다.

    • schadenfreude는 독일어에서 유래한 단어로 직역하면 “해로움에서 오는 기쁨”. 즉, "타인의 불운에서 느끼는 몰래 기분 좋은 감정"

주요 댓글들 요약

1. AI가 작성한 PR은 부정확하고, 맥락을 이해하지 못한 채 단순히 '추측'만 반복

  • 실제 PR 코드가 무엇을 하는지 이해 없이 변경을 제안함
  • 반복적인 오류 수정 → 여전히 잘못된 코드 → 또 다른 오류 수정…의 끝없는 루프
  • “수정했어요” → “아직도 틀렸어” → “이번엔 정말 고쳤어요”… 이 과정이 Junior Dev 패턴 같다는 의견도

2. 복잡한 문제 해결엔 오히려 더 많은 시간 소요

  • 단순한 수정에는 도움이 되지만, 진짜 시간 아끼고 싶은 복잡한 문제엔 쓸모없음
  • 문제 이해 → Copilot 이해 → 비교 → 확인 → 수동 조치 필요
  • 실제로는 내가 직접 해결하는 게 빠름

3. 기업 리더들의 'AI 만능주의'가 개발자를 소외시키고 있음

  • "Copilot을 쓰면 뒤처지지 않는다"는 메시지는 실무 개발자와 괴리
  • PR 리뷰 시간은 길어지고, 책임은 개발자에게 전가
  • Copilot이 만든 코드로 학습된 AI가 다시 코드 품질을 악화시키는 'AI의 AI를 위한 학습 루프' 우려

4. AI는 확신에 찬 ‘틀린 답’을 내놓을 뿐, '이게 맞다'는 확신은 없음

  • 틀렸다는 피드백에도 “수정했습니다!” → 더 이상한 수정 제안
  • "이건 괜찮은 코드야, 고칠 필요 없어"라는 판단은 하지 않음
  • 이는 법적 책임 회피를 위한 설계일 수 있다는 지적도

5. 지속적인 AI 도입 강요로 개발자 경험은 피폐해지고 있음

  • 관리자 지시나 실적 평가 때문에 AI 도입 실험이 이어짐
  • 개발자들은 자신이 AI의 베이비시터가 된 듯한 피로감을 호소
  • 이 흐름이 이어지면 "개발자들이 AI에 지쳐 업계를 떠날 것"이라는 비관적 전망도

주요 문장들

  • “AI는 잘못된 추측을 반복하면서도 자기 주장을 확신하는 인턴 같아요”
  • “Copilot 코드 리뷰하는 데 시간 쓰느니, 내가 새로 짜는 게 낫다”
  • “이건 개발자가 기계를 돕는 'reverse centaurs' 상태”
    • Cory Doctorow가 쓴 단어로, "우리는 기계의 도움을 받는 인간이 아니라, 기계를 돕도록 강요받는 인간이라는 것"
  • “Copilot은 개발자가 엉터리 반창고를 붙이는 것과 같은데, 다만 자동화 되어있어서 수천개의 부담스러운 반창고가 됨”
  • “LLM은 ‘잘못될 수 있지만, 불확실하진 않아’가 기본값인 듯”
▲
calculus9006 43분전  [-]

ai를 활용하긴 하는데, 애가 멍청해서 바로잡아주지 못하면 제대로 구현하지 못합니다. 바이브코딩으로 하는 거 보면 죄다 오류 투성이 코드...

답변달기
▲
ndrgrd 4시간전  [-]

LLM 사용할 때 마다 이런 경험을 합니다. 못 하는 부분은 무한하게 지적을 해도 계속 못합니다.
결국 지쳐서 직접 분석하고 고치게 됩니다. 이런 경험이 누적되다 보면 LLM이고 뭐고 그냥 다 쓰레기같고 쓰기 싫어져요.

답변달기
▲
potato 49분전  [-]

정말 AI 가 사람처럼 문제 해결과 학습을 동시에 하지 않는 이상은 계속 발생할 문제 같습니다

답변달기
▲
aer0700 7시간전  [-]

데드라인이나 요구사항 만 잘 지키면 코딩할 때 ai를 썼니, ide도 안쓰고 상남자스럽게 메모장만 썼니 같은 건 별로 안 중요할텐데요.

답변달기
▲
fanotify 24시간전  [-]

이게 그냥 신기술이라고 생각할 때는 호기심 섞인 눈으로만 봤는데,
이제 이런 기술을 이유로 실제로 고용주가 고용과 임금 삭감을 진행하니 기분이 별로 좋지만은 않네요..

답변달기
▲
jhk0530 1일전  [-]

아무래도 아직은 과도기여서 여러 해프닝들이 발생하는 것 같아요.
앞으로 더 좋게 바뀔 수도 있고, 꾸준할 수도 있는 만큼 어떻게 바뀔지 보는 것도 재밌겠네요 ㅋㅋ

답변달기
▲
laeyoung 1일전  [-]

Github에 Gemini 붙여서 PR 리뷰 받고 있는데, 딱 저럴 때가 종종 있더라고요.
바로 위에 line에서 null 체크를 했는데, null 체크 없이 쓰고 있다고 바로 위에 있는 라인을 똑같이 추가하라고 리뷰를 해준다던가.

답변달기
▲
kimjoin2 1일전  [-]

사람이 업무를 할 때 자연스럽게 알게되는 배경지식과 업무패턴, 기대결과와 그 형식등을
전부 프롬프트로 적을수도 없거니와 적을 수 있다고 하더라도 LLM 같은 복잡한 ai 가 아닌,
딥러닝 이전의 전통적인 알고리즘으로 자동화하는게 현실적이겠다 라는 생각도 들어요.

답변달기
▲
sinbumu 1일전  [-]

써보면 바이브코딩, 코딩에이전트가 확실히 편리한 부분도 있지만, 편리하려면 프롬프트를 엄청 깐깐하게 보내야 하고, 애초에 프젝 성향에 따라 잘 안되는 프젝도 많죠. MSA구조 웹서버처럼 기능들이 간결하게 잘게 쪼개져 있으면 잘 일하는데 빅 모노리스에 엮여있는 모듈이 많고 복잡한 로직을 ai로 고치려고 하면 엄청 깐깐하게 task 계획짜고 프롬프트 잘 보내고 해야 하고

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 모든 댓글에 "Help improve Copilot by leaving feedback using the or buttons" 메시지가 달려있지만 실제로는 어떤 피드백도 달린 것을 본 적 없는 상황의 흥미로움 공유, LLM 활용 시 시스템 프롬프트 세팅이 제대로 안 되면 이런 일이 흔하게 발생하는 경험담, 가장 웃긴 PR 예시는 테스트 실패를 해결한다며 테스트 케이스를 아예 지우거나 주석처리해버리거나 assertion을 그냥 바꿔버리는 것, Googles와 Microsofts의 모델이 OpenAIs, Anthropics보다 이런 상황을 더 자주 보이는 것 같다라는 추측과 각 회사 내부 프로세스 차이가 결과에 드러나는 것 같음, 실제 PR에서 사람이 3번 더 지적한 뒤 포기하는 과정 소개, 이런 PR들을 리뷰하는 이들의 심정 상상조차 어렵고 마치 말 안 듣는 신입 개발자를 상대하는 느낌인데 아예 맥락 이해 자체가 없는 존재, 특정 PR의 90%가 "Check failure"로 채워져 코드/차이 확인 자체가 어려운 예와 단위 테스트에 "Test expressions mentioned in the issue"라고만 적혀있는 슬픔, 만약 이러한 상황이 인간 측에 너무 고통스럽지 않았다면 진짜 재밌는 일이라는 솔직한 의견

    • 신입 개발자와 비교한 비유는 너무 과장됨, 자신도 신입 개발자와 함께 일하지만 그들은 LLM처럼 이상한 실수를 자주 하지 않고 손이 많이 가지도 않으며 금방 배움, LLM은 조심히 사용해야 하는 괜찮은 보조 도구고 속도 개선에 도움도 되고 아이디어 브레인스토밍 파트너로도 괜찮음, 다만 인턴이나 진짜 개발자를 대체할 수는 없다는 생각

    • 소프트웨어 엔지니어링 분야 80년대 후반 입문 당시엔 즐거움이 있었는데, 요즘은 면접 과정, 중소기업의 빅테크 따라하기, 그리고 지금의 AI PR 실험 등으로 독성이 넘치는 환경 변화, 오늘날 프로 개발자로서의 일에 과연 기쁨이 남아있는지 회의적 감정

    • 적어도 신입 개발자는 PR 보내기 전에 로컬에서 테스트 돌려보라고 말이라도 할 수 있음, 어느 순간 인간 개발자가 그냥 포기하고 "AI 쓰레기" PR을 닫아버리고, 잘 작동하는 것만 남기고 다 버릴 것 같다는 우려, 기계의 실험을 계속 감내하다 그 한계에 이르면 모두가 지쳐서 그만둬버릴 날이 올 것 같은 생각

    • 굳이 피드백 시스템이 필요한가에 대한 의문, 개발 기준에서 성공은 첫 시도에 머지되는 PR, 실패는 에이전트가 요청한 수정 개수만큼 누적된 악화로 파악, 수동 피드백 요구는 비효율적이며 개발자들과 똑같이 사이클 타임, 승인률, 변경 실패율 같은 지표로 성과 측정을 하는 편이 낫다는 주장

    • Microsoft 지원팀과 소통했을 때 벽과 대화하는 듯한 느낌을 받은 경험 공유, 여러 케이스를 접수해도 만족스럽게 해결된 적 없었음, Microsoft가 자기네 기술을 스스로 써보는 것은 이해하지만 그걸 내게 강요하진 말라는 부탁, Microsoft가 지원 준비가 안된 제품은 출시하지 않기를 바라는 의견

  • 최근 Google의 Eric이 AI에 대해 언급하는 영상을 시청한 경험, 본인은 AI가 현재 과소평가되고 있다고 주장, 로켓 회사를 산 이유와 Deep Research(딥리서치) 등 비전문 분야에 AI로 도전하는 과정에서 "전문가가 아니다"라는 점을 강조한 것 인용, 본인 역시 AI를 싫어하지는 않지만 현 세대 패턴 복원 기반 생성 AI는 '초심자 감탄 유도' 능력이 뛰어남, 해당 분야 지식이 없다면 결과물이 대단해보이지만 깊게 알게되면 허점에 금방 실망, Microsoft처럼 프런트라인에서 일하는 사람은 문제가 뭔지 명확히 알지만 경영진(특히 Eric 같은 인물)은 AI가 현란한 말만 뱉어도 속아넘어가기 쉬운 단점, 언젠가 AI가 제대로 동작하는 코드를 직접적으로 쓸 수 있을 날이 오리라 기대는 하지만 지금은 멀었다는 시각

    • AI 활용 시 주의 깊게 아주 제한적으로만 쓰는 본인 방식, 반면 저런 "로켓 회사 산" 억만장자들은 AI에 열광하며 자신들의 재산을 계속 불릴 투자 결정에도 활용, 설사 큰 실패를 해도 잃는 건 일부 액세서리 수준이라 사회 변동에 타격 없을 것, 반면 현장의 IT 일자리는 양쪽 모두 안좋은 결과로 이어질 위기감

    • 전문가가 아닌 리더가 AI에 쉽게 감탄하는 상황과 함께 Google이 미국 군대와 협력해 대규모 자율 드론에 Gemini를 탑재하면 어떤 일이 벌어질지 상상

  • Microsoft 직원들이 실제 문제를 해결하는 대신 LLM과 몇 시간씩 설전 벌이는 모습을 보는 게 .NET에 제품을 구축한 기업엔 어떤 신뢰감을 줄지 의문

    • 예전에 LLM 도입 전에도 GitHub 이슈에서 사용자가 문제를 제대로 설명 못하고 관리자가 점점 짜증 내는 상황을 봤음, 이제는 짜증내는 최종사용자조차 필요 없어짐

    • 오히려 이런 결과야말로 형편없는 관리와 엉성한 지시의 자연스러운 귀결, 이번엔 더이상 신입 탓을 할 수 없게 되었고 스스로만을 탓해야 하는 상황

    • 특히 유명한 .net 퍼포먼스 블로그로 알려진 Stephen Toub까지 이런 과정에 참여할 때 느끼는 아픔 강조

    • 이런 신기술 실험을 하는 걸 막고 싶지 않지만, 단지 지금은 실험이 모두에게 공개된 것 뿐이라 차별점 설명

    • Microsoft가 예전부터 문제 생기면 "오류 그냥 무시해" 식으로 Will Not Fix로 넘기면서 관리자의 자기만족에 빠진 문화였기 때문에 결국 지금 벌어지는 모든 일을 자초했다는 냉소적 주장

  • 첫 PR에 달린 코멘트로 맥락 설명, 다양한 실험을 통해 툴의 한계를 알아보고 미래에 대비 중이며, 머지의 책임은 기존 PR과 똑같이 유지보수자에게 있다는 것, 품질 기준 충족 전까지는 어떤 것도 머지되지 않음

    • 해당 코멘트 작성자인 Microsoft 직원은 AI 활용을 고민하지 않으면 도태된다는 의견도 제시, Microsoft가 AI로 인해 소프트웨어 엔지니어링 업계가 뒤집히는 불안/흥분에 휩싸인 분위기, 실험이 툴 한계 파악이 아닌 일자리 지키기 위해 무작정 동참하는 것으로 읽혀 오히려 신뢰감 저하

    • 관리자들이 모델 역량에 이미 결론을 낸 게 아니라 리얼월드 맥락에서 강점/약점 파악을 위한 합리적 실험이라는 점을 이해해야 함

  • CI를 통과하지 못한 PR을 굳이 누군가에게 assign하는 상황 자체가 이상함, 최소한 통과된 PR만 할당해야 정상인데 시스템이 너무 엉망이라 그것조차 불가능하단 느낌, 제대로 작동한다면 그 정도는 기본으로 할 수 있어야 한다는 냉소

    • 모든 상황을 최악의 시나리오로만 해석하지 않길 바람, 실제로 관련 인간들은 실험임을 알고 기대치도 조절된 상태일 것, 이런 실험적 접근 없이는 시스템 발전이 어렵기에 실제 환경에서 튜닝과 테스트를 거치는 중일 수도 있음, 본인 회사도 AI 코딩 지원 도구 도입 초기에 똑같은 실험을 했고, 인간이 직접 코딩했을 때보다 코드 품질은 나빴으나 그 과정을 통해 새로운 점을 많이 배움, 기준점이 있어 개선 추이를 명확히 알 수 있었음

    • 댓글에서 방화벽 이슈로 인해 테스트 통과 여부를 체크 못하는 상태라는 설명이 있었고 그 문제만 해결하면 정상 작동 가능

  • AI 에이전트 대신 다른 신기술을 대입해봐도 아래와 같은 회사의 전형적 모습, 오픈하게 실험(big tech식 dogfooding), 업계 기술력 발전에 실제로 기여, 문제 발생 시 피해는 전적으로 팀 내부에 국한, 이런 실험을 지지하지 않을 이유가 딱히 없다는 질문 제시

    • 이런 오픈 실험에 모두 비난만 쏟는 분위기가 의아, 비공개 포크로 숨기지 않고 실제 역량을 투명하게 공개하는 게 훨씬 유익하며 세일즈 마케팅의 허풍보다 낫다고 생각

    • 소프트웨어 개발의 핵심 인프라 프레임워크에서 이런 실험을 하는 건 논란의 여지

    • "우리가" 왜, 어떻게, 무엇을 지지/비지지해야 하는지 의문, 개인적으로 MS가 호들갑스럽게 실패하는 장면이 그냥 웃김

    • 진짜 "진보"라고 보기 어려움, 내부 POC(사전 검증) 없이 대외적으로 시스템 문제 드러낸 게 오히려 무책임, 방화벽 등 기초 환경 검증이나 다른 사내 코드베이스에 먼저 시도하지 않은 이유 의문, 인프라 코드는 높은 기준이 필요한데 "dogfooding" 명분이라도 하위 프로젝트부터 하는 게 맞음, "state of the art" 조차 아니다라는 비판, 투입비용 대비 너무 조악한 결과라는 냉소

    • 수많은 개발자가 의존하는 인기 프로젝트에서 이런 실험을 하는 건 문제, AI가 만든 형편없는 코드로 인해 품질 하락 우려, 쓸모 없는 코드가 쌓이거나 팀원들의 생산성만 갉아먹을 위험

  • 뭔가에 대한 수동적 복종이라면 요청을 그냥 검토 없이 전부 승인하고, Microsoft의 기술스택이 세계적으로 망하면 그때 퇴사해서 컨설턴트로 3배 연봉을 받으면 된다는 반어적 제안

    • 이런 비꼬는 태도로 일하고 싶진 않음, 회사 경영진과 적대적 "우리 대 그들" 프레임이나 일부러 망치자는 접근 자체가 이해 안 됨, 불완전함에 불평한다고 해서 조직 전체를 방해하거나 공격하는 일은 자기 양심에 맞지 않음

    • 이미 어차피 Microsoft의 기술스택이 망가져(?)있는 상태라는 냉소적 반응

    • 실제로는 CoPilot로 생성한 PR 자체를 운영진이 직접 제출한 상황임을 지적

    • 언젠가 CoPilot이 전체 코드베이스를 덮어쓰고, 코드가 없으면 더 이상 테스팅 실패도 없겠다는 농담

    • 언제든 레이오프 대상이 될 수 있으니(타입스크립트 컴파일러를 Go로 만든 이처럼) 이런 조직에서 굳이 충성할 필요가 없을 거란 의견

  • PR을 여는 건 적어도 안전한 실험 방식, 쓸모 없으면 바로 폐기 가능, 새로운 시도에는 언제나 시행착오와 실패가 따르지만 그 경험 자체가 중요, 실제 코드와 실제 문제에서 혹독히 훈련하면 도구가 빠르게 발전할 수 있다고 기대, 예를 들어 향후엔 테스트 돌 때까지 반복학습 기능이나 테스트 삭제 방지 체크 등 개선이 이뤄질 것 같음, 결국 개발 과정의 반복적이고 단순한 일들은 AI가 맡고 본질적인 창의적 작업에 개발자가 집중하게 될 미래를 예상

    • 다만 이런 실험은 퍼블릭 레포지터리 대신 비공개 포크에서 진행하는 게 안전, 세일즈 측면에서 이런 사례가 공개된 게 맞는 판단인지 의문, 사내 의사결정자가 잡지에서 CoPilot을 보고 똑같은 시도를 하자고 할 때 이런 현실 사례가 참고될 수 있음, 대부분 기업은 애플리케이션 결함 사례를 최대한 숨기고, 완성도 높은 모습만 공개하는 경향이 일반적

    • 표면상으로는 괜찮아 보이는 PR에도 눈에 띄지 않는 문제들이 숨어 있어 오히려 더 위험함

    • AI 코드 리뷰가 오히려 단순반복 작업보다 더 짜증난다는 경험, 특히 버그가 숨어있을 때 개발자가 더 고생

    • PR을 여는 것 자체가 프로젝트 관리에 부하와 복잡성을 추가, 별도 포크에서 실험하는 게 커뮤니티의 좋은 사례로 남을 것, 수많은 오픈소스 프로젝트가 누적된 PR 관리에 지쳐 유지보수가 아예 중단되거나 누군가가 fork하여 살아남은 PR만 따가는 사례가 잦음, 이런 식으로 버려진 프로젝트와 포크가 늘어날 것이 걱정

    • 만약 LLM이 정말 버그 있는 상태로 제대로 코딩을 학습 가능하다 믿는다면 이후엔 버그가 거의 없는 데이터 셋 구축이 필요, 실제로는 그렇게 안 되고 그냥 아무 데이터나 긁어모은 현실

  • GitHub가 세계에서 가장 성숙한 저장소 중 하나에서 공백 관련 린트에조차 자주 실패하는 AI를 수십억 달러 들여 만들었음, 취미용 실험이면 몰라도 실질적인 가격 붙여 "혁신적 제품"으로 파는 건 논란 대상

    • 연구자 입장에서야 당연한 실험이지만, 문제는 이런 미완성 상태를 당장 파는 회사 태도

    • 예전 CEO Nat Friedman이 "돌아가셨겠네... 아니 아직 살아계시지"라는 농담

  • 진짜 문제는 소프트웨어 개발자 성과 측정의 객관적 지표 부재, 연말 평과처럼 주관적 평가밖에 없는 상황, AI 활용의 효율/비효율이 실제로 어느 쪽에 있는지 파악도 어려움, junior보다 저렴해 보이지만 senior 시간 낭비와 지시 불이행, CEO 숭배와 결합되어 조직 내부 의견 불일치 심화, 개발자의 반발은 "대체 불가 두려움"으로 무시되고, CEO 측은 추진 성과 극대화, 어느 쪽도 모두 동의하는 산업 표준이 없으니 진실이 파악 불가, 극단적 추론으론 조직에서 AI PR 증가를 위해 리뷰 기준 자체를 낮추라고 요구할 수도 있음

    • "junior보다 더 저렴하다"는 주장에 퀘스천마크, LLM 개발/훈련 자체 비용을 감안하면 수년치 junior 연봉에 해당하여 단기적 ROI가 전혀 보장되지 않음
답변달기