▲

AI가 나를 멍청하게 만들고 있다

 (jpain.io)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • AI로 글쓰기는 기사·코드·문서 작성에서 강한 유혹이지만, 직접 쓰고 생각하는 능력이 줄어든다는 불안을 키움
  • AI가 만든 결과물은 다시 읽으면 “그냥 AI 같다”는 느낌이 들고, 자신의 말투나 의도를 제대로 담지 못함
  • 지난 1~2년간 코딩에서 AI에 크게 의존하며 거의 프롬프트만 작성했고, 직접 코드 작성법을 잊은 듯한 상실감이 커짐
  • 이제 다시 손으로 코딩하는 법을 배우려 하며, 코드를 읽고 쓸 줄 아는 사람은 AI 이후에도 계속 필요하다고 봄
  • Claude에 글을 붙여넣어 확인하고 싶은 충동 자체가 자기 의심이며, AI가 기대는 불안으로 맞서야 할 대상이 됨

AI 사용이 글쓰기와 코딩 역량을 약화시킨다는 불안

  • AI로 글쓰기는 기사, 코드, 문서 작성에서 매우 유혹적이지만, 직접 쓰는 능력을 줄이고 있다는 감각을 줌
  • 예전에는 글쓰기나 소프트웨어 개발에서 아주 뛰어나지는 않아도 어느 정도 능력이 있다고 봤지만, AI 사용이 늘수록 자기 기술이 나빠지는 느낌이 커짐
  • AI로 쓴 결과물은 다시 읽으면 “그냥 AI 같다”는 인상을 주고, 자신의 말투나 의도와 맞지 않으며 말하고 싶은 바를 제대로 담지 못함
  • 이 불안은 자기 의심과 임포스터 증후군을 키우고, 실제로 자신이 결과물을 만들 수 있는지까지 의심하게 만듦

코딩을 다시 손으로 배우려는 이유

  • 지난 1~2년 동안 코딩에서 AI를 전적으로 사용했고, 거의 프롬프트만 작성했으며 직접 코드 한 줄도 쓰지 않았다고 느낌
  • 그 결과 코딩 방법을 대부분 잊어버린 듯하고, 한때 삶의 중심이었던 코딩을 잃어버린 일이 슬프고 우울하게 다가옴
  • 이제 다시 손으로 코딩하는 법을 스스로 배우는 중임
  • AI가 있어도 소프트웨어 개발 역량이 완전히 사라지지는 않는다고 봄
    • 코드를 읽고 쓸 줄 아는 사람은 계속 필요함
    • 필요한 사람 수는 줄어들 수 있지만, 그런 사람 자체는 여전히 필요함
  • AI가 지난 20~30년간 이어진 소프트웨어 개발자 수요 초과 흐름을 되돌릴 수도 있기를 바람
    • Robert Martin(Uncle Bob)의 강의처럼, 컴퓨터 과학이 직업이 되기 전에는 물리학자, 수학자, 학자 같은 전문가들이 프로그래밍을 했음
    • 소프트웨어 개발자 수요가 급증하면서 전문성이 희미해졌다고 봄
  • AI 없이 쓴 글인데도 내용이 이상하거나 빠진 부분이 있을까 걱정돼 Claude에 붙여넣어 확인하고 싶은 충동이 생김
  • 그런 충동 자체가 AI가 먹고사는 자기 의심이며, 맞서 싸워야 할 대상으로 남음

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 이 주장에는 크게 공감이 안 됨. AI로 코드를 쓸 때마다, AI가 한 일을 전부 훑어보고 내 코드로 보완하거나 고쳐야 한다는 찜찜한 감각과 계속 싸우게 됨
    몇 분 만에 바이브 코딩으로 동작하는 앱을 얻는 도파민은 있지만, 그 찜찜함이 상쇄해 버리고 당분간 사라질 것 같지도 않음
    다만 경험이 있어서 그런 것 같고, 주니어나 미드레벨 개발자였다면 나도 충분히 빠졌을 수 있음. 커리어 초기에 지식 있는 멘토들에게 코드 리뷰로 맞아가며 생긴 흉터가 아니었다면 그 감각도 없었을 듯함

    • 내 경험상 Claude는 코드를 뿜어내는 법밖에 모르는 듯함. 어떤 문제를 줘도 “코드를 줄이기”보다는 “코드를 더 쓰기”로 번역함
      Claude가 만든 것은 아주 꼼꼼히 코드 리뷰해야 하고, 안 그러면 코드베이스가 계속 커지면서 기술 부채 100%에 점근할 것임
      Claude 산출물은 전부 리뷰하는데, 90~95% 정도는 “와, 동작은 하네. 근데 코드가 너무 많다. 이제 더 이상 뺄 게 없을 때까지 3시간 동안 손잡고 줄여보자”가 됨
    • “몇 분 만에 바이브 코딩”은 하지 말아야 함. 누군가 즉흥적으로 만든 농담이었는데 업계가 농담으로 받아들이지 않았고, 일부는 실제 개발 방식으로 가능하다고 생각하지만 그렇지 않음
      에이전트와 더 나은 협업 방식을 찾아야 함. 사람이 봐야 할 중요한 부분은 리뷰하고 나머지를 “외주” 주면, 직접 프로그래밍했을 때와 같은 방식으로 동작하는 코드와 설계에 더 빨리 도달할 수 있음
      나도 에이전트가 쓴 코드의 90%쯤은 리뷰하지만, 수만 자를 직접 타이핑하고 파일 사이를 계속 오가는 것보다 프롬프트 몇 개를 쓰거나 말하는 편이 훨씬 즐거움. 그냥 타이핑에 지친 걸지도 모름
    • 완전히 동의함. 게임 개발에 AI를 보조로 쓰고 있음. 새롭거나 흥미로운 것을 하려면 직접 코드를 써야 하고, 아니면 고생길이 열림
      하지만 시간이 많이 들고 지루한 잡일은 명확한 아키텍처를 설계한 뒤 AI에게 구현 작업을 맡김. 그래도 나중에 다시 확인해서 엉뚱한 것을 만들지 않았는지 봐야 함
      최근 좋은 예로, Godot로 만드는 게임에서 Codex가 이미 Area2D가 제공하는 동작을 처음부터 다시 구현하려고 했음
      AI에게 의미 있는 일을 시키면 발밑지뢰와 기묘한 선택으로 가득해짐. 수백 달러어치 토큰을 쓰면 다를 수도 있겠지만, 한 달 10달러 쓰는 입장에서는 골칫값이 아깝지 않음
      게다가 내 프로젝트는 취미이고 코딩은 여전히 재미있음. 저장/불러오기, 데이터 파일 파싱, 설정 메뉴 같은 지루한 부분만 AI에게 맡기고, 인간 판단이 필요한 부분에서는 멀리 둠
    • 지금은 경험이 정말 가치 있음. 에이전트를 아주 잘 이끌 수 있지만, 말한 것처럼 주니어들은 걱정됨
      나라면 에이전트를 더 깊이 파고들고 더 빨리 배우는 데 썼을 거라고 생각하고 싶음. 예전에는 Stack Overflow, 여러 IRC 채널, Reddit 등을 엮어가며 해법을 만드는 게 꽤 힘들었음
      하지만 대학 때 숙제도 베꼈고 답을 제대로 검토하지 않았으니 확신은 없음. 그래도 학위만 따려고 한 게 아니라 흥미로 프로그래밍을 했으니 달랐을 수도 있음
      어쨌든 LLM 시대에 들어오기 전에 이미 많은 경험과 실패를 겪어 둔 게 다행임
    • LLM이 만드는 코드는 내 기준으로는 그냥 평균임. 내가 클린 코드 권위자라고 하진 않겠지만, 코드가 잘 구조화됐는지는 알아볼 수 있음
      Claude나 GPT보다 매번 내가 직접 쓴 코드가 더 좋음
      한 번은 이미 작성한 프로젝트에서 명세를 뽑아 LLM에게 그 명세만 보고 다시 구현하게 한 뒤 코드를 비교했는데, LLM 버전은 토사물 같았음

  • 개발자로서는 이 모든 게 어느 정도 고용 안정성처럼 느껴짐
    LLM을 한동안 써 보니 꽤 좋고, 쓰는 것도 마음에 듦. 앱 몇 개를 바이브 코딩해 봤는데 아이디어가 즉시 살아나는 건 도파민이 큼
    하지만 내 경험상 맹목적으로 믿으면 반드시 물림. 바이브 코딩한 프로젝트에서도 내가 요청하지 않은 “기능”을 계속 추가함
    개인 프로젝트라 최종 결과가 기대한 대로면 크게 신경 안 쓰지만, 회사들은 그렇게 유연하지 않을 것임. 고객도 수정이나 업데이트 때마다 기능이 바뀌거나 추가되는 걸 좋아하지 않을 듯함
    현재 상황을 요약하면, 많은 회사가 이 방향으로 가고 있고, 제대로 된 엔지니어링 없이 AI는 코드를 더 많이 쓰며 앱을 의도치 않게 바꿀 수 있음
    AI에 대한 두려움과 채용 감소 때문에 시장에 들어오는 주니어 엔지니어는 줄어들 것임
    AI 사용량이 임계점에 도달하면 막대한 변경이 생기고, 이를 “프롬프트”하는 사람들이 압도당하기 시작할 수 있음
    머릿속에 유지해야 할 기능은 더 많아질 것임. LLM을 100% 신뢰할 수 없기 때문에 개발자는 여전히 애플리케이션이 정확히 무엇을 하는지 알아야 함
    결국 버그가 많이 생기고, 개발자들은 추가 인력이 필요하다고 불평하게 됨. 그러면 채용이 다시 시작됨
    지금 가장 힘든 위치는 신규 개발자이고, 가장 좋은 위치는 이미 시장 안에 있는 사람들 같음

    • 10~20년 전 아웃소싱 붐과 비슷한 점이 많음. 작고 저렴한 회사들이 미국 개발자 한 명보다 싼 비용으로 다른 나라 개발팀 전체를 고용할 수 있다는 걸 보고, 높은 기대와 낮은 프로세스로 뛰어들었음
      성공시키기 위한 준비는 거의 안 했고, 가장 싼 선택지를 맹목적으로 고용해 모호한 요구사항을 던진 뒤 지속적인 기술 리뷰나 감독을 거의 하지 않았음
      흐름은 말한 것과 비슷했음. 처음에는 상상 가능한 가장 지저분한 코드로 프로토타입이 빠르게 올라가며 성공처럼 보였지만, 시간이 지나면서 기술 부채와 나쁜 결정이 점점 큰 저항이 되어 진행이 느려지고 결국 프로젝트가 멈추거나 죽었음
      이번에는 다를 수도 있지만, 내 초기 업무의 상당수는 이런 패턴의 프로젝트를 정리하는 일이었음. 새로 올라오는 개발자들도 같은 기회를 얻으면 좋겠음
    • 결국 버그가 많이 생기고 개발자들이 추가 인력이 필요하다고 불평하는 시점까지 내가 버틸 수 있으면 좋겠음
    • 나도 거의 같은 결론임. 인턴들에게 정석적인 길을 가르치려고 정말 애쓰고 있음
    • 분산된 맞춤형 솔루션이 폭발적으로 늘고 유지보수가 필요해지며, 그 결과 채용이 늘 수도 있다는 전반적 감각에는 동의함. 하지만 이 생각을 유력하다고 완전히 받아들이기엔 아직 망설여지는 것을 많이 봤음
      우선 효율 향상이 엄청남. 어떤 가격의 어떤 도구보다 큼. 우리 회사의 주 제품은 웹 앱이고, 지난 몇 년간 주 제품 재작성 작업을 해왔음
      어느 오후에 원하는 스택으로 새 프로젝트를 만들고, 몇 시간 만에 우리가 작업해 온 제품의 MVP를 바이브 코딩할 수 있었음
      완벽하진 않았지만, 기능을 하나씩 작은 프롬프트로 요청했고 각각 5~10분 걸렸음. 꽤 전문적으로 보였고 어떤 기준으로도 “충분히 좋았음”
      시간을 조금 더 주면, 작은 개발팀이 몇 년 걸려 만든 것을 혼자 출시하고 유지할 수도 있었을 것 같음. 안타깝게도 이는 효율 향상 도구라기보다 값싼 “팀 전체 대체재”에 가까움
      또 비기술 CEO들의 AI 과열도 있음. 우리 CEO와 임원진은 Claude의 에이전트 도구군을 완전히 받아들였고, 매일 목업, 앱, 도구 체인을 띄우고 있음
      중독된 게 보이고, 이득을 직접 체감하고 있음. 아직 일어나진 않았지만 CEO가 개발팀 대부분을 해고하고 숙련 개발자 몇 명과 함께 앱 전체를 바이브 코딩해도 놀라지 않을 듯함
      지금은 “AI는 대체자가 아니라 승수다!”라고 말하면서도 같은 문장에서 “이걸로 앞으로 몇 년간 채용을 안 해도 된다면 승리다!”라고 함
      왜 앱 전체를 바이브 코딩하면 안 되냐는 질문을 정면으로 받았는데, 딱히 답이 없었음. “앱을 유지보수하는 법을 모를 것” 같은 그럴듯한 생각은 있지만, Claude는 개발자 한 명 손에서도 꽤 해낼 수 있음
      “AI가 앱을 의도치 않게 바꾸고 버그를 넣을 수 있다”는 말도 있지만, 적절한 관측성, 테스트, 추가 프롬프트로 몇 분에서 몇 시간 안에 고칠 수 있음
      솔직히 회사가 개발팀 전체를 계속 유지하는 게 더는 말이 안 되는 것 같음. 아무리 많은 프로젝트를 시작하고 이니셔티브를 진행해도, 백로그는 빠르게 줄어들고 개별 개발자 처리량은 터무니없이 커짐
      비기술 CEO들은 기술 부채, 인지 부채, 나쁜 소프트웨어 설계 관행, 코딩 학습, 개발자를 똑똑하게 유지하는 것, 문제 해결의 즐거움, 좋은 알고리즘이나 아키텍처의 예술성에는 관심 없음
      그들이 원하는 건 그럭저럭 잘 동작하고, 가치를 제공하고, 돈 낼 만하며, 가능한 한 싼 투자로 출시되는 제품임. 불행히도 AI는 거의 모든 면에서 그 조건에 맞음
      새로 만들어지는 소프트웨어의 엄청난 양이 수요를 늘리길 바라지만, AI가 주는 거대한 생산 능력 증가를 상쇄하기엔 부족할까 걱정됨

  • 다음 달에 TypeScript를 배우려고 시간을 비워뒀음. 그 과정에서 AI를 완전히 배제할 생각은 없음
    계획은 책을 처음부터 끝까지 읽고, 그다음 코드를 쓰는 것임. 이 방법을 어떤 팟캐스트에서 Mitchell Hashimoto에게 들은 것 같음
    원글처럼 프롬프트 코딩에 많은 시간을 써왔기 때문에 기대되면서도 무서움

  • 코드를 손으로 쓰지 않는다고 덜 똑똑해지는 건 불가능함. 그게 가능하다면 휴가를 갈 때마다 더 멍청해져야 함
    챗봇과 대화한다고 뇌의 신경 연결이 죽지는 않음
    실제로 일어난 일은 고도로 기술적인 능력을 잠시 쉬었다는 것임. 지구상의 누구든 한동안 쓰지 않으면 그 기술의 일부를 “잊음”
    하지만 정보가 사라진 게 아니라, 더 관련 있는 정보에 밀려 우선순위가 낮아졌을 뿐임. 잠깐 복습하면 다시 돌아옴
    AI 이전에도 여러 언어 중 하나로 완전한 프로그램을 쓰는 간격이 몇 달씩 벌어지곤 했음. 함수 정의를 어떻게 시작하는지 같은 단순한 것도 잊었음
    하지만 진짜로 잊은 건 아니었고, 기존 함수 하나를 잠깐 보면 함수 정의에서 가능한 다른 문법도 모두 기억났음. 당황할 필요 없고, 뇌는 정상적으로 동작하고 있음

  • 학교에서 AI의 위험을 많이 이야기하지만, 같은 위험은 어떤 학습 환경에도 적용됨
    최근 새 직장을 시작했는데, AI 때문에 온보딩이 훨씬 어려워지고 있음. AI를 덜 쓰는 동료들보다 역할 적응이 훨씬 느림
    익숙하지 않은 언어로 코딩 중이라 바이브 코딩의 유혹이 더 강함. 그래도 Claude가 말도 안 되는 답이나 불필요하게 장황한 답을 줄 때 알아차릴 정도의 실력은 있음
    하지만 Claude에게 코드를 써달라고 하는 시간이 늘수록, 이 직무가 요구하는 능력을 내가 키우고 있다는 느낌은 줄어듦. PR을 올릴 때도 내 작업에 필요한 자신감이 없어서 기분이 좋지 않음
    솔직히 또 다른 부분은, 사람에게 물어봐야 할 질문을 Claude에게 Slack과 문서에서 찾아보라고 시키고 있다는 것임
    AI가 내 사회불안을 먹여 살리며, 이해에도 좋고 기본적인 사회적 상호작용에도 필요한 인간 접촉을 피하게 유혹함
    이게 책임을 회피하는 것처럼 들리지만, 어떤 기술이 특정 유형의 사람에게 특히 중독적이고 부정적인 행동 루프에 가둘 수 있다는 점은 짚어야 함
    지금 AI 의존을 미루면, 나중에는 능력을 키워 결과 검증이 쉽고 반복적인 작업을 AI에 위임할 수 있을 정도가 될 것 같음. 어렵지만 필요함

    • Claude에게 필요한 것을 가르쳐 달라고 하는 방향을 추천함. 이 문자열을 대문자로 바꾸려면? 이 문제는 어떻게 접근하는 게 좋은가? 이 작업에는 표준 방식이 있나?처럼 물어보면 됨
      그러면 그 과정에서 배울 수 있음. 검색엔진처럼 쓸 필요 없이 그 순간 알아야 할 것을 물으면, 토큰 사슬을 흔들어 특히 언어 초보자에게 유용한 무언가를 내놓음
      이렇게 하면 먼저 실력을 키우고 나중에 위임을 시작하겠다는 계획을 실행할 수 있음
      나는 이렇게 해왔고, 내게는 좋은 균형임. 평가할 줄 모르는 코드를 Claude에게 작성시키는 건 미친 짓처럼 보이는데, 이 생각이 소수파인 것 같음
    • 지금은 도제식 교육, 즉 인턴십에는 최악의 시기임. 모두가 AI로 빠르고 좋게 출시하길 기대하지만, 빠른 반복 속에서는 기술을 익힐 시간이 거의 없음
    • LLM은 코드베이스를 요약해서 빠르게 파악하는 데 꽤 유용했음
      사실상 바이브 코딩 외에 내가 겪은 몇 안 되는 진짜 사용 사례 중 하나임

  • AI를 사고 제거용으로 쓰는 게 아니라, 반복적이고 지루한 코드 작성에서 벗어나기 위해 씀. 프로토타입이 구현된 뒤에는 AI가 코드를 작성하는 데 충분히 유능함
    나는 초기 개념증명용 조잡한 프로토타입을 직접 작성함. 주석 없고, 변수를 하드코딩하는 식임. 그다음 AI가 이를 제품 수준으로 다듬음
    덕분에 업무 윤리, 실력, 높은 코드 품질 유지 능력이 제각각인 사람들을 관리하는 대신 에이전트 팀을 지휘할 수 있게 됨
    AI는 코드베이스의 기존 패턴을 유지하거나 업계 모범 사례에 맞추는 데도 꽤 뛰어난 경우가 많음
    AI를 쓰면 더 이상 프로그래밍 언어로 그렇게 많이 쓰지 않게 됨. 영어든 LLM과 대화하는 언어든 그것이 주 언어가 될 것임

    • “프로토타입이 구현된 뒤에는 AI가 코드를 작성하는 데 완벽히 유능하다”라니, 완벽하다고? 확실히 완벽과는 거리가 멀음
      요즘 내 하루 대부분은 코드 생성 로봇이 만든 불완전함을 고치는 데 쓰임
      물론 나는 프로토타입을 다듬는 게 아니라 8년 넘은 중요 제품을 유지보수하고 발전시키고 현대화하는 중이긴 함
    • 반복적이고 지루한 코드가 대체 뭐임?
      어떤 프로젝트에서 그런 지루한 반복 코드가 솔직히 얼마나 된다는 건가?
    • 대부분의 시간은 LLM이 작업할 계획과 프로토타입 윤곽을 만드는 데 쓰임. 안 그러면 전체가 끔찍한 난장판이 됨
      정교하게 만든 프롬프트가 필요하므로, 기반 프레임워크와 언어를 제대로 이해해야 함. 그렇지 않으면 전체가 끔찍한 난장판이 됨
      여러 에이전트를 어떻게 다루는지도 모르겠음. 보통 꽤 빨리 끝나기 때문임. 실행 사이에 뭘 할 수도 없음. “1분만 더 있으면 끝난다” 상태가 계속됨
      끝나면 출력물을 평가해야 함. 그래서 “작업” 중 깊은 사고도 못 함. 패턴이 소셜미디어와 비슷함. 지속적인 주의, 거의 즉각적인 보상임
      결국 주의 집중 시간이 계속 망가지고, 제대로 망가짐
      문제는 이런 계획이 몇 시간 안에 사라지고, 그다음엔 출력물을 분석하고 반복하면서 멍청한 부분을 걸러내야 한다는 점임
      여러 에이전트 출력물을 다루는 건 계속되는 문맥 전환임. 장기적으로 잘해 보길 바람
      에이전트를 마음대로 뛰놀게 하고 아무거나 만들게 두면 출력물은 거의 확실히 끔찍한 난장판이 됨. 끝임

  • 현재 프로젝트에서 매일 Java, Ruby, JavaScript로 코딩함. 예전엔 간단한 Google 검색이면 됐던 언어 차이를 확인하느라 토큰을 많이 낭비함
    Ruby와 JavaScript의 null-safe 연산자 차이나, Ruby와 Java의 continue/break 문 같은 것을 자꾸 헷갈림
    Claude는 내가 가장 복잡하게 시키는 일이 오래된 Java 반복문을 더 현대적인 스트림으로 리팩터링하는 정도라 꽤 실망할 것 같음. 그런 코드는 사람이 즉석에서 쓰기엔 거의 불가능할 수 있음

    • “사람이 쓰기엔 거의 불가능”이라니 아쉽음. 그런 리팩터링은 범위가 좁고, 정확성 검증이 쉽고, 작은 퍼즐 같아서 내가 가장 좋아하는 작업임
      직접 collector를 만들거나 표준 라이브러리의 좀 더 obscure한 부분을 쓰면 보너스 점수임
    • Google이 망가진 것도 도움이 안 됨. 예전엔 단순한 Google 검색이면 되던 것이 이제는 어차피 AI가 끼어든 열화된 내장 경험이 됐음

  • 반대 사례도 있음. /plan 모드에서 AI와 아이디어를 주고받고, 내가 AI의 잘못된 가정을 잡아내며, 필요할 때 AI가 지식 공백을 명확히 설명해 주는 과정은 지적으로 꽤 자극적이고 나를 더 나은 엔지니어로 만드는 것 같음
    핵심은 AI에게 소크라테스식으로 접근하고, AI가 제안하는 것을 전부 신중히 생각하며, 자신감 넘치는 말투와 완벽하게 구조화된 논리에 최면 걸리지 않는 것임

  • 나는 정반대의 경험을 하고 있음. 아마 내가 있는 분야에서는 코드/소프트웨어가 제품이 아니라 도구이기 때문일 것임
    훨씬 더 빠르고 많이 배우고 있음. 예를 들어 지금 라만, NMR 같은 분광학 하드웨어를 다루는데, Claude에게 장비와 하드웨어 수준에서 인터페이스하는 코드를 쓰게 했음
    내가 데이터시트를 뒤지고 래퍼 코드를 잔뜩 쓰는 대신 Claude가 해줬음
    Claude와 여러 기법을 논의하고, 구현하고, 테스트하는 식으로 훨씬 빠르게 진행할 수 있음. 예전이라면 이 루프는 5~10배 더 오래 걸렸을 것임
    결과를 보기 위해 하찮은 코드를 쓰는 데 정신적 노력을 쓰지 않아도 되니, 이 장비와 기법과 데이터에 대해 훨씬 더 많이 배우고 있음
    개발자로 10년 넘게 일했음. 이제야 코드를 계속 제품으로 만들 생각만 하기보다 도구로 활용할 수 있는 세계로 가는 것 같아 기쁨

    • 코드가 제품이 아니라 도구라는 건 그냥 당신 얘기일 수도 있음. 도구로서의 코드는 언제나 존재해 왔음

  • 손으로 코드를 쓸 시간을 가질 특권을 누리는 사람은 많지 않을 것 같음
    실제로 우리가 쓰는 코드를 보면, 내 경우 대부분 새롭거나 멋진 게 아니라 늘 하던 “X를 위한 백엔드 만들기”, 간단한 버그 수정, 미드~시니어 프로그래머에게 사소한 작업들임
    더 어려운 작업은 대체로 코드 위의 아키텍처 결정이고, LLM이 기능 구현에서 탈선하지 않게 하는 시스템을 어떻게 만들 수 있을지도 고민 중임
    하고 싶은 말은, 지금은 손으로 코드를 쓰는 게 괜찮을 수 있지만 앞으로는 주주나 윗사람들이 LLM의 도움으로 기능 출시와 버그 수정을 더 빠르게 하길 원할 것이라는 점임
    그 속도를 못 내면 성과가 낮아질 것임. 결국 중요한 건 우리가 원하는 게 아니라 주주가 원하는 것임
    물론 지치지 않는다면 여가 시간에 손으로 코드를 쓸 수는 있음. 비관론자처럼 들리고 싶진 않지만, 곧 꽤 현실이 될 것이라 봄

    • 애초에 속도 문제가 아니었음. 빠른 진전은 같은 원시 요소를 더 빨리 써서가 아니라, 더 나은 시스템을 설계하고 탄탄한 추상화를 만드는 데서 주로 나옴
    • 누구에게나 손으로 코드를 쓸 시간은 있음. AI가 실제 생산성 향상을 만들어내지 않기 때문임
답변달기