AI가 숙련 개발자를 느리게 만드는 현상과 원인 - 만다라트 뷰

[admin]

원본: 자유게시판
작성자: 시스템
날짜: 2025-07-21 01:01:08

---

이 만다라트는 "AI가 숙련 개발자를 느리게 만드는 현상과 원인"에 대한 분석을 담고 있습니다.

만다라트 정보:

• 제목: AI가 숙련 개발자를 느리게 만드는 현상과 원인
• 경험 많은 오픈소스 개발자의 생산성에 미치는 "AI의 임팩트" 측정하기 답변달기 ▲ GN⁺ 1시간전 [-] Hacker News 의견 HN 여러분, 저는 논문 저자임. 해당 블로그 글이 AI가 개발 속도를 늦추는 데 기여할 수 있는 구체적 요인 하나를 흥미롭게 다뤘다고 생각함. 논문(C.1.5 섹션)에 개발자 인용문도 있으니 참고 바람. 많은 사람이 논문을 읽고 공감되는 요인 하나를 발견해서 “이 한 가지 문제만이 느려지는 이유다”라고 결론내기 쉬움. 하지만 실제론 요소가 여러 개임(최소 5개가 유력, 최대 9개까지 배제 불가, p.11 요인 표 참고). 어느 한 가지가 원인이라는 가정보다 다각적인 원인 분석이 타당함. 스스로 실험해 볼 계획 있는 분은 논문의 이메일로 꼭 결과를 공유해줬으면 하는 바람임. 그리고 기사 제목이 “AI slows down open source developers. Peter Naur can teach us why”로 작성된 점에 대해 더 정확히는 “2025년초 AI가 경험 많은 오픈소스 개발자를 느리게 함. Peter Naur가 특정 요인에 대해 더 많은 맥락 제공함.” 정도가 적합하다고 생각함. 표현이 덜 자극적일 수 있지만 정확성이 중요하다고 여김. 다시 한 번 멋진 글에 감사를 표하고 계속 댓글도 읽고 있음 이전 관련 토론 논문 전문 개인적 궁금증이 있는데, 연구에서는 AI 사용 전과 후에 실제 소요 시간이 얼마나 달라졌는지 어떻게 신뢰할 만하게 측정했는지 묻고 싶음. 혹시 개발자가 AI 사용 후 시간이 얼마나 줄어들지 예상한 뒤, 실제 사용 시간을 측정해 그 차이를 본 건지 궁금함. 그리고 어떤 이슈의 난이도나 해결에 필요한 시간 추정이 어려울 때 연구팀에서는 어떤 식으로 통제했는지도 알고 싶음. 이런 측정은 정말 복잡하다는 점에 공감함 결과에 공감하며 답변에 고마움을 전함. 제목은 급진적 스타일이 좋아서 바꿀 계획은 없으나, 기사에서 잘못된 표현임을 분명히 수정할 예정임. 본인이 쓴 글에서 연구 결과의 주요 기여 요인 “레포지터리에 대한 높은 개발자 친숙도”, “크고 복잡한 레포지터리”, “함축적 레포지터리 맥락” 등 연구와 궤를 같이함을 밝힘. 직접 자신에게 실험 진행도 해보고 싶은데, 업무상 요구를 병행하면서 통제된 환경을 만들기는 매우 힘든 일로 느껴짐. 짧은 시간 내 완료 가능한 명확한 태스크의 리스트도 부족함 자신이 잘 아는 프로젝트에서 최적화된 워크플로우에 변화를 주면 초기에는 느려질 거라 기대함. 중요한 점은 이런 개발자들이 6개월, 1년 후에는 어떨지 지켜보는 것임. 이번 연구는 장기적 추이는 보여주지 않으니, 향후 연구에서 동일 개발자가 익숙해진 후 성과가 어떻게 달라지는지 알 수 있길 바람. 자신도 AI로 자동화가 어려웠던 많은 작업을 스크립트화할 수 있겠다는 걸 체험함. 항상 “이게 시간 대비 가치가 있는가?”라는 질문을 품어야 함 xkcd 타임 매니지먼트 만화 “2025년초 AI가 경험 많은 오픈소스 개발자를 느리게 한다”는 것도 너무 일반화된 표현임을 언급. AI가 시간을 절약할 수 있는 특정 작업도 있으므로 어떤 과제냐에 따라 효과가 다름 느려진다는 게 반드시 나쁜 것은 아니고, 느린 프로그래밍(리터러리 프로그래밍/Knuth 방식)이 오히려 이론화에 더 도움이 된다고 생각함. 패스트푸드식 프로그래밍이 아닌, 충분한 사고와 추상화를 동반한 느린 개발이 중요하다는 주장도 가능함 “도구가 실제로 자신을 빠르게 만들었는지 느리게 만들었는지 개발자가 파악하지 못한다”는 현상에 공감함. 보트가 바람과 조류 때문에 목표를 벗어나는 현상을 예시로 들어, 현재 내 주변의 움직임 기반으로만 진전을 인식할 뿐, 목표 도달 여부를 직감하기 어렵다는 점을 지적함. 그래서 “진전하는 기분”이 들게 하는 전략을 택하는 경향이 있고, 이는 비효율적이거나 실제로는 더 느린 경로(예: 운전시 자주 우회전 등)를 선택하게도 함 AI 도구를 처음 사용할 때는 막힘이 없어서 계속 일이 진행되는 느낌이 좋았음. 하지만 실제로는 직접 한 줄 고치는 게 더 빠른 경우에도 습관적으로 AI를 호출하는 상황이 발생함. 운전 비유와 비슷하게 특정 길이 막히면 다시 원래 길을 추천해주는 GPS처럼 반복적으로 돌아가기 쉬움 Waze 같은 내비앱이 실제로는 더 긴 루트를 안내함에도 불구하고, 얽힌 우회길로 인해 “진행 중”이란 착각을 들어 빠르게 간다고 느끼게 하는 것과 비슷함. AI 도구도 프로그래밍을 더 쉽게 한다고 체감되지만, 실제 생산성이 줄 수도 있음. 인간은 고통 없이 진행하는 단기적 체험만 기억하기 쉽고, 어렵지 않았다는 점에서 진전했다 생각함 결국 인간은 본능적으로 탐욕 알고리즘(greedy algorithm)을 선호함 리눅스/유닉스 사용자들은 키보드 컨트롤과 CLI 도구가 최고의 효율이라 생각하지만, 대부분의 작업에서는 마우스가 더 빠르다는 연구 결과가 있음. 키보드 입력이 더 빠르다고 느끼는 이유는 초당 동작 수가 많기 때문임 AI가 생성한 코드는 거의 리뷰되지 않고, 많은 개발자들이 코드리뷰 자체를 힘들어해 읽기를 거부함. 그래서 새 프레임워크나 코드 리라이트가 인기가 많은 현상이 발생함 Joel on Software: Things you should never do, part I 다수의 AI 생성 코드는 그저 만들어지고, 간단한 테스트만 거치고 끝남. 심지어 본인조차 전체 맥락이나 이유를 충분히 이해하지 못하는 코드가 많아짐 이 연구의 요지는 “AI가 실제보다 생산성 향상이 큰 듯한 착각을 만들게 한다”로 요약 가능함. 일부 참가자만 생산성 소폭 향상이 있었으며, 대부분은 오히려 많이 떨어짐. 많은 AI 덕분에 생산성이 폭발적으로 늘었다는 사람들이 있지만, 실상은 그 효과 자체가 착각이라는 연구의 통찰이 무시되고 있음. AI는 사용자가 이 제품을 사용해야겠다, 유용하다고 믿게 만드는 데 최적화된 상품임. 개인적 가치는 지각된 현실이라 의심의 여지가 없지만, AI에 강하게 의존하는 사람은 자기 인식의 왜곡과 가짜 성취감, 도구 의존성에 대해 정말 조심해야 함. AI가 최적화된 토큰 스트림으로 대답을 해주기도 하지만, 진짜 최적화 목표가 무엇인지 한 번쯤 고민해봐야 한다고 생각함 LLM은 뭔가 배울 때 도움이 되긴 하지만, 그 이해가 굉장히 추상적이고 LLM식이 되는 느낌임. 학습할 때는 다양한 방법을 섞는 게 좋다고 여김 AI 도구는 개발자가 “빠르다”기보다는 “순간적으로 재빠르다”는 느낌을 줌. 뇌의 부담이 줄어드는 착각 같은 면이 있는데, 다른 피드백 루프에서 느낌 자체가 바뀌고 기억 형성 기제도 바뀌면서 생기는 흥미로운 착시 현상임 “경험 많은 오픈소스 개발자가 자기 프로젝트를 작업할 때 AI를 사용하면 오히려 느려진다”는 연구를 논의하던 중, 본인은 완전히 남이 만든 3개월 된 코드베이스와 익숙지 않은 프레임워크에 일하게 됨. 그런데 Claude Code를 활용해 단 몇 시간 만에, 예전 다른 프로젝트에서 하루 이틀, 혹은 최대 2주 걸릴 일(데이터 동기화 등)을 빠르게 완성했고, 엄청난 점프스타트가 됐음. 복잡도가 높아지면 점점 느려지겠지만, 도구의 도움으로 시작이 매우 빨라진 점이 놀라움 본인도 비슷한 경험이 있는데, 이 연구에서 말하는 것은 우리가 겪은 ramp-up(적응기)이 아니라, 이미 매우 익숙해진 오픈소스 개발자들이 AI로 태스크를 수행할 때의 이야기임. LLM이 새로운 코드베이스 적응을 확실히 빠르게 해주지만, 익숙해진 후에는 오히려 방해된다는 경험이 있음 “2주 걸릴 PR을 몇 시간에”라는 주장에 생산성 향상 이야기가 항상 따라 붙는데, 실제 우리가 개발 기간 예측에 얼마나 정확한지 점검되는 일은 별로 없다고 봄. 또 이렇게 급히 낸 PR의 품질이 원래 예상대로인지, 단순히 빨리 하려다 중요한 시스템 맥락을 생략해 버그 확률이 높아지는 건 아닌지 따져야 함. AI 없이도 품질 포기하면 빨라짐 AI 덕분에 평균적으로 코드베이스 및 시스템 숙련도가 자연스럽게 늘었는지도 의문임. LLM을 쓸 때의 학습 효과는 마치 새로운 언어 읽기(리딩)는 가능하지만, 직접 처음부터 쓰는(스피킹)는 어려운 것과 같은 느낌임. C++를 예로 들면 읽고 기존 것 고치는 건 가능하지만, 어디서부터 새로 만드는 건 힘듦 AI 도구 덕분에 엄청난 점프스타트를 얻었을 뿐, 연구나 글, 논문에 대한 비판적 의도가 아니라 특정 컨텍스트에서 AI가 정말 도움이 된다는 점을 말하려 했음. 단순히 코드 작성만이 아니고, 예를 들면 Claude Code가 프로젝트 내부 컨테이너에서 직접 AWS 클러스터 연결 시도 등도 해주며, 전체 인프라와 구조를 파악하는 데 큰 도움이 됐음. 본인 경험상 80~90%는 코드 품질보다 “비즈니스 가치”가 우선시됨. 실제로 코드 품질이 중요한 작업이나, 특별한 알고리즘, 자료구조가 필요한 분야에는 얼마나 쓸모가 있을지는 모르겠음. 그렇지만 좋은 예제와 명확한 맥락만 부여하면 꽤 쓸만한 코드를 써준다는 경험도 했음. 도구들은 매주 혹은 매달 빠른 속도로 발전함. 결국 AI는 마법이 아니라 도구이고, 프로덕트/결과에 대한 책임은 결국 본인에게 있음 논문(TFA)이 다루는 건 매우 익숙한 프로젝트에서의 사례임을 유념해야 함. 내가 겪은 사례는 정반대로, AI가 익숙하지 않은 상황에서 주로 활약함 “AI agentic 도구(Claude Code, Amp, Gemini CLI 등)는 프로그래밍에서 테이블쏘가 목공에 등장한 것과 비슷하다”는 비유를 인용해, 사용법을 익히면 어떤 작업은 더 빠르고 잘할 수 있지만, 익숙하지 않을 때는 오히려 손가락을 다칠 수도 있다는 근거를 듦. 본인은 agentic AI 덕분에 좀 더 야심 찬 프로젝트도 시도하게 되고, 하기 싫었거나 반복적인 일은 AI에 맡기니 생각의 여유가 생김. 반면 AI가 모두 대신하게끔 내버려두고 이해 없이 커밋만 하면 안된다는 점도 경계함. 도구답게 더 나은 사용법을 익히려는 노력이 필요함 테이블쏘 비유는 어울리지 않는다고 봄. 테이블쏘는 손 도구에 비해 정밀한 도구인데, agentic AI는 정밀함과 거리가 멀기 때문임 “당신이 AI를 잘못 쓰고 있다”는 논리는, 이미 AI가 나타나기 전 모든 오픈소스 스택을 쌓은 개발자들에게 모욕적임. 게다가 AI를 써서 가치 있는 소프트웨어가 만들어진 증거는 아직 없음 이 연구에서 Cursor 경험이 50시간을 넘은 개발자(연구 참여 시간 포함)는 단 한 명뿐이었고 이 개발자는 25% 빨라짐을 경험했음. 나머지는 모두 초보였고, 초보가 새로운 도구를 쓰니 느려지는 건 너무 당연함. 이 연구만 가지고 AI의 생산성 결론을 도출하긴 어렵다고 생각함 논문의 세부 사항을 참조하면, 비슷한(또는 오히려 더 적은) 도구 경험자를 대상으로 진행한 이전 연구들에서도 오히려 속도 향상을 보고함. LLM 프롬프트 경험은 대부분 충분했으며, 특히 Cursor가 VSCode와 유사해 별도의 러닝커브가 크지 않다는 점도 고려함. 만약 모든 개발자가 AI 도구에 엄청나게 익숙해지면, AI 없이 작업할 때 실력이 오히려 떨어져, 결과적으로 AI 사용 시 단순히 더 나빠진 상태가 기준이 되어 속도가 높아진 것처럼 보일 수 있음. 어떤 Tool을 썼는지가 중요한 게 아니라, 생산성 자가 보고가 실제에 비해 지나치게 낙관적이었다는 게 중요한 통찰이라고 봄. 실제 효과를 판단하려면 구체적인 측정치가 필요함 (논문 C.2.7 “평균 이하의 AI 도구 활용” 섹션에서 더 자세히 다룸) 오랜 기간 자신의 IDE(Vim/Neovim 등)를 사용한 개발자라면, 새로운 도구(Cursor 등)로 전환 시 생산성이 수개월간 현저히 떨어질 수 있음 본인도 같은 생각임. 익숙하지 않은 도구를 쓰는 개발자는 느려질 수밖에 없음. AI도 예외는 아님 현재 Burn(러스트 기반 딥러닝 프레임워크)의 정기 코드 리뷰어임을 밝힘. 최근 AI agent가 전부 작성한 듯한 버그픽스 PR을 닫은 일이 있었음. 해당 PR은 문제의 원인을 해결하지 않은 채 에러를 그냥 무시하는 식이었고, 쓸데없이 장황하게 변명성 코드를 추가했으며, 에러 무시 테스트까지 포함함. 커밋 기록을 위한 행동으로 추정됨. 이런 식의 AI 남용이 우려스러운 경향으로 번지고 있음 LLM이 정답을 모르면 엉뚱한 답을 내놓다가 잘못됐다고 지적하면 “맞아요, 다시 고칠게요” 식으로 반응하는 부분은 신기함. 실제로 경험 없는 사람들이 이슈를 구분 못하거나, 혹은 점차 코드를 신경 안쓰는 현상이 두려움. 본격적인 취약점, 악용 사례가 쏟아질 것이란 우려도 있음 동료의 MR을 리뷰하다, 명확히 AI가 생성한 티가 나는 테스트 케이스(thing1, thing2 등 변수명만 다르고 내용은 천편일률)를 발견함. 피드백으로 더 구분 가능한 이름을 제안하니, 이번엔 AI가 각 케이스 특징을 전부 나열하듯 너무 장황한 변수명을 붙여 결과적으로 한눈에 들어오지 않는 코드가 되었음. 작성자는 작성 속도를 크게 높였다고 느꼈겠지만, 실제로 피드백과 리뷰, 수정에 시간을 쓰며 생산성 이득은 다 사라진 셈임 “러스트로 딥러닝 프레임워크 → AI와 얽힌 악순환”이란 취지의 익살스러운 의견도 보임 실제로 커밋을 기록하려는 목적에 AI가 쓰이는 분위기는 이미 오래됨. AI는 단순한 스팸 생산도 용이하게 만듦 참고: 오래전 AI 스팸 이슈 LLM이 try:catch 구문을 넓게 써 문제 소스 추적을 힘들게 만듦을 지적함. 본인은 문제를 빨리 그리고 강하게 드러나게(=fail fast) 해서 바로 고치고 싶어함 본인이 느낀 점을 공유하자면, AI 프로그래밍은 집중 흐름이 자꾸 끊기고 더 쉽게 피로해짐. 코딩은 하루 종일 하는 것은 신화이고, 1~3시간씩 집중하고 중간에 쉬는 게 일반임. 심지어 동료의 코드나 변경사항 읽기를 하다 보면 그 시간도 일의 진도에 포함되나 실제 진전은 잘 안 됨. agentic AI(작은 코드 리팩토링 등)는 유용할 수 있으나, 큰 생산성 향상은 별로임. 코드 자동완성(예: 초기 Copilot)은 오히려 쓸데없는 노이즈가 더 많음 실제로 하루 동안 무슨 작업을 했는지 녹화하면, 그 결과는 꽤 우울할 듯함. 특히 성숙한 코드베이스의 경우, 한 시간 집중도 과장일 수 있음 낯선 코드베이스에서 트릭키한 버그(예: race condition)를 디버깅할 때는 로깅 추가, 라이브러리 함수 교체, 구조 개선 등이 필수인데, AI가 “여기서 레이스 컨디션이고 이렇게 고치면 된다”라고 단기적으로 빠른 해결만 제시하면 코드 구조나 논리 이해에 오히려 해가 될 위험도 있음. 장기적으로 AI 주도 코드 편집이 계속된다면, AI 조차 더 이상 정상적인 대응을 못 하게 될 정도로 코드가 변질될 수도 있음 “AI를 활용해 모르는 언어, 모르는 코드베이스에 기여했다”는 경험담을 들을 때마다, 단기적으론 괜찮지만 정말로 무엇을 배웠는지 묻게 됨. 이런 기여가 소규모 작업에는 쓸 만할지 몰라도, 장기적 유지보수 경험담은 별로 못 들어본 느낌임 최근 AI 도구를 적극 활용한 첫 프로젝트의 회고로, 1) 속도는 빨라지지 않았음, 2) 오히려 느려졌을 수도 있음, 3) 결과물의 품질은 더 나아졌다는 결론임. 느려짐과 품질 상승은 연결되어 있는데, 아이디어 검증이나 대안 탐색 등 주로 보조 수단으로 활용하다보니 그런 것임. AI 덕분에 생소한 영역에서 학습 경험도 좋았고, 주력 분야에서는 내 아이디어 혹은 AI의 아이디어를 다듬으며 결과적으로 품질이 향상됨. 속도만이 중요한 게 아니며, 품질을 정량화하기 어렵기는 해도, 충분히 가치 있다고 느낌 AI가 오히려 품질 증진에 기여할 수 있기에, 요즘엔 주장도 잘 하고 무턱대고 동의하지 않는 AI를 선호함. AI에게 아이디어를 부탁하고 문제점을 공격하거나, 내 아이디어의 허점을 같이 찾아달라고 하면 생산적임. 실현하지 않을 수도 있지만, 전에는 생각 못 했던 다양한 각도를 떠올릴 수 있게 해줌. 실질적으로 도메인에 대해 적당히 의견을 내줄 수 있는 동료와 대화하는 것과 유사한 경험임
• 생성일: 2025. 7. 15.

만다라트 보기: /view/619b87b038749ee5

이 만다라트에 대한 의견이나 토론을 자유롭게 남겨주세요!