Hacker News 의견들

• 나는 사용자들을 두 부류로 나눌 수 있다고 봄
  하나는 도구로서 AI를 활용하는 사람들로, 한계를 인지하고 반복적이거나 지루한 일을 맡기거나 요약을 얻는 용도로 씀
  다른 하나는 사고 자체를 외주화하는 사람들로, 주제에 대한 이해가 거의 없고 결과만 원하며 학습 의지가 없음
  후자는 챗봇이 시니어 개발자를 대체할 수 있다고 믿는 부류임

  • 회사가 ‘생각하는 엔지니어’를 원치 않는다는 걸 깨닫고 나도 일에서 사고를 외주화하기 시작했음
    빠른 납기만 중요하고, 고객 피드백은 반년 후에나 오니 의미가 없음
    이제는 최소한의 노력만 들여 월급만 받으며 버티는 중임
  • 또 다른 유형도 있음. 사고 능력을 활용해 더 고도화된 도구를 만들어, 점점 더 많은 사고와 기술을 AI에 위임하는 사람들임. 나와 내 주변이 여기에 해당함
  • 사고를 외주화하는 게 항상 나쁜 건 아님
    나는 독일어 듣기 연습용 앱을 Claude Code와 ElevenLabs로 만들었는데, 교사도 놀랄 정도로 효과적이었음
    코드 학습엔 관심 없고, 독일어 실력 향상이 목적이었음
  • 세 번째 그룹도 있다고 봄. AI를 가상의 팀원처럼 활용해 아이디어를 주고받는 사람들임. 이게 가장 흥미로운 사용 사례라고 생각함
  • 또 다른 부류는 검색엔진, 의사나 상담사, 문서 대체용으로 쓰는 사람들임.
    즉, 단순한 도구 그 이상으로 대화형 파트너로 쓰는 경우임

• AI를 그린필드 프로젝트와 브라운필드 프로젝트에서 써보면 생산성 차이가 큼
  새 프로젝트 첫날엔 일주일치 일을 해내지만, 기존 시스템에서는 20% 정도 향상에 그침
  결국 AI가 ‘혁신가의 딜레마’를 빠르게 재현하게 만드는 셈임
  문제는 AI가 복잡한 시스템을 성숙시키는 단계에서 얼마나 역할을 할 수 있느냐임

  • 엔터프라이즈 IT에서 일하는 입장으로서 이 말에 공감함
    Hashicorp Packer 빌드파일을 AI로 거의 완성했는데, 로컬 AI가 큰 도움이 되었음
    하지만 오래된 인프라에선 예측 불가능성이 커서 LLM이 오히려 망칠 가능성이 큼
  • 사실 이런 현상은 AI가 없어도 새 프로젝트에서 항상 일어남
    처음엔 빠르지만, 나중엔 아키텍처의 한계가 드러남
  • 나는 AI를 생산성 윤활유로 씀. 피곤하거나 과도하게 고민할 때 시작점을 잡아줌
    과공학을 줄이는 데도 도움 됨
  • 하지만 이 속도 향상은 컨텍스트 윈도우 한계에서 멈춤
    프로젝트가 200k 토큰을 넘으면 생산성이 0이 됨
    결국 조직은 기억에 의존하지 않는 프로세스로 승리함
  • 평소엔 10~20% 향상 정도지만, 개인 프로젝트에서는 200~500%까지 향상된 적도 있음

• 한 임원이 Claude Code로 30시트짜리 복잡한 Excel 재무 모델을 Python으로 변환했다는 이야기를 듣고 거의 구역질이 났음
  수학과 지구물리학 배경이 있는 입장에서, 그런 Excel 모델 자체가 악몽임
  그래도 Python 변환본이 원본보다 나쁠 가능성은 크지 않다고 인정함

  • 이런 코드 인접 분야의 비밀은 테스트가 거의 없다는 것임
    잘못된 모델링을 누가 잡아낼까? 거의 아무도 없음
    LLM이 만든 시뮬레이션은 검증 절차가 더 부족함
  • 금융권에서는 실제로 프로덕션 Excel 스프레드시트를 코드처럼 버전 관리하고 테스트함
    초기엔 빠른 실험용으로 쓰다가, 수익이 커지면 기술팀이 정식 앱으로 전환함
  • 하지만 나는 Claude Code 버전이 훨씬 나쁠 거라 확신함
    원본 Excel은 수년간 수정된 반면, 변환본은 가짜 복제물에 불과함
  • “나쁠 가능성이 크지 않다”는 말에 웃음이 나왔음
  • 이제는 “엑셀이 불황을 만들던 시대에서, AI가 만든 금융 모델이 불황을 만드는 시대”로 가는 중임
  • Claude Code가 변환을 거의 한 번에 끝냈다 해도, 중요한 로직을 망쳤을 확률이 높음
    • 물론 Excel과 Python을 동시에 실행해 결과를 비교할 수 있다면 정확도는 높아질 수 있음
    • 하지만 그 Excel 모델 자체가 제대로 검증됐을 가능성도 낮음
    • ‘거의 한 번에’라는 말은 CPU가 ‘거의 100% 신뢰성’ 있다고 말하는 것과 같음
    • 결국 우리의 401k가 AI가 만든 모델에 의해 운용될 수도 있음이 두려움임

• AI로 금융 모델을 만드는 비전문가들이 있다는 게 무섭게 느껴짐

  • 하지만 한 번 큰 사고가 나야 자본가들이 경각심을 가질 듯함
  • 그래도 옆에 Excel을 두고 비교 테스트할 수 있고, 이상하면 AI에게 설명을 요구할 수도 있음
  • 의료 분야로 넘어가면 더 무서울 것 같음
  • 나도 Python에서 Rust로 배우는 중인데, LLM이 자주 실수하는 걸 보며 AI 신뢰의 위험성을 절감함
  • 사실 많은 Excel 모델도 제대로 테스트되지 않음. 그냥 ‘맞는 것 같아’ 수준임

• 지금은 Shadow AI의 탄생기임
  2000년대의 Shadow IT처럼, 직원들이 몰래 Claude Code를 터미널에서 돌림
  공식 Copilot이 CSV도 제대로 못 다루니까
  CISO들은 공포에 떨지만, 금지하면 유능한 직원들이 떠날 것임

  • 문제는 이들이 토큰이나 계정 권한을 그대로 AI에 넘긴다는 점임. 보안 악몽임

• 1980년대식으로 표현하자면, 진짜 혁신은 현장 직원들이 자발적으로 만든 워크플로우에서 나옴
  그들이 프로세스를 가장 잘 알기 때문임
  이후에야 CIO 친화적 패키지 소프트웨어가 따라옴

  • 결국 힘은 꼬리 분포에 있음, 즉 소수의 실험적 시도가 변화를 이끎

• 최근 몇 달간 에이전트가 쓸 만해지면서 다들 이제 막 사용하기 시작했음
  MCP나 LangChain, 벡터 DB 같은 건 한때 유행했지만 지금은 조용함
  아직은 트렌드를 논하기엔 너무 이름

  • MCP 열풍은 대부분 판매 목적이었음. 하지만 프로토콜로 보면 꽤 유용함
    context7과 playwright MCP 서버를 써봤는데, 계획 수립과 피드백 루프에 효과적이었음
  • MCP 얘기하는 사람들은 대부분 LinkedIn에서만 활동하는 관리자들임
  • 나처럼 오래된 리눅스 유저도 Claude Code로 2개의 앱을 주말마다 완성할 정도로 쉬워졌음
  • 실제로는 MCP 대신 REST나 기존 API를 더 많이 씀

• Microsoft Copilot의 Excel 통합은 형편없음
  30년간 복잡한 XML 포맷을 만든 탓에 LLM이 이해할 수 없음
  그래서 우리 회사는 Word 문서를 Markdown으로 마이그레이션 중임. 일종의 업보 같음

  • Tim Berners-Lee가 예견했던 기계가 읽을 수 있는 웹의 꿈이 이제야 현실화되는 중임
    하지만 문서를 AI 친화적으로 만드는 데 드는 시간은 점점 늘어남
  • 아이러니하게도 Claude Code는 Excel에서 훨씬 잘 작동했음
    Copilot은 CSV 변환 지시도 무시하고 실패함
  • 예전에 인턴들에게 Visio XML을 파싱해 JSON으로 변환시키는 프로젝트를 맡겼는데, 성공했지만 금세 사라졌음

• 예전에 들은 말이 있음 — “이제는 큰 기업이 작은 기업을 이기는 게 아니라, 빠른 기업이 느린 기업을 이긴다”
  지금 AI 시대에 이 말이 더 진실처럼 느껴짐. 문제는 어떻게 빠르게 유지하느냐임

  • 하지만 빠른 게 항상 좋은 건 아님. 절벽 아래로 먼저 떨어질 수도 있음
  • 또 언제 속도를 늦춰야 하는지 아는 것도 중요함. 보안과 컴플라이언스를 해치지 않으면서 빠르게 움직이는 법이 관건임
  • 물론 이런 말은 전형적인 스타트업 조언이지만, 때로는 느린 쪽이 이길 때도 있음 (예: Teams vs Slack)