내게 AI는 종 모양 곡선과 같음, 많은 사람들에게도 비슷할 거라고 봄. 아웃풋을 평가하는 기준이 중요하다고 생각함. “코드 라인 수”가 아니라 “좋은 품질의 유지 관리 가능하고, 확장 가능하며, 업그레이드가 쉬운 코드 라인 수”여야 함. 이 기준으로 보면 “전체 레포 생성” 같은 요청의 결과는 의미가 없는 쓰레기이지만, AI가 “getUser(…” 같은 코드를 자동 완성해주는 것은 생산성 향상임. 이게 0.1% 증가인지 1%인지 10%인지는 확실하게 말할 수 없음
내 입장에서 가장 심각한 문제는 지금 회사에서 내가 다루는 문제들이 신중한 계획과 실행을 요구하는데, AI가 전혀 도움이 되지 않는다는 점임. 그런데 우리 매니저는 “우리는 AI-first 회사”라는 이유로 프로젝트 납기 시간을 기존 견적의 20%로 줄였다고 함. SVP들과 PM들 사이에서 이런 집단적 광기가 엄청나게 번지고 있고, 이런 건 전에도 본 적 없음
매니저가 프로젝트 납기를 원래 견적의 20%로 줄였다고 말했는데, 이건 정말 말도 안 되는 일이라고 생각함. 이런 비현실적인 수치를 누군가가 그냥 정해서 현실로 만들어버림. 결국 안 되면 그 책임을 나에게 돌릴 것이고, 위에서는 그 매니저에게 책임을 물을 거임. AI로 정말 생산성이 올라간다면 불필요한 개발자를 정리하면 되지만, 그건 LLM이 개발 프로세스에 성공적으로 자리 잡은 후에 할 일임. 투자금도 AI 버블에 대비해서 S&P 500에서 빼야 하나 고민이 생김
만약 인시던트 대응까지 LLM에게 맡길 수 있다면, CEO가 원하는 대로 하게 두고 그에 따른 평판적인 손해도 감수하면 됨. 만약 실패하면, LLM이 작성한 코드 이전 시점으로 git을 되돌리면 된다고 생각함. 농담 반 진심 반임
현재 AI 수준은 개발자를 대체할 정도는 아니지만, 이전에는 자동화하기 어려웠던 많은 오피스 업무나 매니저 역할은 충분히 자동화할 수 있을 만큼 좋아졌다고 생각함. Google은 실제로 AI 때문에 미들 매니지먼트를 많이 줄였고 개발자는 그만큼 줄이지 않은 듯함
AI가 기술 리더십이 부족한 매니저들이 개발자에게 압박을 가할 핑계로 쓰이고 있음
여러 가지가 동시에 사실일 수 있음. LLM이 무작위로 선정된 일반적인 작업에 대해 개발자 생산성을 10배로 올려주는 건 아님. 반면 LLM이 특정 범위의 작업에서는 생산성을 극적으로 높여줌. 바쁜 반복 업무를 자동화하는 데도 쓸 수 있는데, 인간보다 실제 시간은 오래 걸려도 백그라운드로 작업이 돌아가니 문제되지 않음. 새로운 API나 라이브러리를 익히는 데 LLM이 훨씬 속도를 올려주고, 모르는 언어로 작은 glue 코드를 짤 때 시간도 아끼고 불필요한 학습까지 안 해도 되어 엄청난 도움임. 큰 기존 코드베이스 보수 작업엔 별 생산성 차이를 못 느낌. 새로운 웹사이트 스캐폴딩 세팅은 LLM이 놀랄 정도로 잘함. mock 클래스 작성도, mock 라이브러리 사용법을 잘 파악해서 내가 두어 번 해보다 까먹는 복잡한 작업도 순식간에 처리함. 새로운 코드베이스 구조 파악도 70% 정도는 만족스럽게 해줌. 복잡하게 설계된 프로젝트에서 HTTP 라우트 위치나 의존성 주입 함수 위치 찾기 등에도 “야 Claude, auth 관련 함수들 어디 있냐?” 이렇게 물어보면 편함. 올바른 도구를 올바른 작업에 써야 한다고 생각함
새로운 API나 라이브러리 익히기가 LLM 덕에 훨씬 빨라졌다는 느낌을 동의하면서도, 막상 LLM의 답변을 살펴보고 문서도 직접 읽어보면 관례를 안 따르거나 단순한 예제만 쥐어짜고, 잘못된 특징을 써서 돌아가는 방식이 엉뚱하거나 복잡한 길을 택할 때가 있다는 점이 걱정임. 마치 마법처럼 느끼다가도 너무 믿다 보면 실제론 제대로 이해하지 못하는 착각에 빠지기 쉬움
“바쁜 반복 업무를 백그라운드에서 LLM이 자동화한다"는 게 구체적으로 뭔지 궁금함. 실제로 어떤 업무에 성공하고 있는지 AI 옹호자들이 구체적인 예시를 명확하게 밝혀야 된다고 생각함. 두루뭉술함에 점점 피곤해짐
“LLM이 새로운 API와 라이브러리를 빠르게 익히게 해준다”라는 표현이 더 정확하려면 “이미 오래된 라이브러리나 API를 처음 접할 때”로 바꿔야 할 것 같음. 정말 새로운 라이브러리나 툴에는 LLM이 별 도움이 안 되는 경우가 많음
영상 속에서 스크린에 코드가 쏟아지고, “주니어 개발자들은 끝났다”는 주장 이상의 실체가 없는 게 대부분임. 그 이유는 경제가 불안정하고, AI가 구원자가 되어줄 거라는 기대에 과장과 불안이 가득한 분위기라 생각함. 실제로 AI로 인상적인 결과를 얻을 때도 있긴 하지만, 기본적으로 어느 정도 실력 있는 사람이 아니면 무의미함. 초보~중급 수준의 사람들은 소셜미디어에서 과장된 성공담만 쏟아냄. 사람마다 “AI 슈퍼파워”를 지키려고 심리적·현실적으로 애쓰는 분위기가 형성됨. 결국 하이프 사이클에서 어느 순간 균형점을 찾고, 몇십억 달러가 다시 소각될 날을 기다릴 뿐임
내 경험상, AI 툴들은 완전히 빈 프로젝트(블랭크 캔버스)에선 정말 능력을 발휘함. 예를 들면 새로 React 프로젝트를 만드는 데는 툴이 나보다 빠르게 세팅해줌. 그런데 실제 업무 레포지토리에서는 거의 쓸모가 없음. 이렇기 때문에 AI 툴들이 데모와 홍보에선 엄청난 인상을 주지만, 현실에선 실망만 남기는 결과가 나옴
“충분히 직접 수동으로 해볼 만큼 경험이 있는 사람”이어야 잘 다루는지, AI 툴과 그 한계에 익숙한 사람이어야 하는지, 아니면 그 둘 다가 필요한 건지 궁금함
AI에 관한 과장된 이야기는 대부분 깊이 없는 논문 추상만 읽고, 곧 현실화될 거라 떠드는 대중 과학 미디어 기사랑 비슷하게 들림
내 경험상, AI는 일부 사소한 작업(예: 소규모 리팩토링, 타입 정의 자동화 등)에 쓸모 있었지만, 그 이상의 복잡한 작업에는 여러 가지를 놓치고 재작업이 필요했음. 미래에는 내 말을 다시 생각하게 될 수도 있겠지만, 최근 더 경험이 적은 엔지니어들이 큰 기능을 구현하려고 AI가 내놓는 결과물을 “좋은 코드”라고 무비판적으로 받아들이는 경우가 늘었음. 그런데 이 코드들은 우리 스타일 가이드와 패턴을 따르지 않거나, 이미 나와 있는 라이브러리 대신 굳이 로직을 처음부터 구현해서 결국 우리가 직접 관리해야 할 코드가 늘어남. 나중에는 모든 걸 한 번에 하려는 거대한 PR이 나오기도 함
순수하게 새로 만든 코드라면, 종종 50줄 정도 코드를 위해 큰 라이브러리를 끌어오는 것보다 그냥 짓는 게 이롭다고 생각함. 이 점은 긍정적임
이런 코드들과 라이브러리의 존재 자체를 파악하는 ‘발견’이 숙제로 남아 있고, 팀원들이 내부 코드를 독립적으로 알아서 쓰려면 문서 또는 검색 자체를 LLM에 기대하는 방식도 연구 중임. 내부 라이브러리 지식이 편중되는 현상이 고민거리임
진입 단계 개발에선 상황이 달라짐. 프로젝트 초기에 코딩 스타일이나 기준이 없는 상태라 LLM이 내는 결과가 팀원들이 내는 의견과 큰 차이가 없음. 데모 상태까지만 코드를 만들어도 가치 있음. 여러 프로젝트를 빠르게 데모 단계까지 만들어보는 게 큰 부스트임
여기 주장에 동의함. AI를 써도 생산성 획기적 상승은 못 봄. 소프트웨어 엔지니어가 꾸준히 문제 해결, 분별, 코드화 연습을 안 하면 신경 지식이 약화될 수 있다고 봄. AI가 미래의 2배, 10배 생산성을 가져다 줄 기술이라는 약속은 실체가 없고, 개인 코드베이스에서 약간의 생산성 증가가 있었더라도, 시장에서 실제로 더 나은 제품 출시가 늘진 않았음. 컨설팅을 하면서 종종 파운더나 CTO들이 AI를 밀어붙이다가 오히려 코드를 제대로 관리하지 못하고 더 많은 혼란을 초래하는 걸 자주 봄. 요즘은 엔지니어링 베스트 프랙티스 확립을 위해 어드바이저 역할을 맡는 경우도 많음
대부분의 기술이 그렇듯, 실습과 연습이 끊기면 감각이 둔해짐. 자전거 타기도 오랜만에 하면 몸의 감각이 녹슬듯, 코딩 능력도 실질적으로 약해짐. IT 엔지니어링에도 해당한다고 믿음. 실제로 경계해야 할 신호임
CEO들이 AI로 기존 개발자 생산성이 10배 오른다고 말하지만, 그게 진짜라면 오히려 개발자를 훨씬 더 많이 뽑아야 하는 거 아닌가 싶은 의문이 듦. 만약 같은 투자로 생산성이 10배 오르면 당연히 그 “엔진”에 돈을 퍼붓는 게 합리적임. 그런데 현장에선 생산성은 그대로인데 인건비만 줄이는 데 그친 게 아닌가 싶음
이익률이 떨어지면, 결국 인건비에서 가치를 짜내야 한다고 생각함. AI의 99% 매력은 인건비 절감이고, 채용은 그에 역행함. 나 또한 AI의 생산성 향상 주장에 동의하지는 않지만, 이런 동기 요소가 있다는 점을 지적하고 싶음
많은 C레벨들이 남아있는 인력도 AI로 대체할 거라 기대하는 듯 보임. “곧 AGI가 실현된다"는 내러티브를 따름. 난 그렇게 믿지 않지만, 그런 입장이라면 개발자 더 채용하지 않을 논리도 이해됨
오늘 “수익체감의 법칙”이 뭔지 배울 수 있을 것 같음. 한 조직에 투입할 수 있는 인간·자원의 한계가 존재함. 필요 이상 투입은 무의미함. 해고가 늘어난 이유는 AI가 효율을 올려줬기 때문인데, 인간 한 명이 하던 업무량을 AI가 커버하게 되면 그만큼 고용이 줄어듦. 한 인간 = 한 AI가 아니라, 업무량이 AI에게 넘어가 인간이 줄어드는 구조임. 사람 대체가 완전히 끝난 건 아니지만, 얼마나 인간이 필요한지가 새로운 수요·공급의 기준이 될 것임. 창의적 인재는 항상 더 필요할 텐데, 그런 인재가 부족함. 연봉 10만~20만불 원하는 소프트웨어 엔지니어 중에는, 기업에 얼마를 절약시킬 수 있는지도 모르는 경우가 많음. 학교 교육이 창의력을 죽였다는 생각도 듦. 문제는 역량 부족이 아니라, 스스로 방향을 컨트롤하거나 아이디어를 만들어내는 힘이 부족한 데 있다고 봄
신선한 각도로 신제품 출시량을 바라보는 분석이 인상적임. 빠른 성장 대신 예상보다 큰 변화가 없다고 느꼈음. 대안론으로, 실은 코드 작성이 제품 출시의 병목이 아니었고, 무엇을 만들지 탐험하며 실제 플랫폼에 올리는 것 자체에 많은 시간과 노력이 소요된다는 해석도 가능함. 한편 AI 툴을 잘못 쓰기가 너무 쉽다는 점도 동의함. 때론 “드디어 깨달았다!” 하다가도 다음 날 “또 다른 방법으로 잘못 쓰고 있었구나” 깨닫게 됨. 소프트웨어 개발이 왜 이렇게 어렵고 생산성 가속이 어려운지, 20년 이상 개발을 해도 여전히 명확하지 않음
“코드 작성이 병목이 아니었다”는 통찰이 정말 와 닿음. 소프트웨어에서 진짜 가치는 “어려운 문제”를 푸는 데서 나오고, 쉬운 문제는 이미 템플릿처럼 어디에나 있음을 깨달음. LLM이 쉬운 문제는 빨리 끝내지만, 진짜 병목은 여전히 “하드”한 문제에 있음. 기술, 비즈니스, 고객 등이 이유가 되어 어려운 문제들은 LLM으로 제대로 풀리지도 않고, 진짜 이득은 이 지점에 있음. 반면 템플릿화 가능한 쉬운 문제들은 LLM이 진짜 생산성을 높임
소프트웨어 제공에서 코딩 자체가 병목이 된 적은 없었음. AI는 회사 인력 감축의 명분이나 투자 유치용 구실로 활용될 뿐임
제품 개발에서는 반복적인 사용자 피드백, 예외 케이스 고치기 등 시간이 필요한 과정은 아무리 AI가 있어도 단축시키기 어려움. 이런 점이 소프트웨어가 10년은 걸린다는 joelonsoftware.com의 글과도 연결됨
우리가 그 미래를 지금 만들고 있음. 실제로 내가 속도가 붙기 시작한 건 agentic AI가 충분히 좋아진 4~5월 부터였음. 오늘만 해도 iMessage 아카이브를 웹사이트로 익스포트하는 CLI 도구를 만들었고, 예전 같으면 몇 주 걸릴 일이 이제 하루 이틀 만에 homebrew formula로도 만들 수 있을 듯함. iOS 앱도 진행 상황이 손코딩보다 훨씬 빠르게 나가지만, 일부러 천천히 진행 중임. 참고로 해당 게시글 데이터가 3~4월에 끝나는데, 이 시점부터 generative AI가 코딩에 실질적 도움이 되기 시작했다고 생각함. (난 Copilot을 2022년 11월부터 썼음)
이런 논란이 나올 때마다 “너 아직 최신 AI 안 써봤구나, 이번엔 진짜 잘 됐다”라는 반응이 반복됨이 놀라움
내 경험도 거의 비슷함. 나는 AI 하이프에 늦게 탑승했지만, 최근에 나온 새로운 모델과 툴 조합을 써보고 생각이 바뀌었음. 내 주변에선 대기업들이 이제야 이런 툴 사용을 허락하기 시작했기 때문에 실제 생산성 향상 데이터에는 꽤 시차가 있어서 그 영향이 나중에 드러날 거라 예상함. METR 연구에 대한 아쉬움도 있고, 이런 생산성에 대한 메타 연구가 더 많이 나오길 바람
동의함. agentic AI는 “전통적인” AI와 완전히 다른 툴임. 앞으로 1년 후라면 저자의 데이터와 실험이 어떻게 나올지 기대가 큼
“AI가 드디어 빨라졌다”고 말하는 순간, 불과 5개월 전이라니. AI 속도에서는 5개월이 6년에 해당하는 변화처럼 느껴짐
한때 풀타임 개발자였고, 이후 매니저·CTO로 일하면서 점점 개발 실무와는 멀어져 감. 다시 코딩을 하려고 해보니 프레임워크, API, 언어, 세세한 트릭들을 새로 익혀야 하는 게 예전엔 흥미로웠지만 지금은 짜증나는 일이 됨. 그런데 Claude Code 같은 툴과 소프트웨어 설계 경험 덕분에, 예전처럼 큰 시스템을 다시 개발하는 게 가능해졌음. 내 생산성이 20% 느는 것도, 10배 빨라지는 것도 아님. 애초에 안 하려고 했던 일을 다시 하게 만들어줬으니 무한대의 생산성 증가라고 표현하고 싶음. 만약 내가 개발을 사랑하는 실력자라면 이 툴들이 귀찮기만 하겠지만, 평소 개발하지 않을 사람에겐 정반대임
와, 큰 시스템을 한 번도 아니고 여러 번이나 다시 개발했다니, 자세한 사례를 공유해줬으면 좋겠음
내 AI 코딩 툴에 대한 대이론은, 실제 시간을 크게 단축시키는 게 아니라 짜증을 대폭 줄여준다는 것임. 문법, 컴파일러, 반복 작업에 대한 불필요한 짜증을 아껴 진짜 중요한 데 정신을 쓸 수 있게 만들어줌. 덕분에 예전 같으면 너무 짜증나서 안 할 일도 이제는 하게 되고, 퇴근 전에 산책 대신 그냥 책상에 몇 시간 더 머무를 수 있게 됨
Hacker News 의견
내게 AI는 종 모양 곡선과 같음, 많은 사람들에게도 비슷할 거라고 봄. 아웃풋을 평가하는 기준이 중요하다고 생각함. “코드 라인 수”가 아니라 “좋은 품질의 유지 관리 가능하고, 확장 가능하며, 업그레이드가 쉬운 코드 라인 수”여야 함. 이 기준으로 보면 “전체 레포 생성” 같은 요청의 결과는 의미가 없는 쓰레기이지만, AI가 “getUser(…” 같은 코드를 자동 완성해주는 것은 생산성 향상임. 이게 0.1% 증가인지 1%인지 10%인지는 확실하게 말할 수 없음
내 입장에서 가장 심각한 문제는 지금 회사에서 내가 다루는 문제들이 신중한 계획과 실행을 요구하는데, AI가 전혀 도움이 되지 않는다는 점임. 그런데 우리 매니저는 “우리는 AI-first 회사”라는 이유로 프로젝트 납기 시간을 기존 견적의 20%로 줄였다고 함. SVP들과 PM들 사이에서 이런 집단적 광기가 엄청나게 번지고 있고, 이런 건 전에도 본 적 없음
여러 가지가 동시에 사실일 수 있음. LLM이 무작위로 선정된 일반적인 작업에 대해 개발자 생산성을 10배로 올려주는 건 아님. 반면 LLM이 특정 범위의 작업에서는 생산성을 극적으로 높여줌. 바쁜 반복 업무를 자동화하는 데도 쓸 수 있는데, 인간보다 실제 시간은 오래 걸려도 백그라운드로 작업이 돌아가니 문제되지 않음. 새로운 API나 라이브러리를 익히는 데 LLM이 훨씬 속도를 올려주고, 모르는 언어로 작은 glue 코드를 짤 때 시간도 아끼고 불필요한 학습까지 안 해도 되어 엄청난 도움임. 큰 기존 코드베이스 보수 작업엔 별 생산성 차이를 못 느낌. 새로운 웹사이트 스캐폴딩 세팅은 LLM이 놀랄 정도로 잘함. mock 클래스 작성도, mock 라이브러리 사용법을 잘 파악해서 내가 두어 번 해보다 까먹는 복잡한 작업도 순식간에 처리함. 새로운 코드베이스 구조 파악도 70% 정도는 만족스럽게 해줌. 복잡하게 설계된 프로젝트에서 HTTP 라우트 위치나 의존성 주입 함수 위치 찾기 등에도 “야 Claude, auth 관련 함수들 어디 있냐?” 이렇게 물어보면 편함. 올바른 도구를 올바른 작업에 써야 한다고 생각함
영상 속에서 스크린에 코드가 쏟아지고, “주니어 개발자들은 끝났다”는 주장 이상의 실체가 없는 게 대부분임. 그 이유는 경제가 불안정하고, AI가 구원자가 되어줄 거라는 기대에 과장과 불안이 가득한 분위기라 생각함. 실제로 AI로 인상적인 결과를 얻을 때도 있긴 하지만, 기본적으로 어느 정도 실력 있는 사람이 아니면 무의미함. 초보~중급 수준의 사람들은 소셜미디어에서 과장된 성공담만 쏟아냄. 사람마다 “AI 슈퍼파워”를 지키려고 심리적·현실적으로 애쓰는 분위기가 형성됨. 결국 하이프 사이클에서 어느 순간 균형점을 찾고, 몇십억 달러가 다시 소각될 날을 기다릴 뿐임
내 경험상, AI는 일부 사소한 작업(예: 소규모 리팩토링, 타입 정의 자동화 등)에 쓸모 있었지만, 그 이상의 복잡한 작업에는 여러 가지를 놓치고 재작업이 필요했음. 미래에는 내 말을 다시 생각하게 될 수도 있겠지만, 최근 더 경험이 적은 엔지니어들이 큰 기능을 구현하려고 AI가 내놓는 결과물을 “좋은 코드”라고 무비판적으로 받아들이는 경우가 늘었음. 그런데 이 코드들은 우리 스타일 가이드와 패턴을 따르지 않거나, 이미 나와 있는 라이브러리 대신 굳이 로직을 처음부터 구현해서 결국 우리가 직접 관리해야 할 코드가 늘어남. 나중에는 모든 걸 한 번에 하려는 거대한 PR이 나오기도 함
여기 주장에 동의함. AI를 써도 생산성 획기적 상승은 못 봄. 소프트웨어 엔지니어가 꾸준히 문제 해결, 분별, 코드화 연습을 안 하면 신경 지식이 약화될 수 있다고 봄. AI가 미래의 2배, 10배 생산성을 가져다 줄 기술이라는 약속은 실체가 없고, 개인 코드베이스에서 약간의 생산성 증가가 있었더라도, 시장에서 실제로 더 나은 제품 출시가 늘진 않았음. 컨설팅을 하면서 종종 파운더나 CTO들이 AI를 밀어붙이다가 오히려 코드를 제대로 관리하지 못하고 더 많은 혼란을 초래하는 걸 자주 봄. 요즘은 엔지니어링 베스트 프랙티스 확립을 위해 어드바이저 역할을 맡는 경우도 많음
CEO들이 AI로 기존 개발자 생산성이 10배 오른다고 말하지만, 그게 진짜라면 오히려 개발자를 훨씬 더 많이 뽑아야 하는 거 아닌가 싶은 의문이 듦. 만약 같은 투자로 생산성이 10배 오르면 당연히 그 “엔진”에 돈을 퍼붓는 게 합리적임. 그런데 현장에선 생산성은 그대로인데 인건비만 줄이는 데 그친 게 아닌가 싶음
신선한 각도로 신제품 출시량을 바라보는 분석이 인상적임. 빠른 성장 대신 예상보다 큰 변화가 없다고 느꼈음. 대안론으로, 실은 코드 작성이 제품 출시의 병목이 아니었고, 무엇을 만들지 탐험하며 실제 플랫폼에 올리는 것 자체에 많은 시간과 노력이 소요된다는 해석도 가능함. 한편 AI 툴을 잘못 쓰기가 너무 쉽다는 점도 동의함. 때론 “드디어 깨달았다!” 하다가도 다음 날 “또 다른 방법으로 잘못 쓰고 있었구나” 깨닫게 됨. 소프트웨어 개발이 왜 이렇게 어렵고 생산성 가속이 어려운지, 20년 이상 개발을 해도 여전히 명확하지 않음
우리가 그 미래를 지금 만들고 있음. 실제로 내가 속도가 붙기 시작한 건 agentic AI가 충분히 좋아진 4~5월 부터였음. 오늘만 해도 iMessage 아카이브를 웹사이트로 익스포트하는 CLI 도구를 만들었고, 예전 같으면 몇 주 걸릴 일이 이제 하루 이틀 만에 homebrew formula로도 만들 수 있을 듯함. iOS 앱도 진행 상황이 손코딩보다 훨씬 빠르게 나가지만, 일부러 천천히 진행 중임. 참고로 해당 게시글 데이터가 3~4월에 끝나는데, 이 시점부터 generative AI가 코딩에 실질적 도움이 되기 시작했다고 생각함. (난 Copilot을 2022년 11월부터 썼음)
한때 풀타임 개발자였고, 이후 매니저·CTO로 일하면서 점점 개발 실무와는 멀어져 감. 다시 코딩을 하려고 해보니 프레임워크, API, 언어, 세세한 트릭들을 새로 익혀야 하는 게 예전엔 흥미로웠지만 지금은 짜증나는 일이 됨. 그런데 Claude Code 같은 툴과 소프트웨어 설계 경험 덕분에, 예전처럼 큰 시스템을 다시 개발하는 게 가능해졌음. 내 생산성이 20% 느는 것도, 10배 빨라지는 것도 아님. 애초에 안 하려고 했던 일을 다시 하게 만들어줬으니 무한대의 생산성 증가라고 표현하고 싶음. 만약 내가 개발을 사랑하는 실력자라면 이 툴들이 귀찮기만 하겠지만, 평소 개발하지 않을 사람에겐 정반대임