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

이때의 나

sunhwang

백엔드 면접 질문을 하나하나 보면 별 연결이 없어 보여요. 시스템 구성, MySQL 엔진, 리눅스 패키지 관리자, SSH 터널링, ERD, Redis, 배포, WAS 최적화, PayPal 연동, 시큐어 코딩까지. 영역이 너무 넓죠. 그런데 면접을 몇 번 받아보면 보여요. 질문은 다르지만 가려내려는 건 거의 하나예요. 자기가 만든 시스템을 한 장으로 그릴 수...

백엔드 시스템을 끝까지 그려볼 수 있나요

댓글