고도에서 맞닥뜨린 존재론적 충격

AI 요약

Rocky Mountain Ruby 첫날 기조 발표에서 Travis Turner는 ‘존재론적 충격(ontological shock)’이라는 표현으로 개발자들이 겪는 변화를 설명합니다. 직무와 도구, 고용 안정성을 둘러싼 걱정은 더 근본적인 변화에서 비롯된다는 이야기입니다. 이튿날 Alan Ridlehoover도 AI 도입 뒤 손으로 코드를 쓰지 말라는 회사의 요구를 받고 느낀 충격을 같은 말로 표현합니다. 두 발표는 AI가 개발자의 정체성과 일하는 방식을 흔드는 상황을 회의 전체의 화두로 묶습니다.

Ruby와 Rails로 만드는 AI 도구

Drew Bragg는 약 400줄의 Ruby로 AI 에이전트를 만드는 과정을 실시간 코딩으로 보여줍니다. 웹훅을 여럿 연결했으며, 코드는 GitHub에서 확인할 수 있습니다. Giovanni Panasiti는 RubyLLM을 사용해 Rails 방식으로 에이전트형 RAG를 구성합니다. AI 스택을 Gemfile 안에 담을 수 있다는 점을 보이고, 답변 품질을 가장 크게 높인 요소로 평범한 문자열 처리를 꼽습니다. 문서의 제목과 조항 번호, 표 구조를 고려해 청크를 나누는 작업이 중요하다는 설명입니다. Python이나 별도 언어가 있어야 문자열을 다룰 수 있느냐고 질문하며, Rails 개발자도 AI 분야에서 뒤처지지 않는다고 강조합니다.

에이전트와 테스트를 다루는 기준

Andrea Fomera는 AI 에이전트가 Rails 코드베이스 온보딩을 도울 수 있다고 말합니다. 새로 합류한 사람이 시스템을 빠르게 파악하는 데 에이전트를 활용하되, 팀을 알아가는 경험까지 에이전트에 맡기지는 말라고 권합니다. Ifat Ribon은 AI가 테스트를 더 많이 만들 수 있어도 더 나은 테스트를 보장하지는 않는다고 짚습니다. 테스트가 늘면 피드백이 느려지고 CI 사용량과 유지보수 부담, 개발자의 인지 부담도 커집니다. 구현 세부보다 공개 메서드의 동작과 결과를 검사하고, 리팩터링 뒤에도 테스트가 통과하는지 확인하라고 제안합니다. 에이전트에는 규칙을 담은 하네스를 마련하고, 코드 스캔과 커버리지 같은 결정론적 도구로 테스트가 실제로 잡아내는 범위를 검증해야 한다고 설명합니다.

Rails 애플리케이션의 설계와 유지보수

Nicolas Erlichman은 Active Record에서 모델 상속을 표현하는 방식으로 delegated types를 소개합니다. 기존 선택지인 단일 테이블 상속(single-table inheritance)과 다형 연관(polymorphic associations) 대신 delegated types를 쓰면 통합 조회를 제공하면서 테이블을 비대하게 만들지 않고, 새 유형이 늘어날 때도 모델을 확장하기 쉽다고 설명합니다. Marco Roth는 Herb를 Rails 8.2의 선택형 뷰 엔진으로 통합한 과정을 다룹니다. ActionView를 조정하고 확장한 결과, ERB 뷰를 HTML 구조에 맞춰 다루는 도구와 개발 도구를 Rails 개발자가 기본으로 사용할 수 있게 됐습니다. Fernando Perales는 애플리케이션의 쇠퇴가 갑작스러운 재난이 아니라 점진적으로 쌓인다고 말합니다. 시스템을 바꿀 능력을 보존하고, 트레이드오프를 명시한 뒤 다시 검토해야 한다고 강조합니다.

개발자의 역할과 경험

Alan Ridlehoover는 1950년대 중반 NACA가 IBM 메인프레임을 도입했을 때 계산 업무를 맡던 여성들의 사례로 발표를 맺습니다. 많은 사람이 다른 업무로 옮기거나 은퇴했지만, Dorothy Vaughan, Mary Jackson, Katherine Johnson은 Project Mercury의 중요한 구성원으로 남았습니다. Alan은 기술을 사용하는 도구와 달리 달에 가겠다는 결정은 인간이 내렸다고 말합니다. “메인프레임은 달 표면을 밟지 않았습니다. 우리가 밟았습니다. 달에 가기로 결정한 쪽도 컴퓨터가 아니라 우리였습니다. 전자 컴퓨터는 그곳에 가는 데 쓴 도구였습니다. AI 시대에 연산은 상품이 되고 효율은 기본 조건이 됐습니다. 하지만 별을 향해 나아가려는 인간의 야망은 언제나 없어서는 안 됩니다.”

다른 발표에서는 테스트와 장애 대응, 경력 개발도 다룹니다. Sonja Peterson은 온콜 대응 자신감이 성격이 아니라 익힐 수 있는 기술이라고 말하며, 매일 시스템의 정상 상태를 살피고 명령줄에서 관찰할 수 있는 정보에 익숙해지라고 권합니다. Joel Hawksley는 스태프 엔지니어가 되려는 준비를 승진 직전이 아니라 그보다 훨씬 앞서 시작해야 한다고 설명합니다. 기술 깊이를 밧줄에 빗대어 주니어는 밧줄을 배우고, 시니어는 강도와 매듭을 이해하며, 스태프는 밧줄을 만드는 법을 이해한다고 표현합니다.

dev.to 반응

• @pawel_nowak — 400줄짜리 AI 에이전트 발표와 RubyLLM RAG 발표에서 같은 교훈을 얻었습니다. 흥미로운 부분은 모델 호출 자체가 아니라 주변의 지루한 연결 작업입니다. 평범한 문자열 조작이 답변 품질을 무엇보다 크게 높인다는 말은 모든 팀이 고생을 겪고 나서야 배우는 내용처럼 느껴집니다. Herb가 Rails 8.2의 선택형 뷰 엔진이 된다는 변화도 작아 보이지만, 파싱해야 할 ERB가 얼마나 많은지 생각하면 다르게 보입니다. 글을 써주셔서 감사합니다.
• @learn2027 — 정말 멋진 요약 감사합니다. 😁 회의의 분위기를 즐겁게 담아내고, 도구가 아무리 발전해도 인간의 야망이 없어서는 안 된다는 점을 다시 생각하게 해주셨습니다. AI 이야기가 가득한 가운데 사람을 중심에 둔 점이 특히 좋았습니다. 다음 글도 기대하겠습니다. 🗻🧊📚

원문: dev.to / 번역·요약: Trawling