1차 면접 기술·인성 대비

자기소개
1. 안녕하십니까, SW공통 미사일시스템 연구소에 지원한 김예진입니다.
  
  저는 백엔드 개발과 인프라 구축을 함께 해온 개발자입니다. K-POP 팬을 위한 실시간 영상 공동 시청 플랫폼 DuckOn을 기획부터 운영까지 주도하며, 결과적으로 10개국 MAU 1,000명의 서비스로 성장시켰고, 지금도 10개월째 팀원들과 함께 운영을 이어가고 있습니다.
  
  기능을 만드는 데 그치지 않고, 보안 취약점을 직접 발견해 팀 전체가 이해할 수 있도록 문서화하고 함께 개선하는 경험도 쌓았습니다. 코드가 실제로 동작하고 운영되는 환경에서 책임감을 갖고 문제를 해결해온 개발자라고 자신 있게 말씀드릴 수 있습니다.
  
  오늘 면접을 통해 그 경험을 잘 전달드리겠습니다. 잘 부탁드립니다.
지원동기

천궁-II가 UAE·사우디·이라크 중동 3개국에 잇따라 수출되며 ‘K-방공망 벨트’를 완성하고, 사우디 계약은 단일 무기체계 수출로 역대급 규모(약 4.3조 원)를 기록했다는 뉴스를 인상 깊게 봤습니다. 대한민국 유도무기가 세계 시장에서 신뢰받는 순간이었고, 그 시스템의 SW가 LIG D&A에서 개발된다는 사실이 이 회사에 반드시 합류하고 싶다는 확신으로 이어졌습니다.

Lig d&a에 지원한 이유는 국내 방산업계에서 유일하게 유도무기 체계 전체를 통합하는 기업이기 때문입니다. 무기체계의 두뇌에 해당하는 소프트웨어 전체를 개발하는 기업입니다. 개발자로서 내가 만든 코드가 시스템 전체의 흐름 안에서 어떤 역할을 하는지 완전히 이해하며 일할 수 있는 환경이라고 생각했습니다.

또한 LIG D&A는 지금 단순한 방산 기업을 넘어 변화하는 중입니다. 미국 군용 로봇 기업 Ghost Robotics 인수로 무인화·로봇 분야에 발을 뻗었고, 정지궤도 위성 본체개발 사업 수주로 우주 분야까지 확장하고 있습니다. 창립 50주년을 맞아 Defense와 Aerospace 두 축으로 선언한 사명 변경이 단순한 리브랜딩이 아니라 실질적인 사업 확장의 방향이라는 점에 의해 지원하게되었습니다.

면접 팁 몇 가지:

“왜 방산이에요?” → 실시간 신뢰성 + 코드의 무게

“왜 LIG D&A예요?” → 체계 통합 기업 + 사명 변경(우주·로봇 확장) + 천궁-II 중동 수출 성과

“AI에 대해 어떻게 생각해요?” → 보고서에 인공지능·유무인협업이 핵심 R&D로 명시됐다고 언급하면 공부 잘 했다는 인상 줄 수 있어

웹소켓 기반 실시간 통신 구조 설계시 수백명이 동시 접속하는 환경에서 안정성을 유지하기 위해 고민했다고 하셨는데, 어떤 고민을 하셨나요?

답변

“WebSocket 연결은 HTTP와 달리 연결이 유지되는 구조라 동시 접속자가 늘어날수록 스레드 자원 고갈 문제가 생길 수 있습니다. 그래서 Spring의 기본 스레드풀 설정에 의존하지 않고, WebSocket 메시지 처리를 위한 스레드풀 크기를 서버 사양에 맞게 조정했습니다. 부하 테스트를 통해 방마다 100명 동시 접속까지는 안정적으로 커버된다는 것을 확인했고, 그 결과를 기반으로 현재 서비스 규모에 적합한 설정값을 유지하고 있습니다.”

꼬리질문 대비 필수 암기

면접관이 “몇 개로 설정하셨어요?” 물으면:

“서버 CPU 코어 수를 기준으로 설정했고, I/O 바운드 작업 특성상 코어 수보다 여유 있게 잡았습니다. 다만 정확한 수치는 부하 테스트 결과를 보면서 조정했기 때문에 지금 당장 정확한 숫자를 말씀드리기는 어렵습니다.”

면접관이 “어떤 설정을 건드리셨어요?” 물으면:

“Spring WebSocket에서 setTaskExecutor를 통해 ThreadPoolTaskExecutor를 커스텀하게 설정했습니다.”

5. XSS 위험을 어떻게 판단했고 왜 HttpOnly Cookie로 변경했나요?

“코드 리뷰 중에 refreshToken이 JSON body로 응답되어 프론트엔드에서 localStorage에 저장되고 있다는 걸 발견했습니다. refreshToken은 accessToken보다 생명주기가 훨씬 길기 때문에, 만약 XSS 공격으로 스크립트가 주입된다면 localStorage에 접근해 탈취될 수 있고 장기간 세션이 유지된다는 점에서 위험하다고 판단했습니다. HttpOnly Cookie는 JavaScript에서 접근 자체가 불가능하기 때문에 XSS로 탈취할 수 없고, 추가로 Redis 블랙리스트를 함께 구축해서 탈취된 토큰이 있더라도 서버 측에서 즉시 무효화할 수 있는 구조를 만들었습니다.”

꼬리질문 대비:

“CSRF 공격은요? Cookie로 바꾸면 CSRF 위험이 생기지 않나요?”

“맞습니다. Cookie 방식은 CSRF 공격에 노출될 수 있어서, SameSite 속성을 설정해 다른 도메인에서의 요청에는 Cookie가 전송되지 않도록 처리했습니다.”

6. B+ Tree 구현 중 어려움

B+ Tree 구현 상세 답변(안 A~D + 꼬리질문)은 「B+ Tree 구현 & 포인터 정리」 문서에 모아두었음(중복 제거). 면접에서는 안 B(children[size] 이중 역할) + 꼬리질문 대비가 가장 탄탄함.

1. 로열티 - 민수 vs 방산 차이

“민간 서비스는 장애가 나면 사용자가 불편합니다. 하지만 방산 SW는 장애가 곧 임무 실패이고 국가 안보와 직결됩니다. DuckOn을 운영하며 실시간 시스템의 신뢰성이 얼마나 중요한지 체감했지만, 그 기준이 완전히 다른 환경에서 더 높은 책임감을 갖고 일하고 싶다고 생각했습니다.”

2. 방산 선택 이유

“단순히 안정적인 직장을 찾은 게 아닙니다. 제가 만든 코드가 실제 국가 방위에 기여할 수 있는 환경에서 일하고 싶었습니다. 개발자로서 내 코드의 무게가 가장 크게 느껴지는 곳이 방산이라고 생각했고, 그 환경에서 성장하고 싶어서 선택했습니다.”

3. LIG D&A 선택 이유

“천궁-II가 중동 3개국 수출로 K-방공망 벨트를 완성하며 국산 유도무기의 경쟁력을 세계에 입증했고, 그 시스템 안에 LIG D&A의 SW가 있다는 사실이 결정적이었습니다. 창립 50주년을 맞아 Defense와 Aerospace 두 축으로 도약하는 지금, 이 성장의 흐름에 함께하고 싶습니다.”

4. 워라벨 관련

“업무 강도나 출장에 대해서는 입사 전부터 어느 정도 인지하고 있습니다. 방산이라는 도메인 특성상 프로젝트 일정이나 현장 지원이 필요한 상황이 있다는 걸 이해하고 있고, 그 부분을 감수하고 지원했습니다. 오히려 현장에서 실제 시스템이 운용되는 환경을 직접 경험할 수 있다면 개발자로서 더 빠르게 성장할 수 있다고 생각합니다.”

5. AI에 대해 어떻게 생각하나

“AI는 도구라고 생각합니다. DuckOn에서 OpenAI API를 연동해 실시간 번역 기능을 구현했는데, 그 과정에서 AI가 모든 걸 해결해주는 게 아니라 비용 설계, 실패 처리, 오류 전파 구조까지 개발자가 함께 설계해야 한다는 걸 배웠습니다. 방산 도메인에서는 AI의 신뢰성 검증이 특히 중요하다고 생각하고, AI를 맹목적으로 신뢰하기보다 검증하며 활용하는 자세가 필요하다고 봅니다.”

6. AI 어떻게 활용하고 있나

“개발할 때 코드 리뷰나 트러블슈팅 보조 도구로 활용합니다. 다만 AI가 제안한 코드를 그냥 쓰지 않고, 반드시 원리를 이해하고 검증한 뒤에 적용하는 방식으로 씁니다. 코드의 의도를 모르면 장애가 났을 때 원인을 찾을 수 없기 때문입니다.”

7. CS 질문 - 네트워크 / OS / DB / 알고리즘

각각 한 줄 핵심 답변 준비해야 하는데, 어느 부분이 약하다고 느껴? 전부 다 만들어줄 수도 있는데 범위가 넓으니까 특히 걱정되는 파트 있으면 말해줘. 우선 자주 나오는 것들 먼저 줄게.

네트워크

“TCP와 UDP의 차이는 신뢰성과 속도의 트레이드오프입니다. TCP는 연결 지향으로 순서 보장과 재전송을 통해 신뢰성을 확보하고, UDP는 연결 없이 빠르게 전송합니다. DuckOn에서 WebSocket은 TCP 기반으로 동작해 실시간 채팅의 메시지 순서와 전달을 보장했습니다.”

“프로세스와 스레드의 차이는 메모리 공유 여부입니다. 프로세스는 독립적인 메모리 공간을 가지고, 스레드는 같은 프로세스 내에서 메모리를 공유합니다. 스레드는 컨텍스트 스위칭 비용이 낮지만 공유 자원에 대한 동기화가 필요합니다.”

“인덱스는 검색 속도를 높이는 대신 쓰기 성능과 저장 공간을 희생합니다. B+ Tree 구조로 구현되어 있어 범위 탐색에 유리하고, 이번에 B+ Tree를 직접 구현하며 Leaf 노드 연결 리스트를 통한 Range Search 원리를 코드 레벨에서 이해했습니다.”

알고리즘

“시간복잡도와 공간복잡도 트레이드오프를 항상 고려합니다. 백준 플래티넘 티어를 유지하며 다양한 최적화 문제를 풀어왔고, 실제 프로젝트에서도 N+1 문제를 발견해 DTO 매핑으로 쿼리를 최적화한 경험이 있습니다.”

8. 밸런스 게임

넓고 얕게 vs 좁고 깊게

“저는 좁고 깊게를 선택합니다. 한 영역을 깊이 파고들어야 문제가 생겼을 때 원인을 찾을 수 있다고 생각합니다. 다만 협업하려면 다른 영역도 어느 정도 알아야 한다고 생각해서, DuckOn에서 매주 기술 공유 시간을 만들어 팀 전체의 이해도를 함께 높였습니다.”

상사랑 의견 충돌이 난다면

“먼저 제 의견의 근거를 데이터와 기술적 근거로 정리해 공유합니다. DuckOn에서 JWT 보안 취약점을 발견했을 때도 일방적으로 수정을 요청하지 않고 문제점과 해결 방안을 문서로 만들어 팀에 공유했습니다. 그래도 의견이 받아들여지지 않는다면, 더 넓은 맥락에서 상사가 판단한 이유가 있을 거라 생각하고 따르되 결과를 함께 모니터링하겠습니다.”

9. 같이 일하고 싶은 동료 / 싫은 동료

같이 일하고 싶은 동료

“모르는 것을 모른다고 말할 수 있는 동료입니다. 팀 전체가 서로의 약점을 솔직하게 공유할 때 더 빠르게 문제를 해결할 수 있다고 생각합니다.”

같이 일하기 싫은 동료

“소통 없이 혼자 진행하는 동료입니다. 방산 SW처럼 신뢰성이 중요한 환경일수록 작은 변경사항도 팀과 공유해야 한다고 생각합니다. 혼자 결정하고 나중에 공유하는 방식은 팀 전체의 리스크가 됩니다.”

N+1 문제가 뭔지부터

예시로 설명할게. MemeDuck에서 “밈 목록을 불러올 때 각 밈의 업로더 정보도 같이 가져오는 상황” 이라고 해보자.

N+1 문제 발생하는 코드:

// 1번 쿼리: 밈 목록 전체 조회
List<Meme> memes = memeRepository.findAll();  // SELECT * FROM meme

// N번 쿼리: 각 밈마다 유저 정보 따로 조회
for (Meme meme : memes) {
    User user = meme.getUser();  // SELECT * FROM user WHERE id = ?
    // 밈이 100개면 이 쿼리가 100번 실행됨
}

밈이 100개면?
  1번 (전체 조회) + 100번 (각 유저 조회) = 101번 쿼리
  → 이게 N+1 문제

DTO 매핑으로 해결이 뭔지

해결한 코드:

// JOIN으로 한 번에 다 가져옴
@Query("SELECT new com.memeduck.dto.MemeDto(m.id, m.title, u.nickname)
        FROM Meme m JOIN m.user u")
List<MemeDto> findAllWithUser();

결과: 쿼리 1번으로 끝
  밈 100개든 1000개든 항상 1번만 실행

DTO가 뭐냐면:

// 필요한 데이터만 담는 그릇
public class MemeDto {
    private Long id;
    private String title;
    private String nickname;  // 유저 정보 포함
}

Entity 전체를 불러오지 않고, 필요한 필드만 쏙 뽑아서 한 번에 가져오는 거야.

왜 “단순 DTO 매핑”이라고 표현했냐

Lazy Loading, Fetch Join, Batch Size 등 다양한 해결책이 있는데 그중에서 제일 심플한 방법인 JPQL + DTO 직접 매핑 방식을 썼다는 거야. 복잡한 설정 없이 쿼리 한 줄로 해결한 거라 “단순”이라고 표현한 것.

꼬리질문 + 답변 전체 정리

Q1. N+1 문제를 어떻게 발견했나요?

“MemeDuck 개발 중 밈 목록을 불러올 때 로딩이 느리다는 걸 체감했습니다. 로그를 확인해보니 밈 개수만큼 유저 조회 쿼리가 반복 실행되고 있었고, 이게 N+1 문제라는 걸 파악했습니다.”

Q2. 다른 해결 방법도 있는데 왜 DTO 매핑 방식을 선택했나요?

“Fetch Join이나 Batch Size 설정 같은 방법도 고려했는데, 해당 기능에서 필요한 필드가 명확하게 정해져 있었습니다. Entity 전체를 불러올 필요 없이 필요한 데이터만 JPQL로 직접 뽑는 DTO 매핑이 가장 단순하고 명확한 방법이라 판단했습니다.”

Q3. 개선 전후 성능 차이가 얼마나 났나요?

솔직하게 답변해:

“정확한 수치를 측정하진 않았지만, 데이터가 많을수록 쿼리 횟수가 선형으로 증가하던 구조를 단일 쿼리로 바꿨기 때문에 데이터가 늘어날수록 효과가 커지는 구조가 됐습니다.”

Q4. Fetch Join이랑 DTO 매핑의 차이가 뭔가요?

“Fetch Join은 연관된 Entity 전체를 JOIN해서 가져오는 방식이라 필요 없는 컬럼까지 조회됩니다. DTO 매핑은 필요한 필드만 선택해서 가져오기 때문에 네트워크 비용과 메모리 사용량이 더 적습니다. 조회 목적이 명확한 경우엔 DTO 매핑이 더 효율적이라고 생각했습니다.”

Q5. JPA를 쓰면 N+1이 자주 발생하나요?

“JPA의 기본 로딩 전략이 Lazy Loading이라 연관 관계를 실제로 사용할 때 추가 쿼리가 발생하는 구조입니다. 그래서 연관 데이터를 한 번에 조회하는 경우엔 의식적으로 N+1이 발생하지 않는지 확인하는 습관이 필요하다고 느꼈습니다.”

한 줄 요약 (외워두기)

“밈 목록 조회 시 각 밈마다 유저 쿼리가 따로 나가는 N+1 문제를 발견했고, JPQL로 필요한 필드만 DTO에 직접 매핑해 쿼리 1번으로 줄였습니다.”

이거 하나 입에 붙여두면 꼬리질문 다 막을 수 있어!

Q. 업무에서 AI를 어떻게 활용해봤나요? 방산에서는 어떻게 쓸 수 있을 것 같나요?

“개발할 때 AI 코딩 도구를 실제로 써보면서, 단순히 좋은 질문을 던지는 것보다 AI가 좋은 답을 낼 수 있는 환경 자체를 설계하는 게 중요하다는 걸 체감했습니다. 최근 이 개념이 하네스 엔지니어링이라는 이름으로 정리되고 있는데, 모델 외에 AI가 작동하는 모든 환경을 설계하는 것을 말합니다.

방산에서도 이 개념이 특히 중요할 것 같습니다. 현직자 인터뷰에서 테스트 환경에서 측정되는 수만 개의 데이터를 기록하고 분석하는 데 AI를 활용할 수 있다는 얘기를 봤는데, 실제로 KF-21 시험비행 빅데이터를 활용한 상태기반정비 AI 연구처럼 무기체계 시험 데이터를 AI로 분석하는 흐름이 이미 진행 중입니다.

다만 방산 데이터는 품질이 불균일하고 레이블 기준도 제각각일 수 있어서, AI에 데이터를 그냥 넣는 것만으로는 신뢰할 수 있는 결과가 안 나옵니다. 데이터 전처리 구조, 제약 조건 설계, 피드백 루프를 어떻게 만드느냐가 결과의 품질을 좌우한다고 생각합니다. 저도 입사 후 그 부분에 기여하고 싶습니다.”

5. 핵심 용어 정리 (면접 중 자연스럽게 쓸 수 있도록)

용어	한 줄 설명
하네스 엔지니어링	AI 모델 외 환경 전체를 설계하는 것. Agent = Model + Harness
CBM+ (상태기반정비)	센서 데이터로 고장을 사전에 예측하는 AI 기반 정비 방식
Guides	AI가 행동 전 방향을 잡아주는 피드포워드 제어
Sensors	AI가 행동 후 스스로 교정하도록 신호를 주는 피드백 제어
PHM	건전성 예측 관리(Prognostics and Health Management). 방산 IPS 분야 핵심 개념

마지막 하고싶은말

A안 — DuckOn 운영 경험으로 마무리

저는 만들고 끝내는 개발자가 아니라, 운영하면서 계속 개선해온 개발자입니다. DuckOn을 수료 후에도 팀원들을 설득해 9개월째 이어오며 보안 취약점을 직접 발견하고, 인프라를 고도화하고, 사용자 피드백을 기술로 해결했습니다. 방산 SW도 결국 운영이 끝이 아니라 시작이라는 점에서, 이 태도가 미사일시스템 연구소에서도 실질적인 기여로 이어질 수 있다고 생각합니다. 오늘 면접 기회를 주셔서 감사합니다.

B안 — 팔란티어 MOU + 미래 방향성 강조

저는 LIG D&A가 천궁-II 중동 수출 성공에 이어, 미국 Ghost Robotics 인수(무인·로봇)와 천리안위성 5호 등 정지궤도 위성 개발(우주)로 Defense와 Aerospace를 결합하는 방향으로 나아가고 있다는 점을 인상 깊게 봤습니다. 저는 백엔드와 인프라를 함께 다뤄온 개발자로서, 그 전환의 흐름 안에서 성장하고 싶습니다. 빠르게 방산 도메인을 체득하고, 팀에 즉각 기여할 수 있는 개발자가 되겠습니다. 오늘 기회를 주셔서 감사합니다.

※ 참고: ‘팔란티어 AI 협력 MOU’는 일부 검색 요약에만 보이고 공식 확인이 안 된 정보라 마지막 멘트에서 제외했음. 굳이 쓰려면 “보도된 바로는…”처럼 단정하지 말 것.

C안 — 간결하고 담백하게

저는 코드가 실제로 운용되는 환경에서 책임감을 갖고 개선해온 개발자입니다. DuckOn 9개월 운영이 그 증거입니다. 방산 SW는 그 책임의 무게가 훨씬 크다는 것을 알고 있고, 그 기준에 맞는 개발자로 성장하고 싶어서 이 자리에 섰습니다. 반드시 함께 일하고 싶은 개발자임을 증명하겠습니다. 감사합니다.