AI가 개발자를 바보로 만들고 있음
(eli.cx)- LLM 도구가 개발 생산성을 높이는 것은 사실임
- 그러나 장기적으로는 이러한 도구에 의존하게 되면서 스스로 문제를 해결하는 능력이 저하됨
- 코드 작성의 과정에서 얻는 성취감이 사라지고, 문제 해결보다는 AI의 답변을 기다리게 됨
개발에 대한 열정과 도전 정신의 약화
- 코딩 자체를 즐기지 않는 사람도 있음 → 그런 경우에는 개발 분야가 맞지 않을 수 있음
- 내가 만난 최고의 엔지니어들은 주말에도 자발적으로 도구나 소프트웨어를 만들며 혁신을 추구함
- 시스템의 성능 개선은 근본적인 이해가 있어야 가능하며, 그렇지 않으면 무작위로 시도하는 것에 불과함
'Copilot Lag' 현상
- 'Copilot Lag'은 AI의 다음 지시를 기다리는 상태를 의미함
- 마치 신입 개발자가 선배의 지시를 기다리는 것과 비슷함
- GitHub Copilot을 사용하면서 기초적인 언어 요소와 구문조차 잊어버리게 됨
- 단기적인 속도 향상 때문에 장기적인 지식이 퇴화됨
LLM이 학습 과정을 방해할 수 있음
- Thorsten Ball의 "Writing An Interpreter In Go"를 공부할 때 Copilot이 코드를 생성해 주었지만, 스스로 다시 작성할 수 있는 능력은 얻지 못했음
- 메모리 관리나 데이터 지향 설계 같은 중요한 개념을 놓치게 됨
- AI가 만들어낸 코드는 겉보기에 맞아 보일 수 있지만, 근본적인 원리를 이해하지 못하면 무의미함
LLM을 효과적으로 활용하는 방법
- LLM은 검색 엔진처럼 유용하게 사용할 수 있음
- Stack Overflow를 검색하듯이, LLM의 답변을 참고할 수 있음
- 그러나 LLM은 실제 전문가의 지식을 그대로 반영하지 않으며, 학습된 패턴과 토큰 시퀀스를 기반으로 답변을 생성함 → 오류가 많음
- LLM의 답변을 그대로 받아들이지 말고, 왜 그런 접근 방식을 추천하는지 분석해야 함
- 모르는 것이 있을 때는 스스로 조사하고 학습해야 함
- 새로운 언어(Zig 등)를 학습할 때 배운 내용을 메모하면 유용함
- 메모는 학습 참고 자료가 될 수 있으며, 다른 사람과 공유할 때도 도움이 됨
결론
- AI 도구는 유용하지만 맹목적으로 의존하면 오히려 역효과가 발생함
- AI가 제시한 해결책의 원리를 이해하고, 스스로 학습하려는 태도가 중요함
- 결국 중요한 것은 도구에 의존하지 않고 근본적인 문제 해결 능력을 유지하는 것임
아직 고수준 문제해결에는 딥리서치를 포함한 llm이 유용하지 않습니다. (예를 들면 논문 수준의 알고리즘 개발)
극한의 최적화, 다양한 시스템 특성과 기술 이슈들을 이해해야 하는 코딩 등도 마찬가지로 아직 사람 손이 필요합니다. 개발자는 단순 프로그래머가 아니라 문제해결자입니다. 언젠가는 end to end 문제해결도 가능해지겠지만 지금은 타이핑과 단순 프로그래밍에 쓸 시간을 아끼고 더 어려운 문제 접근방법에 투자할 수 있어서 생산성 면에서 긍정적으로 보입니다.
저자는 맹목적으로 AI도구에만 의존해서 사용하는 것을 이야기 한 것 같긴한데요
저의 개인적인 의견은 AI를 활용해 업무의 효율성이 높아졌다면,
이를 적극적으로 활용하여 반복적인 작업을 줄이고,
확보된 시간을 더 넓은 영역(예: 백엔드 개발자가 프론트엔드나 앱 개발까지 확장)이나
아키텍처 설계와 같은 발전적인 방향으로 투자하는 것이 바람직하지 않을까 생각합니다
전체적인 내용을 봐서는 위 의견에 저자도 동의하실 것 같지만
가끔 AI 자체를 거부하시는 개발자 분들도 있어서 답글 몇자 적어봅니다..ㅎㅎ
.
흠... 애초에 AI를 도구로 보느냐 지능으로 보느냐 관점의 차이인듯.. 저는 이 글에 동의할 수 없는게 아래 댓글에서 얘기했지만 개발자를 코드 레벨로만 보는 것 자체가 잘못된 생각이며 과거 영국에서 산업혁명이 일어났을 때도 농부들은 우리 굶어 죽는다고 아우성이었지만 결과적으로 더 많은 일자리 창출과 인류에 많은 혜택을 주었습니다. 또, 과거 컴퓨터가 등장하였을 때도 컴퓨터 때문에 사람들은 점점 바보가 될 거라는 말들이 있었지만 결과적으로 더 많은 일들을 더 빠른 시간에 해결하고 사람들은 더 스마트해졌습니다.
아직도 cursor와 anthropic의 열렬한 신봉자이긴 합니다만, 어느순간 열광하던 agent 모드를 점차 사용하지 않고 ask 모드로 아키텍처와 구현방법을 먼저 물어본 뒤에 충분히 납득했을때만 한땀한땀 AI의 변경제안을 받아들이도록 스스로 바꾸고 있더라고요.
그렇게 크지도 않은 (하지만 저희 업무 프로젝트에서 꽤 중요한) 모듈을 2명의 엔지니어가 각자가 agent 모드를 이용해 리팩토링 하고 구성을 추가하면서, 어느순간 아키텍처를 정리하겠다던 의도의 코드가 실제로는 가독성도 구조도 더 엉망으로 만들어버리는 상황을 직접 마주하고 나니 이렇게 바뀌게 되었습니다.
저도 이렇게 사용하고 있어요. 정말 완전히 처음 만져보는 언어라면 agent 모드를 쓰는데, 아는 언어면 납득되는 코드인지부터 확인을 하게 되더라고요.
몰랐던 라이브러리 기능이나 바로 떠오르지 않는 쉘스크립트 같은거라면 괜찮지만 이미 deprecated된 기능, 없는 function 같은 게 섞여있어서 디버깅 하느라 시간 다 보내죠
LLM의 답변을 그대로 받아들이지 말고, 왜 그런 접근 방식을 추천하는지 분석해야 함
이 말이 핵심이라고 봅니다
도구는 언제나 사고의 확장과 동시에 사고의 파괴를 가져오는 것 같다는 생각이 듭니다. 사고의 파괴를 통해 고차원적인 사고의 확장으로 나아갈 수 있어야 하는데 그러한 준비가 되지 않은 순간들에서는 항상 이러한 문제들이 따라오는 것 같습니다.
따라서, 결국 도구의 사용에 있어 언제나 이런 고민들이 함께 따라오는 것 같구요. 저는 꼭 필요한 과정들이라고 생각이 듭니다. 단순히 거부한다거나 맹목적으로 쓴다기보단 이 도구를 어떻게 사용하는 것이 좋은가 어떻게 이러한 도구를 활용해서 근본적으로 더 중요한 부분들에 리소스를 쏟을 수 있을까에 중점을 두며 쓰는 것이 바람직하다고 생각듭니다.
(cursor의 usage를 월 1,000회를 넘겨가며...)
Hacker News 의견
- 어떤 사람들은 자신의 코드를 작성하는 것을 즐기지 않을 수 있음. 그런 경우, 그들이 적합하지 않은 분야에서 일하려고 한다고 볼 수 있음
- 나는 수십 년 동안 내 코드를 작성하는 것을 견뎌왔음. 때때로 만족스럽지만, 주로 내 아이디어와 나 사이에 있는 추상화임
- 나는 빠르게 무언가를 만드는 것을 좋아하며, 아이디어가 있을 때 가능한 효율적이고 깔끔하게 구현되기를 바람
- LLMs와 함께 일하는 것을 받아들였음. 이것이 나를 더 게으르게 만들었다고는 생각하지 않음
- 오히려 내가 막힐 때 시작하도록 영감을 줌. LLM이 작업을 시작하면 내가 이어받아 내 방식대로 마무리함
- 나는 이전보다 더 많은 제품을 생산하고 있음
- 나는 사람들과 함께 일했고, 그들 중 몇몇은 친구임. 그들은 자신의 코드와 방법론이 신성하다고 생각함
- AI가 들어오면 그들에게 자리가 없다고 생각함. 나는 창의성을 위해 이 게임에 들어왔고, 그것이 내가 여기에 있는 이유임
- 도구와 문법은 모두 목적을 위한 수단일 뿐임
- 새로운 추상화 계층이 개발되어 하위 계층을 이해하지 않고도 작동하는 코드를 쉽게 개발할 수 있게 될 때마다 이런 일이 반복됨
- 거의 항상 누출이 있는 추상화임. 때로는 하위 계층이 실제로 어떻게 작동하는지 알아야 할 필요가 있음
- 하위 계층을 이해하는 데 많은 시간과 감정적 에너지를 투자한 개발자들은 추상화에 의존하는 사람들이 더 어리석다고 주장함
- 우리는 모두 제3자 라이브러리에 의존하지 않고 코드를 직접 작성하면 더 똑똑해질 것임
- 메모리를 수동으로 관리하면 더 똑똑해질 것임
- 모든 코드를 어셈블리어로 작성하고 컴파일러에 의존하지 않으면 더 똑똑해질 것임
- 자신의 트랜지스터를 배선하면 더 똑똑해질 것임
- 하위 계층을 배우는 것은 교육적임. 종종 최적의 성능을 짜내기 위해 필요함
- 그러나 고객에게 가치를 제공하기 위해 하위 계층을 이해할 필요는 없음
- 코딩 LLMs를 사용하여 내가 아직 이해하지 못한 코드를 이해하는 데 도움을 요청하는 것이 가장 마음에 듦
- 비록 답이 틀릴 때도 있지만, 종종 내가 스스로 해결할 수 있는 힌트를 제공함
- 비슷한 경험을 했음. LLM을 사용하여 기능을 구축했으나, 코드가 이미 존재하는 라이브러리에서 가져온 것임을 발견함
- 제대로 연구했더라면 훨씬 나쁜 버전을 만들지 않았을 것임
- 이제는 주석을 기반으로 에디터에서 프로토타입 기능을 얻는 데만 사용하고 나머지는 내가 함
- AI 파이프라인을 설정하는 것은 재미를 모두 빼앗고 매우 벅찬 작업처럼 느껴짐
- 차라리 코딩을 하고 싶음
- LLM이 2, 3, 4번 연속으로 틀리면 진정한 분노가 끓어오름
- 지치게 됨
- 앞으로 1~2년 내에 더 쉬워지고 UX가 개선될 것으로 기대하지만, 어떻게 될지는 모르겠음
- 아마도 내가 비전을 부족하게 가지고 있을 것임
- LLMs는 학생들이 기술 문제를 깊이 이해하고 집중하는 동기를 빼앗음
- 대신 복사, 붙여넣기하고 이해하지 않고 넘어감
- 전자 계산기 비유가 적절할 수 있음. 손으로 계산하는 방법을 배운 후에야 적절한 도구임
- 실험에서 비즈니스 학생들에게 ChatGPT와 데이터 과학 과제를 주었음
- 그들은 배경 지식 없이 해결책을 찾았지만, 지식을 얻지 못했음
- 친구가 "이 언어 모델은 일반 대중에게 제공되어서는 안 된다"고 언급함
- 이전 직장에서의 개인적인 일화
- 주니어 개발자가 오랫동안 사용되지 않은 브랜치 목록을 생성하는 스크립트를 작성하는 임무를 받았음
- 리뷰 요청을 받았고, 대부분이 awk로 작성되었음
- 그들은 임무 정의를 LLM에 입력하고 답변을 복사하여 풀 리퀘스트에 붙여넣었음
- 플라톤, 파이드로스, 기원전 370년: "그들은 더 이상 스스로 기억하지 않고 외부 표식을 통해 기억을 불러일으키기 때문에 기억을 사용하지 않게 될 것임"
- 나는 구식일 수 있지만, 침묵하는 실패가 시스템이 할 수 있는 최악의 것 중 하나로 여겨졌던 시절을 기억함
- LLMs는 침묵하는 실패 기계임
- 그들은 그들의 자리에 유용하지만, 상사가 인간 노동을 AI로 대체한다고 들으면 그들이 자초한 재앙을 겪을 것이라고 확신함
- 소프트웨어 엔지니어링에 들어간 이유는 무언가를 만들고 작동 방식을 알아내는 것을 좋아하기 때문임
- 키보드로 코드를 작성하는 것은 기술의 부수적인 효과일 뿐임
- 수학자가 되기 위해 화이트보드에 방정식을 쓰는 것을 즐겨야 한다고 말하는 것과 같음
- 엔지니어링에서 해결책을 찾는 것이 일반적으로 최종 목표임
- 손으로 모든 것을 입력하는 것이 가치가 있을 때, 좋은 엔지니어는 손으로 입력해야 함
- 제3자 라이브러리를 가져오는 것이 최선의 사용이라면 그렇게 해야 함
- LLM에 일부 코딩을 맡기는 것이 가장 쉬운 길이라면 그렇게 해야 함
- "Copilot Lag"라는 개념이 있음
- 엔지니어가 각 작업 후에 다음에 무엇을 해야 할지 기다리는 상태를 의미함
- 10-15년 동안 이 경험을 해왔음
- LLM은 너무 많은 해를 끼치지 않을 것임
- 코딩 코파일럿을 포기할 지경에 이르렀음
- 대부분의 시간을 그것들과 싸우는 데 보냄
- 일부는 내 잘못일 수 있음
- UX/구현 문제도 있음
- LLMs는 다양한 주제에 대한 중간 전문가로서 유용함
- 그러나 에코 챔버에 빠지기 쉬움
- 인간의 직관, 호기심, 창의성, 개성이 필요한 순간에 벽에 부딪히는 것은 충격적임
- 나는 그것을 도구 상자에 또 다른 도구로 두는 것에 만족함
- 그러나 실제 사람들과 협력하는 것을 선호함
언제부터인가 코드리뷰와 같은 개념으로 쓸때가 많은거같네요. 코드를 제안받고 코드 방향성을 얘기하고 좀 더 나은 방법에 대해서 고민하고 제안하고 내가 만족할만한 결과가 나오면 인용하고 있어요.
개발자를 코딩에만 제한하면 이런 걱정이 나옴. 사실 개발자는 더 많은 일을 하는데 코딩 부분을 AI에 의존하는 걸 바보가 된다고 생각할 수도 있겠지만 다른 부분에 더 집중할 수 있게 해준다고 볼 수도 있음
김대리. 내가 감히 조언 하고 싶은것이 있읍니다. 다른것이 아니고, 너무 엑셀 팡션? 사용 하지 마세요. 편리함이 있다면, 위험성은 증대하죠. 소를 잡는데는 그만한 칼날이 있고 닭잡는데는 칼이 필요 한가요? 쉬운것이 정답 일수 있읍니다.
다시는 chatGPT를 사용하지 않겠다
저도 비슷한 글을 작성했었습니다.
생산성이 증대되는 효과는 분명히 있지만, 뇌를 맡겨버리는 행위 자체를 지양해야한다고 생각합니다.