경험 많은 오픈소스 개발자의 생산성에 미치는 "AI의 임팩트" 측정하기

(metr.org)

4P by GN⁺ 17시간전 | ★ favorite | 댓글 1개

2025년 초기의 AI 도구가 오픈소스 개발자의 실제 생산성에 미치는 영향에 대한 무작위 대조 실험 실시
연구 결과, AI 도구 사용 시 작업 완료 시간이 평균 19% 더 오래 소요됨
개발자들은 AI가 자신들을 24% 더 빠르게 해줄 것으로 기대했으나 실제 체감과 달리 속도 저하 현상 발생
벤치마크와 일상 경험에서 나타나는 AI 능력과 실제 효과 간의 괴리는 매우 두드러짐
연구는 AI 생산성 영향의 정확한 이해와 다양한 평가 방식의 중요성을 강조함

개요

본 연구는 2025년 초기(Early-2025) AI 도구가 경험 많은 오픈소스 개발자들의 생산성에 미치는 영향을 확인하기 위해 무작위 대조 실험(RCT) 을 수행함
예상과 달리 AI 도구를 사용할 때 개발자들이 19% 더 오래 걸리는 현상이 확인됨
이 결과는 AI 연구 자동화가 소프트웨어 개발에 실제로 미치는 영향 측정의 한 사례로 해석됨
본 방법론을 바탕으로 AI R&D 가속의 현실적 효과를 지속적으로 추정할 계획을 밝힘

연구 동기

기존 코딩/에이전트 벤치마크는 실제 업무 상황을 충분히 반영하지 못하는 한계가 있음
- 자가용 테스트, 컨텍스트 없는 단발성 과제, 자동 채점 구조 등으로 인해 AI 능력을 과대평가할 수 있음
- 반대로, 인간의 적응적 개입이 없는 경우, 실제 AI 모델 성능이 과소평가될 가능성도 존재함
이런 한계를 보완하기 위해 실제 오픈소스 개발자 생산성에 미치는 영향을 실험하여 AI의 현실적 영향을 측정함

실험 방법

16명의 오픈소스 베테랑 개발자를 모집하여, 각자가 수년간 활동한 대형 저장소(평균 2만2천+ 스타, 100만+ 코드 라인) 내 실제 이슈 246개를 선정
각 이슈별로 AI 사용 허용 또는 금지하는 그룹에 무작위로 배정함
AI 허용 시 개발자는 Cursor Pro 및 Claude 3.5/3.7 Sonnet 등 최신 모델을 자유롭게 사용, 금지 시엔 생성형 AI 도움 없이 작업 수행
참가자들은 각 이슈(평균 2시간 소요) 해결 과정을 녹화하고, 자체적으로 소요 시간을 보고함
실험 참가자에게는 시간당 150달러 보상 지급

주요 결과

AI 도구를 사용할 때, 이슈 해결 시간이 평균 19% 더 길어짐
개발자들은 AI가 실제로 생산성을 24% 높여줄 것으로 기대했으며, 실험 후에도 여전히 20%의 속도 향상을 체감한다고 응답함
이처럼 인지와 실제 성과 간에 큰 괴리가 나타남
특정 오해를 방지하기 위해, 본 연구는 다음 내용에 대한 증거를 제공하지 않음:
- 모든 개발자 또는 소프트웨어 개발 전체에서 AI가 느려진다는 일반화
- 다른 분야나 세팅에서 AI의 효과 규정
- 가까운 미래에도 동일한 결과가 지속된다는 단정
- 기존 LLM·프롬프트 기법의 최적화가 불가능하다는 주장

영향 인자 분석

작업 지연을 설명할 수 있는 20가지 요인을 분석, 이 중 5가지가 실제 영향을 준 것으로 판단함
실험 조건, 모델, 이슈 난이도, PR 품질 등 주요 변수가 실험 결과에 의미 있는 영향을 주지 않음이 확인됨
지연 현상은 다양한 데이터 하위집합 및 추정 방법에서도 일관적으로 관찰됨
상세한 분석 내용은 논문 원문에서 확인 가능

결과 해석 및 논의

증거의 충돌 및 원인

AI 벤치마크 점수/사례 보고/실제 실험 간의 결과 차이가 뚜렷함
벤치마크는 자동 채점이 가능한 협소한 문제 중심으로 AI 능력을 측정함
- SWE-Bench: 테스트 기반 오픈소스 PR, RE-Bench: 알고리듬 평가 가능 문제
실제 RCT에서는 20분~4시간 소요되는 복잡·현실적인 작업에서 인간이 오히려 더 느려짐
반면, 산업 현장이나 커뮤니티에서는 AI가 장시간 업무에 상당히 유용하다는 정성적 보고가 많음

해석 프레임워크

각각의 방식이 “실제 능력”을 다르게 측정하는 특성이 있음
사례별 접근 방법:
- RCT의 저평가 문제: 우리 실험 세팅에만 해당하는 특수성 존재 가능성
- 벤치마크/사례의 과대평가 가능성: 실제 풀이와 괴리, 자기보고 근거의 신뢰성 미흡
- 세 방식 모두 실제 일부 하위 문제에만 잘 맞을 수 있음
서로 다른 출처와 실제 능력치의 괴리는 측정 오류·편향(빨간색), 측정 범위 차이(파란색) 라는 해석이 가능함

실험의 추가적 시사점

RCT 결과는 수백 또는 수천 번 AI 결과를 샘플링하는 환경에는 해당하지 않을 수 있음
수십~수백 시간 Cursor 등 AI 도구를 사용한 후에야 능률 향상이 나타날 가능성 존재
고품질 코드, 암묵적 요구사항(문서화, 테스팅, 포맷팅 등)이 많은 환경에서 AI 능력이 제한될 수 있음
벤치마크는 문제 범위가 좁아 실제 업무 난이도를 적절히 반영하지 못함
정성적 체감 보고는 과대평가 및 자기 착각 효과로 신뢰성 저하 가능성이 있음

어떤 단일 평가 방식도 완벽하지 않으므로 서로 보완적으로 사용할 필요성이 강조됨

향후 전망

본 방법론을 지속적으로 개선하여 AI 도구가 개발자 생산성을 실제로 얼마나 변화시키는지 정량 추적 예정임
만약 AI 도구가 현장 개발자의 능률을 크게 높인다면, AI R&D 전반의 급격한 가속/감시 실패/권력 집중 위험 등도 함께 발생할 수 있음
실제 환경에 적합한 평가 프레임워크의 개발이 향후 AI 발전과 산업 전반에 매우 중요함

▲

GN⁺ 17시간전 [-]

Hacker News 의견

Simon Willison의 댓글:
전체 논문은 요약본에서 빠진 세부 내용이 많음 논문 링크
제 개인적인 생각으로는 LLM 기반 AI 도구에서 실질적인 생산성 향상을 얻으려면 사람들이 예상하는 것보다 훨씬 더 가파른 학습 곡선이 존재함
이번 연구엔 다양한 AI 도구 활용 경험을 가진 16명이 참여했으며, 56%는 Cursor를 처음 써봤고, 주로 Cursor에 대한 연구였음
각 참가자는 총 약 15개의 이슈를 다뤘으며, 이슈별로 AI 사용 가능/불가가 무작위로 지정되었음
즉, 한 개발자가 AI가 허용된 과제와 허용되지 않은 과제를 섞어서 진행했음
참가자 중 1/4만 성능이 향상되었고 3/4는 성능이 저하됨
AI 사용 상위권은 Cursor를 50시간 넘게 써본 사람이었음
연구진도 Cursor 경험이 충분한 개발자는 성능 향상이 있었다고 인정함
내 직감으로는, 이 논문은 AI 협업 개발에서 학습 곡선이 높기 때문에, 실무에서 기존 워크플로우에 곧바로 섞으면 오히려 성능이 저하됨을 보여줬다고 생각함
- LLM에 대해 “너가 제대로 못 써서 그래”라는 흔한 반응이 있는데, 이건 너무 책임을 사용자에게 떠넘기는 변명 같음
  대부분의 기술 제품에서는, 사용자가 가치를 느끼지 못한다면 제품의 설계 자체가 잘못된 거라고 생각함 AI에는 왜 이런 논리가 적용되지 않는지 의문임
- Simon에게 감사, 그리고 논문을 꼼꼼히 읽어줘서 고마움 - OS 프로젝트 팬임 몇가지 중요한 포인트를 짚고 싶음
  1) 기존 연구 중 일부는 도구 경험이 적더라도 성능 향상을 보임, 즉 “가파른 학습곡선” 이론만으로 이번 결과가 다 설명되지는 않음
  2) 연구 전 참가자의 90% 이상이 LLM 프롬팅 경험이 있었고, 프롬팅만이 주요 스킬로 여겨짐. VSCode 사용에 익숙하면 Cursor도 쉽게 쓸 수 있다는 게 정설이었음
  3) 모두 AI에 익숙했다면 AI 없는 상황에서 오히려 더 못할 수 있음(적어도 나는 공감함), 오히려 이렇게 되면 AI가 더 나은 것처럼 보이는 착시 현상이 감점 효과
  4) 경험 정보는 미리 예측 전문가들과 공유, 그럼에도 불구하고 예측가들은 생산성 향상 기대치를 지나치게 높게 잡았음
  5) 수백 시간의 사용에 의한 롱테일 스킬이 실제로 존재할 수 있음, 본 연구에서는 이러한 부분까지 말하기 힘듦
  논문이 놀라운 결과를 주니 읽은 사람이 한가지 요인을 뽑아서 “이 것 때문이다!”라고 쉽게 결론짓기 쉬움
  실제로는 복합적인 원인일 수 있음(최소 5가지, 최대 9가지는 배제 불가, 11쪽 표 참조)
  한가지 정말 중요한 시사점: 개발자의 자기 보고 만족감은 실제와의 간극이 심했고, 이는 사용하는 툴의 종류와 무관함
  생산성 측정에는 현장에서의 실제 데이터가 꼭 필요함(논문 C.2.7 참고: “평균 이하의 AI 도구 활용” 섹션에서 자세히 다룸)
- 참가자 75%가 LLM 경험이 있음에도 AI 사용 시 작업 속도가 오히려 느려졌다로 해석할 수 있는데, 하나는 LLM 학습곡선이 매우 가파르다는 해석, 또 하나는 현재 LLM의 실제 프로그래밍 보조 효율이 과대평가되어 있다는 점임 사람들이 일관되게 성능 예측을 착각하고 있음
- LLM을 잘 다루게 되어도 본인이 작성한 코드에 대한 이해도가 떨어질 수 있음
  개발자는 시간이 갈수록 코드에 정통해지지만, LLM은 오히려 점점 안 좋아질 수 있음
  LLM으로 빠르게 코드를 생성할 수 있지만, 충분히 신경 쓰지 않으면 코드에 대한 숙련도가 축적되지 않음
  초반에는 경쾌하게 빠른 개발이 되지만, 막상 뒷단에선 이해가 부족하고 LLM도 초기엔 쓸만하다가 점점 개선이 안 되어, 어느 순간 LLM도 그 사용자도 감당 못하는 난장판 코드가 됨
  유혹을 피하면서 LLM이 좀 더 깔끔한 코드를 내도록 끈질기게 관리하고, 본인도 코드를 꼭 공부해야 한다고 생각함 스스로 이해하려는 노력이 필요함
- AI 도구로 인해 생산성이 높아진 사람도 있고 아닌 사람도 있는 걸 볼 수 있음
  내 추측으론, 긴 텍스트나 코드를 빠르게 읽어낼 수 있는 사람이 상당한 이점을 가짐
  쓸모없는 제안을 빨리 알아채고 좋은 답을 얻을 때까지 반복하는 능력이 매우 중요함
  빠른 스캐닝 능력은 경력자와 상관관계가 있지만, 의외로 신입 중에도 이게 빠른 사람이 있음
  검색 능력이 뛰어난 사람이 LLM 활용에서도 유리할 수 있음, 구글링 능력과 비슷한 맥락으로 보임
80/20 법칙을 다시 떠올리게 됨 - 전체 작업의 80%를 20% 시간 내 해결해주고 나머지 20%를 위해 80% 시간을 소모함
항상 “거의 다 왔다”는 느낌이 있어서 매몰비용 오류에 빠지기 쉬움
최근 시도해본 방법으론, AI를 “해결사”가 아니라 “마찰 제거자”로 활용하는 방식이었음
프로그래밍은 내가 직접 하면서, 사소하게 까먹은 문법 같은 것만 AI에 물어서 작업 속도를 높임
직접적인 코드 전체 제안은 거의 안 봄 항상 스스로 생각하면서 코드를 작성해, 이해도와 실력 저하를 막음
- 예전에는 80% 작업에 80% 노력, 남은 20%에도 또 80% 노력이 들어가는 역-파레토 방식임
  “작은 장애물”만 해결하는 AI 활용에 동의함
  어제도 자바 stream API로 List 처리하면서 ConcurrentOperationsException 때문에 애먹었음
  직접 메서드 작성하다가 안 풀려서 AI에 “스레드 안전한 리스트 변환 메서드” 맡겼더니 해당 API에 이미 내장 메서드가 있다고 알려줌
  이런 잡다한 문제엔 AI가 최고임 - 복잡하지만 정의가 명확할 때
- Stack Overflow를 좀 더 강력하게 쓸 때 특히 유용함, 내가 해야 할 일을 대략은 아는데 구체적으로 환경에 맞춰 어떻게 할지 모를 때, 그리고 디버깅이나 러버 덕킹에도 도움 됨
- “마지막 20%를 위해 80% 시간을 소모한다”는 게 AI 도입 전에도 내 경험이었음 초기에 걸리는 시간만 줄여도 좋음 관련 경험자로부터 들었던 최고의 AI 평가는 “내 기술의 90%가 무가치해졌고, 나머지 10%는 천 배 더 중요해졌다”는 것임, 과장이 있지만 핵심은 마음에 듦
- “항상 거의 다 됐다”는 착각 때문에 오히려 시간 낭비가 유발됨 AI가 뭔가 유용해 보이도록 만드는 데 특화되어서, 진짜 생산성 향상인지 판별하려면 높은 수준의 비판적 사고가 필요함
- 기존 코드베이스에 기능을 추가할 때 특히 유용함, “기존 검색 파라미터 외에 foo를 추가해야 한다”거나 “x 관련된 코드를 제거해달라” 같은 작업에서 좋음
HN 유저들에게, 논문 저자임 - 오래된 HN 사용자이고 오늘 댓글에 질문/피드백 달리면 최대한 답변해주고 있음 시간 없다면 논문 전체 대신 소개 블로그 포스트나 x.com의 발표 스레드를 추천함
- 논문의 방법론과 저자님의 소통 방식이 매우 프로페셔널하고 인상 깊음, 좋은 연구임
- 이 연구는 클릭베이트 없이 솔직하게 연구 결과를 제시하고, 읽기 쉽게 잘 정리되어서 최고의 연구 중 하나라고 생각함
- AI로 처리하는 티켓이 정말 AI에 적합한 유형이었는지 고려했나요? “이 티켓 AI로 처리해봐”라는 식이 현실적이긴 하지만 비효율적일 수도 있음 AI에 적합하게 쓰면 정말 한몫하는데, 오히려 역효과인 경우도 많음 연구 참가자들이 충분한 AI 경험이 있었다면 이 구분을 해냈겠지만, 논문을 읽으면서 그 여부가 명확하지 않음
- 가능한 한 익명 처리된 원시 데이터셋 공개나, 최소한 개발자별 작업 소요 절대 시간 정보를 논문에 추가해줄 수 있는지 궁금함 Cursor 경험이 많은 참가자가 실제로 다른 사람보다 빠른지, 아니면 원래 느린 사람이라 AI로 더 큰 상승 효과를 얻었는지 궁금함 Hawthorne effect(관찰자 효과)까지 고려한 진짜 좋은 실험적 평가를 볼 수 있어 기쁨
- (논문은 안 읽고 포스트만 봄) 주관적 피로도(subjective fatigue)가 AI가 더 빠르다고 오해하는 원인을 설명해주는 지표로 측정했는지 궁금함 개발자에서 관리자 전환 후 뇌가 피곤한 상황에선 AI가 더 편해서 좋음
이 연구 결과, 특히 “개발자들은 AI가 속도를 24% 올릴 것으로 기대했으나, 실제론 느려졌음에도 경험 후에도 20% 빨라졌다고 믿음” 부분이 매우 흥미로움. 이렇게 실제와 인식의 간극이 드라마틱하게 큰 이유가 뭘까? 혹시 뇌가 ‘정신적 노력’을 시간의 경험으로 착각해서 그런 게 아닌지도 궁금함
- 근거는 없지만 무서운 생각이 있음: 코딩할 때 AI와의 상호작용이 마치 소셜미디어 도파민 루프와 비슷하게 뇌를 자극하는 것 아닐까(정도는 다르긴 해도) AI가 반복적으로 답을 제시하면서 두뇌가 긍정적 평가를 받는 것처럼 느끼게 되고, 그래서 개발자가 AI를 실제보다 더 긍정적으로 평가하는 현상이 생기는 것 아닐지? 혹시 이게 중독 현상까지 일으킨다면, 실제로 생산성 효과를 과대평가하게 되는 것 아닐지?
- 이 현상은 시장에서 많은 사람들이 AI 도구를 실제보다 더 뛰어나게 믿도록 만드는 거대한 캠페인 결과일 수도 있음 경제 전문가, ML 전문가 그룹 자체가 AI 회사 이해관계자와 겹치고, 경영진이 그걸 곧이곧대로 받아들여 큰 성과를 약속함 그게 결국 기반 기대치를 전체적으로 올려버리는데, 경험 많은 개발자에게도 영향을 끼침 경험적으로 입증하기 어렵지만, AI 생산성에 대한 집단적 착각이 넓게 퍼진 이유일 수 있음
- HN 댓글의 많은 AI 열성팬도 이 현상에 빠져있을 가능성을 궁금해함 실제로 스스로 성능을 측정하지 않는 한, AI가 정말 본인 생산성을 올리고 있는지 미심쩍음
- 가끔 정반대의 경험을 하기도 함 오늘 Claude code로 예제 데모 앱 코드를 만들려고 해봤는데, 구경하면서는 멋지고 SF 같아서 재밌었지만 15분만에 정신이 멍해지고 지루해짐
“개발자들은 AI가 24% 더 빠르길 기대했고, 실제로 느려졌음에도 20% 더 빨라진 것 같다고 믿었다”는 걸 보면, 여기엔 두 가지 문제가 있다고 느낌
하나는 동일 인물이 같은 맥락에서 AI로 했을 때와 안 했을 때 걸리는 시간을 제대로 비교하기 힘듦
또 다른 하나는 PR 오픈/머지까지 걸리는 기간 같은 표면적 지표로 AI 효율을 측정하기 쉬운데, 실제로 AI 도입하면 리팩토링, 테스트, 이슈 해결 등 후처리에 더 많은 시간이 배분됨
“PR이 빨리 열렸다”만 보고 AI가 빠르다 착각하기 쉬움, 하지만 향후 작업이 늘어나는 걸 간과하기 쉬움
- 특정 기술이나 관행이 생산성에 미치는 영향은 측정이 정말 어려움 자기 보고(anecdote)만 믿고 결론내리는 건 위험하다고 봄, 누구든 쉽게 자기환각에 빠질 수 있으니까 연구 자체도 한계 인정하고 있으니, 생산성 관련 논의엔 큰 오차범위를 의식해야 함 AI라는 기술은 살면서 본 것 중 제일 이상함, 단편 사례나 의심스런 벤치마크로부터 인과관계를 읽어내는 건 거의 운세풀이 같음
- 논문에서는 AI 허용/비허용 상황에서 PR 품질 저하가 관찰되지 않았음 참가자들 대부분은 리포지토리 기준에 익숙하고, ‘대충 제출해서 PR 띄우기’ 스타일이 아님 연구 내 PR의 중간 리뷰 시간은 1분 정도임 작성자의 말대로 시간 사용 방식은 완전히 달라짐 논문 10쪽에 AI 사용/미사용별 시간 분포가 나와있으니 참고 바람, AI 활용 시 코딩 시간은 줄고 AI랑 상호작용 시간은 늘어남
- “동일인이 동일 맥락에서 AI로, 혹은 AI 없이 작업할 때 각각 걸린 시간 차이”를 정확히 아는 건 불가능하다는 지적에 대해, 실험 설계상 무작위 할당(random assignment)을 통해 AI 그룹과 비AI 그룹 효과를 분리함 개인, 상황, 환경 등의 차이는 무작위 처리로 상쇄시킴 표본과 효과 크기만 크면 통계적으로 의미있는 차이를 뽑아낼 수 있음
- Figure 21을 보면 초기 구현(PR까지 걸린 시간) 자체도 증가했고, PR 리뷰 후 시간이 더 늘어나긴 했어도 전체적으론 큰 영향은 없어 보임 Figure 18에서 확인할 수 있듯 실코딩 시간은 줄었지만, 프롬프트 작성과 결과 대기, 출력 검토 등으로 절감 효과가 상쇄됨 5분 이하 단순 작업은 오히려 LLM 활용을 안하는 게 더 나았을 수도 있음
각 워크플로우별 PR 내용을 비교해보고 싶음 Copilot은 내가 직접 할 때보다 더 많은 코드를 제안하는데, 불필요한 체크나 반복, 추상화 없이 코드량이 많아지는 경우가 많음 내 개인적인 가설은, LLM이 너무 많은 코드를 써내는 모습을 보면 문제 해결에 얼마나 오래 걸릴지 체감이 왜곡되는 것 같음
LLM을 활용해 대규모 코드베이스에서 작업할 때 진짜 어려운 점은, 해야 할 작업을 정확히 묘사하는 것임 수많은 코드 상호작용 속 이슈를 설명하는 데만 오히려 손으로 직접 처리하는 것보다 오래 걸릴 때가 많음, 반면 신규 프로젝트에서 보일러플레이트 코드 만들 때는 LLM과 가장 잘 맞는 것 같음
- 나도 같은 경험임 Knuth가 말하듯 코드의 본질은 코드 자체뿐 아니라 개발자의 머릿속에도 존재함 모든 맥락을 정확히 LLM에 전달하지 않는 한, 몇 년간 쌓인 개념과 전략을 다 쏟아낼 수 없음
참가 개발자 모집비만 300 x 246 = 약 73K를 써놓고 논문은 학술지에 실리지도, 동료 검토도 없음 논문은 겉으론 정돈돼보이고 AI 생성스럽진 않지만 어떻게 이런 자금이 가능했는지 궁금함
- 가장 큰 재정지원은 The Audacious Project였고, 공식 발표 통해 확인 가능함 또 2025년 4월까지 AI 회사에서 받은 평가 대가가 없다고 웹사이트 각주에 명시돼있음
- 회사들은 이런 류의 ‘화이트페이퍼’를 자주 냄 기술 보고, 정책 제안, 홍보물의 결합 형태임
- 학술지, 동료 리뷰 유무만 따지는 건 의미가 없다고 봄 과학은 누가 출판하든 중요한 게 아니라 재현과 반복 성과가 핵심임 심리학의 재현 위기 사례처럼, 저널 등재 자체가 신뢰성을 담보하지 않음
- 대부분의 나라에선 연구에 공적 지원금이 있음, 미국은 과거에 더 지원했으나 근래엔 대폭 삭감되었음
- 재단 소개 페이지를 보면 AI 회사, 정부 등 다양한 곳에서 자금을 받는 듯함
취미 OSS 프로젝트에서 AI는 오히려 방해만 됨 코드 생성/스캐폴딩은 오히려 걱정거리가 아님, 오히려 코드리뷰, 커뮤니티 관리가 더 중요함 AI 도구로 할 수 있는 일은 한계가 뚜렷함 그런데 누군가 내 오픈 PR에 AI 코드 리뷰 도구를 투입해서 30줄짜리 PR에도 이모지와 정리된 글머리표로 2페이지 짜리 요약을 뱉어냄 불필요한 소음 줘서, 이제는 그런 코멘트 지우거나 숨기느라 진짜 유지보수 시간만 더 줄어듦
학습곡선만 넘으면 빨라지지만(혹은 누군가 말한 대로 “이제는 AI 없이 일하는 법을 까먹을 때까지”) 진짜로 측정해야 할 건… 새벽 3시에 PagerDuty 알람 울릴 때, 정말 그 코드 디버깅까지 걸리는 시간임 또 그 코드의 장기적 품질은 어떤지 궁금함 나는 비즈니스 로직을 공유 폴더로 끌어올리고, 호출 체인을 위로 모아 API는 깔끔하게 내리고, 로직/API/디스플레이 분리, 캡슐화 등 코드 구조를 오랜 시간 개선해왔음(의존성 주입으로 결합도 감소 등) AI 코드가 장기적으로 더 나은 품질/이식성/확장성이 생길까? 아니면 결국 품질이 낮은 코드가 점점 쌓여 엉킨 쓰레기장이 되어, 결국 버그 수정에 시간의 절반을 쏟아붓게 되는 것일까?

답변달기