면접 정리 [test]
아래는 NOWBartend 프로젝트를 기반으로 예상되는 면접 질문 리스트와 모범 답변입니다. 기술 면접에서 자주 나오는 **‘왜’, ‘어떻게’**에 대한 내용을 중심으로 구성했습니다.
🔍 전체 면접 예상 질문 리스트 + 답변
1. AOP 기반 Lock 구성
Q. 락을 AOP로 구성한 이유는 무엇인가요?
A. AOP는 공통된 기능을 모듈화해 핵심 로직과 분리할 수 있기 때문에 락과 같은 횡단 관심사를 깔끔하게 처리하기 적합했습니다. 예약 처리 같은 트랜잭션 로직마다 락을 일일이 적용하는 것보다, 공통 인터셉터 방식으로 선언적 락 제어를 가능하게 하여 유지보수성을 높일 수 있었습니다.
Q. 락이 전체 로직에 적용되어 병목이 생긴다고 했는데, 어떤 식으로 개선했나요?
A. 초기에는 예약 처리 전체에 락을 걸어 조회·검증 단계에서도 병목이 발생했습니다. 이후 조회/검증 단계에서는 락을 제거하고, 실제 DB 변경이 일어나는 구간에만 락을 걸도록 수정했습니다. 이를 통해 락 점유 시간을 수초 단위에서 수십 ms로 줄였고, TPS도 2배 이상 향상되었습니다.
Q. 분산 락은 어떤 방식으로 구현하셨나요?
A. Redis 기반의 Redisson 라이브러리를 활용해 분산 락을 구현했습니다. 인터페이스 기반 AOP에서 메서드 호출 시 특정 키를 기준으로 락을 획득하고, 트랜잭션 수행 이후 락을 해제하는 구조입니다. 락 키는 예약 대상의 바 ID와 사용자 ID를 기준으로 설정했습니다.
2. 성능 테스트 및 개선
Q. 성능 테스트는 어떻게 진행했나요?
A. JMeter를 사용하여 3,700명 이상의 가상 사용자를 설정한 부하 테스트를 진행했습니다. 테스트 결과, 락이 전체 로직에 적용된 경우 평균 응답 시간이 100160초까지 증가했으며, TPS는 200300에 머물렀습니다. 이후 로직 분리와 락 최적화로 3060초 내 응답, 400500 TPS까지 개선되었습니다.
Q. TPS가 낮아진 원인은 무엇이었나요?
A. 락이 전체 로직에 걸리면서, 병렬 처리가 가능한 단순 조회 요청까지 직렬화되어 병목이 발생했습니다. 특히 알림 로직까지 동기적으로 처리하면서 응답 지연이 커졌습니다.
3. 비동기 처리 & 메시지 큐
Q. 알림 시스템을 비동기화한 이유와 방식은?
A. 예약 완료 시 알림 생성 및 전송까지 동기적으로 처리되면, 전체 응답 지연의 원인이 됩니다. 이를 해결하기 위해 메시지 큐를 도입했습니다. 예약 성공 시 이벤트를 발행하고, 별도의 알림 서비스에서 큐를 구독해 알림을 생성 및 전송하게 했습니다. 이를 통해 응답 시간과 락 점유 시간을 모두 줄일 수 있었습니다.
Q. 메시지 큐는 어떤 방식으로 구현하셨나요?
A. Spring의 @Async를 사용한 단순 비동기 처리로 시작했지만, 확장성과 장애 대응을 고려해 Redis Stream 기반의 메시지 큐로 전환했습니다. 이벤트 발행 시 Redis Stream에 메시지를 넣고, 별도 스레드에서 구독하여 알림을 처리했습니다.
4. 지리 기반 탐색 & 카카오 API
Q. 카카오 지도 API는 어떻게 활용했나요?
A. 카카오의 장소 검색 API를 통해 사용자의 현재 위치 기반으로 반경 내 바 리스트를 조회했습니다. 프론트엔드에서 현재 위치 정보를 전달받고, 서버에서 해당 좌표 기준의 반경 검색을 수행하여 가까운 가게 목록을 제공합니다.
Q. 위치 기반 검색의 정렬 기준은 무엇이었나요?
A. 거리순으로 정렬하며, 서버에서 좌표간 거리를 계산해 정렬했습니다. 추후에는 사용자 평점이나 예약 가능 여부를 함께 고려한 정렬 방식도 적용할 계획입니다.
5. 보안 및 인증 처리
Q. Spring Security를 어떻게 적용하셨나요?
A. JWT 기반 인증 시스템을 구축했고, 사용자 인증 시 토큰을 발급해 이후 요청의 Header에 포함해 인증하는 방식으로 구현했습니다. Role 기반 인가도 설정하여, 관리자와 일반 사용자의 접근 권한을 구분했습니다.
Q. 소셜 로그인은 어떻게 구현했나요?
A. Spring Security OAuth2 클라이언트를 활용하여 카카오, 구글 로그인을 구현했습니다. 사용자 정보는 최초 로그인 시 DB에 저장하고, 이후 JWT 토큰 기반으로 인증 처리합니다. 이를 통해 사용자의 접근 편의성을 높이고 회원가입 절차를 간소화했습니다.
6. 전반적인 설계와 기여
Q. 프로젝트에서 가장 도전적이었던 부분은?
A. 동시성 제어와 관련된 트랜잭션 정합성 문제 해결이 가장 도전적이었습니다. 단순히 락을 거는 것에서 끝나는 것이 아니라, 병목의 원인을 정확히 진단하고 조회와 변경 구간을 분리하여 성능을 유지하면서도 정합성을 지키는 데 중점을 뒀습니다.
Q. 지금 돌아본다면 개선할 여지가 있던 부분은?
A. 락 처리 로직의 세분화와 큐 처리 방식에서 좀 더 범용적인 이벤트 기반 아키텍처 (예: Kafka)를 적용하면 추후 확장성에 더 유리했을 것 같습니다. 이번 프로젝트에선 Redis Stream으로 충분했지만, 대규모 트래픽 시점에는 메시지 브로커를 바꾸는 것도 고려하고 있습니다.
완벽하게 준비할 수 있도록, 당신의 HANSUNG STOCK 프로젝트를 면접에서 처음 소개하는 방식 → 이어지는 질문 흐름 → 예상 질문 & 답변까지 대화형 시뮬레이션처럼 구성해드릴게요. 이 흐름대로 말하면 자연스럽고 논리적으로 강하게 어필할 수 있습니다.
🧭 1. 면접에서 프로젝트 소개하는 방식
🎙️ 자기 입으로 설명할 1분 스크립트
“제가 진행한 HANSUNG STOCK은 딥러닝을 활용한 주가 예측 및 자동매매 웹 서비스입니다. Python과 Django 기반으로, 사용자가 종목 이름을 입력하면 해당 주가를 예측하고, 지정된 전략에 따라 자동으로 매매까지 수행할 수 있게 구현했습니다.
Keras 기반 LSTM 모델을 사용했고, 실제 매매는 대신증권 CYBOS Plus API를 통해 수행했습니다.
매매 로직은 변동성 돌파 전략 기반이며, 자동매매 프로세스는 Django 웹 서버와 독립적으로 돌아가야 했기 때문에 subprocess를 활용해 백그라운드에서 매매가 유지되도록 했습니다.또한, 종목별 뉴스는 BeautifulSoup으로 크롤링해서 시각화했고, Chart.js를 활용해 주가 변동도 직관적으로 보여줬습니다.”
🔁 2. 연계형 면접 예상 질문 + 답변
📌 Q1. 왜 딥러닝을 사용해서 주가를 예측하려 했나요?
A. 단순 시계열 모델보다 LSTM 같은 딥러닝 기반 모델이 시계열 예측에서 장기 의존성(Lag)을 잡는 데 더 효과적이라 판단했습니다. 물론 주가 자체는 예측이 어렵지만, 사용자에게 데이터 기반 참고 지표를 제공하고자 활용했습니다.
📌 Q2. 예측 정확도는 어느 정도였나요?
A. 초기에는 RMSE가 다소 컸고, 사용자 피드백에서도 만족도가 낮았습니다. 그래서 ‘변동성 돌파 + 이동평균’ 조건을 활용한 보완 전략으로 수정했고, 예측 자체보다는 "어떤 조건에서 매수/매도를 자동화할 것인가"를 더 현실적인 방향으로 집중했습니다.
📌 Q3. CYBOS Plus API는 어떤 방식으로 연동하셨나요?
A. Windows 기반의 로컬 환경에서 실행 가능한 COM 기반 API입니다. Python의 win32com.client를 활용해 로그인, 종목 검색, 계좌 조회 등을 구현했고, 종목명 → 종목코드 매핑도 직접 구현했습니다.
📌 Q4. 자동매매 로직은 어떻게 실행되나요?
A. 사용자가 종목을 선택하고 매매를 설정하면, Django에서 subprocess.Popen()으로 별도 Python 스크립트를 실행해 장 종료 전까지 백그라운드로 매매를 수행합니다. 이를 통해 웹 서버가 중단돼도 매매 로직은 영향을 받지 않습니다.
📌 Q5. subprocess가 아니라 Celery 같은 큐를 사용하지 않은 이유는?
A. 당시 목표가 간단한 실험 시스템 구축이었고, 실시간성이 강한 작업은 아니었기 때문에 subprocess로 충분했습니다. 실제 서비스 수준이라면 Celery나 Redis 기반 작업 큐 도입이 더 바람직하다고 생각합니다.
📌 Q6. 딥러닝 말고 다른 예측 모델도 테스트해봤나요?
A. 네, Sklearn 기반으로 RandomForest, SVR도 테스트했지만, 예측 흐름상 LSTM이 가장 부드럽고 시계열 연속성에 적합하다는 결과를 얻었습니다. 다만, 데이터가 제한적일 땐 간단한 모델이 더 유리할 수도 있다는 점도 확인했습니다.
📌 Q7. BeautifulSoup 크롤링은 어떤 용도로 활용했나요?
A. 사용자가 특정 종목을 선택하면, 해당 종목과 관련된 뉴스 상위 5건을 네이버 금융에서 크롤링해 롤링 배너 형식으로 제공합니다. 종목 관련 이슈를 실시간으로 제공해 예측 신뢰도를 높이는 보조 수단으로 활용했습니다.
📌 Q8. 프로젝트에서 가장 어려웠던 점은?
A. 장시간 실행되는 자동매매 로직을 Django와 분리해 유지하는 부분이 가장 어려웠습니다. 중간에 웹이 꺼지거나 예외 발생 시 매매가 멈추는 문제가 발생해서, subprocess와 예외 처리 로직을 통해 이를 안정화하는 데 가장 시간을 많이 썼습니다.
📌 Q9. 프로젝트를 통해 배운 점은?
A. 딥러닝만으로는 예측의 한계가 분명하다는 걸 체감했고, 실용성을 고려한 전략 보완이 중요하다는 걸 배웠습니다. 또한, 사용자 입력 처리 → 예측 모델 → 매매 실행 → 시각화까지 하나의 End-to-End 시스템을 설계하는 경험을 할 수 있었습니다.
📌 Q10. 지금 한다면 어떻게 개선하고 싶나요?
A.
- API 의존성 낮추기: CYBOS 대신 Python 기반의 OpenDart + WebSocket 기반 실시간 API로 전환
- 예측 전략 고도화: 강화학습 기반의 전략 적용
- 아키텍처 개선: Celery 도입, 모델 추론 서버와 웹 분리
- 실사용자 피드백 기반의 자동매매 커스터마이징 추가
✅ 정리: 면접 핵심 포인트
구분 내용
| 목표 | 예측 + 자동매매 End-to-End 웹 서비스 구축 |
| 강점 | 딥러닝 적용 + 실매매 전략 설계 + API 연동 |
| 어려움 | 프로세스 분리와 예외 처리 |
| 개선 여지 | 실시간성 강화, 전략 정교화, MSA 구조 전환 |
원하신다면 이 내용을 기반으로 6슬라이드 발표자료도 바로 구성해드릴 수 있어요.
지금 같이 정리해볼까요?
정확한 방향을 짚어주셔서 좋아요!
✅ 면접은 결국 "왜 그걸 썼는지"를 이해하는 질문,
✅ 지원 포지션이 백엔드라면 “AI 모델 자체”보다 “서비스화, 아키텍처, 통합 기술 선택 이유”가 중요합니다.
그래서 지금부터는 HANSUNG STOCK 프로젝트를 "백엔드 개발자 관점"에서 설명하고,
왜 이 구조를 썼는지 = 설계 의도 중심으로 면접 답변을 구성해 드릴게요.
🧠 HANSUNG STOCK – 백엔드 관점 설명 (면접용)
🎙️ 1분 요약 (왜를 중심으로 설명)
“딥러닝 예측보다는 예측 기반 자동매매 시스템을 서비스화한 전체 구조 설계에 집중했습니다.
Django를 선택한 이유는 빠른 웹 API 개발과 Python 생태계와의 통합 때문이고, CYBOS API로 주가 정보를 받아와 사용자 요청에 따라 종목 검색, 시각화, 자동매매를 수행하는 구조입니다.
백엔드 입장에서 특히 고려한 점은 장시간 실행되는 자동 매매 프로세스를 메인 서버와 분리해 안정적으로 운영하는 것이었고, 이를 위해 subprocess로 백그라운드 프로세스를 분리했습니다.
또한, 주가 정보와 뉴스 데이터를 한 화면에 통합 제공하고, 변동성 기반 전략을 조건화하여 사용자마다 맞춤 실행이 가능하게 설계했습니다.”
🔗 면접 질문 + 백엔드 관점의 “왜” 중심 답변
Q1. 왜 Django를 사용하셨나요? (vs Flask)
A.
Flask는 가볍지만 확장 구조가 부족하고, 자동매매처럼 폼 기반 데이터 처리, ORM, Admin, 인증 같은 내장 기능이 필요한 상황에선 Django가 훨씬 유리했습니다.
또한 Python 생태계에서 주가 예측 모델, API 연동, 시각화까지 모두 포함하려면 Django에서 빠르게 백엔드 구조를 잡는 것이 더 실용적이라 판단했습니다.
Q2. 왜 subprocess를 사용해 자동매매 로직을 따로 실행했나요?
A.
자동매매는 장중 6시간 이상 돌아가는 로직입니다. 이걸 Django 서버 내부에서 처리하면 웹 요청 지연, 메모리 점유, 예외 발생 시 전체 서버 중단 가능성이 있었습니다.
그래서 웹 서버는 요청만 받고, 실제 매매는 별도 백그라운드 프로세스에서 지속 실행되도록 subprocess.Popen()을 사용했습니다. 이는 MSA의 관점에서도 로직 분리가 된 구조입니다.
Q3. 백엔드 개발자로서 자동매매 서비스에서 가장 신경 쓴 부분은?
A.
- API 연동 신뢰성 – 대신증권 API는 호출 횟수 제한이 있으므로, 호출 주기를 제어하고 재시도 로직을 넣었습니다.
- 프로세스 분리 – 장시간 자동매매가 서버와 별도로 돌아야 했기에 비동기 처리 구조를 명확히 했습니다.
- 에러 처리와 유저 입력 검증 – 종목명이 오타나 잘못된 경우, 예외 없이 graceful fallback 되도록 예외처리를 강화했습니다.
Q4. 뉴스 크롤링을 왜 서버에서 직접 구현하셨나요?
A.
사용자 입장에서 종목 예측만으로는 불안하기 때문에, **정성적 정보(뉴스)**를 함께 제공하면 신뢰도가 높아집니다. 그래서 뉴스 크롤링을 서버에서 수행하고, 롤링 배너로 제공합니다.
또한 이는 주가 예측의 context로도 활용할 수 있어 미래 확장성까지 고려한 설계였습니다.
Q5. 왜 Chart.js로 시각화했나요?
A.
Chart.js는 클라이언트에서 렌더링하는 가벼운 라이브러리이며, Django의 템플릿 엔진과도 잘 연동됩니다.
백엔드에서 JSON 형태로 가공한 주가 데이터를 템플릿에 전달하고, 프론트에서 Chart.js로 시각화하여 성능 이슈 없이 처리할 수 있었습니다.
Q6. 왜 LSTM을 사용했나요? → (AI 질문으로 넘어오면 간결하게)
A.
AI가 목적이 아니라 예측 기반 로직을 API화하고 서비스화하는 것이 목적이었습니다.
그 중 시계열 예측에 적합한 LSTM을 선택했고, 실제 전략은 단순 예측보다는 조건 기반 자동매매로 연결되기 때문에 모델 자체보다 모델을 어떻게 서비스에 통합했는지가 핵심이었습니다.
Q7. 지금 한다면 백엔드 구조에서 어떤 걸 개선하고 싶나요?
A.
- subprocess → Celery + Redis 구조로 변경해 분산 처리 및 로그 추적 개선
- Django 단일 서버 → FastAPI + 추론 서버 분리(MSA화)
- API 연동은 증권사 오픈 API로 교체하거나, Kafka를 이용한 실시간 스트리밍 기반 분석 구조 도입
✅ 정리 – 백엔드 면접 핵심 요약
면접 포인트 설명
| 왜 Django? | 빠른 서비스 구축 + 내장 기능 풍부 (ORM, Admin 등) |
| 왜 subprocess? | 장시간 실행 로직 분리 → 안정성과 유연성 확보 |
| 어디에 집중했나? | API 신뢰성, 사용자 예외처리, 서버 분리 설계 |
| AI 모델은 부가적 수단 | 주가 예측이 아닌 백엔드 구조 설계와 안정성 중심 |