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의 혜택은 두 번째 부류가 더 봄
  • 사람을 잘 다루는 사람은 관리자가 되어야 함. 그리고 세 번째 부류도 있음 — 시스템 설계를 좋아하고 구현은 남에게 맡기는 사람