Posts

이 영상의 핵심은 단순히 “텔레그램에서도 Claude Code를 쓸 수 있다” 는 소개가 아닙니다. 발표자는 Claude Code 2.1.80부터 들어온 channels 기능을 실제로 텔레그램과 연결해 보고, 봇 생성부터 페어링, 응답 흐름, 파일 전달, 권한 프롬프트 문제까지 한 번에 보여 줍니다. 그래서 이 영상은 기능 발표보다 원격 사용이 실제로 어디서 막히는지 를 이해하는 데 더 가치가 있습니다 (t=0, t=4, t=8, t=124, t=446). 다만 영상에 나오는 몇몇 셸 명령은 화면으로는 보이지만 자동 생성 자막에서는 대부분 “이 명령어” 수준으로만 남습니다. 그래서 이 글은 복붙용 명령 모음보다, 초보자가 헷갈리기 쉬운 구성 요소의 역할과 실행 순서 를 정확히 이해하는 데 초점을 맞춥니다 (t=37, t=50, t=61). 더보기

이 영상이 흥미로운 이유는 “Claude Code로 앱 하나를 빨리 만들었다” 는 데 있지 않습니다. 오히려 이미 가지고 있는 롱폼 영상과 자막을 바탕으로, 숏츠 후보를 고르고 자르고 렌더링하고 다시 고치는 과정을 Claude Code와 어떻게 협업할 수 있는지 거의 날것 그대로 보여 준다는 점이 핵심입니다. 발표자는 처음부터 “숏폼을 못 만드는 이유는 시간이 없어서” 라는 운영 병목을 제시하고, 1시간 안에 로컬 기반 숏츠 생성기를 같이 만들어 보자고 선언합니다. 그래서 이 영상은 완성품 자랑보다, 문제 정의와 실행 루프를 어떻게 에이전트에게 넘기는지 관찰하는 데 더 큰 가치가 있습니다 (근거: t=0, t=17, t=56, t=3126). 더보기

기존 프로젝트 유지보수에서 Claude Code를 쓸 때 가장 중요한 건 “얼마나 똑똑한 프롬프트를 쓰느냐"가 아닙니다. 더 중요한 건 Claude Code가 실수하기 어려운 작업 흐름 을 먼저 고정하는 것입니다. 기존 서비스는 새 기능을 밀어 넣는 속도보다, 현재 동작을 안전하게 읽고, 필요한 부분만 좁게 바꾸고, 바로 검증하는 리듬이 훨씬 중요합니다. Claude Code는 CLAUDE.md 기반 프로젝트 메모리, 커스텀 서브에이전트, 스킬, 훅, 프로젝트 설정을 모두 지원합니다. 그래서 유지보수용 환경을 만들 때도 “AI가 알아서 잘하겠지"에 기대기보다, 분석 → 최소 수정 → 검증 → 리뷰 순서를 문서와 자동화로 고정하는 편이 훨씬 안정적입니다. 더보기

모노레포에서 CLAUDE.md 를 하나만 두면 금방 복잡해진다. 프런트엔드 규칙, 백엔드 테스트 명령, 워커 금지 사항이 한 파일에 섞이기 시작하면, 결국 “항상 읽히지만 대부분 지금 작업과는 무관한 지침"이 된다. 그래서 실무에서는 루트에는 공통 규칙만, 하위 폴더에는 그 서브프로젝트 전용 규칙만 두는 쪽이 훨씬 잘 맞는다. 이 글은 그 구조를 어떻게 나누면 좋은지, 그리고 frontend/, backend/, worker/, apps/*, packages/* 같은 폴더를 스캔해서 각자에 맞는 CLAUDE.md 를 생성하는 init-subproject-claude 스킬은 어떻게 설계하면 좋은지를 한 번에 정리한 글이다. 더보기

로컬 LLM을 이야기할 때 대부분의 출발점은 Ollama입니다. 설치가 간단하고 바로 써볼 수 있기 때문입니다. 그런데 이번 영상은 질문 자체를 바꿉니다. 내 PC에서 모델이 돌아가느냐 가 아니라, 여러 요청을 계속 받아내는 서빙 엔진으로도 효율적인가 를 봐야 한다는 것입니다. 영상은 vLLM의 강점이 바로 그 지점, 즉 KV Cache 메모리 관리와 다중 요청 스케줄링에서 나온다고 설명합니다. 근거 영상 중요한 것은 숫자를 그대로 외우는 것이 아니라, 왜 어떤 환경에서는 차이가 거의 없고 어떤 환경에서는 크게 벌어지는지 를 이해하는 것입니다. 영상 도입부는 Red Hat의 2025년 8월 8일 벤치마크를 인용해 vLLM의 높은 TPS와 낮은 지연시간을 언급하지만, 뒤에서 보여주는 자체 테스트에서는 단일 요청에서는 큰 차이가 없고 동시 요청 환경에서 우위가 커진다고 정리합니다. 이 글은 바로 그 차이를 만든 구조를 따라가 보려는 글입니다. 근거 영상 더보기

2026년 3월 20일 OpenAI Developers에 올라온 Designing delightful frontends with GPT-5.4 의 핵심은 단순히 “GPT-5.4가 더 예쁜 화면을 만든다"가 아닙니다. 더 정확히는, GPT-5.4는 이미지를 보고 판단하고, UI를 구현하고, 다시 실행해 검증하는 루프 가 이전보다 훨씬 자연스러워졌고, 그 루프를 살리는 프롬프트 구조가 따로 있다는 이야기입니다. 이 글은 같은 달 3월 5일 공개된 Introducing GPT-5.4 와 함께 읽으면서, OpenAI가 왜 시각 참조, 디자인 제약, 낮은 reasoning, 실제 콘텐츠, Playwright 검증을 한 세트로 묶어 이야기하는지 정리합니다. 포인트는 “길게 지시하면 잘 만든다"가 아니라, 좋은 프런트엔드가 나오도록 작업면 자체를 설계하는 것 입니다. 더보기

2026년 3월 21일 기준으로 browser-use 의 GitHub 저장소 페이지는 81.6k stars 를 보여 주고, pyproject.toml 과 PyPI 메타데이터는 최신 공개 버전을 0.12.2, 지원 Python 범위를 >=3.11,<4.0 으로 적고 있습니다. README가 이 프로젝트를 짧게 설명하는 문장은 "Make websites accessible for AI agents" 인데, 이 한 줄이 의외로 정확합니다. browser-use 는 단순한 브라우저 매크로나 Playwright 래퍼가 아니라, 웹페이지의 상태를 LLM이 판단할 수 있는 작업 공간으로 바꾸고, 그 판단을 다시 브라우저 액션으로 연결하는 계층 을 만들려는 프로젝트입니다. 더보기