코더에서 아키텍트로: AI가 코드를 작성하는 시대에 Rails를 배우는 방법

최근 저는 10년 전 제가 Ruby on Rails를 배웠던 방식이 이제는 완전히 구식이 되었다는 사실을 깨달았습니다.

당시 저는 Railscasts와 같은 튜토리얼을 시청하거나 책을 읽으며 문법 (syntax)을 암기하는 데 수백 시간을 보냈습니다. has_many :through 연관 관계를 정확히 어떻게 작성하는지, 또는 중첩된 폼 (nested form)을 어떻게 구성하는지를 반드시 배워야 했습니다. 저는 **작성자 (Writer)**였습니다. 저의 가치는 정확한 코드를 만들어내는 능력이었습니다.

2026년, 문법은 흔한 상품 (commodity)입니다. Cursor나 GitHub Copilot과 같은 도구들 덕분에, 이제 AI가 작성자입니다. 저는 _"내 포스트에 다대다 (many-to-many) 관계를 가진 태깅 시스템을 추가해줘"_라고 프롬프트 (prompt)를 입력할 수 있고, 코드는 몇 초 만에 작성됩니다.

하지만 여기에 문제가 있습니다: AI는 훌륭한 작성자이지만, 형편없는 아키텍트 (architect)입니다.

만약 당신이 코드가 어디에 위치해야 하는지 모른다면, AI는 코드를 가장 쉬운 곳에 쏟아부을 것이고, 이는 대개 당신의 컨트롤러 (controllers)와 모델 (models)을 거대하고 지저분하게 만듭니다. 이 "튜토리얼 이후의 시대 (Post-Tutorial Era)"에서 살아남으려면, 문법에 집중하는 것을 멈추고 **아키텍처 (Architecture)**에 집중하기 시작해야 합니다.

직접 코드를 타이핑하지 않는 상황에서 "Rails 방식 (Rails Way)"을 배우는 방법은 다음과 같습니다.

1. "어떻게 (How)"에서 "어디에 (Where)"로 이동하기

전통적인 방식의 튜토리얼을 따르면, 메서드 (method)를 어떻게 작성하는지를 가르쳐줍니다. 2026년에는 그 메서드가 어디에 속해야 하는지를 물어야 합니다.

만약 AI가 Stripe API와 통신하는 로직을 User 모델 안에 넣으라고 제안한다면, 당신은 다음과 같이 말할 수 있어야 합니다: "아니, 그건 app/services에 있는 서비스 오브젝트 (Service Object)에 속해야 해."

학습 방법: Rails Sidecar 패턴을 공부하세요. 현대적인 앱들이 다음과 같은 것들을 어떻게 사용하는지 살펴보세요:

• Service Objects: 제3자 API 로직을 위해.
• ViewComponents: 복잡한 UI 로직을 위해.
• Jobs: 100ms 이상 걸리는 모든 작업을 위해.

2. AI 감사하기 ("왜 (Why)" 테스트)

AI의 제안을 수락하기 위해 단순히 "Tab" 키를 누르지 마세요. AI가 코드 블록을 생성할 때마다 수동 감사를 수행하세요. 스스로에게 물어보세요: "왜 백그라운드 잡 (background job) 대신 콜백 (callback)을 사용했을까?"

만약 답을 모른다면, AI에게 그 트레이드오프 (trade-offs)를 설명해달라고 요청하세요:

"여기서 왜 백그라운드 잡 (background job) 대신 after_create 콜백 (callback)을 사용하는 것이 위험한가요?"

이것이 오늘날 아키텍처를 배우는 방식입니다. AI를 주니어 개발자로 대하고, 당신 자신을 **편집장 (Editor-in-Chief)**으로 대하십시오. AI가 자신의 아키텍처적 선택을 정당화하도록 강제함으로써, 당신은 프레임워크의 근본적인 원칙을 배우게 됩니다.

3. "오마카세 (Omakase)" 제약 사항 배우기

Rails는 "오마카세" 프레임워크 (셰프가 재료를 선택함)입니다. 이는 **설정보다 관습 (Convention over Configuration)**을 기반으로 구축되었습니다.

AI가 Rails 코드를 매우 잘 작성하는 이유는 Rails가 매우 엄격한 관습 (conventions)을 가지고 있기 때문입니다. 만약 당신이 "영리하게" 행동하려다 자신만의 폴더 구조나 명명 패턴 (naming patterns)을 만들어내려 한다면, AI는 혼란에 빠지고 환각 (hallucination)을 일으키기 시작할 것입니다.

전략: 기본값 (defaults)에 의존하십시오. 표준 Rails 8 패턴 (Solid Queue, Hotwire 등)을 더 많이 따를수록, AI는 더욱 강력한 초능력이 됩니다. 2026년의 아키텍처는 앱의 "배선 (wiring)"을 매우 표준적으로 유지하여 AI가 이를 완벽하게 탐색할 수 있도록 만드는 것입니다.

4. Rails 소스 코드 읽기

더 이상 구문 (syntax)을 암기하는 데 시간을 쓰지 않으므로, 그 여분의 두뇌 에너지를 사용하여 GitHub에 있는 실제 rails/rails 소스 코드를 읽는 데 사용하십시오.

ActiveJob이 내부적으로 실제로 어떻게 작동하는지 이해한다면, 백그라운드 작업 (background tasks)을 어떻게 설계해야 할지 정확히 알게 될 것입니다. 당신에게는 "할 일 목록 (To-Do List)" 앱을 보여주는 튜토리얼이 필요한 것이 아니라, 프레임워크의 **핵심 패턴 (Core Patterns)**을 이해하는 것이 필요합니다.

요약

"튜토리얼 중심 개발자 (Tutorial-Driven Developer)"의 시대는 끝났습니다. 만약 당신이 지시 사항을 따르는 법만 안다면, AI는 이미 당신의 업무를 수행할 수 있습니다.

2026년에 가치 있는 개발자가 되려면, 반드시 **아키텍트 (Architect)**가 되어야 합니다.

1. 구문 암기를 멈추십시오. 그 일은 AI가 처리합니다.
2. 패턴을 배우십시오. Concern을 사용할지 Service를 사용할지 그 시점을 파악하십시오.
3. 표준을 강제하십시오. .cursorrules나 RuboCop을 사용하여 AI가 경로를 벗어나지 않게 하십시오.
4. "이유 (Why)"를 이해하십시오. AI에게 항상 그 제안의 트레이드오프 (trade-offs)를 물으십시오.

이제 코드는 무료입니다. 그 코드가 어떻게 서로 맞물려 돌아가는지에 대한 **안목 (Taste)**과 **비전 (Vision)**이 바로 수익을 창출하는 핵심입니다.