기술 포스트는 영어 위주로 작성하려 했으나, 이후 기수들이나 후배들에게 조금이나마 도움이 될 수 있을까 싶어 합격 회고는 한글로 작성한다.
SWMaestro는 BOB와 함께 신입생 때부터 선배들에게 들어왔던 인재 양성 과정이다. 이전 기수 지원 기간에는 알고리즘 실력도, 프로젝트 완성도도 애매해서 지원서를 쓰다가 14기를 기약했던 기억이 난다. 이번에는 내가 만든 프로젝트를 제대로 설명할 수 있고, 코딩 테스트도 최소한의 안정권까지 올려둘 수 있다고 판단했다.
전체 준비 방향
합격 회고는 자칫 결과만 남기기 쉽다. 하지만 이 과정에서 더 중요했던 것은 내가 어떤 지식을 외웠는가보다, 내가 만든 프로젝트를 얼마나 구조적으로 설명할 수 있었는가였다. 이 글은 SWMaestro 14기를 준비하면서 코딩 테스트와 면접을 어떻게 분리해 준비했고, 어떤 질문에 대비했는지를 정리한 기록이다.
준비는 크게 세 갈래로 잡았다.
- 코딩 테스트는 모든 문제를 다 맞히는 것보다, 구현 실수 없이 풀 수 있는 문제를 확실히 가져가는 쪽으로 준비했다.
- 면접은 내가 했던 프로젝트를 구조, 기술 선택, 실패 가능성, 개선 방향까지 설명할 수 있도록 정리했다.
- CS와 백엔드 기본기는 키워드 암기가 아니라 꼬리질문을 받았을 때 말이 끊기지 않는 수준을 목표로 했다.
지나고 보니 가장 중요했던 것은 화려한 지식보다 정리된 설명이었다. 특히 프로젝트 면접에서는 “이 기술을 써봤다”보다 “왜 썼고, 문제가 생기면 어디를 볼 것인가”를 말할 수 있는지가 훨씬 중요했다.
코딩 테스트
시험은 Programmers에서 2시간 동안 진행되었다. 구성은 알고리즘 4문제와 SQL 1문제였다. 1차는 서버 문제로 한 번 무효 처리되었고, 이후 같은 방식으로 다시 진행되었다.
1차에서 느낀 점
1차는 구현과 시뮬레이션 비중이 컸다. 단순 구현, 좌표 평면 탐색, 조합 탐색, DFS 성격의 문제가 섞여 있었고 SQL은 문자열 처리 성격이 강했다. 문제 자체의 아이디어가 엄청 새롭다기보다는, 제한 시간 안에 조건을 빠뜨리지 않고 구현하는 쪽이 어려웠다.
당시 내가 가져가야 한다고 느낀 유형은 이 정도였다.
| 유형 | 준비 포인트 |
|---|---|
| 구현 / 시뮬레이션 | 조건을 상태값으로 나누고, 예외 케이스를 먼저 적어두기 |
| 완전탐색 / 조합 | 입력 크기를 보고 brute force가 되는지 빠르게 판단하기 |
| DFS / 백트래킹 | 상태 정의와 방문 처리 기준을 명확히 잡기 |
| SQL | 기본 SELECT, JOIN, GROUP BY 외에 문자열 처리 함수도 한 번 훑기 |
특히 구현 문제는 풀이 방향을 알아도 코드가 길어지면 실수가 생긴다. 그래서 SWMaestro 코딩 테스트를 준비한다면 어려운 알고리즘을 새로 파는 것보다, 구현량 있는 문제를 시간 재고 푸는 연습이 더 효율적이라고 생각한다.
2차에서 느낀 점
2차도 알고리즘 4문제와 SQL 1문제였다. 구현, DP, Queue 기반 시뮬레이션, Dijkstra와 DP가 섞인 그래프 문제가 나왔다. 개인적으로는 그래프 문제보다 DP 문제의 edge case 처리가 더 까다로웠다.
결과적으로 1차와 2차 모두 시간 압박이 꽤 있었다. 대략 2문제 정도가 안정권처럼 느껴졌고, 멘토님께 들은 바로도 2차에서는 많은 연수생들이 1번과 SQL 정도만 확실히 풀었다고 했다. 코딩 테스트만 놓고 보면 취업 코딩 테스트의 필수 유형을 꾸준히 공부한 사람에게 크게 낯선 시험은 아니지만, 구현 체력이 부족하면 생각보다 쉽게 흔들릴 수 있다.
내가 다시 준비한다면 우선순위는 이렇게 둘 것 같다.
- 구현과 시뮬레이션 문제를 매일 짧게라도 풀기
- DP는 점화식보다 상태 정의와 edge case 점검에 집중하기
- 그래프는 BFS, DFS, Dijkstra 기본 template을 손에 익히기
- SQL은 JOIN, GROUP BY, UNION, 문자열 함수를 최소 한 번씩 풀어보기
면접 준비
면접 준비는 처음에 키워드를 너무 많이 벌려서 오히려 지저분해졌다. 나중에는 아래처럼 묶어서 정리했다. 이 방식이 훨씬 도움이 됐다.
1. 프로젝트 설명
가장 많이 준비한 것은 프로젝트 자체였다. 면접에서 내가 한 프로젝트를 깊게 물어볼 가능성이 높다고 생각했기 때문이다.
프로젝트별로 아래 질문에 답할 수 있게 정리했다.
- 이 프로젝트가 해결하려던 문제는 무엇인가
- 내가 맡은 부분은 어디까지인가
- 왜 그 기술 스택을 선택했는가
- DB schema, API, deployment 구조는 어떻게 되어 있는가
- 장애가 난다면 어떤 순서로 확인할 것인가
- 지금 다시 만든다면 무엇을 바꿀 것인가
예를 들어 Redis를 사용한 프로젝트는 caching 대상, Redis 장애 시 DB fallback, Base62 기반 short URL 생성, MariaDB character set 설정, Docker Compose의 depends_on, CSV parsing 흐름까지 묶어서 설명할 수 있게 했다. 단순히 “Redis를 썼다”가 아니라 “왜 Redis가 필요했고, Redis가 죽으면 어떻게 되는가”까지 말할 수 있어야 했다.
GPT 기반 프로젝트는 기술 구현뿐 아니라 BM, 비용 구조, 사용자 확보 방식까지 준비했다. SWMaestro 면접은 순수 기술 면접만이 아니라, 팀 프로젝트를 실제로 끝까지 끌고 갈 수 있는 사람인지도 보는 느낌이었다.
2. 백엔드 기본기
백엔드 기본기는 깊게 파기보다, 내가 사용한 기술과 연결되는 범위를 중심으로 정리했다.
| 영역 | 정리한 내용 |
|---|---|
| Spring / Spring Boot | 의존성 관리, embedded server, 초기 설정, Spring Security와 CORS |
| REST API | URI 설계, CRUD, JSON response, frontend/backend 연동 시 흔한 문제 |
| Testing | JUnit5, Spock, Mocking을 언제 쓰는지 |
| Database | 정규화, RDB와 NoSQL 차이, MySQL/MariaDB/PostgreSQL/Redis의 특징 |
| Cache | Redis caching 대상, session/API response caching, fallback 전략 |
| Docker / Deployment | container 간 통신, Docker Compose, EC2 배포, 환경 설정 |
| Git / 협업 | branch 규칙, commit 단위, pull/review 습관 |
예전에는 이런 내용을 키워드만 줄줄 외우려 했는데, 면접에서는 그렇게 준비하면 금방 티가 난다. “정규화가 뭔가요”에서 끝나는 것이 아니라, “왜 이 프로젝트에서는 이 schema가 괜찮았나요”로 이어질 수 있기 때문에 프로젝트와 연결해서 준비하는 편이 낫다.
3. 협업과 리더십
협업 질문도 꽤 중요하다고 느꼈다. 예상 질문은 대략 이런 것들이었다.
- 의견이 맞지 않는 팀원이 있으면 어떻게 할 것인가
- 초기 기획을 그대로 수행할 수 없는 상황이면 어떻게 할 것인가
- 기술 스택이 다른 팀원과 어떻게 소통할 것인가
- 본인이 리더라면 일정과 backlog를 어떻게 관리할 것인가
나는 초기 기획을 촘촘하게 세우되, 구현하면서 바뀌는 요구사항은 backlog와 timeline에 반영하는 방식으로 답변을 준비했다. 팀원이 서로 다른 기술 스택을 쓰는 상황에서는 API contract, data format, CORS, security 같은 접점을 문서화하고, frontend/backend merge 시 문제가 날 수 있는 부분을 먼저 확인하겠다고 정리했다.
심층 면접
분과마다 면접관에 따른 분위기와 질문 방향이 다르다고 들었다. 내가 면접을 봤던 1분과는 기술과 인성 질문이 골고루 섞여 있었다. 인성 질문은 다섯 명에게 공통으로 주어지는 경우가 많았다.
가장 기억에 남는 질문은 면접 후반부에 나왔다. 현재 같이 면접을 보고 있는 지원자들 중 누구와 팀을 하고 싶은지, 누가 리더에 적합한지 묻는 질문이었다. 다른 지원자의 답변을 제대로 듣지 않았으면 대답하기 어려운 질문이었다. 실제로 얼버무리는 사람도 있었고, 반대로 특정 지원자를 고르고 근거를 말하는 사람도 있었다.
기술 면접은 발표했던 프로젝트를 중심으로 깊게 들어갔다. 프로젝트가 빈약해 보이면 기획 의도와 기술 선택을 더 집요하게 묻는 느낌이었다. 코딩 테스트에 관해서는 1차와 2차 문제지가 배부되었지만, 코딩 테스트 질문은 전체 지원자 중 몇 개 나오지 않았다. 다만 Programmers 제출 기록, 제출 코드, 부분 점수까지 면접관이 알고 있었기 때문에 준비 없이 넘길 수 있는 영역은 아니었다.
결론적으로는 본인이 만든 프로젝트를 빠짐없이 숙지하고, 사용한 기술에 대한 꼬리질문만 제대로 대비하면 답하기 어려운 면접은 아니었다. 1차와 2차 코딩 테스트를 통과했다면 남은 것은 내 경험을 얼마나 명확하게 설명할 수 있느냐에 가까웠다.
면접에서 남은 것
결국 SWMaestro 준비는 화려한 기술 목록을 늘리는 과정이 아니라, 내가 실제로 만든 것을 끝까지 설명할 수 있는 상태로 만드는 과정이었다. 프로젝트의 구조와 실패 가능성, 그리고 다시 만든다면 바꿀 지점까지 말할 수 있을 때 면접은 훨씬 덜 불안해진다.