Ruby on Rails 신입 데이터베이스 면접
새 면접Q. Rails의 Active Record에서 has_many와 belongs_to 관계를 설정할 때, 데이터베이스 테이블에는 어떤 컬럼이 필요한가요? 예를 들어 User has_many Posts, Post belongs_to User 관계를 구현한다면 어느 테이블에 외래키를 추가해야 하나요?
belongs_to가 선언된 모델 쪽에서 상대 모델을 참조하는 컬럼이 필요합니다.
belongs_to가 선언된 Post 테이블에 user_id 컬럼을 추가해야 합니다. 외래키는 항상 belongs_to 관계를 선언한 쪽의 테이블에 위치합니다. 이 컬럼은 정수형(integer)으로 생성하며, User 테이블의 id를 참조합니다. 마이그레이션에서는 add_reference 또는 add_column 메서드를 사용하여 user_id를 추가할 수 있습니다. 선택적으로 foreign_key: true 옵션을 추가하면 데이터베이스 레벨에서 참조 무결성을 보장할 수 있습니다.
- • belongs_to 쪽 테이블에 외래키 컬럼 추가
- • 외래키 컬럼명은 모델명_id 형식
- • foreign_key 옵션으로 참조 무결성 보장 가능
게시판, 댓글 시스템 등 거의 모든 관계형 데이터 모델링에서 기본이 되는 연관관계 설정입니다.
foreign_key: true 옵션을 추가하지 않으면 어떤 문제가 발생할 수 있나요?
Q. 데이터베이스 인덱스(Index)가 무엇인지 설명하고, 인덱스를 추가하면 어떤 장점과 단점이 있는지 말씀해주세요.
책의 색인(찾아보기)과 비슷한 역할을 하며, 조회 속도와 쓰기 속도 사이의 트레이드오프가 있습니다.
인덱스는 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조입니다. 책의 색인처럼 특정 컬럼의 값을 빠르게 찾을 수 있도록 별도의 정렬된 구조를 만듭니다. 장점으로는 WHERE, JOIN, ORDER BY 절을 사용하는 조회 쿼리의 성능이 크게 향상됩니다. 단점으로는 인덱스를 저장할 추가 디스크 공간이 필요하고, INSERT, UPDATE, DELETE 작업 시 인덱스도 함께 갱신해야 하므로 쓰기 성능이 저하됩니다. 따라서 자주 조회되는 컬럼에만 선택적으로 인덱스를 추가해야 합니다.
- • 검색 속도 향상을 위한 자료구조
- • 조회 성능은 향상, 쓰기 성능은 저하
- • 추가 저장 공간 필요
사용자 이메일 검색, 게시글 작성일 정렬 등 빈번한 조회 쿼리의 성능 최적화에 필수적입니다.
Rails 마이그레이션에서 인덱스를 추가하는 방법을 설명해주세요.
Q. Rails에서 N+1 쿼리 문제가 무엇인지 설명하고, 이를 해결하기 위한 방법을 말씀해주세요. 예를 들어 10개의 게시글과 각 게시글의 작성자 이름을 보여주는 상황을 가정해주세요.
반복문 안에서 연관된 데이터를 조회할 때 발생하며, eager loading으로 해결할 수 있습니다.
N+1 쿼리 문제는 연관된 데이터를 조회할 때 불필요하게 많은 쿼리가 실행되는 성능 문제입니다. 10개 게시글의 작성자를 조회하면, 게시글 목록 조회 1번 + 각 게시글마다 작성자 조회 10번으로 총 11번의 쿼리가 실행됩니다. 이를 해결하려면 includes 메서드를 사용하여 연관 데이터를 미리 로드(eager loading)해야 합니다. Post.includes(:user).all처럼 작성하면 게시글과 작성자를 2번의 쿼리로 모두 가져옵니다. 다른 방법으로는 joins를 사용한 INNER JOIN이나 preload, eager_load 메서드도 있습니다.
- • 반복문에서 연관 데이터 조회 시 쿼리가 N+1번 실행되는 문제
- • includes를 사용한 eager loading으로 해결
- • 쿼리 횟수를 N+1번에서 2번으로 감소
게시판 목록, 댓글 목록 등 연관 데이터를 반복 표시하는 모든 화면에서 성능 최적화를 위해 필수적으로 고려해야 합니다.
includes와 joins의 차이점은 무엇인가요?
Q. 데이터베이스 트랜잭션이 무엇인지 설명하고, Rails에서 트랜잭션을 사용해야 하는 상황의 예를 들어주세요.
여러 데이터베이스 작업을 하나의 논리적 단위로 묶어 모두 성공하거나 모두 실패하도록 보장합니다.
트랜잭션은 여러 데이터베이스 작업을 하나의 논리적 단위로 묶어서, 모든 작업이 성공하면 커밋(commit)하고 하나라도 실패하면 전체를 롤백(rollback)하는 기능입니다. ACID 속성을 보장하여 데이터의 일관성을 유지합니다. Rails에서는 ActiveRecord::Base.transaction 블록을 사용합니다. 예를 들어 송금 기능에서 A계좌 잔액 차감과 B계좌 잔액 증가는 반드시 함께 성공하거나 함께 실패해야 하므로 트랜잭션으로 묶어야 합니다. 또한 주문 생성과 재고 감소, 게시글 삭제와 관련 댓글 삭제 등도 트랜잭션이 필요한 상황입니다.
- • 여러 작업을 하나의 단위로 묶어 전체 성공 또는 전체 실패 보장
- • 데이터 일관성 유지를 위한 ACID 속성
- • 송금, 주문 등 연관된 데이터 변경 시 필수
결제, 포인트 적립/차감, 재고 관리 등 데이터 정합성이 중요한 모든 금융/상거래 로직에서 필수입니다.
트랜잭션 블록 안에서 예외가 발생하면 어떻게 되나요?
Q. Rails에서 대량의 데이터를 조회할 때 find_each를 사용하는 이유와, all.each와의 차이점을 설명해주세요.
메모리 사용량과 배치 처리 방식에서 차이가 있습니다.
find_each는 대량의 레코드를 조회할 때 메모리 효율적으로 처리하기 위해 사용합니다. all.each는 모든 레코드를 한 번에 메모리에 로드한 후 반복하므로, 데이터가 많으면 메모리 부족 문제가 발생할 수 있습니다. 반면 find_each는 기본적으로 1000개씩 배치로 나누어 조회하고 처리하므로 메모리 사용량이 일정하게 유지됩니다. batch_size 옵션으로 한 번에 가져올 레코드 수를 조절할 수 있습니다. 수만 건 이상의 데이터를 처리하는 배치 작업이나 데이터 마이그레이션 스크립트에서 반드시 사용해야 합니다.
- • 대량 데이터 처리 시 메모리 효율성 확보
- • 배치 단위로 나누어 조회하여 메모리 부담 감소
- • 기본 1000개씩 처리, batch_size로 조절 가능
회원 전체 이메일 발송, 정산 배치, 데이터 마이그레이션 등 대량 데이터를 처리하는 백그라운드 작업에서 필수적입니다.
find_in_batches는 find_each와 어떻게 다른가요?
Q. 동시에 여러 사용자가 같은 상품을 구매하려고 할 때 재고가 마이너스가 되는 문제가 발생했습니다. 이런 동시성 문제를 해결하기 위한 데이터베이스 락(Lock) 방법을 설명해주세요.
Rails에서는 lock 메서드나 with_lock 메서드를 사용하여 비관적 락을 구현할 수 있습니다.
이 문제는 동시성 제어가 필요한 상황으로, 비관적 락(Pessimistic Lock)을 사용하여 해결할 수 있습니다. Rails에서는 lock 메서드를 사용해 SELECT FOR UPDATE 쿼리를 실행하여 레코드를 잠급니다. 예를 들어 product.lock!이나 Product.find(id).lock!을 사용하면 해당 레코드를 읽는 동안 다른 트랜잭션이 수정할 수 없습니다. 또는 with_lock 메서드로 블록 내에서 안전하게 재고 확인과 차감을 수행할 수 있습니다. 다른 방법으로는 낙관적 락(Optimistic Lock)을 위한 lock_version 컬럼을 사용할 수도 있지만, 재고 관리처럼 충돌이 빈번한 경우는 비관적 락이 적합합니다.
- • 동시 접근 시 데이터 정합성 문제 발생
- • 비관적 락(lock, with_lock)으로 레코드 잠금
- • SELECT FOR UPDATE로 다른 트랜잭션의 수정 차단
한정 수량 상품 구매, 좌석 예매, 쿠폰 발급 등 동시 접근이 많은 자원을 관리할 때 필수적입니다.
비관적 락과 낙관적 락의 차이점과 각각 어떤 상황에 적합한지 설명해주세요.
Q. Rails 마이그레이션 파일에서 change 메서드와 up/down 메서드의 차이점을 설명하고, 각각 언제 사용하는지 말씀해주세요.
Rails가 자동으로 롤백을 추론할 수 있는지 여부가 핵심입니다.
change 메서드는 Rails가 자동으로 롤백 방법을 추론할 수 있는 경우에 사용하는 간편한 방식입니다. add_column, create_table, add_index 같은 대부분의 기본 작업은 Rails가 역방향 작업을 자동으로 생성할 수 있습니다. up/down 메서드는 롤백 방법을 명시적으로 지정해야 할 때 사용합니다. 예를 들어 데이터 변경, 복잡한 SQL 실행, remove_column에서 컬럼 타입을 복구해야 하는 경우 등은 up에 마이그레이션 로직, down에 롤백 로직을 각각 작성해야 합니다. 일반적으로는 change를 사용하고, 필요한 경우에만 up/down을 사용하는 것이 권장됩니다.
- • change는 Rails가 자동으로 롤백 추론 가능
- • up/down은 명시적 롤백 로직 필요 시 사용
- • 데이터 변경, 복잡한 작업은 up/down 사용
스키마 변경 시 안전하게 롤백할 수 있도록 마이그레이션을 작성하는 것은 운영 환경에서의 배포 안정성을 위해 필수입니다.
마이그레이션을 롤백하는 명령어는 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!