Hacker News 의견들

• 2025년 3월 Aral Balkan의 글이 인상 깊었음
  코딩은 진흙 덩어리를 다듬어 원하는 형태로 만드는 과정과 같음. 이 과정에서 재료의 한계와 특성을 배우게 됨.
  만들기 전에는 무엇을 만들고 싶은지 가장 모르는 시점임. 디자인은 단순히 문제 해결이 아니라 올바른 문제를 발견하는 일임.
  창작 과정을 건너뛰면 배움과 발견의 인간적인 요소를 잃게 됨. 직접 다듬은 작품은 속속들이 이해하지만, 자판기에서 받은 결과물은 그저 모양만 닮은 모조품일 뿐임

  • 에이전트형 도구로 프로그래밍할 때는 아이디어가 평균적인 형태로 퇴화하지 않도록 계속 밀어붙여야 함
    새로운 아이디어일수록 도구가 이를 ‘정상화’하려 하기 때문에, 그 저항을 이겨내는 노력이 필요함.
    이 과정에서 자신의 아이디어가 무엇이고 무엇이 아닌지를 명확히 정의하게 됨. 밀어붙이기를 멈추는 순간, LLM이 프로젝트의 독창성을 덮어버림
  • 나는 이 모든 게 추상화의 연속이라고 생각함. OS나 컴파일러, 표준 라이브러리를 직접 만들지 않아도 괜찮음.
    이미 만들어진 도구를 조합해 새로운 것을 만드는 게 내 일임.
    창작 과정을 건너뛴다고 해서 작품의 가치가 떨어지는 건 아님.
    예를 들어, Zelda가 Havok 물리 엔진을 쓰거나, Unreal로 만든 게임이 훌륭하지 않은 건 아니잖음
  • 30년간 10곳의 회사에서 일하며, 회사는 나에게 ‘코드 작성’이 아니라 비즈니스 가치 창출을 기대했음
    최근 3주간 Codex, Claude, 테스트 세션을 병행하며 만든 결과물에 자부심을 느낌.
    과거엔 아이디어를 실현하는 게 목표였고, 지금은 고객 만족과 일정·예산 준수가 목표임
  • 한 단계 위로 올라갈 수도 있음. 직접 진흙을 빚는 대신, 각 부품을 명세(specify) 하고 기계가 만들게 할 수 있음
    이렇게 하면 수천 개의 부품으로 구성된 복잡한 시스템을 만들 수 있음.
    과거에는 이런 역할을 회사 조직이 대신했음 — 상층부가 명세를 내리고, 하층부가 부품을 만드는 식으로
  • Michelangelo가 “David가 아닌 부분을 깎아냈다”고 말했듯, 작업은 매체에 영향을 받음
    예전엔 Ruby on Rails로 만든 사이트를 금방 알아볼 수 있었음.
    매체의 특성을 이해하지 못한 채 사람이나 에이전트에게 일을 맡기면, 깨끗한 코드와 유지 불가능한 코드의 차이가 생김
    결국 책임은 지시자에게 있음. 매체 경험이 없으면 결과를 평가할 준비가 안 된 셈임

• 나는 단순히 타이핑이 줄었을 뿐, 여전히 똑같이 생각하고 있음
  도구가 좋아졌을 뿐, 프로그래밍은 여전히 프로그래밍임.
  낙타를 타고 사막을 건너든 헬리콥터를 타든, 결국 여행은 여행임.
  도구가 발전했다고 해서 본질이 바뀐 건 아님

  • 이 글의 댓글들을 보면 서로의 경험을 이해하려는 시도조차 없는 태도가 놀라움
    서로 다른 경험이 공존할 수 있다는 걸 잊은 듯함.
    “생각하기 싫다”는 댓글이 특히 인상적이었음
  • 헬리콥터로 사막을 나는 게 잘못은 아니지만, 직접 걸은 사람과 같은 경험은 아님
    추상화의 다음 단계로 올라가는 건 좋지만, 그 과정에서 잃는 가치도 인정해야 함
  • 저자의 말이 이해됨. 우리는 세세한 부분을 고민하던 시절을 그리워함
    LLM은 단순히 도구의 진화일 뿐이지만, 세밀한 사고 과정이 사라지는 건 아쉬움
  • 하지만 LLM 코딩은 단순한 추상화가 아님.
    오히려 다른 사람에게 일을 시키고 검토하는 행위에 가까움.
    프로그래밍을 싫어하던 사람들은 환영하겠지만, 이걸 ‘프로그래밍’이라 부를 순 없음
  • 에이전트 코딩 후에는 정신적 모델이 약해지는 느낌임
    직접 코드를 짜면 데이터 구조가 머릿속에 그려지지만, 에이전트가 대신하면 그 감각이 사라짐.
    이해 없이 코드를 커밋하는 건 나에게 가치가 없음

• LLM 기반 코딩을 기존 추상화와 동일시하는 건 잘못된 비유임
  컴파일러나 프레임워크는 누수가 없는 추상화를 목표로 하지만, LLM은 본질적으로 누수가 있음
  결국 버그를 찾고 수정하는 건 여전히 인간의 몫임.
  LLM은 우리가 피하려 했던 불확실성과 리스크를 다시 들여온 셈임

  • LLM 코딩은 결국 프롬프트를 코드로 압축 해제하는 과정임
    프롬프트에 모든 변수를 명시하지 않으면, 평균적인 결과물이 나옴.
    자연어가 이런 정보를 담기에 적합한가에 대한 의문이 있음
  • 지금의 LLM은 서툰 인턴 같음. 하지만 인간 전문가가 누수 없는 코드를 만들 수 있다면, LLM도 언젠가는 가능하지 않을까 생각함
  • LLM은 비결정적이라, 입력이 아닌 출력 결과를 버전 관리해야 함
    이는 추상화가 아니라 비결정적 코드 생성임
  • 만약 C 컴파일러가 가끔 작동하지 않는다면, 우리는 그냥 계속 빌드 버튼을 누를 뿐일 것임
    이런 점에서 LLM은 인간의 사고 방식에도 다르게 작용함
  • 많은 개발자들이 ‘추상화’의 의미를 제대로 이해하지 못한 듯함

• 나는 ‘생각하는 사람(thinker) ’이라서 AI 코딩에 큰 흥미가 없음
  OS 커널이나 그래픽 엔진을 직접 만드는 게 즐거움임.
  결과보다 문제를 푸는 과정이 내 취미이자 보람임
  반면 ‘빌더(builder)’들은 AI를 통해 더 빠르게 만들 수 있어 열광함

  • 하지만 ‘빌더=비사고형’이라는 구분은 틀림
    모든 엔지니어는 사고하는 사람임. 단지 도구의 목적이 다를 뿐임

• 수십 년간 코딩해온 입장에서, AI 도구는 자유로움을 줌
  예전엔 시도조차 못했던 아이디어를 빠르게 실험할 수 있음.
  덕분에 짧은 시간 조각을 활용해 개인 프로젝트를 진행할 수 있음

  • 휴대폰으로 프로젝트를 진행한다는 게 흥미로움. 어떻게 하는지 궁금함
  • 가족과 함께하는 삶 속에서 짧은 순간을 진전으로 바꾸는 능력이 정말 큼
  • 나도 이 의견에 동의함. 대부분의 프로그래밍은 보일러플레이트 낭비였음
    AI 덕분에 진짜 사고에 집중할 수 있게 되었음.
    이제는 싱귤래리티가 다가오고 있다고 느껴짐
  • 오후 한나절 동안 여러 접근법을 실험할 수 있음.
    실패해도 배움이고, 성공하면 품질 검증에 집중할 수 있음

• “생각하기”에도 여러 형태가 있음
  집중적으로 몰입하는 사고와, 배경에서 천천히 숙성되는 사고가 있음.
  두 방식 모두 깊은 몰입의 형태이며, AI 시대에 쉽게 잃기 쉬운 부분임

  • 나에게도 여러 종류의 ‘hard thinking’이 있음
    수학적 문제 해결, 철학적 사고, 실무의 복잡한 제약 등 각각 다른 형태의 지적 긴장감을 줌
    결국 중요한 건 어떤 형태든 깊이 있게 몰입하는 경험임

• 내 주변 시니어 엔지니어들을 보면 두 부류가 있음
  일부는 약간의 생산성 향상을 얻었지만, 사고의 깊이가 줄어든 사람들도 있음
  LLM이 제시한 답을 그대로 복붙하는 경우가 많음.
  진짜 문제는 질문을 제대로 던지는 능력의 부재임

  • 구현보다 커뮤니케이션 오버헤드가 더 큰 문제임.
    성숙한 시스템일수록 이런 비율이 90% 이상을 차지함

• 동료 엔지니어들이 AI에 열광하며 직업의 본질을 팔아넘긴 것이 아쉬움
  우리는 생산 수단을 가졌는데, 스스로 포기한 셈임

  • 단기적으로는 실업이 생길 수 있지만, 소프트웨어 수요는 무한함
    AI 덕분에 개발이 싸지고 빨라지면, 오히려 시장이 커질 것임
  • AI를 믿지만 반대하는 태도는 모순적임.
    기술 발전은 항상 특정 직군을 불리하게 만들지만, 사회 전체의 진보를 가져옴
    과거 우리가 자동화를 통해 다른 산업의 일자리를 줄였던 것처럼, 이제 그 순서가 우리에게 온 것뿐임
  • 가치 없이 효율만 추구한 실용주의자들이 문제임
    그 결과는 공허함뿐임. 하지만 그들에겐 그조차 목적이었을지도 모름
  • 이 계층은 마치 소부르주아가 더 큰 부르주아에게 흡수되는 과정 같음
  • 윤리와 철학이 결여된 기술주의의 결과임
    “할 수 있으니 한다” 는 사고가 인간성을 잃게 만듦

• AI가 사고를 없애는 게 아님. 평범한 회사와 평범한 사고방식이 문제임
  진짜 사고를 중시하는 회사를 찾아가야 함

• 나도 LLM으로 코딩하지만 여전히 깊이 생각함
  설계, 리스크, 제약, 기술 부채, 대안 등을 고민함

  • 하지만 LLM과 함께하는 사고는 다른 종류의 사고임
    여러 맥락을 오가며 관리하는 ‘매니지먼트형 사고’에 가깝고,
    며칠간 한 문제에 몰입하는 과학자형 사고와는 다름
  • 나도 비슷한 경험임. LLM 덕분에 코딩은 쉬워졌지만, 검증과 리뷰가 훨씬 어려워짐
    특히 AI를 쓰는 주니어들의 PR은 더 길고 복잡해졌고,
    이제 내 일의 대부분이 리뷰 중심으로 바뀌었음
  • LLM은 작은 단위의 반복 작업에 쓰는 게 가장 효율적임
    빠른 프로토타입, 헬퍼 함수, 코드 자동완성, 라이브러리 탐색 등에서 유용함
  • Claude Code로 100% 코드를 생성해도 여전히 깊은 사고의 비율은 높음
    오히려 단순 작업이 줄어들어 더 많이 생각하게 됨
  • 하지만 LLM 이후의 사고는 코드 자체에 대한 피드백 루프가 사라짐
    예전에는 코드 작성이 상위 설계 사고를 되돌아보게 했지만,
    이제는 그 과정이 줄어들어 ‘덜 깊이’ 생각하게 됨