Hacker News 의견
  • 에이전트의 인지적 한계를 고려해서 명령을 내리는 것이 중요함을 느낌, 예를 들어 큰 변화는 요구하지 않고 계획을 세운 뒤 작은 단계별로 실행을 지시하고 각 단계를 테스트하면서 진행해야 하고, 복잡한 단계에서는 문제와 해결 방안을 시각화하는 코드를 작성하게 하면 좋음, 어떤 단계에서 실패하면 코드에 로깅을 추가하고 로그를 저장한 뒤 테스트하고 로그를 검토해 원인을 파악하는 과정을 반복적으로 시도해야 효과적임, 기존 코드의 설계 방식을 통해 모델이 변경해야 할 부분을 파악하게 하면 AI가 전체를 한 파일에 몰아넣지 않게 할 수 있음, 여러 사람이 이러한 팁을 공유한 블로그를 봤는데 여전히 완벽하진 않지만 쓸모없는 결과가 95%까지 나오진 않는 경험임

    • 나는 이런 것들을 이미 다 시도하는데도 대부분 쓸모없는 코드가 나오고, 그나마 제대로 동작할 때도 결국 직접 손을 봐야 쓸 만해짐, 정말로 잘 작동하는 경우가 있긴 해서 그땐 신나지만 개인적으로 효율성 향상은 크게 못 느끼고 있음
    • 큰 규모의 복잡한 작업에서는 "지금 당장 코드를 작성하지 마세요. 각 단계를 자세히 설명할 거예요"라고 지시하는 방식이 효과적임을 느낌, 예를 들어 입력 읽기, 후보 생성, 후보 점수 부여, 우선순위 및 정렬, 출력 데이터 구조 생성, DB에 저장 등으로 단계적 개요를 제시함, Claude는 이 단계들을 TODO 리스트와 문서로 정리해서 다음에 이어서 진행하기 편하게 관리함, 실제로 한 시간 작업하다가 그만두고 “완료한 스테이지는 코드 생성하고 코멘트 남겨서 다음에 이어서 하자”라고 시키면 쉽게 연속 작업이 가능했음
    • 여러 LLM/에이전트를 오래 써도 여전히 유용한 결과를 얻기가 힘듦, 쓸데없는 출력을 피하려면 직접 작업할 때보다 더 많은 에너지를 프롬프트 작성에 써야 하고, 프롬프트 문구나 말투, 원하지 않는 연관이 생기지 않게 신경 쓰다 보니 괜히 불안해짐, 별도의 프론트엔드 프레임워크처럼 LLM 프롬프트를 관리해주는 도구가 있으면 좋겠음, 일반적인 프롬프트 구조를 정리하거나 모범 사례를 기본값으로 적용해서 코드에서 뭔가 찾거나 새 기능 설계, 테스트 작성할 때 고민을 많이 줄여주길 바람
    • 이런 정교한 절차라면 그냥 본인이 직접 코드를 작성하는 것이 낫다고 생각함
    • 개인 프로젝트에서 AI와 vibe coding을 시도해 보니, 테스트 주도 개발 방식이 vibe coding과 상당히 궁합이 좋았음, 문제를 작은 테스트 가능 단위로 분해하고, 먼저 AI에게 유닛 테스트부터 작성하게 한 뒤 실제 코드를 구현하는 방식을 추천함
  • 이제는 이런 기사들이 단순한 리팩토링 작업이나 React 보일러플레이트가 아닌, 실제로 "에이전트가 분산 처리하는" 구체적인 작업 예시를 포함해야 할 시점임을 느낌, Sanity에 오랫동안 요청된 기능들이 있다는데, 에이전트가 상당량을 병렬화 처리한다고 주장함, 그런데 "코드의 80%를 학습하지 않는 주니어 개발자가 썼다"는 식의 주장은 믿기 어려움

    • 내 생각에 "학습하지 않는 주니어 개발자"라는 표현은 잘못됨, Claude는 오히려 실전 경험이 없는 문헌 속 정답만 아는 고학력 시니어에 가깝고, 백과사전적인 지식은 탁월하지만 실전 감각이 부족함, 최근 Claude로 커머셜 코드베이스를 구축하는데 대부분의 입력이 '코드의 맛'과 성공의 정의에 집중되고, 코드 자체는 일회용에 불과함
    • 이렇게 AI 코드가 늘고 있는데, 여전히 오픈소스에는 미해결 이슈가 쌓여 있음, 이 점이 참 아이러니함
    • 실제 AI에 맡긴 작업 예시와 결과를 보여준다면 과장된 기대에 의문을 제기할 기회를 제공할 수 있는데, 실전 예시 없이 Claude Code가 대단하다는 이야기만 계속 올라오는 현실임
    • 세일즈화된 엔지니어가 "레슨" 대신 "러닝스(learnings)" 같은 표현을 사용하는 기술 블로그를 보면, 개발 경력이 쌓이면서 오히려 구글 검색에 덜 의존하고 그냥 문서만 챙겨보는 내 경로와 반대임을 느낌
  • 작성자가 생산성 향상이 있다고는 했지만, 흔히 지적되는 한계도 그대로 언급해서 실질적으로는 별 얘기가 없었던 것 같음, 누구도 핵심 기능 개발을 Claude Code에 위임하지는 않을 거라고 확신함

  • 보일러플레이트를 피하는 게 개발자의 일이자, 미래의 자신에게 편의를 제공하는 추상화임, AI로 보일러플레이트를 생성하면 추후 전체 인스턴스를 일일이 변경해야 할 때 오히려 불편함이 커지고, 여러 군데에 흩어진 보일러플레이트 코드가 불일치하면 문제는 더 커짐

    • 프레임워크나 도구들이 이미 대부분 보일러플레이트 자동 생성기를 포함하고 있는데 굳이 AI에 토큰과 비용을 들여서 이걸 시키는 게 그리 큰 가치인지 의문임
  • 흥미로운 점은 이 사람은 AI로 기초 구현을 시도하는데, 나는 반대로 반드시 기반을 직접 먼저 구축함, 그래야 구조와 작동 원리를 정확히 이해할 수 있으므로 이후엔 AI에게 반복성 있는 보일러플레이트만 맡기면 됨, AI는 따라 쓰기는 잘 하지만 아키텍처 설계에는 굉장히 취약함

    • LLM은 유지보수 가능한 아키텍처를 계획하는 것이 매우 약함, 코드가 발전함에 따라 구조를 리팩터링하지 못하고, 맥락 이해 한계로 여기서 한계가 있을 수 있음
  • 기본 연봉도 비싼데 거기에 월 1천에서 1.5천 달러씩 추가 비용을 들여 생산성이 오를지도 모르는 사소한 문제에 투자해야 한다는 주장에 의문임, 최소한 내 상사는 좋아하지 않을 것 같음

    • 하드웨어 업체들은 개발자 인건비보다 비싼 각종 EDA 툴 라이선스를 연례적으로 구매함, 만약 생산성이 눈에 띄게 좋아진다면 1천 달러쯤은 아무것도 아닌 셈임
    • 개발자 연봉이 그렇게 비싸다면 오히려 투자하지 않는 게 비합리적임, 월 1-1.5k 달러로 생산성을 확실히 높일 수 있다면 그걸 망설이는 쪽이 비효율적이고, 이런 관점에서 AI 투자 비용만 따지는 것은 너무 단순화된 시각임을 강조함, AI로 개발자 수를 줄일 수 있다면 그 역시 실제 절감 효과임
    • 본인은 intellij pro AI로 월 20달러도 채 못 쓰고 있는데, Claude가 정말 그렇게 비싼지 의문이 들어 찾아보니 실제로 그럴 수 있긴 함, 어쨌든 어딘가의 예산에 AI 구독료가 추가되는 게 현실이고, 이미 회사가 고성능 인터넷 비용을 지불하는 것과 똑같이 AI 비용도 기본이 되고 있음
    • 그리고 이 가격도 사실 보조금 기반임을 기억해야 함
    • 앞으로 기업들이 어떻게 변화할지 흥미롭게 보고 있음, 확실한 건 결국 개발자가 어떤 기준으로 평가받을지가 관건임, AI 사용으로 인해 인사고과/해고 등에서 불이익을 받을 위험이 커지는지, 그리고 LLM이 아닌 본인이 성과의 주역임을 어떻게 입증할지가 중요 이슈임
  • 본문에서 언급된 MCP(Multi-Channel Processor) 활용 방식이 이해가 잘 안 됨, Claude code는 curl이나 gh 등으로 셸에서 써드파티 서비스를 거의 다 호출할 수 있는데, MCP를 쓰면 오히려 문제가 있을 수 있음(예: linear MCP 서버는 이슈가 너무 길면 자르지만, 직접 API 호출하면 이런 제한이 없음), 뭔가 내가 빠뜨린 점이 있는지 궁금함

  • Anthropic이 Boris Cherny(Claude Code의 창시자)와의 인터뷰를 올렸는데, Claude Code의 에이전트 코딩 미래와 활용법에 대한 아이디어도 공유함 https://youtu.be/iF9iV4xponk

  • "$1000-1500/월 예산" 언급을 보며, 혹시 API 키만 쓰고 claude MAX 같은 월정액 플랜 정보를 모르는 건 아닌가 하는 생각이 듦, $100~200/월이면 무작정 쿼리만 반복하는 게 아니라면 충분히 커버된다 봄

    • $1k-1.5k는 너무 비싼 수치임을 느낌, 20배짜리 Max 플랜도 월 $200에 충분히 많은 사용량을 커버하고, 5시간마다 사용량이 초기화됨, 그럼에도 불구하고 한도를 매일 초과한다면 그 정도면 토큰 단위 결제가 오히려 더 비쌀 수도 있음
  • Claude나 기타 에이전트 쓸 계획이면 반드시 로깅을 강추함, 로그 파일 전체를 AI에 넣으면 문제를 정리해서 답을 얻거나 다음 단계로 진입할 수 있는 확률이 높아짐, 로깅은 정말로 모든 것임