이번 소식은 눈에 띄는 대형 발표보다는, 조용하지만 실무에 오래 남을 변화들이 유독 많이 보였어요. Rails 쪽에서는 require_dependency deprecation처럼 시대가 바뀌었음을 보여주는 정리 작업이 있었고, MySQL DDL 옵션 확장이나 스키마 로딩 성능 개선처럼 운영 현장에서 바로 체감할 수 있는 업데이트도 이어졌어요. 또 한편으로는 TutorialKit.rb가 “재미있는 실험”을 넘어 정말 써볼 만한 도구의 단계까지 올라왔고, Basecamp는 제품 안에 AI를 억지로 끼워 넣기보다 에이전트가 자연스럽게 일할 수 있는 길을 열어주는 쪽으로 한 발 더 나아갔어요. 여기에 당근의 DB Meetup 소식까지 더해져서, 이번 소식은 전반적으로 “기술이 어떻게 현실적인 도구가 되어가는가”를 보여주는 흐름으로 읽혔어요.
그리고 이번 소식이 조금 늦어진 점은 먼저 죄송하다는 말씀을 드려야 할 것 같아요. 토론토에 와 있으니 밤이 되면 하루가 끝나는 줄 알았는데, 한국과 회의를 시작하면 그때부터 2차전이 열리더라고요. 토론토의 밤과 서울의 낮이 손잡고 제 소식지 마감을 데려가 버렸습니다. 덕분에 시차를 몸으로 배우는 중이지만, 그 와중에도 이번 호에 담을 만한 이야기들은 더 단단히 골라볼 수 있었어요. 조금 늦었지만, 그래서 더 알차게 가져왔다는 마음으로 이번 소식도 편하게 읽어주세요.
🎧 10분 요약 오디오로 들어보시겠어요? → YouTube로 듣기
새로운 소식
이번 주 Rails: “조용하지만 실무에 바로 꽂히는 변화들”
이번 주 Rails 소식은 화려한 기능 추가보다는, 실무에서 바로 체감할 수 있는 변화들이 조용히 쌓인 한 주였어요. 특히 앞으로의 방향성을 엿볼 수 있는 deprecation과 함께, 운영 안정성과 성능 개선에 초점이 맞춰진 점이 인상적이에요.
먼저 눈에 띄는 변화는 require_dependency의 deprecated 소식이에요. 별도의 대체 없이 Rails 9에서 제거될 예정인데요, 이는 Zeitwerk 기반의 autoloading이 충분히 안정화되면서 과거의 패턴을 정리하는 흐름으로 볼 수 있어요. 레거시 코드베이스를 운영 중이라면, 미리 사용 여부를 점검해두는 것이 좋겠어요.
데이터베이스 쪽에서는 MySQL을 사용하는 팀들에게 반가운 개선이 있었어요. 이제 add_column, change_column 같은 컬럼 단위 DDL 작업에서도 lock:과 algorithm: 옵션을 사용할 수 있게 되었어요. 이를 통해 읽기/쓰기 블로킹 없이 온라인 스키마 변경을 보다 유연하게 제어할 수 있게 되었고, 실제 서비스 운영 중 마이그레이션 부담을 줄여줄 수 있는 변화예요.
성능 측면에서도 개선이 이어졌어요. 스키마를 로드할 때 테이블 생성 SQL을 batch로 묶어서 실행하도록 변경되면서, db:schema:load 속도가 향상되었어요. CI 환경이나 로컬 초기 세팅에서 체감할 수 있는 부분이라, 반복적인 환경 구성 비용을 줄이는 데 도움이 될 것으로 보여요.
또한 Rails가 기본으로 생성해주는 Dockerfile의 빌드 성능도 개선되었어요. 기존 프로젝트에서도 변경된 내용을 참고해 적용하면 이미지 빌드 시간을 줄일 수 있어, 배포 파이프라인을 운영하는 팀이라면 한 번 확인해볼 만한 업데이트예요.
PostgreSQL을 사용하는 경우에도 작은 개선이 있었어요. readonly 모드(prevent_writes: true)에서도 RESET 명령어 실행이 가능해지면서, 설정을 기본값으로 되돌리는 작업이 더 유연해졌어요. 운영 환경에서의 제약을 조금 더 현실적으로 풀어준 변화라고 볼 수 있어요.
마지막으로 Action Text에도 변화가 있었는데요, 이제 value와 block을 동시에 사용할 수 있게 되었어요. 기존에는 둘 중 하나만 사용할 수 있었지만, 이제는 에디터 내부에 커스텀 UI나 툴바를 삽입하면서도 콘텐츠 바인딩을 유지할 수 있어 확장성이 더 좋아졌어요.
전체적으로 이번 주는 “눈에 띄는 기능”보다는, 성능 개선, 운영 편의성, 그리고 레거시 정리에 초점을 맞춘 업데이트들이었어요. 당장은 작아 보이지만, 이런 변화들이 쌓이면서 Rails의 개발 경험을 더 안정적으로 만들어가고 있다는 느낌을 주는 한 주였어요.
This Week in Rails 보기: https://rubyonrails.org/2026/3/20/this-week-in-rails
TutorialKit.rb, 이제는 실험이 아니라 실제로 써볼 수 있는 단계에 왔어요
Evil Martians의 TutorialKit.rb가 release candidate 단계에 도달했어요. 이전에 한 차례 소개됐을 때만 해도 “브라우저 안에서 Ruby와 Rails 튜토리얼을 실행한다”는 실험적 성격이 더 강하게 느껴졌다면, 이번에는 실제로 튜토리얼을 만들고 배포할 수 있는 도구로 한층 다듬어진 모습이 인상적이에요. 이제는 설치기부터 데모 Rails 앱, 기본 레슨 구성, 배포 워크플로, HTTP 지원까지 갖추면서, 작성자는 복잡한 wasm 빌드 과정 대신 튜토리얼 콘텐츠 자체에 더 집중할 수 있게 되었어요.
가장 눈에 띄는 부분은 시작 경험이에요. npx create-tutorialkit-rb my-tutorial 한 번으로 새로운 튜토리얼 프로젝트를 만들 수 있고, 그 안에는 Rails 8 기반의 데모 앱과 기본 레슨, 그리고 배포 설정까지 함께 들어 있어요. 특히 프런트엔드 프레임워크를 덜어내고 서버 렌더링 중심의 순수 Rails 구조를 유지했다는 점은, 학습자가 Rails와 Ruby의 핵심에 더 집중할 수 있게 해준다는 점에서 방향이 분명해 보여요. 여기에 인증 흐름이나 기본 디자인 시스템까지 포함되어 있어서, 튜토리얼 제작자가 처음부터 모든 것을 직접 세팅하지 않아도 된다는 점도 장점이에요.
이번 글에서 흥미로운 또 하나의 포인트는 AI 친화적인 저작 환경이에요. TutorialKit.rb는 Claude Code skills를 함께 제공해서, AI 코딩 에이전트가 튜토리얼 구조와 제약 사항을 이해한 상태에서 레슨 초안 작성이나 앱 커스터마이징을 도울 수 있도록 했어요. 단순히 “AI로 문서를 써보자” 수준이 아니라, WebAssembly 환경의 제약이나 파일 구조, lesson 설정 규칙 같은 도메인 지식을 에이전트에게 함께 실어준다는 점에서 꽤 현실적인 접근이에요. 앞으로 개발자가 문서와 교육 자료를 만들 때 AI를 어떻게 협업 파트너로 활용할 수 있는지 보여주는 사례로도 읽혀요.
배포 경험도 많이 정리됐어요. Netlify와 Fly.io용 워크플로가 기본 제공되고, Rust 툴체인 설치나 ruby.wasm 빌드, 캐싱, Astro 사이트 빌드, 필요한 헤더 설정까지 CI에서 자동으로 처리해줘요. 즉, 작성자는 복잡한 인프라나 브라우저 제약을 깊이 이해하지 않아도 배포 가능한 결과물을 만들 수 있어요. “브라우저 안에서 돌아가는 Ruby 튜토리얼”이라는 흥미로운 아이디어가 실제 서비스 가능한 형태로 내려온 이유가 바로 이런 세부 자동화 덕분이라고 느껴져요.
기술적으로는 HTTP 지원이 큰 진전이에요. 원래 WASI Preview 1 환경에서는 네트워크 소켓이 없어 Ruby의 Net::HTTP가 그대로 동작할 수 없는데, 이번에는 JavaScript 브리지와 fetch를 활용해 이를 우회하는 방식을 프레임워크 차원에서 정리했어요. 완벽한 네이티브 네트워킹은 아니고 CORS 프록시 같은 제약도 남아 있지만, 외부 API를 사용하는 튜토리얼까지 브라우저 안에서 다룰 수 있게 되었다는 점은 활용 범위를 크게 넓혀줘요. 예를 들어 LLM API를 호출하는 Ruby 예제까지 설치 없이 브라우저에서 실행할 수 있다는 건, 교육 콘텐츠의 가능성을 꽤 넓혀주는 변화예요.
성능과 개발 경험 개선도 함께 이루어졌어요. 이 프로젝트는 ruby.wasm에 의존성을 어떻게 묶어 넣을지에 대해 여러 전략을 실험했는데, 최종적으로는 부팅 속도와 재빌드 시간을 모두 고려한 hybrid 접근으로 정리됐어요. 전체를 다시 컴파일하는 monolithic 방식은 느리지만 안정적이고, pure Ruby gem은 더 빠르게 패킹하는 deferred packing 전략으로 일상적인 튜토리얼 제작 속도를 개선했어요. 이런 부분은 최종 사용자에게는 잘 보이지 않지만, 도구가 “재미있는 데모”를 넘어 실제 저작 환경으로 쓰이려면 꼭 필요한 기반이에요.
전체적으로 보면 이번 TutorialKit.rb RC 소식은 단순히 “브라우저에서 Ruby가 돌아간다”는 데서 끝나지 않고, Ruby 생태계 안에서 문서와 학습 경험을 새롭게 만들 수 있는 도구가 한 단계 성숙했다는 의미가 있어요. 특히 gem이나 라이브러리를 유지보수하는 개발자라면, 설치 장벽 없이 직접 만져보는 인터랙티브 튜토리얼을 만들 수 있다는 점에서 꽤 매력적으로 느껴질 것 같아요. 아직 WASI 제약이나 C 확장 호환성 같은 한계는 남아 있지만, 적어도 이제는 “흥미로운 실험”이 아니라 “실제로 한 번 써볼 만한 도구”라는 평가가 어울리는 시점에 온 것 같아요.
Basecamp, 이제 에이전트가 직접 읽고 쓰고 정리하는 협업 도구가 되었어요
DHH가 3월 25일 공개한 소식은, Basecamp가 단순히 AI 기능을 몇 개 붙인 수준이 아니라 아예 agent-accessible한 서비스로 한 단계 나아갔다는 점에서 눈에 띄어요. 이번 변화의 핵심은 개편된 API와 새로운 CLI, 그리고 이를 에이전트가 잘 활용할 수 있도록 돕는 skill을 함께 제공했다는 데 있어요. 덕분에 이제 에이전트는 Basecamp 안의 정보를 읽고 요약하는 데서 그치지 않고, 할 일 목록을 만들고, 메시지를 작성하고, 파일을 업로드하고, 일정까지 정리하는 식으로 실제 업무 흐름에 직접 개입할 수 있게 되었어요.
흥미로운 점은 37signals가 그동안 제품 안에 AI 기능을 억지로 녹여 넣는 접근을 경계해왔다는 점이에요. 지난 1년 반 동안 여러 AI 기능을 실험했지만, 사용자에게 정말 반가운 기능이라고 확신할 수 없으면 출시하지 않았다고 해요. 대신 이번에는 Basecamp 자체를 에이전트가 잘 사용할 수 있도록 “접근성”을 열어주는 방향을 택했어요. 제품 내부에 어색한 AI 버튼을 붙이는 대신, 사용자가 이미 익숙하게 쓰는 에이전트 환경에서 Basecamp를 다룰 수 있게 한 셈이에요. 요즘 많은 서비스가 AI를 붙였지만 오히려 제품 경험을 해치는 경우가 있는 만큼, 이 접근은 Basecamp다운 절제된 선택처럼 보여요.
DHH는 특히 브라우저 기반 조작의 비효율을 강조했어요. 에이전트가 웹 UI를 직접 다루려면 화면을 보고, 요소를 찾고, 클릭하고, 다시 확인하는 과정을 반복해야 해서 느리고 불안정한데요. 반면 CLI는 텍스트 기반이라 에이전트가 훨씬 빠르고 정확하게 다룰 수 있어요. 결국 이번 발표는 “AI를 어디에 넣을까”보다 “AI가 우리 제품을 가장 잘 다룰 수 있는 인터페이스는 무엇인가”라는 질문에 대한 Basecamp의 답이라고 볼 수 있어요.
실무 관점에서 보면 이 변화는 꽤 의미가 커 보여요. 예전에도 API를 통해 비슷한 자동화는 가능했지만, 직접 통합을 만들고 유지하는 비용이 컸기 때문에 실제로 활용하는 고객은 많지 않았어요. 그런데 이제는 에이전트가 여러 도구를 넘나들며 정보를 모으고, 그 결과를 Basecamp 안에서 바로 실행 가능한 형태로 정리할 수 있어요. 예를 들어 다른 서비스에서 버그나 고객 불만을 수집한 뒤, 이를 Basecamp 프로젝트 안에서 요약하고 후속 작업까지 만드는 흐름이 훨씬 쉬워지는 거예요. 단순한 “요약”이 아니라 실제 협업 도구 안에서 행동으로 이어지는 지능에 더 가까워졌다고 볼 수 있어요.
한마디로 정리하면, Basecamp는 AI 기능을 제품 안에 억지로 넣기보다, 에이전트가 제품을 잘 사용할 수 있게 길을 터주는 방향을 선택했고, 그 선택이 앞으로 HEY나 Fizzy 같은 다른 37signals 제품으로도 확장될 가능성을 보여준 소식이에요.
블로그 보기: https://world.hey.com/dhh/basecamp-becomes-agent-accessible-3ae6b949
37signals의 REWORK 영상 요약 보기: https://secondb.ai/summary/19231/?tab=my
당근, 첫 DB Meetup 개최… Aurora 운영부터 pgvector 검색 최적화까지 실무 노하우를 공개해요
당근이 오는 4월 24일 서울 교보타워에서 첫 번째 DB Meetup을 연다고 밝혔어요. 이번 밋업은 데이터베이스 운영과 최적화에 관심 있는 엔지니어를 대상으로 하며, 당근 DB팀이 실제 서비스 환경에서 쌓아온 운영 경험과 최적화 노하우를 공유하는 자리로 구성됐어요. 세션 주제도 꽤 실무적이에요. Aurora DB의 표준 구성과 자동화 파이프라인, 엔드포인트 운영과 오토 스케일링, Database Insight 활용 사례, Kubernetes 환경의 MongoDB 운영 경험까지 당근 서비스의 데이터베이스 운영 전반을 엿볼 수 있도록 꾸려졌어요.
개인적으로 눈에 띄는 세션은 **“pgvector 검색 최적화” 예요. 행사 안내에 따르면 이 세션에서는 pgvector의 전반적인 소개와 함께 벡터 검색을 최적화하기 위한 운영 노하우가 다뤄질 예정이에요. 여기에 당근이 중고거래 서비스에 pgvector를 실제로 적용하면서 겪은 최적화 경험이 녹아 있을 것이기 때문에, 단순한 기술 소개를 넘어 대규모 서비스의 검색·추천 뒷단에서 데이터베이스 레벨 최적화가 어떻게 이뤄지는지 엿볼 수 있는 흥미로운 사례가 될 것 같아요. Rails나 웹 애플리케이션 관점에서도, 요즘 점점 중요해지는 벡터 검색을 운영 환경에서 어떻게 다루는지 참고할 만한 포인트가 많은 세션으로 보여요.
행사는 2026년 4월 24일 금요일 오후 2시부터 6시 30분까지 진행되고, 참가 신청은 3월 25일부터 4월 3일까지 받으며 추첨을 통해 최종 참가자가 확정돼요. 발표자와 AWS 엔지니어가 함께하는 현장 Q&A도 예정되어 있어서, 데이터베이스 운영과 최적화에 관심 있는 분들이라면 꽤 매력적인 오프라인 이벤트가 될 것 같아요.
행사 안내 보기: https://x.com/daangnteam/status/2036658512575791590?s=20
행사 자세히 보기: https://luma.com/fz8rvak7