직장에서 팀을 옮겼거나 새 직장에 입사했을 수도 있습니다. 아니면 즐겨 쓰는 오픈소스 앱에서 버그를 발견하고 첫 풀 리퀘스트(PR)를 작성하려고 할 때도 있죠.
git clone으로 코드를 받아 app/models 폴더를 열었는데, 정작 아무것도 보이지 않는 경험, 누구나 한 번쯤 있으셨을 겁니다. Rails의 디렉터리 구조는 늘 익숙한 그대로인데도, 정작 코드 속에서는 길을 찾기가 어렵습니다.
그렇다면 낯선 Rails 앱을 가장 빠르게 학습하는 방법은 무엇일까요?
1단계: 프로젝트 용어 사전 만들기
이 앱에서 Player란 무엇일까요? Session은 또 뭘까요? Account, User, Provider는 어떻게 다른 걸까요?
모든 앱은 저마다 다른 용어와 추상화 개념을 사용합니다. 앱의 어휘를 이해하지 못하면, 새로운 클래스 이름을 볼 때마다 app/models 폴더를 헤매며 시간을 낭비하게 됩니다. 더 나쁜 경우에는 기능의 동작 방식을 잘못된 전제로 이해하게 되죠.
그래서 가장 먼저 해야 할 일은 프로젝트의 용어 사전을 만드는 것입니다. 이 앱이 무엇으로 구성되어 있는지 배우는 거죠. 빠르게 시작하려면 db/schema.rb부터 읽어 보세요. 앱이 사용하는 용어와 데이터가 서로 어떻게 연결되는지 자연스럽게 파악할 수 있습니다. 특히 *_id 컬럼에 주목하세요. 모델 간의 관계가 그 컬럼에 드러나 있습니다.
시각적인 자료가 더 편하다면 rails-erd 젬을 활용해 보세요. Rails 모델로부터 모든 테이블과 컬럼, 그리고 그 관계를 담은 ERD 다이어그램을 생성해 줍니다. 출력물을 책상에 두고 작업하면 앱의 나머지 부분을 이해하는 데 큰 도움이 됩니다.
2단계: 모델과 일반 Ruby 객체 살펴보기
잘 설계된 Rails 앱이라면 모든 것이 데이터베이스 테이블과 대응되지 않습니다. 프로젝트 어휘를 확장하기 위해 app/models 안에서 db/schema.rb에는 없던 클래스와 속성을 찾아보세요.
단, 여기서 너무 깊게 파고들 필요는 없습니다. 내부 동작 방식에 빠져 길을 잃기 쉽습니다. 지금 단계의 목표는 오직 프로젝트 어휘를 채우는 것뿐입니다.
앱을 구성하는 요소들을 알아갈수록, 특정 객체가 왜 존재하는지, 왜 그런 식으로 결합되어 있는지 궁금해질 겁니다. 바로 다음 단계가 그 질문에 답하기 위한 것입니다.
3단계: 직접 실행해 보고 "왜"를 찾기
앱이 사용하는 객체들에 익숙해졌다면, 이제 앱을 직접 실행해 보세요. 화면을 클릭하며 탐험하고, 문서가 있다면 참고하면서 방금 배운 용어들이 실제로 어떻게 구현되어 있는지 확인합니다.
앱을 사용하다 보면 한 차원 높은 시야가 생깁니다. 모델들이 왜 그런 연관 관계(association)를 가지는지, 왜 그룹으로 묶여 있는지, 왜 그런 클래스 이름이 붙었는지 이유가 보이기 시작합니다. 같은 페이지에 함께 나타나거나, 하나의 폼에서 함께 만들어지기 때문일 수도 있습니다.
앱을 구성하는 부품들과 그것들이 존재하는 이유를 이해했다면, 이제 전체가 어떻게 동작하는지 파악할 준비가 된 것입니다.
4단계: "어떻게" 파악하기
여기까지 왔다면, 이제 세부적으로 앱을 학습할 만큼 충분한 기반이 마련된 상태입니다. 더 이상 낯선 용어나 새로운 개념에 주의가 흩어지지 않습니다. 배우고 싶은 하나의 주제를 골라 끝까지 따라가 볼 수 있죠.
여기서 나아갈 방법은 여러 가지입니다. 제가 즐겨 쓰는 방법 몇 가지를 소개합니다.
- UI를 탐색하며 스스로 물어보기: 지금까지 파악한 구성 요소를 안다면, 이 기능은 어떻게 만들어졌을까? 추측해 본 뒤 디버거로 검증하거나 실제 동작을 확인하세요.
- 테스트 케이스 하나를 골라 끝까지 추적하기: 코드를 직접 읽거나 디버거로 탐색하면서 흐름을 따라가 보세요.
- 라우트나 컨트롤러 액션 하나 선택하기: UI에서 그 컨트롤러 액션에 도달하는 경로를 찾아낼 수 있는지 확인해 보세요.
이 시점에서 다시 모델과 일반 Ruby 객체로 돌아가기에도 좋습니다. 이번에는 모델의 내부 동작 방식까지 충분히 깊게 들어갈 수 있습니다.
앱에 대해 호기심을 가지세요. 지식의 빈틈을 발견하고, 디버거와 코드로 그 빈틈을 메워 나가면 됩니다.
왜 테스트부터 읽으면 안 될까?
흔히 이런 말을 들어왔습니다. "코드베이스를 이해하고 싶으면 테스트부터 읽어라! 테스트는 실행 가능한 문서다!"
하지만 저에게는 이 방법이 통한 적이 없었습니다. 테스트 케이스는 너무 좁고 너무 세부적입니다. 테스트만으로 학습하면 앱의 큰 그림을 놓치는 느낌이 들죠.
Rails 앱처럼 거대한 것, 혹은 대부분의 젬조차 이해하려면 항상 전체적인 개요가 먼저 필요했습니다. 어떤 구성 요소들이 앱을 이루고 있는지, 그리고 그것들이 왜 존재하는지 알아야 하기 때문입니다.
단, 테스트가 실제로 돌아가도록 만드는 것은 반드시 해야 합니다. 테스트가 실패한다면 시스템 자체가 고장난 상태이고, 고장난 시스템에서 얻은 발견은 신뢰할 수 없습니다.
What → Why → How
새로운 Rails 앱을 이해하려면 다음 세 단계를 순서대로 밟으세요.
- What(무엇): 이 앱은 어떤 부분들로 구성되어 있는가?
- Why(왜): 그 부분들은 왜 존재하는가? 왜 그런 방식으로 결합되어 있는가?
- How(어떻게): 각 부분은 어떻게 동작하는가?
이 과정을 거치면 넓은 시야와 좁은 세부 지식을 모두 갖추게 되어, 그 새로운 앱을 진정한 '내 것'으로 만들 수 있습니다.