백엔드 면접 질문을 하나하나 보면 별 연결이 없어 보여요. 시스템 구성, MySQL 엔진, 리눅스 패키지 관리자, SSH 터널링, ERD, Redis, 배포, WAS 최적화, PayPal 연동, 시큐어 코딩까지. 영역이 너무 넓죠.
그런데 면접을 몇 번 받아보면 보여요. 질문은 다르지만 가려내려는 건 거의 하나예요.
자기가 만든 시스템을 한 장으로 그릴 수 있는가, 그리고 그 안의 박스 하나를 깊게 열어볼 수 있는가.
이 글은 그 관점에서 자주 나오는 13가지 영역의 핵심을 정리한 거예요. 모범 답안이 아니라, 자기 경험을 한 번 더 짚어보는 체크리스트로 봐주시면 좋아요.
시스템 전체를 한 장에 그려본다#
면접의 첫 질문은 보통 비슷해요.
"지난 프로젝트의 시스템 구성을 설명해보세요."
이 질문이 가려내는 건 단순해요. 자기가 만진 시스템을 한 장으로 그릴 수 있는지요. 그릴 수 있으면 그다음 질문이 의미를 갖고, 못 그리면 뒤 질문이 다 막혀요.
좋은 구성도에는 세 가지가 들어가요.
- 컴포넌트와 책임 — 클라이언트, 로드밸런서, WAS, DB, 캐시, 외부 API 각각이 무엇을 하는지
- 컴포넌트 간 통신 — HTTP/HTTPS, gRPC, JDBC, 큐, 어떤 프로토콜로 무엇이 오가는지
- 실패 경로 — 한 컴포넌트가 죽으면 어디로 폴백되는지, 어떤 데이터가 유실되는지
배포도 사실 이 그림의 연장선이에요. "어디에 올리는가"(EC2, ECS, EKS, Lambda 등), "어떻게 무중단으로 바꾸는가"(블루-그린, 카나리, 롤링), "롤백은 어떻게 하는가" — 이 세 가지가 배포 질문의 본질이에요.
WAS 셋팅과 최적화는 이 그림의 한 박스를 깊이 들여다보는 거예요. 톰캣이든 Spring Boot 내장이든, 핵심은 같아요.
- 스레드 풀 사이즈 — 동시 처리 가능한 요청 수, CPU와 I/O 특성에 맞춰 조정
- 커넥션 풀 사이즈 — DB가 받을 수 있는 커넥션 수와 맞춰야 함 (WAS × 인스턴스 수 ≤ DB max_connections)
- 타임아웃 — 응답, DB, 외부 호출 각각 다른 값으로 명시
- JVM 옵션 — 힙 사이즈, GC 알고리즘 (보통 G1이 기본, 큰 힙에서는 JDK 21+의 Generational ZGC가 사실상 기본 권장)
데이터를 어떻게 다루는가#
데이터 영역은 세 가지가 묶여요. DB 선택, 스키마 설계, 캐시 전략.
MySQL을 썼다면 어떤 엔진을 썼는가#
"MySQL 써봤어요"만으로는 부족해요. 어떤 스토리지 엔진을 썼는지가 핵심이에요.
| 엔진 | 특징 | 언제 |
|---|---|---|
| InnoDB | 트랜잭션, 외래키, 행 단위 락, 클러스터드 인덱스 | 거의 모든 일반 케이스 |
| MyISAM | 트랜잭션 없음, 테이블 락, 빠른 카운트 | 거의 안 씀 (legacy) |
| Memory | RAM 저장, 영속성 없음 | 임시 테이블 |
요즘 현장은 사실상 InnoDB가 기본이에요. 그래서 더 깊은 질문은 "격리 수준은 뭘로 두셨어요?"로 이어져요. REPEATABLE READ(기본)와 READ COMMITTED의 차이, 그리고 갭 락이 데드락에 어떻게 영향을 주는지 정도는 답할 수 있어야 해요.
ERD를 그릴 때 무엇을 보는가#
ERD를 그리는 사람과 받아쓰는 사람이 갈리는 지점은 여기예요.
- 정규화의 의도와 비정규화의 의도 — 1NF/2NF/3NF를 외우는 게 중요한 게 아니라, 어디까지 정규화하고 어디부터 의도적으로 비정규화할지 결정할 수 있는가
- 인덱스를 염두에 둔 키 선택 — 자주 조회되는 컬럼이 PK/UK/인덱스에 들어가 있는가, 복합 인덱스 순서는 카디널리티 큰 컬럼이 앞에 있는가
- 외래키 정책 —
ON DELETE를CASCADE로 둘 건지RESTRICT로 둘 건지, 애플리케이션이 책임질 건지 - 변경에 강한 설계 — 자주 바뀌는 속성은 별도 테이블로 분리해두면 마이그레이션이 쉬워져요
Redis(또는 Valkey)는 구축인가 매니지드인가#
2024년 Redis의 라이선스 변경(SSPL/RSALv2) 이후 Linux Foundation 주도의 Valkey 포크가 주류 OSS 대안으로 자리 잡았어요. AWS ElastiCache/MemoryDB도 Valkey를 기본 옵션으로 제공해요. 어느 쪽을 썼든 질문의 결은 같아요.
"직접 구성하셨어요, 아니면 매니지드 쓰셨어요?"
이게 중요한 이유는 운영 깊이를 가른다는 거예요.
- 직접 구성 — 마스터-슬레이브 복제, Sentinel(고가용성), Cluster(샤딩) 중 어떤 모드인지, 메모리 정책(
maxmemory-policy)은 어떻게 잡았는지 - 매니지드 (ElastiCache, MemoryDB 등) — 운영 부담은 적지만 비용 구조와 제약(파라미터 그룹 제한, 클러스터 모드 차이)을 이해해야 함
캐시 자체에 대해서도 정리해두면 좋아요. 무엇을 캐싱하는가(읽기 많고 변경 적은 데이터), 만료 정책(TTL, LRU), 캐시 미스가 났을 때 일어나는 일(thundering herd 방지). 답이 깊어져요.
인프라를 직접 만져본다#
리눅스, 패키지 관리, SSH는 보통 묶여서 나와요. 결국 "터미널에서 일할 수 있는가"를 보는 거예요.
어떤 리눅스를 썼는가 = 어떤 패키지 관리자에 익숙한가#
| 배포판 | 패키지 관리자 |
|---|---|
| Ubuntu / Debian | apt, dpkg |
| RHEL / CentOS / Amazon Linux | yum, dnf, rpm |
| Alpine | apk (도커 이미지에서 자주 봐요) |
| Arch | pacman |
같은 패키지여도 배포판마다 이름이 다르고, 의존성 트리도 달라요. apt로는 nginx인데 Alpine에선 nginx와 함께 ca-certificates까지 명시해야 하는 식이죠.
"패키지를 올려봤다"는 의외로 가치가 커요#
사내 사설 저장소든 npm/PyPI/Maven Central이든, 패키지를 한 번이라도 배포해본 경험은 다음을 보여줘요.
- 시맨틱 버저닝(SemVer)의 의미를 안다 —
major.minor.patch의 변경 기준 - 의존성을 명시적으로 관리할 줄 안다 — peer/dev/optional 의존성의 차이
- 메타데이터(README, license, keywords)가 발견성에 어떤 영향을 주는지 안다
라이브러리 하나를 만들어서 사내에라도 올려보면, 라이브러리를 쓰는 관점만 갖고 있을 때는 안 보이던 게 보여요.
SSH 키와 터널링#
- 키 생성은
ssh-keygen -t ed25519 -C "email"— RSA보다 짧고 빨라요 - 공개키 등록은 서버의
~/.ssh/authorized_keys에 한 줄로 추가 - 권한 중요:
~/.ssh는 700,authorized_keys는 600
터널링은 외부에서 막혀 있는 내부 자원에 안전하게 접근하는 표준 방법이에요.
# 로컬 13306 → bastion 경유 → RDS 3306
ssh -L 13306:rds.internal:3306 user@bastion.example.com이렇게 열어두면 로컬 MySQL 클라이언트로 localhost:13306에 붙기만 하면 돼요. VPN 없이 운영 DB에 잠깐 붙어야 할 때 자주 써요.
보안을 코드 레벨에서 고민한다#
시큐어 코딩과 결제 연동은 사실 한 묶음이에요. 외부와 닿는 모든 지점에 대한 의심이거든요.
시큐어 코딩의 큰 4가지#
- 입력은 항상 검증한다 — SQL 인젝션은 파라미터 바인딩으로, XSS는 출력 시 이스케이프로
- 인증과 인가는 분리한다 — "누구냐"(authentication)와 "뭘 할 수 있냐"(authorization)는 다른 층
- 비밀은 코드에 두지 않는다 — 환경 변수, 시크릿 매니저(AWS Secrets Manager, Vault)로
- 로그에 민감 정보를 남기지 않는다 — 카드 번호, 토큰, 개인정보는 마스킹
PayPal 같은 외부 결제 연동에서 가장 중요한 것#
기능 동작보다 상태와 멱등성이에요.
- 결제 상태 머신을 명확하게 정의 —
PENDING → APPROVED → CAPTURED → REFUNDED같은 흐름을 코드와 DB에 동일하게 새겨두기 - 웹훅(IPN) 검증 — PayPal이 보낸 콜백인지 서명으로 확인, 그리고 같은 이벤트가 재전송돼도 한 번만 반영되도록 idempotency key 처리
- 환불·취소의 트랜잭션 일관성 — 외부 API 호출과 우리 DB 업데이트 사이에 불일치가 생기지 않게 보상 트랜잭션이나 outbox 패턴 고려
- 결제 정보는 직접 저장하지 않는다 — 카드 번호는 토큰으로만 보관 (PCI DSS 4.0 기준)
이 영역은 "되는 코드"와 "운영해도 안 무너지는 코드"의 차이가 가장 크게 나는 곳이에요.
결국 한 가지 질문으로 모인다#
13가지 영역을 다 짚었는데, 결론은 처음과 같아요.
자기가 만진 시스템을 한 장으로 그릴 수 있고, 각 박스 안을 한 단계 더 들여다볼 수 있는가.
면접 준비는 "MySQL 격리 수준 4가지 외우기" 같은 게 아니에요. 자기가 실제로 만진 시스템의 그림을 한 번 더 그려보고, 각 박스마다 "내가 이걸 왜 이렇게 골랐지?"를 자문해보는 거예요. 그러면 같은 질문이 와도 모범 답안이 아니라 자기 답이 나와요.
마지막에 따라붙는 비기술 질문도 사실 같은 결이에요. "앞으로 뭘 잘 하고 싶은지", "3년 뒤 어떤 모습이고 싶은지", "다른 면접 보는 곳 있는지" — 이건 자기 커리어의 시스템 구성도를 그려본 적이 있는지를 묻는 거예요. 자기가 어디로 가고 있는지 한 장에 그릴 수 있는 사람은 답이 빨라요.
기술이든 커리어든, 결국 같은 근육이에요. 한 장에 그려보고, 박스 하나를 열어보는 습관.
Spring is a time for rebirth and the fulfilment of new life.
— Byron Pulsifer
