AI 코딩이 드러낸 개발자들의 슬픔과 분열

• AI 코딩 도구의 확산이 개발자 사이에 항상 존재했지만 보이지 않았던 동기의 차이를 수면 위로 드러내고 있음
• 코드 작성 자체의 장인적 만족감을 잃는 것에 대한 슬픔과, 코드를 둘러싼 생태계·커리어 환경 변화에 대한 슬픔은 서로 다른 종류의 상실감
• 1980년대부터 프로그래밍을 해온 개발자의 시각에서, AI 코딩은 C64 BASIC에서 어셈블리로, 함수에서 시스템 설계로 이어진 추상화 단계의 자연스러운 연장선
• 수십 년간 코드를 읽고 리뷰한 경험은 AI가 생성한 코드의 품질을 판단하는 감각과 판단력으로 여전히 유효
• 어떤 종류의 슬픔을 느끼는지 인식하는 것이 핵심이며, 장인적 상실과 맥락적 상실은 각기 다른 대응 방식을 요구

---

애도의 시작

• James Randall은 1980년대 7살 때부터 프로그래밍을 시작한 개발자로, 발견의 감각과 끈기를 통해 무언가를 알아내는 경험이 "압축" 되었다고 표현
  • 완전히 사라진 것은 아니지만, 압축 과정에서 무언가가 상실됨
• Nolan Lawson은 "We Mourn Our Craft"라는 글에서 더 직접적으로 상실감을 표현
  • 코드를 손으로 빚던 감각, 새벽 2시에 디버거로 버그를 잡던 경험, "내가 만들었다"는 자부심을 그리워하게 될 것
• 이러한 감정들은 실제 상실에 대한 진짜 감정이지만, 읽으면서 서로 다른 것을 애도하고 있다는 느낌이 지속적으로 들었음

분열의 본질

• AI 코딩이 개발자 사이에 항상 존재했지만 덜 가시적이었던 분열을 드러내고 있음
• AI 이전에는 양쪽 진영 모두 같은 방식으로 일했음: 같은 에디터, 같은 언어, 같은 풀 리퀘스트 워크플로우 사용
  • 장인 지향 개발자와 결과 지향 개발자가 나란히 앉아 같은 제품을 출시하며 구별이 불가능했음
  • 작업의 동기는 보이지 않았는데, 프로세스가 동일했기 때문
• 이제 갈림길이 생김: 기계에 코드를 맡기고 무엇을 만들지 지휘하거나, 직접 손으로 코드를 작성하는 것 중 선택해야 함
  • 이 선택의 순간에 처음 프로그래밍을 시작한 이유가 비로소 가시화됨
• 대학 시절 수학·컴퓨터과학 수업에서도 같은 분열이 존재했음: 증명과 정리 자체를 좋아하는 사람과, 응용에 적용할 때만 흥미를 느끼는 사람

나의 슬픔은 달랐다

• 지난 18~24개월간 실제로 슬픔과 적응 기간을 겪었음
• 새 도구를 이해할 수 없을까 두려웠지만, 실제로는 이해할 수 있었음
• AI가 만든 코드의 품질을 판단하는 능력을 잃을까 걱정했지만, 수십 년간 코드를 읽고 리뷰한 경험은 증발하지 않았음
  • 무언가 잘못되었을 때 여전히 알아챌 수 있고, 안목은 그대로 유지
• 퍼즐 풀이가 끝날까 두려웠지만, 실제로는 한 단계 위로 올라갔을 뿐
  • C64에서 바이트를 배치하던 것 → 함수 작성 → 시스템 설계로 이어진 커리어의 모든 전환과 동일한 패턴
  • 이제 퍼즐은 아키텍처, 구성, 어시스턴트 지휘의 영역으로 이동
• 대부분의 두려움은 현실과 부딪혀 유지되지 않았으나, 일부 슬픔은 남아 있음

남아 있는 슬픔

• HTML을 손으로 쓰는 것이 아니라, 열린 웹 생태계 자체에 대한 슬픔
  • AI의 공유재(commons) 학습, 사람들의 인터넷 경험을 형성하는 주체의 추가적 집중화가 실제 상실
  • 개인적 생산성 향상과 무관하게 사라지지 않는 문제
• 커리어 지형의 변화에 대한 슬픔
  • 30년 이상 해온 웹 개발이 더 이상 뜨거운 분야가 아님
  • 모바일 앱이 일부를 가져갔고, AI 엔지니어링이 현재 주도적 위치를 차지
  • 전환에 성공하고 있다고 생각하지만, 불안은 진짜이며 아직 끝나지 않았음
• 이 슬픔의 핵심: 코드를 쓰는 행위 자체를 그리워하는 것이 아님
  • 코드 주변의 세계가 변하고 있는 것에 대한 슬픔
  • Randall과 Lawson의 슬픔은 장인 정신 자체에 대한 것이고, 이 글의 슬픔은 맥락과 이유에 대한 것

어느 쪽도 틀리지 않았다

• Kevin Lawver는 Lawson에 대한 응답 글에서 과거에 집착하기보다 장인 정신과 열정을 재방향 설정할 것을 주장
• 단순히 향수 대 실용주의로 프레이밍하는 것을 넘어, 자신이 느끼는 슬픔의 종류를 인식하는 것이 실질적으로 유용
• 장인적 상실을 애도하는 경우: "그냥 적응해"라는 말로는 해결되지 않음
  • 그 만족감을 다른 곳에서 찾거나, 일의 느낌이 달라질 것을 받아들여야 할 수 있음
  • 지금까지 장인 정신에 생계가 있었던 것 자체가 행운이었음
• 맥락적 상실을 애도하는 경우: 더 실행 가능한 대응이 가능
  • 새 도구 학습, 원하는 웹을 위한 노력(비록 작은 웹이더라도), 슬퍼하면서 동시에 적응하는 것이 가능
• Nolan Lawson의 표현 인용: "새로운 세계를 축하하지도, 저항하지도 않는다. 해가 뜨고 지며, 나는 무력하게 궤도를 돌고, 내 항의는 그것을 멈출 수 없다"
  • 하지만 슬픔과 공포 속에서도 약간의 흥분이 있다는 것은 솔직한 고백

컴퓨터에게 일을 시키다

• 1980년대에 프로그래밍을 시작한 이래 배운 모든 언어는 목적을 위한 수단이었음
  • 컴퓨터가 원하는 일을 하게 만드는 새로운 방법
• AI 코딩은 그 연장선상의 최신 단계로, 불연속이 아닌 사다리의 다음 칸
• 다만 이 사다리 자체가 변하고 있고, 기대고 있는 건물도 변하고 있어 어디로 가는지 정확히 알 수 없음
• 확실한 것: 생각해서 만든 것이 실제로 작동하는 순간의 만족감은 40년이 넘도록 변하지 않았음
  • 코드가 거기에 도달하는 경로는 달라졌지만, 작동하는 그 순간은 동일

[savvykang]

RAD 도구 나왔을때는 사람들이 어떤 식으로 반응했을지 궁금합니다

[github88]

호들갑 너무 떠네요

[ahwjdekf]

웹 프로그래밍 따위는 ai 가 해주는게 너무 잘된일이라고 봅니다.

[brilliant08]

다른 프로그래밍은 뭔가 숭고한 가치를 가지고 있나보군요.

[onetoday]

HN 평균 연령대가 많이 높고 뭔가 뒤쳐지는 사람들 같다는 느낌이 들 때도 종종 있어요.
그래서 이런 부정적인 글(비판적이 아닌)은 안 읽고 넘기는 편

참고로 가끔 코딩 직접 하는 재미가 떠오를 때가 없진 않고,
웹 쪽이라 좀 더 가능한 것이지 않을까 싶긴 한데
코드 타이핑 안 한지 3개월 넘어가는 중입니다.

무엇보다 이렇게 개발하는 게 너무 재밌어서 어릴 때 처럼 자발적 야근도 많이 하게 되네요

[snisper]

AI때문에 그렇게 고민이면 안쓰면 그만 아닐런지

[GN⁺]

Hacker News 의견들

• 글이 완전히 오해하고 있다고 생각함. ‘장인형(craft)’ 개발자도 결과를 추구하지만, 오래 지속되고 확장 가능한 결과를 추구함
  좋은 프로그래머의 목표는 스스로를 쓸모없게 만드는 것임. 예전엔 어셈블리어로 싸이클을 세고 비트를 포장하던 시절이 있었지만, 컴파일러를 쓰는 게 당연했음. CRUD 앱을 직접 만들던 시절도 있었지만 이제는 프레임워크가 대신함. 메모리 관리, 타입 시스템, 고수준 언어, 노코드/로우코드 시스템 등은 모두 발전의 일부임. 결국 프로그래밍의 목적은 컴퓨터가 우리가 하지 않아도 되게 만드는 것임
  진짜 갈라짐은 ‘소프트웨어는 개선 가능하고 이해 가능한 것’이라 보는 사람과, ‘남이 만든 불가해한 장애물’이라 보는 사람 사이의 사고방식의 차이라고 생각함
  • 이 관점이 마음에 듦. 시스템을 오래 다루다 보면 모든 세부사항이 의미 있게 느껴짐. 하나를 바꾸면 전체에 어떤 영향이 생길지 감이 옴. 하지만 AI 시대의 소프트웨어에서는 이런 이해가 불가능해질까 걱정됨. 너무 많은 코드가 자동으로 생성되어 전체를 파악하기 어려워질 것 같음. 결국 수정이 어렵다면 새로 AI로 만드는 게 더 합리적일지도 모름. 그래서 모듈성(modularity) 이 더 중요해질 것 같음
  • 거의 다 동의하지만 마지막 문장은 예외임. 그건 지능의 문제가 아니라기보다, 실제로 두 번째 부류의 사람들은 수준이 낮은 경우가 많다고 생각함
  • 혹시 이 구분이 Pirsig의 ‘고전적 vs 낭만적’ 구분과 비슷한 걸까 궁금함. 전자는 구조와 원리를 이해하려 하고, 후자는 외형과 감각, 효용을 중시함
  • “좋은 프로그래머는 스스로를 쓸모없게 만든다”는 말은 예전엔 자주 들었지만, 요즘은 거의 사라진 듯함
• 진짜 분열은 기술 발전이 본질적으로 좋은 것이라 믿는 사람과, 역사적으로 생산성 향상이 노동시간 단축으로 이어지지 않았음을 아는 사람 사이에 있음
  8시간 노동제도 기술이 아니라 정치적 투쟁의 결과였음
  • 진짜 분열은 자본 소유자와 노동자 사이에 있음. 자본가는 노동자의 생산물 일부를 상속받은 종이쪼가리로 먹고 삶
  • 이런 논의가 Hacker News에서 더 자주 보이는 게 흥미로움. AI가 개발자를 대체하면, 똑똑하고 동기부여된 사람들이 정치적으로 각성할 수도 있을 것 같음. 역사적으로 기업이 너무 커지면 결국 국가처럼 취급받게 됨
  • 극단적인 주장들이 너무 많음. 결국 진짜 분열은 과학기술을 지지하는 사람과 혐오하는 사람 사이에 있음
• 이제는 단순히 기계식 키보드 타이핑을 좋아하는 사람의 문제가 아님. 진짜 차이는 시스템을 이해하고 새로 만드는 걸 좋아하는 사람 vs 그걸 남에게 맡기고 결과만 챙기는 사람임
  단, 남이 인간이라면 멘토링이나 환경 조성으로 그 공을 나눌 수 있음
  • “진짜 분열”이 항상 ‘지적으로나 도덕적으로 우월한 나’와 ‘열등한 그들’의 구도로 흘러가는 게 웃김
  • 나는 시스템을 이해하고 새로 만드는 걸 좋아하면서도 AI에게 반복작업을 위임하는 걸 즐김. 이런 나는 존재하면 안 된다고? 동의 못함
  • 개발자에는 두 부류가 있음. A형은 보안·테스트·CI까지 꼼꼼히 챙기지만 사용자 입장에선 답답할 수 있음. B형은 테스트나 배포엔 약하지만 사용자 경험을 중시함. 둘 다 필요함. 다만 AI는 A형의 영역부터 대체할 듯함
  • “Claude, 이 무게 좀 들어줘” 같은 느낌임
  • 사람마다 즐거움을 느끼는 지점이 다름. 나는 퍼즐 푸는 과정을 좋아함. 계획보다 즉흥적 해결이 더 즐거움
• AI 이전에는 두 부류 모두 같은 일을 했음 — 같은 에디터, 같은 언어, 같은 PR 워크플로우. 차이는 동기였음. 그래서 어떤 사람은 AI가 코드를 대신 써주는 걸 좋아하고, 어떤 사람은 자신이 즐기던 부분이 사라져서 아쉬워함
  Kellan의 글 “Code has always been the easy part” 도 같은 맥락임. 우리 세대는 웹이 주는 주체성의 감각에 중독되어 기술에 뛰어들었음
  • 진짜 차이는 품질 기준임. 어떤 사람은 변수명 하나에도 몇 시간을 쓰고, 어떤 사람은 “돌아가면 됐다”고 생각함. 둘 다 가치 있음. 다만 모델의 발전 속도가 빨라서 작년 기준으로 판단하면 안 됨. 기본 출력은 평균적이지만, 잘 다루면 훨씬 높은 품질을 얻을 수 있음
  • Perl 프로그래밍이 미학적으로 즐겁지 않았다고? 나는 Perl을 다루는 게 자랑스러웠음. 읽기 어려운 언어를 자유자재로 다루는 쾌감이 있었음
  • Perl은 분명 매력이 있었음. unless 같은 문법은 흐름을 자연스럽게 표현하게 해줬음. 다만 진화가 멈추면서 각자 다른 방식으로 확장해 취약한 코드베이스가 생김
  • 나는 코딩 자체는 즐겁지 않지만, 문제를 풀어냈을 때의 만족감이 큼. 이런 사고 과정이 두뇌 유연성을 유지시켜준다고 느낌
  • 이건 이분법이 아님. 나는 두 부류의 혼합형임. AI가 업무 코딩을 대신해주니, 집에서는 전통적인 코딩을 즐길 여유가 생김
• 나는 결과 중심형임. 결과의 품질을 중요하게 생각함. 코딩 과정보다 완성된 제품의 완성도에 집착함. 하지만 요즘 앱들은 15년 전보다 느리고, 버그가 많음. Claude 앱도 클릭 안 되는 버튼이 뜰 때가 있음
  AI 코딩은 생산성 10% 정도만 올려줌. 진짜 병목은 무엇을 만들지 이해하고 설득하는 과정임. 코딩은 그걸 이해하는 수단일 뿐임
  • 나도 AI를 코드 작성보다 정보 수집과 검증에 더 많이 씀. 여러 LLM을 리뷰어로 두고 서로 비판하게 함. 복잡한 비즈니스 로직을 다루는 데 큰 도움이 됨. AI는 엣지 케이스 탐색에도 유용함
  • 코딩이 병목이 아니라는 데 동의함. AI가 10배 생산성을 만든다는 건 말이 안 됨. 나는 원래 코딩이 빠른 편이라 AI가 크게 도와주지 않음. 오히려 품질보다 속도를 강요받는 상황이 됨. 팀원들이 AI로 수천 줄을 뽑아내니 코드 품질이 급락함
  • 코드 품질과 제품 완성도를 혼동하는 것 같음. 대부분의 문제는 비즈니스 결정에서 비롯됨
  • “결과만 중요하다면 왜 직접 안 하고 외주를 주지 않느냐”는 질문도 가능함
• “HTML을 손으로 쓰던 웹”을 그리워함. 개인이 직접 만들던 DIY 웹 생태계가 기업 소유의 AI 도구로 대체되는 게 슬픔. 지금은 그 중간 단계지만, 개방형 웹의 쇠퇴가 가속화되고 있음
• 생성형 AI도 장인정신의 연장선에서 쓸 수 있음. 오픈소스 코드를 불러와 “이건 왜 이렇게 동작하나?”를 묻는 식으로 이해 기반의 개발을 할 수 있음
  • 퍼즐 푸는 재미는 사라지지 않고 한 단계 위로 이동했음. 이제는 시스템 전체의 구조와 이유를 설계하는 게 장인의 영역임
  • 물론 그 결과를 업스트림에 기여해야 함
  • 사실 이런 건 예전부터 검색엔진으로도 가능했음
• 세 가지 시나리오 모두 나쁨. ① 약한 AI → 대공황 2.0, ② 예상 수준의 AI → 소수의 초부자 독점, ③ 초강력 AI → 인류 멸종. 이상적 AI의 양은 0임
  그래도 저항은 해봐야 함
  • 나도 예전엔 그렇게 생각했지만, 요즘 AI 붐 이후의 현실적 한계를 보며 시장이 곧 조정될 거라 느낌. 지금은 AOL 시대에 더 가까움
  • 진짜 지능은 단순히 텍스트를 도구 호출로 바꾸는 게 아니라, 계획·비판·창의적 문제 해결을 포함해야 함
  • 사실 1, 2번 시나리오 모두 같은 사람들이 이익을 봄. 3번은 대중의 시선을 돌리기 위한 환상임
• 스타트업에서 오래 일하다 보니 ‘장인정신’은 버림. 대신 AI 코드 리뷰 부재나 너무 큰 PR이 얼마나 위험한지 감이 생김. 이런 건 장인정신이 아니라 정확성과 기술 부채 관리의 문제임
  • ‘결과 추구자’가 아니라 공을 챙기며 일은 피하는 사람들이 문제임. 그들의 코드가 망가져도 이미 다른 프로젝트로 떠남
  • 내 경험상 ‘장인정신 vs 결과’ 구도보다, 건물 전체를 잘 짓는 감각이 더 중요함. AI가 하청업자처럼 일부를 맡는 건 좋지만, 지금은 전체를 외주 주는 수준이라 결과물이 엉망임
• 개발자는 두 부류임. 코딩을 너무 좋아해 관리자가 되지 않는 사람, 그리고 기회가 되면 바로 관리자가 되는 사람. AI의 혜택은 두 번째 부류가 더 봄
  • 사람을 잘 다루는 사람은 관리자가 되어야 함. 그리고 세 번째 부류도 있음 — 시스템 설계를 좋아하고 구현은 남에게 맡기는 사람