🔥 오늘의 주요 소식
Stop correcting AI code. Build the system agents need.
이 글은 AI 코딩 에이전트가 코드 작성의 상당 부분을 떠맡게 된 지금, 엔지니어가 정말 해야 할 일이 무엇인지를 묻는다. 제목 그대로 논지는 에이전트가 만든 코드를 사람이 매번 사후에 고쳐 쓰는 지금의 관행 대신, 에이전트가 제대로 일할 수 있는 시스템을 먼저 만들어야 한다는 것이다. 저자 Jennifer Riggins는 요즘 업계가 '루프(loop)'라는 말을 유행처럼 쓰지만 AI 주도 개발 맥락에서 그것이 정확히 무엇을 뜻하는지는 불분명하다는 문제의식에서 글을 시작한다. '소프트웨어 엔지니어가 더 이상 코드를 직접 작성하지 않는다면 이제 무엇을 하는 사람인가'라는 질문이 글 전체를 관통한다. 에이전트 산출물을 건건이 교정하는 방식은 규모가 커질수록 지속 가능하지 않다는 전제 아래, 검증·피드백 루프 같은 사전 설계된 시스템 구축을 대안으로 제시한다. 결국 엔지니어링 조직의 일이 '코드 교정'에서 '에이전트를 위한 시스템 설계'로 재정의돼야 한다는 것이 핵심 메시지다.
💡 왜 중요한가: AI 에이전트 도입이 늘수록 엔지니어링 조직의 병목은 '코드 작성'이 아니라 '에이전트 산출물을 검증·신뢰할 시스템의 부재'로 옮겨간다는 점을 시사한다.
🔗 원문 보기 · The New Stack
DevOps & 인프라
5 steps to build great service architecture and operational resilience
The New Stack
이 글은 장애 대응 역량을 높이기 위한 '서비스 아키텍처' 구축 방법을 5단계로 제시한다. 문제의식은 알림이 울렸을 때 대응팀이 즉시 답해야 하는 세 가지 질문 — 무엇이 고장났는지, 누가 책임지는지, 영향 범위가 어디까지인지 — 를 서비스 지도 없이는 답하기 어렵다는 데서 출발한다. 1단계는 조직에서 가장 중요한 비즈니스 서비스 하나를 골라 그 밑을 받치는 기술적 서비스들을 매핑하는 것이다. 2단계는 각 서비스의 소유자를 정하고 에스컬레이션 정책을 세운 뒤 모니터링 도구를 연결하는 것이다. 이후 단계들은 이렇게 만든 서비스 아키텍처를 조직 전체로 확장해 관측성과 사고 대응 프로세스에 녹여 넣는 데 초점을 맞춘다. 서비스 아키텍처가 갖춰지면 인시던트의 영향 범위와 동원해야 할 팀을 즉시 파악할 수 있어 대응 속도가 빨라지고 이후 발생하는 모든 장애의 비용이 줄어든다고 글은 설명한다. 나아가 이렇게 구조화된 서비스 데이터는 향후 AI 기반 트리아지 자동화의 토대로도 쓰일 수 있다고 언급한다.
💡 서비스 지도 없이는 알림이 울려도 무엇이, 누구 책임으로, 얼마나 번지는지 답할 수 없다는 것이 이 글의 핵심이며, 이는 온콜 대응 속도와 장애 비용에 직결된다.
How routing keys isolate Kafka consumer tests on a shared broker
The New Stack
이 글은 공유 Kafka 브로커에서 여러 개발자가 동시에 테스트를 돌려도 서로 간섭하지 않도록 '라우팅 키'로 격리하는 방법을 다룬다. 문제의식은 Kafka를 소비하는 서비스의 변경 사항은 실제 시스템에 붙여서 돌려보기 전까지는 검증됐다고 보기 어렵다는 데서 출발한다. 토픽을 통째로 복제하거나 클러스터를 여러 개 두는 기존 방식은 비용과 운영 복잡도가 크다는 것이 저자 Arjun Iyer의 지적이다. 대안으로 제시하는 방법은 프로듀서가 메시지 헤더에 라우팅 키를 담고 컨슈머 그룹 단위로 격리하는 것이다. 개발자가 자신의 서비스 버전을 테스트 환경에 배포하면 my-service-group-sandbox123처럼 고유한 컨슈머 그룹에 합류하고, 샌드박스 전용 라우팅 키 덕분에 그 컨슈머 그룹으로만 관련 메시지가 전달된다. 이 방식으로 전체 메시징 인프라를 복제하지 않고도 여러 개발자가 동시에, 서로 겹치지 않게 격리된 테스트를 돌릴 수 있다. 결과적으로 공유 브로커 한 대만으로도 멀티 클러스터 수준의 테스트 격리를 훨씬 저렴하게 구현할 수 있다는 것이 이 글의 결론이다.
💡 클러스터·토픽을 늘리지 않고 라우팅 키와 컨슈머 그룹만으로 테스트를 격리할 수 있다는 것은, Kafka 기반 서비스의 병합 전 검증 비용을 크게 낮출 수 있다는 의미다.
이 다이제스트는 RSS 피드에서 수집한 뒤 AI(Claude)가 요약·정리했습니다. 자세한 내용은 원문 링크를 확인하세요.