📂 개발
nest_rails.png

Nest프로젝트 Ruby On Rails로 이전하기 (with 채용과제, 작성중)

#Ruby On Rails,2025-07-23

어쩌다보니 Ruby On Rails로 과제를 진행하게 되었다.

사실, 원래 Nest로 과제를 진행했다. 하지만 개발을 완료하고 제출을 하기위해 메일을 켠 순간, 해당 기업으로부터 새로 업데이트된 과제를 반영해줄 수 있냐는 메일이 왔음을 확인했다. 물론, 기간도 추가적으로 할당받았고,,

내용은 거의 동일했다. 하지만, 개발한 Nest 프로젝트를 Ruby On Rails로 바꿔야하는 상황이 다가왔다. 개인적으로 Nest로 개발한 백엔드 결과물에 아쉬운점이 많았는데 시간도 추가적으로 할당받고, 새로운 프레임워크를 배울 수 있는 오히려 좋은 기회가 다가온 것 같다. 백엔드 프레임워크만 다르지 결은 비슷할테니,,

물론 이게 과제 형태로 취업을 보장할 수 없는 상황이지만, 기간을 정해두고 하나 둘 씩 개발하는 과정을 직접하면서 시간효율적으로 실력이 는다는 것을 느꼈다. 아무튼 새로운 프레임워크를 배우는데 이와 같은 환경이 생김에 감사하다.

물론 과제 내용이 codex와 같은 AI툴을 활용해서 개발하는, 바이브코딩과 같은 형태였지만 새로운 내용을 공부하는 것이다보니 이를 기록하면서 개발을 진행해볼까 한다.

Ruby on Rails 알아보기

게임을 좀 해보면 이런 말들이 있다.

로아, 이거 메유법으로 설명해줘, 이터널리턴 이거 롤유법으로 설명해줘..

비슷한 장르의 다른 게임의 경우 신규 유저들이 게임 시스템을 이해하고 싶어 커뮤니티에 글을 저런식으로 작성하곤한다.

나도 저런식으로 접근하려한다. 루비온레일즈 ~ 이거 nest의 ~ 이더라.. 이런식으로

프로젝트의 시작

Ruby on Rails (ROR)은 풀스택 프레임워크다. django와 비슷한 결의 프레임워크라고 보면 될거같다.

어찌되었든 해당 과제에서는 api 버전으로, 즉 백엔드로서의 ROR을 기대했기에 다음 명령어로 프로젝트를 생성했다.

rails new ringle_ror --api --database=postgresql

DB에 맞춰 postgres 설정도 추가로 넣어줬다.

물론 간단한 프로젝트의 경우엔 sqlite가 좋다고 한다. ROR 서버 내부에서 동작하게 하여 지연을 방지하고, 최근 개발진들이 sqlite에 대한 지원을 많이 해주고 있기 때문에,,

어찌되었든 실제 서비스를 하는 기업이라면 어떤 DB를 쓸까 생각해본 결과 postgres가 적합하다고 생각했다.

DB 스키마

ROR은 자체적으로 Active Record라는 ORM 시스템이 존재한다.

이전에 prisma로 스키마를 AI 활용해서 ROR에 맞는 스키마를 생성했다. 해당 과정에서 사용한 명령어 예시는 다음과 같다.

rails generate model User email:string password:string company_id:uuid
# updatedAt, createdAt은 자동 생성

이를 입력하면 app/model, db/migrate 내부에 파일이 생긴다.

models 내부에 있는 파일은 상호작용을 관리한다. 어떤 테이블과 어떤 관계인지, 어떤 값을 가져야하는지 등을 지정한다.

migrate 내부 파일은 실제 DB에 올라갈 테이블의 규격을 설정한다.

아무튼, 이들을 스키마에 맞게 수정하면된다.

Auth 구현

devise를 주로 사용한다고 한다. 물론 빌트인 auth를 사용하는 것도 방법이지만, 많은 ROR 개발자들이 devise로 auth를 구현하는 것을 확인했다.

하지만, devise를 활용하여 개발하면서 session 관련된 오류를 많이 봤다. 내가 구현하고자 했던 로그인 방식은 토큰방식이였기에 이와 맞지 않다고 생각했다.

devise-jwt를 추가설치해서 구현 가능했으나 낭비가 심하다고 생각하여 직접 구현했다.

Controller

사실 이부분에서 충격 많이받았다. service가 따로 없어도 되나 싶었는데, 이게 끝이라고? 수준의 길이로 기능이 구현되었다.

물론 devise를 사용하진 않았지만, devise를 사용한 로직이 정말 짧았다고 느껴지는데, 아래코드가 그 예시 중 하나다.

# POST /api/v1/admins/sign_in
def create
  # 이 메서드는 유효한 사용자(Admin)를 찾고, 비밀번호를 검증하며,
  # 성공 시 sign_in 헬퍼를 통해 JWT를 발급합니다.
  self.resource = warden.authenticate!(auth_options)
  sign_in(resource_name, resource)

  render json: {
    message: 'Admin logged in successfully!',
    admin: {
      id: current_admin.id,
      email: current_admin.email
    }
  }, status: :ok
end

아니 로그인로직 이게 끝이다. 진짜다. 알아서 토큰만들고, refresh는 쿠키에, 헤더엔 access 잘 담아 보내준다.

왜 ROR이 짧은 코드가 장점인지 알 수 있는 부분이었다.

restful action

nest로 개발할 땐, param은 뭐고,,, 이런걸 다 설정해줘야했다.

하지만 ROR의 경우, 해당 함수명으로 명칭만 지어주면 알아서 이를 해결해준다.

  • create : POST에 해당, Create
  • index : GET에 해당, 전체 정보를 반환하는 경우
  • show : GET에 해당, params를 추가적으로 인식하고, 해당 id값에 해당하는 리소스 획득
  • update : PATCH/PUT에 해당, params에 해당하는 것을 수정
    • 종종 동일하게 사용된다고 한다.
  • delete : param에 해당하는 리소스 제거

이런 특징이 있기 때문에 restful한 api 설계에 더 도움받는 느낌도 들었다.

nest로 개발할 때 실수했던 부분도 이런 자료들을 보면서 다시 잡는 기회가 되었던 것 같다.