요즘 에이전트를 활용하면서 가장 많이 고민하게 되는 주제는 오케스트레이션이다. 단순히 큰 모델에게 지시하는 것을 넘어, 여러 에이전트를 어떻게 구성하고 연결할 것인가가 핵심이 되고 있다.

최근 코드를 읽지 않는 것에 대한 옹호라는 글을 읽었다. AI가 코드를 생성하는 시대에 라인별 코드 리뷰 대신 스펙과 테스트, 검증 인프라에 의존하자는 주장이었다. 이에 대한 내 생각을 정리한다.

AI 코딩 에이전트 쓸 때 프로젝트 루트에 CLAUDE.md나 AGENTS.md 같은 파일 두는 게 일반적이다. 클로드 코드를 쓰면 init 명령어로 이 파일을 자동 생성할 수도 있는데, 써 본 결과 이 방식은 오히려 독이 됐다.

AI 코딩 도구가 일상화되면서 풀 리퀘스트에 대한 회의론이 커지고 있다. PR 리뷰가 더 이상 이해와 책임을 넘기는 장치로 작동하지 않는다는 지적이다. 하지만 이 논의에 빠진 한 가지 가정이 있다. 코드를 쓰는 것과 리뷰하는 것이 같은 주체여야 한다는 전제 말이다.

AI가 하루에도 수천 개의 제품을 만들어내는 시대가 왔다. 창작은 더 이상 희소한 자원이 아니다. 진정으로 희소해진 것은 사람들의 관심이다.

집에 오래 방치해 두었던 인텔 아이맥이 있다. 더 이상 주력 머신으로 쓰지 않아서 책상 위에서 먼지만 쌓이고 있었는데, 이번에 OpenClaw를 설치해서 다시 쓰기 시작했다.

바이브 코딩(Vibe Coding)에 대해 부정적인 시각이 많다. 개발도 제대로 모르는 사람들이 AI를 이용해 쓰레기 같은 코드를 양산하고, 코드를 읽을 줄도 모르고 이해할 줄도 모른 채 그냥 복사-붙여넣기만 하다가 결국 망가진다는 주장이다. 또, AI로 만들어낸 결과물이 투두리스트나 가계부처럼 특별할 것 없는 것들이 대부분이며, 비슷비슷한 아이디어에 몰려서 똑같은 제품을 반복해서 만들어낸다는 비판도 있다.

서버리스(Serverless)하면 대부분 AWS Lambda 를 떠올리곤 합니다. 하지만 서버리스는 단순히 FaaS(Function-as-a-Service)만을 의미하지는 않습니다. 이번 포스트에서는 서버리스 아키텍처에 대한 개념과 키워드를 정리하고, FaaS 의 내부 구조를 살펴봅니다.

GitHub 에서 오픈 소스를 사용하다병면 발견한 버그를 직접 수정하거나, 새로운 기능을 추가하고 싶을 때가 있습니다. 하지만 어디서부터 어떻게 시작해야 할 지 막막하기도 합니다. 이번 포스트에서는 오픈 소스에 컨트리뷰션(기여)하는 절차를 간단히 알아보겠습니다.

쿠버네티스(Kubernetes)에서 시시각각으로 변하는 오브젝트의 상태를 저장하고 관리하려면 어떻게 해야 할까요? 가장 먼저 생각할 수 있는 방법은 YAML 파일로 export 해서 저장하는 것입니다.