▲

생성형 AI 코딩 툴과 에이전트가 나에게 효과 없는 이유

(blog.miguelgrinberg.com)
12P by GN⁺ 12시간전 | ★ favorite | 댓글 5개
  • 글쓴이는 AI 도구가 자신을 더 빠르게 만들어주지 못한다는 점을 가장 큰 이유로 들며 생성형 AI 코딩 도구를 사용하지 않음
  • AI가 생성한 코드를 검토하고 이해하는 데 드는 시간이 직접 작성하는 것보다 더 오래 걸릴 수 있다고 판단
  • 코드 품질과 책임은 여전히 개발자 본인에게 있으므로, 검토 없이 AI 코드를 사용하는 것은 위험
  • AI를 인턴처럼 보라는 주장에 대해, AI는 학습을 하지 못하므로 기억 상실이 있는 인턴 같다고 비판
  • 오픈 소스 기여와 AI 코드의 차이를 설명하며, 사람과의 상호작용은 새로운 아이디어를 제공한다는 점에서 가치가 있음

서론

  • 많은 사람들이 나에게 생성형 AI 코딩 도구를 사용하는지, 어떻게 생각하는지 묻곤 함
  • 본 글에서는 찬반 양쪽의 입장을 벗어나 개인적인 기술적 경험만을 정리함
  • AI가 나의 코딩에 도움이 되지 않는 이유를 기술적 관점으로 설명함

AI는 더 빠르지 않음

  • 생성형 AI 코딩 툴을 사용해도 내 작업 속도가 빨라지지 않음
  • AI가 코드를 작성해줘도 코드의 책임은 나에게 있음, 코드 전체를 꼼꼼히 리뷰하고 완전히 이해해야만 프로젝트에 반영 가능함
  • 코드 리뷰는 코드 작성만큼 오랜 시간과 집중이 소요되며, "코드 읽기가 쓰기보다 어렵다"라는 업계의 격언도 있음
  • AI가 작성한 코드를 "블랙박스"처럼 신뢰하는 것은 매우 무책임한 선택임. 코드 결함 발생 시 법적, 금전적 책임도 프로그래머에게 있음
  • 품질 저하와 리스크 증가 없이 AI로 생산성 증가나 수익 증대는 불가능함

AI는 배가(레버리지) 도구가 아님

  • 어떤 사람들은 AI 코딩 툴이 효율을 배가시켜 준다고 주장하나, 이는 주관적 인상에 불과함
  • 일부 사용자는 AI가 생성한 코드를 검토 없이 사용하거나 부분 검토만 하여 시간을 아끼지만, 나는 이 과정을 건너뛸 수 없으므로 도움이 되지 않음
  • 새로운 언어나 기술 학습에서 AI를 사용하는 것이 효율적이라는 주장도 동의하지 않음. 새로운 것을 배우는 과정 자체가 프로그래밍의 즐거움임
  • 실제로 Rust, Go, TypeScript 등 다양한 언어를 직접 학습하며, 이런 경험을 AI에 위임하지 않음
  • 모든 코드의 책임감은 결국 내게 있기 때문임

AI 코드는 인간 코드와 다름

  • "오픈 소스 기여도 내가 작성하지 않은 코드인데, 왜 AI 코드와는 다르게 대하는가?"라는 질문에 자주 직면함
  • 사실 오픈 소스 PR도 시간을 투자해 철저히 리뷰함. 하지만 사용자와의 협업은 새로운 아이디어와 동기부여로 이어짐
  • AI 에이전트를 여러 개 돌려서 버그 이슈 해결 PR을 받는 게 게임 체인저라는 주장도 있지만, 결국 코드 리뷰의 병목은 사람이어서 오히려 느려짐
  • AI 도구가 보급되며 품질이 낮은 PR이 빈번히 생성됨. AI 코드에는 미묘한 이질감이 있고, PR의 제출자에게 질문을 하면 답변하지 않는 경우가 많음
  • 책임 있는 코드 기여 및 오픈 소스 커뮤니티 소통이 인간 코드의 중요한 차별점임

AI와 인턴의 차이

  • AI를 인턴에 비유하는 주장도 있지만 근본적으로 다름
  • 인턴의 초기 코드는 많은 리뷰와 시간이 들지만, 피드백을 통해 빠르게 성장함
  • 인턴의 성장 투자로 결국 독립적으로 맡길 수 있는 중요한 동료가 됨
  • AI 도구는 매번 새로운 작업마다 지식을 잊고 다시 시작, 성장하거나 노하우를 축적할 수 없음
  • 이는 한 번도 발전하지 않는 인턴과 같으며, 생산성 향상에 기여할 수 없음

결론

  • 글을 통해 생성형 AI 코딩 툴을 적용할 때의 기술적 문제점을 분명히 전달하고자 함
  • AI 코딩에는 '공짜 점심'이라는 것은 존재하지 않음
  • AI로 인해 빨라지거나 생산성이 높아졌다는 주장은 품질 기준을 내려 추가 리스크를 감수하거나, AI 판매자의 이익에서 비롯됨
  • 프로그래머는 항상 최종 책임자임을 유념해야 함
▲
ceruns 3시간전  [-]

copilot (claud) + codex (o3/4o/codex-mini 3모델 동시 mcp) 의 agent 모드로 완전 정착했는데, 이걸 사용하는 사람과 프로젝트의 성향에 따라 효과는 천차만별이라고 생각합니다.

저는 5-6개 워크스페이스에서 동시에 작업 걸고 완료되는 순서대로 확인하는데, 오픈소스 코드 내부까지 들여다보고 검증해주는 작업을 모델이 전부 해줄 수 있으니 꽤 괜찮다고 생각합니다. 점심시간에 작업 걸고나면 한 두개는 작업이 끝나있습니다. 밤새 진행하는 경우도 가끔 있는데 copilot rate limit 이라는게 블랙박스라...

고성능 커널이나 call stack 전체 단순화, readibility 확보 같이 인간에게는 맥락 전환이 많아서 시간이 걸리는 태스크도 프롬프트와 목표만 잘 주면 해내는데 (인간보다 메모리에 많은 코드를 올릴 수 있으니), 이런 코드에서 패치를 리뷰하는건 쉽죠... 그리고 API 사용 실수나 오픈소스 프로젝트 자체 버그로 인해 발생하는 장애를 겪어보신 분들에게는 Agent로 확실히 검증하게 하는게 마음 건강에도 괜찮습니다...

다만, 어디까지나 사용하는 개발자가 패치를 이해할 수 있어야 합니다. 그리고 프롬프트를 던질 줄 알아야겠죠. 경험으로 알아내서 빠르게 문제를 형성하고 던져야지만 거기서부터 시작할 수 있으니까요. 수식 없이 고성능 커널 개발이 불가능한 것 처럼요. 문제가 chip/os 레벨인지, 어플리케이션 레벨인지, remote resource 문제인지 감을 잡는건 아직 시니어 역할인 것 같습니다.

답변달기
▲
cronex 11시간전  [-]

개인적인 경험상 생성형 코딩 도구 사용에 대해서 느낀 점이랑 비슷합니다.

  • 개발자 입장에서 귀찮으면서 시간이 생각보다 오래 걸리는 단순 인터페이스 작업의 경우 생각보다 잘 정리된 결과물을 제공해줍니다.
  • 특히 예시에 해당 할 수 있는 한두개의 인터페이스를 예외처리와 주석을 포함해서 잘 구현해주면 그걸 학습해서 코딩 시에 유사한 내용을 포함해서 처리해 줄 수 있습니다.
  • 또한 추가적으로 기존에 사용하지 않던 새로운 플랫폼이나 SDK를 사용 시에 발생하는 문제를 더 적은 시행착오를 겪고 해결할 수 있게 해주는 가이드가 될 수 있습니다.
  • 물론 모든 경우 최종적으로 세부적인 체크는 해야 하지만 직접 복붙해서 작업하다가 실수하는 경우보다 훨씬 코팅 품질이 좋고 직접 작업한 것을 검토하는 것보다 문제가 되는 부분을 찾아내기가 훨씬 수월합니다. (보통 내가 짠 코드에서 문제 찾기 보다 남이 짠 코드에서 문제 찾기 쉬운 것과 일맥 상통하죠.)
  • 위 장점은 어디까지나 생성된 코드를 직접 검토해서 코드의 문제점이나 유효성을 판단할 수 있는 수준의 중/고급 개발자가 사용 했을 때의 케이스입니다. 그럴 수 없는 초급, 저수준 개발자의 경우 오히려 코드 품질 및 결과물의 수준이 나락으로 가고 개발 방향도 제대로 못잡고 완성도 못하는 수준에 빠질 수 있습니다.
  • 특히, 기존에 널리 알려지지 않은 새로운 방법론이나 알고리즘, 데이터 구조는 코딩형 AI는 제대로 구현해줄 수도 없고 시도했을 때의 결과물은 처참한 수준입니다.
  • 즉, 완성된 개발자가 작업 속도 향상이나 결과물 품질을 개선하기 위해 사용하기 좋은 도구일 뿐 한 명의 개발자를 완전히 대체하거나 경험 없는 초급 개발자를 성장시킬 수 있게 하는 하는 용도로 쓰일 수 없습니다.
  • 오히려 초급 개발자가 제대로 된 가이드 없이 사용 시 역효과만 발생할 가능성이 높습니다.
답변달기
▲
ndrgrd 9시간전  [-]

Copilot, ChatGPT류, Cursor 등을 어느 정도 사용해본 입장에서는 개발 툴의 템플릿이나 스니펫 수준의 역할에는 잘 어울리지만 agent나 coworker 정도는 아닙니다.

답변달기
▲
allinux 10시간전  [-]

cursor 를 사용중입니다.
chat모드를 agent 보단 ask 를 선호하는데 역시 검토후 내 코드에 적용되기를 원하기 때문이며 대체적으로 본문에서와 같은 단점에 대해 동감합니다.
그럼에도 생성형 ai는 계속할 예정인데 내가 생각치 못한 아이디어나 코드를 생성하는 경우도 많이 있기 때문에 참고목적으로는 충분히 가치가 있다고 판단하고 있기 때문입니다.

답변달기
▲
GN⁺ 12시간전  [-]
Hacker News 의견

  • 누군가는 새로운 언어나 기술을 배울 때마다 궁금한 게 생기곤 하여 예전에는 구글 검색이나 Stack Overflow에 질문을 올려 답을 기다리곤 했음 지금은 ChatGPT나 Gemini에 바로 묻고, 훨씬 빠르게 답변을 받아 생산성이 크게 향상됨 이처럼 질문에 대한 신속한 답을 얻는 것만으로도 학습 과정이 빨라진다는 점을 강조하고 싶음

    • ChatGPT와 Gemini가 정답을 제시하는 근거는 Stack Overflow를 포함한 웹상에서 이미 존재했던 지식을 학습했기 때문임 모든 사용자가 AI만 이용해서 질문하면 결국 신뢰할만한 공개 지식의 원천이 고갈될 수 있음 이것은 백과사전 시대, 즉 고비용으로 정보를 수집·판매하던 시대의 부활과 유사함 또한, 글쓴이가 비판하는 것은 코드를 직접 작성해주는 AI 코딩 도구이지, 질문에 답해주는 도구와는 구분해서 설명해야 함

    • 예전에 익숙하지 않은 API를 사용하다가 프로그램이 크래시된 적이 있었음 스택 트레이스를 Gemini에 넣어보니 즉시 원인에 대한 실마리를 얻어 두 줄만 수정해서 문제를 해결함 이런 경험만 봐도 AI의 가치는 실감 가능함 익숙하지 않은 분야에서 바보 같은 실수로 오래 헤맬 필요가 없어지는 점이 큰 장점임

    • 검색이 점점 더 블로그 스팸을 우선시하게 됐는데, 그보단 잘 된 공식 문서나 사용자 가이드로 근본부터 배우는 게 더 교육적임 좋은 API 문서를 읽다 보면 전체 설계나 추가 기능까지 자연스럽게 배울 수 있음 블로그 예제나 튜토리얼로는 당장 문제는 풀어도 진짜 실력 향상에는 도움 안 됨 숙제만 대신 풀어주는 셈이므로, ChatGPT가 진정한 자기 학습을 촉진하지는 않는다고 생각함

    • 어려운 문제에서는 반드시 AI 결과를 검증하는 과정이 필요함 AI 자동완성 기능을 꺼둔 이유도 실제로는 효율이 크지 않고, 오히려 불필요한 수정이 많았기 때문임 신기하게도 완전히 오프라인 로컬 모델만으로도 상당한 참고 자료를 얻을 수 있음 Google 내장 Gemini 결과도 품질이 별로임 내가 걱정하는 주된 문제는 사람들이 AI만 활용해서 정보를 얻으면, Stack Overflow 같은 진짜 지식 저장소가 사라질 수 있다는 점임

    • 작은 보일러플레이트 도구에는 AI가 완벽함 브라우저 익스텐션이나 Tampermonkey 스크립트처럼 간단한 건 거의 문서 안 보고 바로 작업 시작 가능함 복잡하지 않은 코드 자동 완성이나 사소한 수정에도 AI는 꽤 유용함 평소라면 시작조차 안 했을 작은 프로젝트를 빠르게 처리할 수 있음

  • 직접 코드를 작성할 때 얻을 수 있는 잠재적 이점은 문제에 대한 강력한 멘탈 모델을 두뇌에 남길 수 있다는 점임 나중에 문제 해결이나 신규 기능 통합 때 이 '무의식적' 학습 효과가 매우 크게 작용함 자기 손으로 직접 해봤던 기억이 쌓여야 진정한 실력이 향상됨 내가 봤던 조직에서는 LLM 도입 이후에도 생산성에서 실질적 배가를 경험하지 못했음 단순히 두뇌를 덜 쓰고 쉬운 길만 찾게 되는 걸 착각하는 게 아닐까 생각함

    • 사람들이 두뇌 에너지를 덜 들여 문제를 푸는 데 익숙해지고, 그 착각이 마치 생산성인 것처럼 느끼는 현상을 아주 잘 요약했다고 생각함 Google Research가 2024년 LLM 생산성 효과를 실험한 결과, 책으로 학습한 집단보다 LLM 사용 집단이 오히려 시간이 더 오래 걸렸고, 내용 숙련자가 아닌 초보자만 점수가 약간 올랐음 하지만 많은 참여자가 스스로 더 빠르고 정확하다고 착각했고, 연구진은 그 이유를 '인지 부담 감소' 때문이라고 해석함 관련 논문 링크 https://storage.googleapis.com/gweb-research2023-media/pubtools/…

    • 두뇌 에너지를 덜 쓰고 더 오래 일할 수 있다면 실제로 더 많은 업무량을 소화할 수 있지 않을까? 현재도 고난도 업무는 3~4시간이 한계임 걷기 속도로 마라톤을 뛸 수 있다면 결과적 총 출력이 늘 수 있다는 시각임

  • 전통적 코딩과 AI 코딩은 서로 별개의 스킬이라는 부분에 동의함 나 역시 AI가 코딩을 대체한다는 주장에는 매우 회의적임 하지만 프롬프트 관리나 맥락 유지 같은 'AI 코딩' 자체에도 상당한 숙련 곡선이 존재한다고 보며, 이 지점에서 다수가 그 가치를 과소평가한다고 생각함 마치 수작업 그림과 사진 촬영처럼, 서로 추구하는 목적 자체가 다를 수 있다는 시각임 내가 선호하는 방식은 'AI가 힘든 작업을 처리하고, 나는 전체 설계와 조율을 담당하는 것'임

    • LLM 기반 코딩은 단순 자동완성 이상의 작업, 즉 작업 정의-피드백-반복을 반복하며 외주를 주는 경험과 흡사함 차이점은 처리 속도(LLM이 우위), 신뢰성(인간 우위)이지만 장기적으로는 이 경계도 점점 옅어질 듯함 중요한 것은 나는 본질적으로 작업 세부를 직접 다루고 싶은 유형임 인프라와 프로그래밍을 배우고 파고드는 게 좋아서 시작한 직업임 그래서 관리자 역할을 피하고 덜 벌더라도 직접 만드는 일을 고집함 차라리 AGI가 동료가 될 수준이 오면 다시 관심 가지겠음 AI라는 명칭 자체도 향후에는 그리 특별하게 여겨지지 않을 가능성이 높음

    • AI 코딩의 학습 곡선이 생각보다 크다고 해도, 몇 년을 투자해야 하는 피아노와는 다름 현존하는 가장 숙련된 AI 코더들도 겨우 3년 정도의 경험이고, 모델도 계속 바껴서 과거 경험이 현 세대 모델에 안 맞는 부분이 많음 마스터로부터 배우는 구조가 없는 점도 한계임

    • AI 코딩 스킬이 과연 장기적으로 가치 있는가? 현재 AI 도구들의 스킬셋이 미래 세대에 얼마나 이전될지 회의적임 당장 효율이 올라도 모델, 도구가 바뀌면 무용지물 될 가능성을 염두해야 함

    • AI 코딩 숙련은 몇 분 아니면 한 시간이면 충분하다고 생각함 비유적으로 GDB나 UNIX처럼 한 권씩 파고 드는 영역이 아니라고 느낌 그림과 사진도 근본 원리나 목표가 전혀 달라 혼동하지 않듯, AI 코딩도 기존 코딩과는 완전히 다른 활동임

    • 직접 코딩을 선호하는 것이 단지 AI 코딩 실력이 부족해서라고 보는 자신감에는 동의 못함 지금까지 소액 결제와 프리 트라이얼을 써본 ROI만으로도 충분히 판단 가능함

  • 실제로 AI 코드리뷰나 결과 검수 대신, AI가 생성한 코드를 그대로 PR에 올리고 리뷰를 남에게 미루는 문화가 생김 이런 상황에서는 GenAI가 정말 유용하다기보다, 일을 미루는 데 활용되는 부작용이 큼

    • 이런 경험을 나도 했음 관리자가 역량이 떨어지면, 누가 실질적 가치를 만드는지 구분하지 못함 나는 코딩 에이전트에서 진정 많은 가치를 얻고 있지만, 역량 없는 조직이 엉성한 산출물을 보상하는 구조가 심각한 문제라고 생각함

    • 제출자 PR이 계속해서 AI 결과물 그대로면, 피드백을 누적해 팀장이 반드시 문제 제기를 해야 맞다는 입장임

  • Claude Code를 자주 쓰는 입장에서, 남이 작성한 코드를 검토할 때 직접 작성하는 것과 시간 차이가 거의 없다는 주장에 100% 동의함 LLM은 나름 쓸만하지만, 통제권을 넘길수록 실제 릴리스까지는 오히려 더 오래 걸림 RSI 증상 완화에는 좋았지만, 시간 절약 효과는 생각보다 과장되는 경우가 많았음

    • 코드를 꼭 리뷰해야 하느냐는 질문을 받고, 보통 나는 주로 AI 결과물을 스팟 리뷰만 하고, 스펙 문서를 AI에 작성하게 한 뒤, 내가 최종 검토와 테스트를 꼼꼼히 진행함 사실 대다수의 오픈소스 라이브러리 코드는 처음부터 직접 리뷰하지도 않음

    • 여기엔 "내가 직접 작성한 코드는 별도의 시각에서 검토할 필요가 없다"는 전제가 존재함 실제로는 미래의 나도 잠재적 코드 독자임 AI 코딩은 이런 마인드셋을 강제함, 즉 명확한 수용 기준을 세우고, 테스트와 일관적 규칙으로 검증해가는 구조임 결과적으로 더욱 견고하고 기록이 남는 개발 문화를 유도함

    • Claude Code로 버그 디버깅은 '테스트부터 작성*하면 AI가 몇 분 만에 고치는 게 일상임 새 검색 기능 도입 후엔 복잡한 작업도 5분 만에 처리 가능, 이 부분에서의 시간 절약은 체감상 매우 분명함

    • RSI 증상 해결법으로 항상 팔을 따뜻하게 유지하는 방법도 추천함

    • "모든 것을 대화형 인터페이스로 처리하고 싶지 않은데, 하이브리드 방식 UI 도입 사례가 있냐"라는 궁금점 제기

  • Generative AI 코딩 도구는 업무의 쉬운 부분만 빨라지고, 오히려 어려운 부분은 더 어렵게 만듦 실제로 코딩 그 자체에 걸리는 시간이 아주 크지 않아서, 그 부분만 100배 빨라져도 전체 생산성이 크게 달라지지 않음 그래서 굳이 거기 시간 쓰고 싶지 않음

    • 이미 특정 스택과 문제 영역을 꿰뚫는 엔지니어라면 굳이 어떤 도구도 필요치 않음, 학습도 필요없음 하지만 이 논리는 현실적으로 의미 없음 결국 도구 선택은 개인 최적화임

    • 나는 AI에게 알고리즘 작성, 코드 원인 설명, API 호출, 특정 함수 구현 등을 시킴 완전한 코드 전체는 아니어도, 점점 디버거와 함께 활용하는 일이 늘어남

    • 혹시 배관공인가?라는 농담 섞인 질문

  • 글쓴이가 "코드를 직접 작성하는 것 만큼이나 남이 쓴 코드 리뷰가 시간이 들거나 더 많은 경우도 있다"는 대목은, 시큐리티 감사처럼 정교한 코드 리뷰 경험이 있던 나도 공감함 하지만 AI가 아주 단순한 루틴 작업에 특화된다면, 코드를 구체적으로 들여다 볼 필요 없이 eBPF 베리파이어처럼 포괄적 검수만으로 충분할 수도 있음 너무 복잡한 이슈가 있으면 그냥 PR을 거절함 단순 반복적 코드에는 사람이 꼼꼼히 감수할 필요도 덜함

    • 하지만 이게 정말 효율적 방법인지 의문임 수십 PR을 열었다가 하나만 통과시킬 거면 차라리 동료 코드가 훨씬 믿음직함 시간과 금전, 환경 자원 낭비만 초래하는 구조는 바람직하지 않다고 봄

    • 정말 '반복적 Go 함수'라면, 그 코드를 굳이 작성할 가치가 있었는지 의문임 비효율적이고 재사용성 적은 코드, 그저 흔한 라이브러리 한 두 줄이면 끝날 일을 굳이 AI로 만들 이유를 못 느끼겠음

    • 코드를 읽는 속도가 쓰는 속도보다 빠른 사람에겐 GenAI가 유용하고, 반대로 쓰는 것이 더 빠른 사람은 별로 쓸 필요가 없음

    • 왜 AI가 작성한 코드를 인간이 쓴 것과 다르게 검수해야 하는가에 대한 궁금증 제기

    • 반복적이고 단순한 작업에는 IDE 템플릿 바인딩과 변수 자동 완성 기능으로도 충분히 커버 가능하며 이 방식은 무료라는 점을 강조함

  • 인턴과 AI 코딩 보조 도구 비교 논의에서, 인턴은 실제 코드, 비즈니스, 시스템 히스토리를 배우는데 AI는 반복적으로 맥락을 설명해줘야 함 이런 한계가 여전함

    • 중요한 맥락은 mdc 파일에 저장하면, 다음 담당자도 그 정보를 참고하게 되어 오히려 문서화·지식 지속성이 좋아진다는 시각

    • 어떤 LLM들은 이런 식으로 시스템 프롬프트가 14k씩 길어지는 원인이 됨

    • 인턴은 진짜로 CARE(신경씀)하는 경우가 많음

    • 중요한 비즈니스 맥락을 그냥 시스템 프롬프트에 넣는 방식도 가능함

  • 현재 AI 모델은 본질적으로 기존 데이터 패턴만 학습함 성공 사례 템플릿을 조합하는 것이지, 근본부터 새로운 해법을 유도하는 구조가 아님 문제를 보면 가장 비슷한 경험에서 답을 찾으려 하지, 처음부터 원칙적으로 접근하지 않음 인간 전문가는 First-principles(AI가 어려워하는 근본 원리로부터의 논리적 접근)에 능숙함 AI는 유사성을 우선시해 틀에 박힌 해결책을 내놓고, 특히 혁신이 필요한 영역이나 관습이 통하지 않는 문제엔 한계가 두드러짐 문맥 오염(context poisoning)도 인간이 훨씬 효율적으로 대응함

    • 사실 인간도 기존 데이터에서 배운 패턴을 확장하는 존재임, '새로운 방법론' 자체도 성공 경험에 기반해 발전한 것임 AI 또한 이런 점에선 인간 학습과 큰 차이가 없다고 생각함

  • 나는 AI가 생성 코드 영역에서 별로 기대하지 않는 입장이지만, 반복적이고 지루한 보일러플레이트 작업은 AI가 N배(체감상 매우 큰 수치) 빠름 실제 경험담을 들자면, ChatGPT에 React Context 기반 모달 구성 예시를 던졌더니 후크, 프로바이더 등 일련의 구조를 바로 뽑아줌 당장 30분 정도 절약함, 이런 반복적 작업에는 월 20달러가 훨씬 아깝지 않음

    • 이런 경우 라이브러리 문서 예제에서 들고와 쓸 때도 많고, 5분이면 직접 가장 꼭 필요한 기본 구현을 끝낼 수 있음 하지만 생성 코드는 주로 현 상황에 맞춘 전체 해법을 내놓기에, 이후 점진적 구조 개선·리팩터링에는 오히려 불편이 많음

    • 나 역시 주로 보일러플레이트나 ad-hoc 스크립트에 AI를 씀 복잡한 실제 문제는 아직 AI에 전적으로 맡기긴 어렵다고 봄 특히 시스템에 깊이 파고드는 문제는 사람이 직접하며, 과정에서 얻는 통찰이 중요함 AI는 프로젝트가 클수록, 융합된 요소가 많을수록 한계가 커진다고 느낌

답변달기