시니어 개발자는 코드만 잘 짜는 게 아닙니다. 설계 의사결정, 팀 리딩, 기술 방향 제시까지 할 수 있어야 합니다.

시리즈 구성:

  • 1편: 인프라/스케일링 - 트래픽, DB, 분산시스템
  • 2편: 운영/안정성 - 장애대응, 이벤트 아키텍처, 배포
  • 3편 (현재): 설계/리더십 - 의사결정, 시스템디자인, 코드리뷰

1. 설계 의사결정

Q1. 새로운 기술을 도입할 때 어떤 기준으로 판단하시나요?

기대 답변:

  • 문제 해결: 현재 기술로 해결 안 되는 명확한 문제가 있는가?
  • 팀 역량: 학습 곡선과 유지보수 가능성
  • 생태계 성숙도: 커뮤니티, 문서, 안정성
  • 운영 비용: 인프라 비용, 모니터링 도구 지원

🔄 꼬리질문 1: 기술 부채(Technical Debt)는 어떻게 관리하시나요?

기대 답변:

  • 스프린트마다 일정 비율 할당 (예: 20%)
  • 영향도와 긴급도 매트릭스로 우선순위
  • 리팩토링 전 테스트 커버리지 확보
  • 큰 부채는 별도 프로젝트로 계획

🔄 꼬리질문 2: 아키텍처 의사결정 기록(ADR)을 작성해보신 적 있나요?

기대 답변:

  • Context: 배경과 제약사항
  • Decision: 선택한 방안
  • Consequences: 예상되는 장단점
  • 팀 내 공유와 온보딩에 활용. 나중에 “왜 이렇게 했지?” 방지.

🔄 꼬리질문 3: 기술 선택에서 실패한 경험이 있다면?

이 질문의 의도: 완벽한 결정만 있는 건 아닙니다. 실패 경험에서 무엇을 배웠는지, 어떻게 수정했는지가 더 중요합니다.

2. 시스템 디자인

Q2. URL 단축 서비스를 설계해주세요.

기대 답변:

  • 요구사항 확인: 일일 요청 수, 저장 기간, 읽기/쓰기 비율
  • 단축 알고리즘: Base62 인코딩, Hash + 충돌 처리
  • 저장소: 키-값 구조, Redis(캐시) + DB(영구)
  • 확장성: 샤딩(short key prefix 기준), Read Replica

🔄 꼬리질문 1: Short URL 충돌은 어떻게 처리하나요?

기대 답변:

  • Hash 충돌: 다른 suffix 추가 후 재시도
  • Unique ID 기반: Snowflake, UUID 사용
  • DB Unique Constraint: 삽입 실패 시 재생성

🔄 꼬리질문 2: 초당 10만 요청이 들어온다면?

기대 답변:

  • 캐싱: 인기 URL은 Redis에 캐시
  • Read Replica: 읽기 분산
  • CDN: 리다이렉트 응답 캐싱
  • 로드밸런서: 요청 분산

🔄 꼬리질문 3: 악성 URL 차단은 어떻게 하시겠어요?

기대 답변:

  • 생성 시 검사: Google Safe Browsing API
  • 신고 기능: 사용자 리포트
  • 주기적 스캔: 비동기 배치로 검사
  • Rate Limiting: 대량 생성 방지

3. 코드 리뷰와 품질

Q3. 코드 리뷰할 때 어떤 점을 중점적으로 보시나요?

기대 답변:

  • 의도 파악: 왜 이렇게 작성했는지 이해
  • 버그 가능성: 경계 조건, null 처리, 동시성
  • 가독성: 네이밍, 구조, 복잡도
  • 테스트: 충분한 커버리지, 엣지 케이스
  • 설계: 책임 분리, 확장성

🔄 꼬리질문 1: 리뷰에서 의견 충돌이 있으면 어떻게 하시나요?

기대 답변:

  • 먼저 상대 의견을 충분히 이해
  • 객관적 근거(성능, 가독성, 유지보수)로 토론
  • 합의 안 되면 팀 컨벤션 또는 테크 리드 판단 요청
  • “나중에 개선하자”로 타협하기보다 지금 결정

🔄 꼬리질문 2: 주니어 코드를 리뷰할 때 특별히 신경 쓰는 점은?

기대 답변:

  • 교육적 피드백: “이건 틀렸어” 대신 “이렇게 하면 더 나아요 + 이유”
  • 칭찬 먼저: 좋은 점 언급 후 개선점 제시
  • 질문 형태: “이건 왜 이렇게 했어요?”로 생각 유도
  • 너무 많은 지적 피하기: 핵심 2-3개에 집중

🔄 꼬리질문 3: 코드 리뷰 없이 머지된 코드에서 버그가 발견되면?

기대 답변:

  • 먼저 버그 수정 (blame 아닌 해결 우선)
  • 프로세스 점검: 왜 리뷰 없이 머지됐는지
  • 자동화: CI에 필수 리뷰어, 테스트 통과 조건 추가
  • 팀 회고: 재발 방지 논의

4. 팀 리딩과 멘토링

Q4. 주니어 개발자 멘토링은 어떻게 하시나요?

기대 답변:

  • 1:1 미팅: 주 1회, 업무 외 고민도 공유
  • 페어 프로그래밍: 복잡한 작업은 함께
  • 점진적 위임: 작은 기능 → 큰 기능 → 설계 참여
  • 심리적 안전감: 질문해도 괜찮다는 분위기

🔄 꼬리질문 1: 팀원이 계속 같은 실수를 반복하면?

기대 답변:

  • 먼저 근본 원인 파악 (지식 부족? 집중력? 프로세스 문제?)
  • 체크리스트나 자동화로 실수 방지
  • 1:1에서 솔직하게 피드백
  • 개선 계획 함께 수립

🔄 꼬리질문 2: 팀 내 기술 공유는 어떻게 하시나요?

기대 답변:

  • 주간 기술 공유: 15-30분 발표
  • Wiki/Notion 문서화: 팀 지식 축적
  • 스터디 그룹: 관심 주제별 소그룹
  • 장애 리뷰 공유: 실수에서 배우기

🔄 꼬리질문 3: 본인이 가장 성장했던 경험은?

이 질문의 의도: 성장 마인드셋이 있는지, 자신의 성장을 돌아볼 줄 아는지 확인합니다. 겸손함과 자기 인식 능력을 봅니다.

5. 협업과 커뮤니케이션

Q5. 기획/디자인 팀과 의견 충돌이 있을 때 어떻게 하시나요?

기대 답변:

  • 경청: 상대 의도와 배경 이해
  • 데이터 기반: 기술적 제약, 비용, 일정을 구체적으로 설명
  • 대안 제시: “안 돼요” 대신 “이렇게 하면 가능해요”
  • 문서화: 결정 사항과 이유 기록

🔄 꼬리질문 1: 일정이 부족한데 기능 추가 요청이 들어오면?

기대 답변:

  • 현재 상황 투명하게 공유 (남은 일정, 리스크)
  • Trade-off 제시: “이걸 하려면 저건 다음 스프린트로”
  • 우선순위 재조정 요청
  • 무리한 약속 안 하기 (야근으로 해결 X)

🔄 꼬리질문 2: 원격 근무에서 협업 잘 하는 팁은?

기대 답변:

  • 비동기 소통: 문서화 철저히, 컨텍스트 충분히 공유
  • 오버 커뮤니케이션: 진행 상황 수시로 공유
  • 화상 미팅: 복잡한 논의는 텍스트보다 얼굴 보고
  • 명확한 기대치: 응답 시간, 회의 시간대 합의

🔄 꼬리질문 3: 기술 결정을 비개발자에게 설명할 때 어떻게 하시나요?

기대 답변:

  • 비유 활용: 기술 용어 대신 일상적 비유
  • 영향 중심: “이게 뭔지”보다 “이게 왜 중요한지”
  • 시각 자료: 다이어그램, 간단한 도식
  • 질문 유도: 이해했는지 확인

마무리: 시니어에게 기대하는 것

  1. Trade-off 사고: “정답”보다 “상황에 맞는 선택”
  2. 실패 경험: 장애 대응, 잘못된 설계 경험에서 배운 점
  3. 설명 능력: 복잡한 개념을 쉽게 풀어서 설명
  4. 오너십: 문제를 끝까지 해결하려는 태도
  5. 성장 마인드셋: 모르는 건 인정하고 배우려는 자세

면접에서 모든 질문에 완벽하게 대답할 필요 없습니다. 생각하는 과정과 경험에서 우러나온 인사이트가 더 중요합니다.

시리즈 전체 정리

편 주제 핵심 키워드
1편 인프라/스케일링 트래픽, 캐싱, 샤딩, 분산락, CAP
2편 운영/안정성 서킷브레이커, Kafka, 배포, 모니터링
3편 설계/리더십 ADR, 시스템디자인, 코드리뷰, 멘토링

이 세 가지를 균형 있게 갖춘 개발자가 진짜 시니어입니다.