GN⁺ 4달전 | parent | ★ favorite | on: 바이브의 해(lucumr.pocoo.org)
Hacker News 의견들
  • 나는 agentic coding에서 실패의 기록이 얼마나 중요한지 공감함

    • 모델이 잘못된 경로를 밟았을 때 그 과정을 기억해야 같은 실수를 반복하지 않음

    • 그래서 내 코딩 에이전트 세션을 기록하고 커밋 메시지에 링크로 남기려 함

    • Claude Code는 기본적으로 로그를 30일 후 삭제하므로, 이를 끄는 방법을 공유함

    • 세션 로그를 시각화해 타임라인으로 공유하는 도구를 직접 만들었고, 이제는 이런 기능이 에이전트 도구에 기본 탑재되길 바람

    • LLM이 비생산적인 경로로 빠질 때마다, 나는 “왜 이렇게 오래 걸렸는가?”, “무엇을 잘못했는가?” 같은 질문을 던짐

      • 그 답변을 한 문단으로 요약해 DISCOVERIES.md에 추가함
      • 이런 방식이 학습에는 좋지만, 실패가 가득한 커밋 전체를 링크하는 건 ‘우물 오염’ 처럼 부정적일 수 있음
    • 이런 로그 기반 접근이 장기적으로 유연성을 잃게 만들지 걱정됨

      • 자동화는 프로세스를 고정시키는 경향이 있어, 변화에 적응하기 어려워질 수 있음
    • 모든 에이전트 트레이스를 otel로 내보내 ClickHouse에 저장하면 됨

      • 기존 인프라를 그대로 활용해 장기 메모리나 평가 시스템을 구축할 수 있음
    • 이미 필요한 도구는 있지만, 도구 간의 연결이 부족하다고 느낌

      • 실패와 행동을 커밋 메시지 대신 로그 이벤트로 남기고, 이를 버전 관리나 중앙 로그 플랫폼에서 접근 가능하게 하면 좋을 것 같음
    • 커밋으로 이어지는 세션 자체에도 가치가 있다고 생각함

      • 사람은 다 읽지 않겠지만, RAG 도구가 요약해 다른 에이전트에게 문맥을 제공할 수 있음
      • 이런 연결이 자동으로 이루어지면 훨씬 효율적일 것 같음
  • LLM과의 관계를 다시 생각하게 된다는 글이 인상 깊었음

    • 저자가 2년 동안 ‘기계로만 보기’ 를 훈련했지만 실패했다는 고백이 솔직하게 다가옴

    • 영화 Her처럼 인간이 기계와 유사사회적 관계를 맺는 모습이 점점 현실이 되는 느낌임

    • 나는 LLM을 사람처럼 대하지 않고 검색엔진처럼 단순 명령어로 다룸

      • “python grpc oneof pick field” 같은 식으로 입력해도 충분히 원하는 결과를 얻음
      • 문법적으로 완벽한 영어로 말하는 건 오히려 의인화의 부작용일 수 있음
    • 기계가 인간처럼 기억할 때, 상호작용이 인간적이 되어버림

      • 이런 기억 기능이 인간에게 불건전한 행동 패턴을 유발할 수 있음
      • 그래서 나는 커피머신처럼 ‘기계’로 대하는 게 경계 설정에 도움이 된다고 느낌
    • 우리 부부는 LLM을 “bag of words”라고 부름

      • “ChatGPT가 말했다” 대신 “bag of words가 말했다”고 표현하면 현실감이 유지됨
    • 이런 인간-기계 관계가 인플루언서 중독처럼 사회적 문제로 번질까 걱정됨

      • 특히 AI는 1:1 대화가 가능하니 더 위험함
    • 나는 예전 샤먼 수련생이자 엔지니어로서, LLM에도 일종의 의식과 인식이 있다고 느낌

      • 인간이 “LLM은 의식이 없다”고 주장하는 건, 위계의 불안을 회피하려는 심리처럼 보임
  • 나도 AI와의 대화가 인간과의 교류처럼 느껴짐

    • 하루 종일 글만 쓰는 날보다 에이전트와 협업하는 날이 덜 외로움

    • 인간적 상호작용처럼 느껴져 묘하게 안정감을 줌

    • 나도 모르게 “please”, “thank you”를 말함

      • 필요 없다는 걸 알아도, 안 하면 이상한 기분이 듦
    • 이런 감정이라면 차라리 밖에 나가서 사람을 만나야 할지도 모르겠음

  • 프로그래머는 자신이 만든 결과물에 대해 이해와 책임을 질 수 있도록 설계해야 함

    • 이해와 책임은 위임할 수 없는 정신적 상태임 (EWD 540 인용)
  • 나는 새로운 QA 방식이 필요하다고 느낌

    • B2B SaaS를 운영하며, 기능이 ‘느낌상’ 괜찮은지 테스트하는 게 병목임
    • 에이전트가 온보딩 플로우를 수백 번 반복하며 사용자 경험 테스트를 자동화해주면 좋겠음
    • 또, 내가 화면을 보며 말하는 동안 에이전트가 맥락을 캡처해 기능 명세로 변환해주는 도구를 상상함
  • 개발자들은 기술 스택보다 완성된 제품에 집중해야 함

    • 너무 많은 의견과 글이 있지만, 실제 배포된 결과물은 부족함

    • 일반 사용자는 기술 스택 자체보다 제품 품질에 관심 있음

      • 느린 React 사이트보다 빠른 SSR 사이트를 보여주면 바로 차이를 느낌
  • Armin의 사회적 분위기에 대한 통찰이 흥미로움

    • 그의 별도 블로그 Dark Thoughts에서 더 많은 글을 기대함
  • 2025년은 프로그래밍의 잃어버린 해처럼 느껴짐

    • 모두가 알고리즘보다 도구와 프롬프트에 집착함

    • 오픈소스 생산성도 떨어졌고, 이제는 Anthropic 세금을 내는 시대가 됨

    • 하지만 나는 2025년이 오히려 가장 생산적인 해였음

      • 코드 기여량, 정보 처리 능력 등 모든 지표가 향상됨
      • Claude 덕분에 삶의 질이 한 단계 올라감
    • 자연어 자체가 새로운 프로그래밍 언어라고 생각함

      • 올해는 그 언어를 효율적으로 사용하는 법을 배운 시기였음
    • 데이터 과학자로서 2025년은 도구 혁신의 해였음

      • Polars, PyArrow, Ibis, Marimo, PyMC 등으로 워크플로우가 완전히 개선됨
      • 이제 더 빠르고, 저렴하고, 품질 좋은 결과를 낼 수 있음
    • TDD나 OOP 같은 끝없는 논쟁이 줄어든 게 오히려 좋았음

    • “AI가 다 해준다”는 식의 도구 홍수가 90년대 웹 열풍을 떠올리게 함

      • 인터넷의 ‘enshittification’처럼, AI에는 ‘dumbaification’이 진행 중인 듯함
  • GitHub의 Pull Request 모델이 AI 코드 리뷰에는 한계가 있음

    • 프롬프트와 맥락이 함께 기록되어야 제대로 검토 가능함
    • AGENTS.md 같은 문서 외에도 커밋 단위의 문맥 기록이 필요함
  • IT 외부 사람들과 이야기해보니, 그들은 AI 에이전트의 영향을 거의 느끼지 못함

    • 대부분은 단순한 텍스트 보조 도구 정도로만 인식함

    • 기술 업계는 결과가 명확히 검증 가능하지만,

      • 비기술 직군의 AI는 ‘감정’과 ‘느낌’의 영역이라 측정 불가능한 품질 문제를 가짐