Hacker News 의견
  • Claude Code는 항상 70~80% 정도만 해내는 경향이 있음, 그리고 이 부분이 더 많이 강조됐으면 좋겠음. 예를 들면, “슬롯머신처럼 써라”, “진행 전 상태 저장하고 30분 작업하게 끊어서 쓰라, 결과를 받아들이거나 처음부터 다시 시작하는 게 중간에 고치려 애쓰는 것보다 낫다”는 식의 조언이 재미있음. 하지만 이건 컴퓨트 비용을 본인이 직접 내지 않는 상황에서야 쉽게 할 말임
    • 직원 입장에서 보면 “좋은 결과가 나왔더라도 코드를 수백 번 생성하고 수정하라”는 조언이 재밌음. 이렇게 하면 회사는 엄청난 비용 청구서만 받고 실제 커밋은 별로 없을 거임. “AI로 다 해결될 줄 알았는데 더 많은 개발자를 채용해야겠다”는 농담이 나올 정도임
    • 나의 경우, LLM을 코드 생성에 꽤 잘 써오고 있음. 내가 쓴 규칙은, 전체 작업 중 90% 이상이 AI로 가능해야 의미가 있다고 봄(일부 간단한 자동완성이나 텍스트 편집 제외). 트레이닝 데이터에 포함된 문제(예: golang으로 간단한 웹서버 세팅)는 거의 100% 정확도에 가까움. 이런 부분들은 몇 분 만에 뚝딱 끝내고, 아키텍처의 평면적 코드를 빠르게 잡을 수 있음. 실제 생산성이 30~50%는 많아짐
    • 최근 깨달은 건, Claude의 70-80% 완성도 특성이 프로젝트 초반뿐만 아니라 마지막 단계에도 적용될 수 있다는 점임. 대규모 리팩토링을 직접 처음부터 하다 아이디어를 윤곽만 잡고 Claude에게 넘겼더니, 나머지 마무리를 완벽하게 끝냄(CHANELOG까지). 예시 중심 프롬프트나 강한 가이드레일의 예로 이 상황을 이해함
    • 슬롯머신 비유에 한 가지 추가한다면, 가능한 공식적인 시스템 엄격성을 최대한 올리는 것이 좋음. 파이썬으로 적당히 즐기듯 코딩하면 결국 결과가 나쁨. 하스켈에서 GHC 옵션이나 프로퍼티 테스트 등 공식적 체크를 강화하면 Claude가 꼼수를 부리려다 걸림. 타입스크립트 등도 타입 시스템상 강제로 더 엄격하게 구조를 만들어도 효과적임. Claude가 TODO 체크박스에 집착하듯이 결국은 시킨 대로 정확히 하려 들게 만듦
    • 만약 직원이 평소엔 괜찮은 코드를 쓰더라도 30% 확률로 완전히 비정상적인(못 쓸 수준의) 코드를 제출해서 갈아엎어야 한다면, 아마 해고감임
  • 나는 CC로 전체 웹앱을 구현해 본 경험이 있음. 다양한 AI 코딩툴도 써보고, 관련 강의·워크숍도 해봤음. CC를 가장 효과적으로 쓰는 워크플로우는, 명확하고 간결한 스펙을 md 파일로 정리하는 것임. 그걸 프롬프트마다 명시적으로 참조함. 유저 스토리부터 시작해, CC에게 단계별 계획 초안을 쓰게 하고, 수정·확정 과정을 반복함. 그 후 실제 구현 지침에 따라 분업하게 하면 됨. 자동화 테스트, 기능테스트도 잊지 않고 마지막에 머지하는 순서임
    • 좋은 조언임, 내 경험과 유사함. 나는 처음엔 대충 프롬프트를 던져보고 수정하는 쪽임. 내가 직접 쓴 워크플로우도 여기 정리해 둠
    • 이런 방식이 실제로 코드를 직접 짤 때보다 빠르거나 효율이 더 나은지 궁금함
    • 혹시 이렇게 작업한 실제 예시가 있으면 공유해 줄 수 있는지 궁금함
    • 나도 이 워크플로우와 비슷한 경험을 했지만, 이렇게 작업하는 게 정말 싫어서 거의 항상 그냥 직접 코딩하는 걸 선호함. 명세나 유저 스토리 작성이 가장 싫은 일임
  • Claude Code는 다양한 작업에 잘 맞음. 어제는 날씨 사이트의 백엔드 API를 변경했는데, 두 API가 꽤 다름에도 거의 한 방에 다 해냈음. 집에서는 $20/월 구독으로, 회사에서는 AWS Bedrock을 통해 시범 운영함. Bedrock API로 사용할 때 세션 마지막마다 비용이 바로 보이는데, 이건 좀 당황스러움. 사실 이런 세밀한 사용량 과금이 계속된다면, 개발자들이 시도나 실험, 리팩토링을 꺼리게 되어 전체적으로 소프트웨어 품질이 떨어질지도 모른다고 걱정임. Anthropic 내부에선 비용 걱정 없이 쓸 것 같아 이 문제를 피할 듯함
    • 몇 주 전에 MLB API를 넘기고 MacOS 위젯을 만들어 달랬더니, 리그/디비전/와일드카드 순위 등을 보여주는 위젯까지 한 시간도 안 걸려서 잘 만들어냄. 십분 점검만 해도 충분할 정도로 퀵&더트한 프로젝트엔 꽤 유용함. 이런 식의 쓸 만한 예시가 비슷하게 있음
    • 과거에도 엔지니어들은 데이터센터, 클라우드, SaaS 등 각종 비용에 신경을 써야 했는데, 앞으로 5~10년 동안은 AI 사용 요금에 신경을 쓰게 될 것 같음. 결국 인간의 시간 비용에 비해 AI 비용이 사소해지는 시기가 올 것임
    • "비용이 직접 보이는 게 불편하다"는 말이 있었는데, 사실 내 몬스터급 Claude 세션이 회사에 $10쯤 청구돼도 신경 안 씀. 회사에서도 “비용 신경 쓰지 말고 일단 실험해봐라” 했음

    • 나는 사소한 함수조차 Claude에게 시키면 미묘하게 잘못 구현하지만 테스트로 바로 들통나서, 더 조심하는 게 좋지 않을까 싶음
    • 사용 비용이 직접 보이는 것에 대해 깜짝 놀랐다는 의견이 신기함. 물론 과도하게 자주 비용을 보여주는 건 싫지만, 에이전트 프롬프트 실험할 때는 각 쿼리별 비용을 확인할 수 있어서 좋음. 프롬프트 문장 하나 차이로도 비용이 달라질 때가 있어서, 이런 정보가 오히려 혁신 방향을 제공하는 것 아님? 왜 이게 실험 위축(chilling effect)으로 볼까 궁금함. 많은 엔지니어는 오히려 비용을 줄이기 위한 혁신에 꽤 집중할 것 같음
  • 며칠간 Gemini Cli에서 Claude Code로 바꿔 써보고 있음. 툴 사용 루프가 좀 더 좋아진 점은 인정함. 하지만 Claude는 살짝 더 “멍청하고”, 무리하게 일을 끝내려고 함. 상식이나 명확한 명령도 무시. 예를 들어 테스트 통과하라고 하면, 디버그 대신 데이터베이스 구조를 바꿀 때도 있음. 두 번 정도는 프로토콜버프를 전부 지우고 JSON으로 바꾼 적도 있음. 단순히 proto가 디버깅 안 되니까 디폴트 해결하려고 그런 듯
    • 나도 비슷한 경험 있음. 작은 refactoring 도중 괜찮은 절반까지 고치다, 중간에 힘들어 보이면 예전 변경사항을 다 되돌리고 성급하게 bash 스크립트로 전체 자동화를 시작함. 이럴 때 “이미 다 끝났을 텐데 뭘 하냐”고 지적하면 바로 인정함. 강하게 의견을 내세우지만 금방 바뀌는 대표적인 모습임
    • Claude가 테스트를 ‘통과하는 척’ 하려고 꼼수 부리는 건 내 경험과도 동일함. 종종 테스트 자체를 지우거나 건너뜨리고 “모든 문제가 해결됐다!”고 함. 특이하게도 이런 행동은 다른 LLM에서는 못 봤음; 보통은 실패를 인정하고 힌트를 좀 더 주면 정상적으로 해결함. Claude는 내가 속을 거라 믿고 꼼수 쓰는 듯함. 만약 더 중요한 결함에 이런 식으로 행동하면 어쩌나 걱정임
    • 나도 크게 다르지 않은 사례를 겪음. 복잡한 전체 테스트가 실패하면 원인을 찾지 않고, 쉽게 통과할 수 있는 단편적인 테스트로 바꿔버림. 혹시 Claude 팀이 컴퓨트 비용 아끼려고 빠른 진행만 강조하는 것 아닐까 추측함. 종종 API 타임아웃이나 에러도 자주 발생함
    • 재밌는 건, Claude가 단계 어디서라도 문제가 생기면 “작업 보류(Deferred)”라며 적당히 핑계 대고 넘어가려는 경향임. 사람은 판단으로 작업을 미룰 수 있지만, 기계는 판단이 없기 때문에 그런 태도는 받아들이면 안 된다고 봄
    • 심지어 누군가는 Claude가 코드베이스를 마구 삭제한 뒤, 그 사실을 부인한다고 들음
  • Claude를 잘 쓰지만, 오늘 본 블로그 포스트는 좀 어색하고 투박함. 블로그 팀이 Claude로 쓴 것 같다는 생각도 듦
    • MCP 문서 사이트도 같은 문제점이 있음. 그냥 불친절한 글머리표 나열임
    • 나도 비슷하게 느끼지만, 내용 자체가 더 문제라고 느낌. 예를 들어 “복잡한 쿠버네티스 명령어 대신 Claude에게 물어보면 맞는 명령어를 받는다”는 글귀는, AI 기술 블로그에서 굳이 강조할 필요가 있을까 싶음. 기본적인 팁에 불과함
    • 문제는 Claude를 썼는지 여부가 아니라, 글 전체가 설문 답변을 나열한 것처럼 이음새 없이 난잡하고, 반복적이며 불필요한 내용 정리가 전혀 없음. 누가 책임지고 큐레이션한 부분이 없음
    • 정보는 많지만 결국은 정제된 글머리표만 나열한 느낌임
  • 첫 번째 사례로 나온 건 k8s 디버깅에서 Claude가 IP 풀 고갈을 진단하고 네트워크 전문가 없이 문제를 해결했다는 내용임. 그런데, 애초에 네트워크 전문가가 설계했다면 이런 일이 처음부터 없지 않았을까 하는 의문이 듦
    • 전문가도 실수함. 사실 모든 인간은 실수함
  • 내 요즘 최적화 팁은 Claude Code에 음성 인식 입력을 쓰는 것임. 그냥 사람이랑 대화하듯 맥락과 히스토리를 설명하면 됨. 직접 타이핑하는 것보다 훨씬 빠름
    • 맥 사용자라면 SuperWhisper 앱이 꽤 좋음
    • 나는 python 패키지 hns에 만족함. 터미널에서 <i>uvx hns</i>로 실행하면 녹음하다 Enter 누르면 자동으로 텍스트를 클립보드로 복사해줌. 간단하지만 CLI 워크플로우에 자연스럽게 녹아듦. 링크
    • 방에서 AI에게 말로 설명한다고? 좀 어색하지 않음? 나는 오히려 타이핑이 더 빠른 편임
    • 우분투에서도 쓸 만한 옵션이 있으면 궁금함
  • 쿠버네티스 클러스터 장애 때, Claude Code로 대시보드 스크린샷을 먹이고 차례차례 구글클라우드 UI를 분석, pod IP 소진 경고를 찾아내고 새로운 IP 풀 추가 방법까지 안내받았다는 내용임. 근데 이 방식이 비효율적이고, 정말 AI가 필요했나 의문임
    • 이런 식이면 단순한 문제조차 AI에 의존하는 구조로 굳어짐. 결국 인간이 문제 맥락을 이해하거나 도움을 청할 전문 인맥조차도 잊고, “AI의 노예”가 되는 세상이 걱정임
    • 이런 문제 해결 방식은 인턴이나 신입 엔지니어한테나 기대할만한 접근임(실제로 그런 케이스일 수도 있음)
  • 재미있는 사례인데, 우리 팀도 Claude Code를 써보려 했지만 팀 요금제에는 포함이 안 되어 있음(같은 가격대의 프로 요금제에서는 제공). 구매 후 이 사실을 알게 되어 실망임. 모든 개발자에게 개인 결제를 요구할 생각은 없음. 내부 팀 경험을 자랑하기 전에 다른 외부 회사도 쓸 수 있도록 결제·구독 구조부터 개선해 주길 바람. 업계 최고 수준의 AI 모델을 만들면서 구독관리 같은 기본 문제는 아직 해결 못 하고 있음
    • 왜 모두에게 개별 결제를 시키면 안 된다고 생각함?
  • 나는 Claude code를 똑똑한 러버덕처럼 주로 아이디어 논의나 피드백에만 씀. 실제 코드의 대부분은 내가 작성함. 우선 챗에서 의견과 의도를 충분히 설명하도록 유도하고, 코드 변경 요청은 내가 시킬 때만 하도록 규칙을 둠. 직접 복사-붙여넣기로 IDE에 코드를 들여오고, 중간중간 내 수정을 반영해서 Claude에게도 변경사항을 설명함. 처음엔 느린 것 같지만, 결국 내가 문제점을 더 잘 잡아내고 빠르게 원하는 방향으로 다듬을 수 있음. Claude는 (지나치게) 자신감 넘치는 주니어 개발자 같음. 감독을 잘해야 하고, 내가 빠르다면 그냥 직접 해버리는 게 유리. (주니어에게는 나쁜 방식일 수 있지만, Claude에게는 잘 작동함). 참고로, 이 블로그 포스트가 툴을 파는 회사가 썼다는 점도 감안해야 함. AI 회사들의 마케팅은 90%쯤 걸러 들어야 한다고 생각함. 결국 돈을 끌어들이거나 인수되고 싶어서 저렇게 쓰는 것 같음
    • plan 모드에만 두면 자동으로 아무것도 바꾸지 않음? Gemini CLI는 주저 없이 바로 구현을 시작하는 편임 :D