(5/5) 데이터·AI 플랫폼 면접 — S3 레이크부터 Bedrock 까지, 그리고 60분 진행 시나리오
🧭 AWS 전문가 면접 가이드 — 면접관을 위한 배경 지식과 질문 5부작 — “AWS 시니어를 뽑아야 하는데 정작 내가 AWS 를 잘 모른다.” 꽤 흔한 상황이에요. 서비스 이름을 200 개 외운다고 면접이 되는 것도 아니고요. 이 시리즈는 면접관 입장에서 필요한 것만 골라 담았습니다. 각 편은 ① 5분이면 따라오는 배경 설명 → ② 실제로 던질 질문 → ③ 답을 못 알아들어도 쓸 수 있는 채점 포인트 순서로 이어져요. 전체 그림과 면접 전략을 먼저 잡고(1편), 인프라·아키텍트(2편), DevOps·플랫폼(3편), 보안·거버넌스와 금융권 규제(4편), 데이터·AI 플랫폼과 60분 진행 시나리오(5편)까지 갑니다. 전체 5편.
- 뭘 물어야 하나 — 전체 그림과 면접 전략
- 클라우드 인프라·아키텍트 — VPC 부터 비용까지
- DevOps·플랫폼 엔지니어 — IaC, CI/CD, EKS 운영
- 보안·거버넌스 — IAM 부터 금융권 규제까지
- 데이터·AI 플랫폼 + 60분 면접 진행 시나리오 ← 지금 글
Summary
마지막 편이에요. 앞의 세 갈래가 “시스템이 돌아가게 하는 사람” 이었다면, 데이터·AI 플랫폼은 “데이터가 흐르게 하는 사람” 입니다. 요즘은 여기에 LLM 서빙까지 얹히면서 범위가 빠르게 넓어지고 있어요.
이 갈래에서 면접관이 가장 헷갈리는 게 하나 있어요. 후보자들이 도구 이름을 아주 많이 댑니다. 그런데 도구를 아는 것과 파이프라인을 새벽에 다시 돌려본 것은 완전히 다른 일이에요. 그래서 이 편의 질문들은 대부분 “실패했을 때 어떻게 하냐” 를 향합니다.
그리고 이 글 뒤쪽에 시리즈를 마무리하는 실전 도구를 붙였어요. 60분 면접 진행표, 다섯 축 채점표, 레드 플래그 종합입니다. 시간이 없으면 1편과 이 글의 뒷부분만 들고 들어가셔도 면접은 굴러갑니다.
💡 이 글에서 다루는 것
- 데이터가 흐르는 길 — 수집·저장·가공·분석 4단계
- S3 데이터 레이크 — 파티셔닝과 파일 포맷이 왜 곧 돈인가
- 파이프라인 운영의 현실 — 재처리, 멱등성, 스키마 변경
- Bedrock 과 RAG — LLM 을 실제로 운영한다는 것
- 질문 10개 + 채점 포인트
- 60분 면접 진행 시나리오와 시간 배분표
- 다섯 축 채점표와 레드 플래그 종합
1. 배경 — 데이터가 흐르는 길
데이터 플랫폼은 결국 네 단계예요. 이 순서만 잡으면 후보자 설명을 따라갈 수 있습니다.
| 단계 | 하는 일 | 대표 도구 |
|---|---|---|
| 수집 | 여기저기서 데이터를 끌어오기 |
Kinesis, MSK, DMS, 배치 잡 |
| 저장 | 원본 그대로 쌓아두기 |
S3 |
| 가공 | 쓸 수 있는 모양으로 정리 |
Glue, EMR, Airflow |
| 분석 · 서빙 | 질문에 답하기 | Athena, Redshift, Bedrock |
왜 다들 S3 에 쌓나요
싸고, 사실상 무한하고, 안 망가지기 때문이에요. 그래서 “일단 원본은 S3 에 다 넣어두고, 필요할 때 가공한다” 가 요즘 기본 전략입니다. 이걸 데이터 레이크(호수)라고 불러요.
이 말은 자주 나오니 구분해두면 좋아요.
| 용어 | 뜻 | 성격 |
|---|---|---|
| 데이터 레이크 | 원본을 그대로 쌓아둔 곳 |
유연함. 정리 안 하면 늪이 됨 |
| 데이터 웨어하우스 | 분석용으로 정돈된 데이터베이스 |
빠름. 미리 설계 필요 |
💡 실무자들이 자조적으로 쓰는 말이 있어요. “관리 안 한 데이터 레이크는 데이터 늪(swamp)이 된다.” 후보자가 이런 표현을 쓰면 실제로 방치된 레이크를 수습해본 사람일 확률이 높습니다.
파티셔닝과 파일 포맷 — 여기가 곧 돈이에요
이게 이 갈래 면접의 핵심 개념이라 조금만 자세히 볼게요.
S3 에 SQL 을 던지는 서비스(Athena)는 읽은(스캔한) 데이터 양만큼 돈을 받아요. 그래서 같은 질문이라도 데이터를 어떻게 저장해뒀느냐에 따라 비용이 수십 배 차이 납니다.
두 가지 장치가 있어요.
- 파티셔닝 — 날짜 같은 기준으로 폴더를 나눠 저장하는 것. “3월 데이터만 보자” 는 질문이 3월 폴더만 읽게 됩니다.
- 컬럼 형식 파일(Parquet 등) — 필요한 열만 골라 읽을 수 있는 저장 형식. 열 100개 중 3개만 쓰면 3개만 읽어요.
이 둘을 안 하면 매번 전체 데이터를 다 읽습니다. 그래서 이 질문이 강력해요.
“같은 쿼리 비용을 줄여본 경험이 있나요? 뭘 바꾸셨어요?”
경험자는 파티셔닝이나 파일 포맷 이야기를 바로 합니다. 그리고 “작은 파일이 너무 많아서 느렸다” 는 이야기가 나오면 확실해요. 이건 겪어보지 않으면 모르는 문제거든요.
2. 배경 — 파이프라인 운영의 현실
파이프라인은 만드는 것보다 다시 돌리는 게 어려워요. 면접에서 봐야 할 건 이 세 가지입니다.
실패했을 때 어떻게 되나
데이터 파이프라인은 반드시 실패해요. 원본 시스템이 늦게 주거나, 형식이 갑자기 바뀌거나, 자원이 모자라거나. 그래서 실패를 전제로 설계했는지를 봅니다.
여기서 나오는 단어가 멱등성이에요. 어려운 말 같지만 뜻은 단순해요. 같은 작업을 두 번 돌려도 결과가 같은 것. 이게 안 되어 있으면 재실행할 때마다 데이터가 중복되고, 그러면 아무도 감히 다시 돌리질 못합니다.
💡 “실패한 작업을 다시 돌리면 데이터가 중복되나요?” — 이 질문 하나로 파이프라인 설계 수준이 드러나요. 잘 만든 팀은 “덮어쓰기 방식이라 몇 번을 돌려도 같습니다” 라고 답합니다.
스키마가 바뀌면
원본 시스템에서 컬럼 하나가 추가되거나 타입이 바뀌면 파이프라인이 깨져요. 이건 기술 문제라기보다 조직 문제예요. 데이터를 주는 팀과 받는 팀 사이의 약속 문제거든요.
그래서 이 질문의 좋은 답에는 협업 이야기가 섞입니다. “변경이 있으면 미리 알려달라고 합의했어요” 나 “그래도 통보 없이 바뀌는 경우가 있어서 자동 감지를 걸었어요” 같은.
백필 — 과거 데이터를 다시 채우는 일
로직이 잘못돼서 지난 3개월 데이터를 다시 계산해야 하는 상황이요. 데이터 엔지니어에게 가장 아픈 작업이고, 그래서 좋은 면접 질문이에요. 해본 사람은 “며칠 걸렸다”, “비용이 얼마 나왔다”, “그 후로 백필하기 쉽게 구조를 바꿨다” 같은 이야기를 합니다.
📎 이런 오케스트레이션을 실제로 운영한 기록으로는 블로그의 Airflow 를 EKS·ECR·GitHub Actions 로 굴리기 편이 있어요. 스케줄러와 워커가 어떻게 나뉘는지 보면 후보자 이야기를 따라가기 쉬워집니다.
3. 배경 — 데이터에서 돈이 새는 곳
2편에서 인프라 비용을 다뤘는데, 데이터 쪽은 새는 지점이 달라요.
| 구멍 | 왜 새나 | 대책 |
|---|---|---|
| 쿼리 스캔량 | 파티션·포맷이 없으면 매번 전체를 읽음 |
파티셔닝, 컬럼 형식 |
| 오래된 원본 | 몇 년 치가 비싼 등급에 그대로 |
수명주기 정책으로 저렴한 등급 이동 |
| 상시 켜둔 분석 클러스터 | 밤에도 낮에도 계속 과금 |
사용량 기반 전환, 일시 중지 |
| 작은 파일 폭발 | 파일이 수백만 개면 느리고 비쌈 |
주기적 병합 |
후보자가 수명주기 정책이나 작은 파일 병합을 언급하면 실제로 레이크를 오래 운영한 사람이에요.
4. 배경 — Bedrock 과 LLM 서빙
요즘 이 갈래 채용에는 LLM 이 거의 항상 붙어요. 최소한만 짚을게요.
Bedrock 이 뭐냐면
여러 회사의 LLM 을 AWS 안에서 API 로 호출할 수 있게 해주는 서비스예요. 모델을 직접 서버에 올릴 필요 없이 호출만 하면 되고, 데이터가 AWS 밖으로 나가지 않는다는 점 때문에 규제 산업에서 많이 검토합니다.
RAG — 가장 많이 나올 단어
모델은 우리 회사 문서를 모릅니다. 그래서 질문이 들어오면 관련 문서를 먼저 찾아서 같이 넣어주고 답하게 하는 방식을 씁니다. 이게 RAG 예요. 검색해서(Retrieval) 붙여주고(Augmented) 답하게(Generation) 하는 거죠.
면접에서 볼 포인트는 딱 하나예요. “만들었다” 와 “품질을 측정했다” 는 다릅니다.
RAG 는 데모를 만들기가 아주 쉬워요. 하루면 됩니다. 그런데 실제로 쓸 만하게 만드는 건 완전히 다른 일이고, 그 차이는 평가 체계가 있느냐에서 갈려요.
“그 답변이 좋은지 나쁜지는 어떻게 판단하셨어요?”
이 질문에 “사용자 피드백을 받았다”, “정답 셋을 만들어서 정기적으로 돌렸다”, “검색이 틀렸는지 생성이 틀렸는지를 나눠서 봤다” 같은 답이 나오면 진짜 운영한 사람이에요. “잘 나왔습니다” 로 끝나면 데모까지만 해본 겁니다.
비용과 지연
LLM 은 입력과 출력 글자 수(토큰)에 따라 과금돼요. 그래서 대화가 길어지면 비용이 급격히 늘고, 문서를 많이 붙일수록 비싸집니다. 여기서 나오는 대책이 프롬프트 캐싱이나 모델 라우팅(쉬운 질문은 싼 모델로) 같은 것들이에요.
📎 이 주제들은 블로그에 실제 구축 기록이 있어요. 맥락 유지와 캐싱은 Bedrock 챗봇 맥락 유지 전체 설계, 벡터 검색은 ChromaDB 로 RAG 제대로 쓰기, 비용 관리는 LLM API 비용 추적 — 과금 구조 편을 보시면 후보자와 같은 언어로 대화할 수 있습니다.
5. 질문 10개 + 채점 포인트
Q1. 데이터가 어디서 들어와서 어디로 가는지 설명해 주세요
- 왜 묻나 — 전체 흐름을 갖고 있는지, 그리고 자기가 맡은 조각 밖을 아는지 봅니다.
- 👍 좋은 답 — 원본 시스템부터 최종 사용자까지 순서대로 이어져요. “이 데이터를 실제로 누가 어떻게 쓰는지” 까지 말하면 아주 좋습니다.
- ⚠️ 걸리는 답 — 도구 이름만 나열하고 데이터가 왜 흐르는지는 없어요.
Q2. S3 에 데이터를 어떤 구조로 쌓으셨나요
- 왜 묻나 — 파티셔닝과 파일 포맷 감각을 봅니다. 이게 곧 비용과 성능이에요.
- 👍 좋은 답 — 날짜 기준 파티셔닝, 컬럼 형식 파일, 원본과 가공본을 구역으로 나눈 이야기가 나옵니다.
- ⚠️ 걸리는 답 — “그냥 날짜별 폴더에 CSV 로 넣었습니다” 인데 규모는 크다고 해요.
Q3. 파이프라인이 실패하면 어떻게 되나요? 다시 돌리면 중복되나요?
- 왜 묻나 — 이 편에서 가장 중요한 질문이에요. 실패를 전제로 설계했는지가 여기서 갈립니다.
- 👍 좋은 답 — 재실행해도 결과가 같다고 설명하고, 그 구조를 말해요. 부분 실패 시 어디부터 다시 도는지도 압니다.
- ⚠️ 걸리는 답 — “실패하면 수동으로 확인하고 지운 다음 다시 돌립니다.” 소규모면 가능하지만 시니어 답변으로는 약해요.
Q4. 원본 스키마가 예고 없이 바뀐 적 있나요? 어떻게 대응하셨어요?
- 왜 묻나 — 기술과 협업을 같이 봅니다. 데이터 엔지니어는 남의 팀에 의존하는 일이 많아요.
- 👍 좋은 답 — 겪은 사례가 있고, 이후에 감지 장치나 사전 합의를 만들었다고 합니다.
- ⚠️ 걸리는 답 — 그런 일은 없었다고 해요. 데이터를 오래 다뤘다면 반드시 겪습니다.
Q5. 데이터가 맞는지는 어떻게 확인하시나요
- 왜 묻나 — 파이프라인이 성공했는데 데이터가 틀린 경우가 가장 무서워요. 조용히 잘못된 숫자가 보고서로 나갑니다.
- 👍 좋은 답 — 건수 비교, 값 범위 검사, 중복 검사 같은 자동 점검이 있어요. 품질 검증 도구를 붙였으면 더 좋습니다.
- ⚠️ 걸리는 답 — “작업이 성공하면 정상이라고 봅니다.”
Q6. 지난 몇 달 치를 다시 계산해야 했던 적 있나요
- 왜 묻나 — 백필 경험이요. 이거 해본 사람은 티가 납니다.
- 👍 좋은 답 — 기간, 소요 시간, 비용, 그리고 그 뒤에 구조를 어떻게 바꿨는지가 나옵니다.
- ⚠️ 걸리는 답 — 없다고 하거나, 그냥 다시 돌렸다고만 해요.
Q7. 쿼리나 저장 비용을 줄여본 경험이 있나요
- 왜 묻나 — 데이터 플랫폼은 비용이 급격히 커지는 영역이에요. 감각이 있는지 봅니다.
- 👍 좋은 답 — 스캔량을 줄인 구체적 방법, 수명주기 정책, 작은 파일 병합 중 하나 이상이 나와요. 숫자로 말하면 확실합니다.
- ⚠️ 걸리는 답 — 비용은 신경 써본 적 없다고 합니다.
Q8. 개인정보나 민감한 데이터는 어떻게 다루셨나요
- 왜 묻나 — 데이터 갈래에서 사고가 나면 규모가 큽니다. 4편의 보안 감각이 이 갈래에도 필요해요.
- 👍 좋은 답 — 가명 처리나 마스킹을 어디 단계에서 하는지 말하고, 접근 권한을 데이터 구역별로 나눈 이야기가 나옵니다. 개발 환경에 운영 데이터를 그대로 안 넣는다는 원칙이 있으면 좋아요.
- ⚠️ 걸리는 답 — “레이크에 다 넣고 권한으로 막습니다” 만 말해요. 틀린 건 아닌데, 그것만으로는 부족합니다.
Q9. (AI 를 다뤘다면) LLM 을 실제 서비스로 운영해보셨나요
- 왜 묻나 — 데모와 운영의 차이를 봅니다. 요즘 이 구분이 가장 흐릿한 영역이에요.
- 👍 좋은 답 — 사용자 수, 월 비용, 응답 지연 같은 숫자가 나와요. 비용을 줄이려고 한 시도(캐싱, 모델 분리)와 실패 대응(모델이 응답 안 할 때) 이야기가 있으면 확실합니다.
- ⚠️ 걸리는 답 — 만들어봤다는 이야기만 있고 운영 숫자가 없어요.
Q10. (RAG 를 했다면) 답변 품질은 어떻게 판단하셨어요
- 왜 묻나 — 앞서 말한 그 질문이에요. RAG 경험의 진위를 가르는 단 하나의 질문입니다.
- 👍 좋은 답 — 평가 방법이 있어요. 정답 셋, 사용자 피드백 수집, 검색 문제와 생성 문제를 분리해서 본 이야기가 나오면 최고입니다.
- ⚠️ 걸리는 답 — “테스트해보니 잘 나왔습니다.” 이건 데모예요.
6. 60분 면접 진행 시나리오
이제 시리즈를 실제로 쓰는 법이에요. 60분 기술 면접 기준입니다.
| 시간 | 무엇을 | 참고 |
|---|---|---|
| 0~5분 | 인사, 회사·팀 소개, 면접관 솔직 고백 |
아래 설명 |
| 5~15분 | 공통 오프닝 — 규모, 본인 기여, 청구서 |
1편 Q1~Q3 |
| 15~40분 | 갈래별 심화 5~6문 | 해당 편의 질문 목록 |
| 40~50분 | 장애 이야기 + “다시 하면 뭘 바꿀까” |
1편 Q4, 2편 Q10 |
| 50~55분 | 후보자 질문 받기 | 아래 설명 |
| 55~60분 | 다음 절차 안내, 마무리 |
— |
0~5분 — 솔직하게 시작하세요
1편에서도 말했지만, 이 한마디를 먼저 하는 게 면접 전체의 품질을 올립니다.
“저는 AWS 를 깊게 알지는 못해요. 팀에 어떤 분이 필요한지 판단하려는 자리라, 최대한 쉽게 설명해 주시면 감사하겠습니다.”
이렇게 시작하면 세 가지가 좋아져요. 후보자가 용어 뒤에 숨지 않게 되고, 설명 능력을 자연스럽게 평가할 수 있고, 후보자도 긴장을 풉니다.
15~40분 — 갈래별 심화
여기가 본론이에요. 다만 모든 편의 질문을 다 하려고 하지 마세요. 25분이면 깊은 질문 5~6개가 한계입니다. 얕게 열 개보다 깊게 다섯 개가 훨씬 정확해요.
각 질문마다 꼬리 질문 한 번씩을 붙이는 게 핵심입니다. 시리즈 내내 반복한 그 세 마디예요.
- “그걸 안 했으면 어떻게 됐을까요?”
- “그때 다른 선택지는 뭐였나요?”
- “지금 다시 하면 똑같이 하실 건가요?”
40~50분 — 실패 이야기에 시간을 넉넉히
여기를 아끼지 마세요. 시니어 판별의 대부분이 이 10분에서 결정됩니다. 장애 회고 하나를 처음부터 끝까지 듣는 데는 정말 10분이 걸리고, 그만한 가치가 있어요.
50~55분 — 후보자 질문이 사실 평가 구간이에요
“궁금한 거 있으세요?” 는 형식이 아니라 마지막 평가 항목입니다. 시니어는 여기서 좋은 질문을 해요.
| 👍 좋은 질문을 하는 후보자 | ⚠️ 아쉬운 경우 |
|---|---|
| “지금 팀이 겪는 가장 큰 기술 부채가 뭔가요?” |
질문이 없어요 |
| “온콜은 어떻게 돌아가나요?” |
연봉·복지만 물어요 |
| “제가 들어가면 첫 3개월에 뭘 하길 기대하시나요?” |
이미 공고에 있는 걸 다시 물어요 |
7. 다섯 축 채점표
면접 직후 5분 안에 채우세요. 기억은 놀랄 만큼 빨리 흐려집니다.
| 축 | 무엇을 보나 | 점수 |
|---|---|---|
| 규모 | 숫자로 말하는가. 그 숫자가 서로 맞는가 |
1~4 |
| 깊이 | 꼬리 질문 세 번을 버티는가 |
1~4 |
| 장애 | 실패에서 배운 게 있는가 |
1~4 |
| 트레이드오프 | 포기한 것을 말하는가 |
1~4 |
| 전달력 | 모르는 사람에게 설명할 수 있는가 |
1~4 |
점수 감각은 이렇게 잡으시면 돼요.
- 4 — 묻지 않아도 구체적으로 나온다
- 3 — 물으면 나온다
- 2 — 물어도 일반론으로 답한다
- 1 — 해당 경험이 없다
시니어 채용이면 합계보다 최저 점수를 보세요. 어느 한 축이 1이면, 그게 나중에 그대로 문제가 됩니다. 특히 트레이드오프와 장애 축이 1인 시니어는 위험해요. 기술은 배우면 되지만 판단 습관은 잘 안 바뀝니다.
8. 레드 플래그 종합
시리즈 전체에서 나온 위험 신호를 한자리에 모았어요.
| 유형 | 신호 |
|---|---|
| 규모 부풀리기 | 형용사로만 말함. 숫자끼리 앞뒤가 안 맞음 |
| 공 가로채기 | 모든 걸 “제가 주도했습니다”. 팀 기여와 구분 못 함 |
| 회고 없음 | 장애 경험이 없음. 모든 원인이 외부 |
| 트레이드오프 없음 | 모든 과거 결정이 옳았음. “다시 해도 똑같이” |
| 자동화 과장 | “전부 자동화돼 있습니다”. 수동 작업을 하나도 못 댐 |
| 보안 기본 부재 | 관리자 권한을 요청대로 부여. 비밀번호를 코드에 보관 |
| 영웅 서사 | 모든 장애를 혼자 처리. 런북·회고 없음 |
| 규제 립서비스 | 절차 이름만 나열, 고생담이 전혀 없음 |
| 데모 수준 | RAG·LLM 을 만들었다는데 평가 방법이 없음 |
반대로, 하나만 있어도 크게 가산할 신호도 정리해둘게요.
- 청구서 항목을 순위까지 기억하고, 줄인 결과를 숫자로 말한다
- 자기 실수로 난 장애를 담담히 이야기하고, 그 후 바꾼 것이 있다
- “지금 다시 하면 이걸 바꾸겠다” 가 구체적으로 나온다
- 아직 자동화 못 한 수동 작업을 바로 몇 개 댄다
- 넓게 열린 권한을 좁히면서 겪은 조직 저항 이야기를 한다
- 모르는 걸 “모릅니다, 대신 이렇게 찾아보겠습니다” 라고 말한다
마지막 항목이 사실 제일 중요해요. 모르는 걸 모른다고 말하는 시니어는 팀을 안전하게 만듭니다. 반대로 모든 질문에 막힘없이 답하는 사람이 오히려 위험할 수 있어요. AWS 는 한 사람이 다 알 수 있는 크기가 아니거든요.
9. 마무리
다섯 편을 정리하면 이렇게 됩니다.
- 면접관이 AWS 를 잘 알 필요는 없어요. 필요한 건 후보자의 말을 알아듣고 되물을 수 있을 정도의 지형 감각입니다.
- “AWS 잘하는 사람” 은 없어요. 네 갈래 중 어디에 무게중심이 있는지부터 가르세요.
- 숫자를 요구하세요. 규모, 비용, 시간. 진짜 해본 사람은 숫자를 기억합니다.
- 실패를 물으세요. 인프라 실력은 대부분 사고에서 만들어집니다.
- 꼬리 질문 세 마디면 충분해요. “안 했으면?”, “다른 선택지는?”, “다시 한다면?”
이 정도면 AWS 를 몰라도 시니어를 꽤 정확하게 가려낼 수 있어요. 그리고 하나 더 말씀드리면, 이렇게 준비해서 들어간 면접은 좋은 후보자가 회사를 높게 평가하게 만듭니다. 면접은 양방향이라, 잘 준비된 질문 자체가 우리 조직에 대한 설명이 되거든요.
일단 오늘은 여기까지…..
좋은 분 만나시길 바랄게요. 면접 보시고 나서 “이 질문이 잘 먹혔다” 싶은 게 있으면, 그게 다음 면접의 진짜 자산이 됩니다.
← 이전 글: (4/5) AWS 보안·거버넌스 면접
