수산INT 면접, 60분 안에 끝내는 정리

RAG 파이프라인과 SKALA 모델 서빙 과제를 하면서, 모델보다 배포·환경 분리·재학습 같은 운영 단계에서 더 많이 막혔습니다. 그래서 AI를 버린 것이 아니라 AI를 포함한 서비스가 돌아가는 플랫폼을 만드는 쪽을 택했다고 말하세요. 수산이 AI 내재화와 eSafe AI를 밀고 있다는 점을 붙이면 자연스럽습니다.

SKALA 일정(2026년 12월 수료 예정)을 먼저 밝히고 [정확한 수료일]과 조율 가능 여부를 미리 확인해 두세요. 일정을 모른다고 답하는 것이 가장 안 좋습니다.

실제 통근 시간과 경로를 말하고, 시차출퇴근제(07~10시 출근)를 활용하겠다고 답하면 회사 제도를 알고 있다는 인상도 줍니다.

공공 시스템 운영에서 장애 민원을 직접 처리해 봤다는 점을 근거로 수용한다고 답하고, 동시에 장애를 줄이는 자동화가 DevOps의 목표라는 점을 덧붙이세요.

보안 제품을 만드는 회사의 플랫폼을 책임지는 DevSecOps·플랫폼 엔지니어. 특히 파이프라인에 SBOM과 서명을 기본으로 넣고, 개발자가 셀프서비스로 배포하는 환경을 만드는 사람이라고 구체적으로 말하세요.

근거를 먼저 맞추고, 말로 안 정해지면 작게 만들어 비교합니다. 출근하자! 2인 백엔드 팀에서 [어떤 설계를 두고 의견이 갈렸고, PR 리뷰에서 무엇을 근거로 정했는지]. 결정이 나면 내 안이 아니어도 그대로 따르고, 우려한 점은 테스트나 모니터링으로 남깁니다.

KLID 차량조회를 사람이 반복하던 것을 자동화해 하루 약 2시간을 줄였고, 오류 보정으로 정확도를 95% 이상으로 올렸습니다. 출근하자!에는 GitHub Actions CI(lint → test → build)를 붙였습니다. "반복되는 일을 보면 자동화한다"는 습관을 DevOps 지원 이유로 이어 말합니다.

실제로 들은 말 하나와 그 장면을 짝으로. [들어 본 표현] → [그 장면]. 퇴사 전 인수인계 문서를 남긴 일은 "남은 사람이 덜 고생하게 한다"는 근거가 됩니다.

[실제 실수 1건]을 골라 바로 알린 시점 → 복구 → 재발 방지 순서로. 마지막에 "그래서 사람 손을 거치는 배포를 파이프라인으로 바꾸는 일에 관심이 생겼다"고 이으면 직무와 연결됩니다.

공공 운영 현장에서 고객이 실제로 겪는 장애를 보고 온 경험, 새 도구를 직접 띄워 보며 익히는 속도. "선배보다 잘한다"가 아니라 "선배가 덜 쓰는 시간을 메울 수 있다"는 톤으로.

우체국·새마을금고 가상계좌 풀을 만들 때 기획자와 요구사항을 맞춘 사례. [무엇이 엇갈렸고, 어떤 문서나 예시로 맞췄는지] 핵심은 용어를 상대의 말로 바꾼 장면입니다.

공공 시스템 장애 민원을 다룬 경험. [민원을 직접 받았는지, 담당 공무원을 거쳤는지] 수산 고객의 많은 수가 공공기관이라는 점을 마지막 한 줄로.

후기에 반복해 나오는 방식입니다.

• GitOps: 서버를 사람이 직접 바꾸지 않고, Git에 적힌 설정대로 시스템이 스스로 맞춰지게 하는 배포 방식
• 컨테이너: 프로그램과 실행에 필요한 것을 한 상자에 담아 어느 서버에서나 똑같이 돌게 하는 기술
• IaC: 서버와 네트워크 구성을 문서가 아니라 코드로 적어, 같은 환경을 몇 번이든 똑같이 만드는 방법
• SSL 복호화: 암호화된 통신을 잠깐 풀어 위험한 것이 있는지 보고, 다시 암호화해 보내는 것

1차 뒤 처우협의가 따로 있습니다. "내규를 따르되, 경력 1년을 반영해 주시길 바란다" 수준으로 답하고, 숫자 범위는 미리 정해 둡니다. [희망 범위] (참고: 대졸 초임 3,600만 원, 1인 평균 6,000만 원)

수산 제품은 고객의 암호화 트래픽을 풀어 봅니다. 고객 데이터·로그·인증 정보는 필요한 만큼만 접근하고, 시크릿을 평문으로 두지 않고, 업무 자료를 개인 PC나 외부 AI에 올리지 않는다고 답합니다. 마지막 항목은 eSafe AI가 막으려는 상황과 같다고 연결할 수 있습니다.

괜찮다고 답하고, 지방세운영지원단 파견 근무로 고객 현장에서 일해 본 경험을 근거로 듭니다. 폐쇄망 반입 절차를 겪어 봤다는 점도 공공 고객이 많은 회사에서는 강점입니다.

일단 맡아서 끝내고, 반복되는 일이면 줄일 방법을 찾는다고 답합니다. KLID 반복 조회 자동화 카드가 근거가 됩니다.

발전설비 정비, 건설기계, IT보안을 하는 그룹이고 상장 3사 가운데 수산INT가 IT보안을 맡는다는 한 문장이면 충분합니다.

[본인 방법 한 가지]를 짧게. 장애 대응처럼 긴장되는 상황을 어떻게 넘기는지 한 문장을 더하면 충분합니다.

한 문장으로 핵심 메시지를 다시 말하고, 준비한 역질문 하나로 이어 갑니다.

말이 아니라 데이터로 한 번 더 제안합니다. 작게 재현한 결과, 비슷한 장애 사례, 비용 비교를 준비합니다. 그래도 결정이 유지되면 따르고, 롤백 계획이나 모니터링 알람처럼 위험을 줄이는 장치를 함께 넣자고 제안합니다. 결과가 나온 뒤 "제 말이 맞았다"는 태도는 피합니다.

기준은 장애·보안 > 고객 납기 > 내부 개선입니다. 기준으로도 판단이 어려우면 팀장에게 우선순위를 확인합니다. 요청한 사람들에게는 언제 가능한지 먼저 알려 기다림을 관리합니다.

네. 회사에서는 경력과 역할이 기준이고, 신입으로서 먼저 배우는 입장입니다. [다양한 연차·나이의 동료나 공무원과 일한 장면 한 줄]

혼자 약속하지 않습니다. 가능한 범위와 위험을 정리해 담당 영업·PM과 함께 답합니다. 우체국·새마을금고 가상계좌 풀을 만들 때 요구사항을 조율한 경험을 예로 듭니다.

반대 이유를 한 번 분명히 말하고, 내가 놓친 것이 있는지 듣습니다. 결정이 나면 따르고, 우려한 점은 테스트나 모니터링 항목으로 남깁니다.

감정적으로 대응하지 않고 커밋·PR·이슈 기록으로 사실을 정리해 당사자와 먼저 이야기합니다. 함께 한 일이라면 함께 한 것으로 인정합니다. 평소에 작업을 PR과 문서로 남겨 두면 이런 일이 줄어듭니다.

모른다고 먼저 말하고, 아는 것과 연결해 추론하거나 어떻게 확인할지 말합니다. 예: "직접 써 보지는 않았지만 ~와 같은 원리라면 ~일 것 같습니다. 확인해 보겠습니다." 아는 척이 가장 큰 감점입니다.

부족했던 부분(예: IaC 실무)을 채워 DevOps 직무에 계속 지원하겠다고 담담하게 답합니다.

실제로 읽은 것 하나를 회사와 이어서 말합니다. [본인이 읽은 이슈] 예: Terraform 라이선스 변경과 OpenTofu, PQC 전환, N2SF 망 보안체계. 읽지 않은 것은 말하지 않습니다.

"문제를 숨기는 문화"처럼 일과 관련된 것으로 답하고, 반대로 기대하는 문화(장애 회고를 공유하는 팀)를 말합니다. 야근·회식 같은 답은 피합니다.

다른 트랜잭션이 잠근 행은 기다리지 않고 건너뛰어, 잠기지 않은 행부터 처리합니다. 여러 VM에서 발급 요청이 몰려도 같은 가상계좌를 중복 발급하지 않고 대기 시간도 줄어듭니다. 작업 큐 테이블 패턴이라고 설명하면 좋습니다.

파이프라인을 직접 짰는지, 있는 잡을 실행만 했는지 정확히 말하세요. [실제 범위] 범위가 작다면 이력서에서 빼거나 'Jenkins(사용)'처럼 낮춰 쓰는 편이 안전합니다.

• 답변 틀: 빌드 산출물, 전달 방식(망분리라면 반입 절차), JEUS 배포 절차, 롤백 방법. [실제 내용]
• 마무리: "수동 절차의 실수 가능성을 격어봤기 때문에 아티팩트 버전 고정과 자동 배포의 가치를 안다." 수산 제품도 공공 폐쇄망에 들어가서 이 경험이 강점이 될 수 있습니다.

오류 케이스를 분류하고 보정 로직을 넣어 정확도를 95% 이상으로 올린 과정을 설명하고, 반복 조회를 자동화해 하루 약 2시간을 줄인 점을 "반복 작업을 보면 자동화하는 습관"으로 묶으세요.

자료가 적어 레거시 코드와 내부 구조를 직접 파야 했던 경험을 말하고, 낯선 시스템을 대하는 방법(작게 재현 → 원인 좁히기)을 보여주세요.

문서와 코드를 반복해 읽고 작은 단위로 테스트하며 원인을 좁혔다는 답이 자소서와도 이어집니다. Python 영상 처리 파이프라인을 Delphi와 연동한 사례를 붙이면 언어가 달라도 시스템을 잇는 능력을 보여줄 수 있습니다.

연차 차감은 충돌이 드물어도 한 번 어긋나면 돈·인사 문제가 되고, 재시도 로직보다 잠금이 단순해서 골랐다고 답하세요. CountDownLatch로 8개 스레드를 동시에 돌려 잔여 5일을 넘지 않는지 TDD로 검증한 것이 핵심입니다.

findAllById로 IN 쿼리를 한 번만 날리고, Hibernate Statistics로 쿼리 수를 세는 회귀 테스트를 넣었습니다. 참여자 1명 방과 5명 방이 똑같이 5쿼리인지 확인했다는 숫자까지 말하세요.

allowedOriginPatterns("*")와 allowCredentials(true)를 함께 쓰면 어떤 사이트든 세션 쿠키를 싣어 요청할 수 있습니다. 화이트리스트로 바꾸고 허용되지 않은 origin은 403, 허용된 origin은 200이 나오는 회귀 테스트로 증명했습니다. 보안 회사라 반응이 좋을 소재입니다.

접속 중인 사용자에게는 양방향 WebSocket, 그렇지 않으면 단방향 SSE로 읽음 상태를 보냈습니다. 꼬리질문으로 스케일아웃 시 연결이 여러 인스턴스에 흩어지는 문제가 나오면, MQ나 Redis Pub/Sub으로 인스턴스 간 메시지를 퍼뜨린다고 답하세요.

로그인 직후 Redis 세션 레이스 컨디션(#65)은 프론트 지연으로 완화만 했고, 우선순위 판단으로 미뤄다고 솔직하게 말하세요. 운영에서 완벽보다 위험 대비 비용을 따지는 태도로 보여줄 수 있습니다.

학습 목적으로 수집·저장·처리·서빙을 일부러 나눠 각 컴포넌트의 역할을 익혔다고 분명히 말하세요. "실제 서비스라면 Kafka·Spark 없이 Airflow와 벡터 DB만으로 시작했을 것"이라는 판단을 덧붙이면 오버엔지니어링 의심을 풀 수 있습니다.

Kafka·MinIO·ES는 검증된 차트를 설정만 바꿔 쓰는 것이고, FastAPI·DAG·Spark Job은 코드가 자주 바뀌어 빌드·배포 자동화가 필요하기 때문입니다. 변경 주기가 다른 것을 다른 도구로 관리했다고 정리하세요.

values에서 바꾼 항목(예: executor, DAG 동기화 방식, 리소스)과 helm upgrade, helm rollback을 설명하세요. [실제 바꾼 values] 카카오톡 알림을 붙인 블로그 모니터링 DAG도 자동화 사례로 쓸 수 있습니다.

모델이 노트북 안에만 있으면 어떤 버전이 서비스 중인지 모르기 때문에, 학습 이력과 버전을 남기고 게이트를 통과한 모델만 승격하도록 설계했다고 답하세요. "CI/CD의 품질 게이트를 모델에 적용한 것"이라고 말하면 DevOps 직무와 이어집니다.

CI는 변경을 자주 합치고 자동으로 빌드·테스트하는 것입니다. 지속적 전달은 언제든 배포 가능한 상태를 유지하되 운영 반영은 사람이 승인하고, 지속적 배포는 그 승인까지 자동입니다. 보안 제품처럼 인증·고객 납품이 엮힌 곳은 지속적 전달이 현실적이라고 덧붙이세요.

• .gitlab-ci.yml에 stages(순서)와 jobs(단위 작업)를 정의하고, Runner가 잡을 실행합니다. Runner executor는 shell, docker, kubernetes 등입니다.
• rules로 브랜치·변경 파일에 따라 실행 여부를 정하고, needs로 스테이지를 기다리지 않는 DAG 실행을 만듭니다.
• artifacts는 잡 사이 산출물 전달, cache는 의존성 재사용입니다. Protected 브랜치에서만 쓰는 Protected/Masked 변수로 시크릿을 다룹니다.
• GitHub Actions와 비교: workflow·job·step과 stage·job이 대응되고, runner 개념도 같아서 출근하자! 경험을 그대로 옮길 수 있다고 말하세요.

Jenkins는 설치형 서버에 플러그인으로 확장해 자유도가 높지만 서버·플러그인 관리 부담이 큽니다. GitLab CI는 저장소·MR·레지스트리·보안 스캔이 한 플랫폼에 있고 설치형도 가능해 폐쇄망 환경에 잘 맞습니다. GitHub Actions는 마켓플레이스 액션이 풍부한 클라우드 중심입니다.

CI가 이미지 푸시 후 GitOps 저장소의 kustomization 이미지 태그를 바꾸는 커밋이나 MR을 올리는 방법이 일반적입니다. ArgoCD Image Updater로 자동 갱신하는 방법도 있습니다. 태그는 latest 대신 커밋 SHA나 버전, 가능하면 다이제스트로 고정합니다.

코드 변경과 배포 변경의 이력·권한을 분리하고, 설정만 바꿔도 앱 CI가 돌지 않게 하려는 것입니다. 운영 배포 승인을 설정 저장소의 MR 승인으로 관리할 수 있습니다.

의존성 cache, Docker 레이어 캐시(자주 바뀌는 파일을 Dockerfile 아래쪽에), needs로 병렬화, rules: changes로 바뀐 서비스만 빌드, 빠른 테스트를 앞에 두기입니다.

평문은 절대 두지 않고, Sealed Secrets(클러스터 키로 암호화한 값만 커밋), SOPS, External Secrets Operator(Vault 등 외부 저장소 참조) 중 하나를 씁니다.

ArgoCD가 OutOfSync로 드리프트를 보여주고, self-heal이 켜져 있으면 Git 상태로 되돌립니다. 근본적으로는 RBAC로 운영 클러스터 직접 수정 권한을 줄이고 모든 변경을 MR로 받습니다.

같은 작업을 여러 번 실행해도 결과가 같은 성질입니다. Ansible 모듈은 이미 원하는 상태면 아무것도 바꾸지 않고(changed=0), shell 모듈을 남발하면 멱등성이 깨진다는 말까지 하면 좋습니다.

네트워크, 클러스터, DB처럼 함께 바뀌는 단위로 나누고, 입력 변수와 출력값을 명확히 하며, 모듈 버전을 태그로 고정해 환경마다 다른 버전을 단계적으로 올립니다.

plan을 주기적으로 돌려 드리프트를 찾고, 코드를 맞추거나 apply로 되돌립니다. 코드 밖에서 만든 자원은 import로 state에 편입합니다.

Helm은 템플릿과 values로 매니페스트를 생성하고 릴리스 단위로 설치·업그레이드·롤백하는 패키지 관리자입니다. Kustomize는 템플릿 없이 base YAML에 패치를 덮는 방식이라 결과가 읽기 쉽습니다. 외부 오픈소스는 Helm, 자체 앱의 환경 차이는 Kustomize로 쓰는 조합이 흔하고, 제 프로젝트도 그렇게 나눴다고 답하세요.

HashiCorp가 2023년 Terraform 라이선스를 BSL로 바꾼 뒤 리눅스 재단 산하 포크인 OpenTofu가 나왔고, 문법이 거의 같아 전환이 쉬운 편입니다. 알고 있다는 정도면 충분합니다.

Deployment는 상태 없는 앱, StatefulSet은 고정 이름·전용 볼륨이 필요한 DB류, DaemonSet은 노드마다 하나씩(로그·모니터링 에이전트), Job·CronJob은 한 번 또는 주기적으로 끝나는 작업입니다. 주식 파이프라인에서 PostgreSQL을 StatefulSet으로, 수집을 CronJob으로 뒤던 것을 예로 드세요.

ClusterIP는 클러스터 내부용, NodePort는 모든 노드의 같은 포트를 열고, LoadBalancer는 외부 LB를 붙입니다. Ingress는 호스트·경로 기반 L7 라우팅과 TLS 종료를 한 곳에서 다룹니다.

metrics-server가 수집한 CPU·메모리 사용량을 requests 대비 비율로 보고 레플리카를 조절합니다. requests가 없으면 동작하지 않고, scaleDown 안정화 창으로 줄었다 늘었다를 반복하는 현상을 막습니다.

requests는 스케줄링 기준이자 보장치, limits는 상한입니다. 메모리가 limit을 넘으면 OOMKilled, CPU는 죽지 않고 스로틀링됩니다. 가산에서 고해상도 이미지로 메모리 오류를 잡은 경험과 연결해 "원인 코드를 고치는 것과 limit을 올리는 것을 구분한다"고 답하세요.

둘 다 설정을 주입하지만 Secret은 base64 인코딩일 뿐 암호화가 아닙니다. etcd 암호화와 RBAC, 외부 시크릿 저장소 연동이 필요하다는 말까지 해야 보안 회사 면접에서 점수를 받습니다.

PVC는 앱이 저장소를 요청하는 것, PV는 실제 볼륨, StorageClass는 PVC가 오면 PV를 동적으로 만드는 규칙입니다. prod 오버레이에서 PVC를 20Gi로 늘린 것을 예로 드세요.

Chart.yaml, values.yaml, templates/로 이뤄지고, helm upgrade --install로 배포하며 릴리스 이력이 남아 helm rollback으로 되돌릴 수 있습니다. ArgoCD와 쓸 때는 ArgoCD가 차트를 렌더링하므로 롤백도 Git으로 합니다.

멀티스테이지 빌드로 빌드 도구를 빼고, 작은 베이스 이미지(slim, distroless)를 쓰고, 자주 바뀌는 레이어를 뒤로 두고, non-root 사용자로 실행합니다. 블로그 예제 Dockerfile에서 멀티스테이지와 non-root를 적용했다고 말하세요.

VM은 하이퍼바이저 위에 OS를 통째로 올리고, 컨테이너는 호스트 커널을 공유하며 네임스페이스·cgroup으로 격리합니다. 컨테이너가 가볍지만 격리가 약해 보안 제품은 VM과 컨테이너를 함께 쓰게 됩니다. 수산이 SSL VA VM과 컨테이너 기반 ePrismX를 모두 갖고 있다는 점을 연결하세요.

SAST는 소스 코드를 실행 없이 분석, DAST는 띄운 서비스에 실제 공격 요청을 보내 검사, SCA는 오픈소스 의존성의 알려진 취약점과 라이선스를 검사합니다. 파이프라인에서는 SAST·SCA를 빌드 전에, DAST를 스테이징 배포 뒤에 둡니다.

레지스트리에 있는 이미지가 우리 파이프라인이 만든 것인지 증명하려는 것입니다. CI에서 cosign으로 서명하고, 클러스터에서 Kyverno 같은 정책 엔진이 서명 없는 이미지를 거부합니다.

RBAC 최소 권한, NetworkPolicy 기본 차단, Pod Security Standards(restricted), runAsNonRoot·readOnlyRootFilesystem, Secret 암호화와 외부 저장소, 이미지 다이제스트 고정을 순서대로 말하세요(보안 핵심 개념의 Kubernetes 보안 기본).

러너는 코드와 시크릿을 모두 보므로 공격 대상입니다. Protected 브랜치에서만 배포용 변수를 열고, 운영 배포용 러너를 분리하고, privileged 도커 빌드 대신 Kaniko·Buildah 같은 rootless 빌드를 고려한다고 답하세요.

header.payload.signature 구조이고, IdP 공개키(JWKS)로 서명을 검증한 뒤 만료(exp), 발급자(iss), 대상(aud)을 확인합니다. 발급 후 취소가 어려워 수명을 짧게 두고 Refresh Token으로 갱신합니다.

인가 코드가 가로채여도 code_verifier 원문을 모르면 토큰을 받을 수 없게 하는 장치입니다. 클라이언트 시크릿을 안전하게 보관할 수 없는 SPA·모바일에서 필수고, 지금은 모든 클라이언트에 권장됩니다.

Keycloak 같은 IdP에 각 도구를 OIDC 클라이언트로 등록하고, IdP 그룹을 ArgoCD RBAC 역할과 GitLab 권한에 매핑합니다. 퇴사자 계정을 IdP에서 한 번만 막으면 모든 도구 접근이 끊긴다는 것이 핵심 장점입니다.

단일 서비스 그룹웨어라 서버가 세션을 바로 끊을 수 있는 쪽이 더 단순하고, Redis로 세션을 공유해 서버를 늘려도 되도록 했다고 답하세요. 서비스가 여러 개로 나뉘면 OIDC로 가는 것이 자연스럽다는 선까지 연결하세요.

ss -lntp | grep <포트> 또는 lsof -i :<포트>로 찾고, systemctl status로 서비스 상태를 봅니다.

소유자·그룹·기타의 읽기(4)·쓰기(2)·실행(1) 합입니다. 755는 소유자만 쓰기, 모두 읽기·실행, 644는 소유자만 쓰기, 모두 읽기입니다. 비밀키 파일은 600으로 둡니다.

연결은 SYN → SYN-ACK → ACK, 종료는 FIN → ACK → FIN → ACK입니다. 먼저 끊은 쪽에 TIME_WAIT가 남고, 연결을 많이 만들고 끊는 서버는 TIME_WAIT가 쌓여 포트가 부족해질 수 있다는 것까지 말하세요.

DNS 조회(캐시 → 리졸버 → 루트·TLD·권한 서버) → TCP 연결 → TLS 핸드셰이크 → HTTP 요청·응답 → 렌더링. 수산 면접에서는 "회사망이라면 이 경로 중간에 SWG·SSL 가시성 장비가 끼어 검사한다"고 덧붙이세요.

보안 핵심 개념의 SSL/TLS 항목대로 답하고, 인증서는 서버 인증서 → 중간 CA → 루트 CA 체인을 단말에 있는 신뢰 루트로 검증한다고 설명하세요. Forward 방식 SSL 가시성에서 사설 루트 CA를 배포하는 이유가 바로 이것입니다.

L4는 IP·포트로 나누고 빠르며, L7은 URL·헤더·쿠키를 보고 나눌 수 있어 TLS 종료가 필요합니다. Kubernetes에서는 Service가 L4, Ingress가 L7에 가깝습니다.

각각 한 문장으로 답할 수 있게 보안 핵심 개념을 읽어 두세요. N2SF는 등급별 망보안, 제로트러스트는 매 요청 검증, PQC는 양자컴퓨터 이후에도 안전한 암호입니다.

프롬프트·첨부파일로 개인정보·기밀이 외부 LLM에 나가는 것이 가장 크고, 지니친 권한의 에이전트와 프롬프트 인젝션도 있습니다. 수산은 eSafe AI 게이트웨이와 DLP의 프롬프트 분석으로 대응한다고 말하고, RAG를 만들며 LLM 입출력을 다뤄 본 경험을 연결하세요.

GitLab·GitHub webhook(push, MR)이 기본입니다. Poll SCM은 주기적으로 저장소를 확인해 비효율적이고, 야간 빌드는 triggers { cron('H 2 * * *') }처럼 씁니다. H는 잡마다 시간을 흩어 동시에 몰리지 않게 합니다.

여러 서비스가 쓰는 공통 단계(빌드, 스캔, 알림)를 별도 Git 저장소의 Groovy 라이브러리로 두고 @Library('ci-lib') _로 불러 씁니다. 서비스마다 Jenkinsfile을 복사하지 않아도 되고, 스캔 기준을 한 곳에서 바꿉니다. 공고의 "표준화"와 같은 이야기입니다.

parallel로 테스트와 정적 분석을 동시에, 의존성 캐시(PVC·로컬 저장소), Docker 레이어 캐시, when { changeset 'module/**' }로 바뀐 모듈만 빌드, 빠른 테스트를 앞에 둬 일찍 실패시키기, options { timeout() }으로 멈춘 빌드 정리.

Console Output에서 처음 실패한 단계를 찾고, 다시 돌려도 같은지(에이전트·캐시 차이) 봅니다. 에이전트 디스크·메모리, 최근 플러그인 업데이트 여부도 확인합니다. Replay로 Jenkinsfile을 고쳐 다시 돌려 보고, post { failure { } }로 실패 알림을 보냅니다.

stage는 stages·job으로, Credentials는 Masked·Protected 변수로, 에이전트 label은 Runner tag로, Shared Library는 include 템플릿으로 옮깁니다. 새 서비스부터 옮기고, 같은 이미지·스캔 단계를 유지해 결과를 비교하며 점진적으로 바꾼다고 답합니다.

예시 Jenkinsfile (면접에서는 단계 이름과 이유만 말할 수 있으면 됩니다)

pipeline {
  agent { kubernetes { yamlFile 'ci/pod.yaml' } }   // gradle, trivy, kaniko 컨테이너
  options { timeout(time: 20, unit: 'MINUTES') }
  environment { IMAGE = "registry.local/app:${env.GIT_COMMIT.take(7)}" }
  stages {
    stage('Test')  { steps { container('gradle') { sh './gradlew test' } } }
    stage('Scan') {
      parallel {
        stage('SAST')  { steps { container('gradle') { sh './gradlew sonar' } } }
        stage('Trivy') { steps { container('trivy')  { sh 'trivy fs --exit-code 1 --severity CRITICAL .' } } }
      }
    }
    stage('Image') { steps { container('kaniko') { sh '/kaniko/executor --context . --destination $IMAGE' } } }
    stage('GitOps') {
      when { branch 'main' }
      steps {
        withCredentials([string(credentialsId: 'gitops-token', variable: 'TOKEN')]) {
          sh './ci/bump-tag.sh $IMAGE'   // overlays/dev의 이미지 태그 변경 커밋
        }
      }
    }
  }
  post { always { junit 'build/test-results/**/*.xml' } }
}

이미지 이름·태그 오타, 프라이빗 레지스트리 인증(imagePullSecrets) 누락, 레지스트리 접근 불가가 원인입니다. 폐쇄망 고객사라면 내부 레지스트리 미러에 이미지를 미리 넣어야 합니다.

Service selector에 맞고 Ready인 파드 IP가 EndpointSlice에 모이고, 각 노드의 kube-proxy가 iptables(또는 IPVS) 규칙으로 ClusterIP를 파드 IP로 바꿉니다. 이름은 CoreDNS가 서비스.네임스페이스.svc.cluster.local로 풀어 줍니다. Cilium 같은 eBPF CNI는 kube-proxy 역할을 대신하기도 합니다.

파드마다 IP를 주고 노드 사이 통신을 만드는 네트워크 플러그인 규격입니다(Calico, Flannel, Cilium). NetworkPolicy는 CNI가 지원해야 동작하므로 Flannel만 쓰면 적용되지 않습니다.

nodeSelector(라벨 일치), nodeAffinity(필수·선호), taint·toleration(노드가 허용한 파드만 받음, 전용·GPU 노드), podAntiAffinity나 topologySpreadConstraints(같은 앱을 다른 노드·존에 분산)를 씁니다.

etcdctl snapshot save로 주기 백업하고 snapshot restore로 복구합니다. 매니페스트는 Git에 있어 다시 만들 수 있지만, Secret·PV 데이터는 Velero 같은 도구로 따로 백업합니다.

init 컨테이너는 본 컨테이너 전에 순서대로 실행되고 끝나야 합니다(DB 대기, 설정 준비). 사이드카는 함께 돌며 로그 수집·프록시를 맡습니다. 1.29부터는 initContainers에 restartPolicy: Always를 준 네이티브 사이드카를 씁니다.

ResourceQuota는 네임스페이스 전체 사용량 상한, LimitRange는 컨테이너별 기본값과 최대 requests·limits입니다. 팀이나 고객별로 네임스페이스를 나눌 때 한쪽이 자원을 독차지하지 못하게 합니다.

CRD로 새 리소스 종류를 정의하고, Operator는 그 리소스를 원하는 상태로 맞추는 컨트롤러입니다(DB 백업·장애조치 자동화). ArgoCD의 Application, cert-manager의 Certificate도 CRD입니다. "쿠버네티스의 조정 루프를 내 도메인으로 확장하는 것"이라고 답합니다.

Pod Security Standards(privileged·baseline·restricted)를 네임스페이스 라벨로 적용하고, runAsNonRoot, readOnlyRootFilesystem, capabilities: drop: [ALL], privileged 금지를 기본으로 둡니다.

get -o wide, describe, logs -f --previous, exec -it, port-forward, top pod/node, get events --sort-by=.lastTimestamp, kubectl debug(이미지에 셸이 없을 때 임시 컨테이너), rollout status / history / undo.

provider(AWS·쿠버네티스 등 대상 API), resource(만들 자원), data(이미 있는 자원 조회), variable(입력), output(다른 모듈·사람에게 넘길 값), module(묶음 재사용)입니다. terraform init으로 provider를 받고 plan으로 차이를 본 뒤 apply합니다.

로컬이 아니라 원격 backend(S3 + DynamoDB 잠금, GitLab managed state 등)에 두고 잠금을 걸어 동시에 apply하지 못하게 합니다. state에는 비밀번호 같은 값이 평문으로 들어갈 수 있어 접근 권한과 암호화가 필요합니다. 환경마다 state를 분리합니다.

workspace는 같은 코드에 state만 나눠 간단하지만 실수로 다른 환경에 apply하기 쉽습니다. 실무에서는 envs/dev, envs/prod 디렉터리마다 backend와 tfvars를 두고 공통 모듈을 부르는 방식을 많이 씁니다.

lifecycle { prevent_destroy = true }, 교체가 필요하면 create_before_destroy, 파이프라인에서 plan 결과를 MR에 남겨 사람이 보고 승인한 뒤에만 apply합니다. plan에 destroy가 있으면 멈추게 하는 규칙도 둡니다.

MR에서 fmt -check → validate → plan(결과를 MR 코멘트·아티팩트로), main 병합 후 승인을 거쳐 apply입니다. tfsec·Checkov로 보안 설정을 정적 검사합니다. 같은 plan 파일을 apply해야 검토한 내용 그대로 반영됩니다.

module "cluster" {
  source       = "../../modules/k8s"
  env          = "prod"
  node_count   = var.node_count
}
resource "helm_release" "airflow" {          # 실습 계획: Airflow 설치를 코드로
  name       = "airflow"
  chart      = "airflow"
  repository = "https://airflow.apache.org"
  values     = [file("values-prod.yaml")]
}

shell·command 대신 apt, copy, template, service처럼 상태를 확인하는 모듈을 씁니다. 그러면 이미 원하는 상태면 changed가 아니라 ok로 끝납니다. 꼭 shell을 써야 하면 creates나 changed_when으로 조건을 겁니다.

ansible-vault로 변수 파일을 암호화하고, CI에서는 vault 비밀번호를 시크릿 변수로 주입합니다. 로그에 찍히지 않게 no_log: true를 씁니다.

--check --diff로 무엇이 바뀌는지 미리 보고, --limit으로 한 대·한 그룹부터 적용하고, serial로 몇 대씩 나눠 롤링 적용합니다.

Chart.yaml(이름·버전·의존성), values.yaml(기본값), templates/(Go 템플릿 매니페스트), _helpers.tpl(공통 이름·라벨)입니다. 차트 버전과 앱 버전(appVersion)은 따로 관리합니다.

pre-install, pre-upgrade 같은 시점에 DB 마이그레이션 Job을 먼저 돌릴 때 씁니다. ArgoCD로 배포하면 Helm hook이 ArgoCD sync hook으로 바뀌어 동작합니다.

ArgoCD가 helm template으로 렌더링해 적용하므로 클러스터에 Helm 릴리스 이력이 남지 않습니다. 롤백도 helm rollback이 아니라 Git revert로 합니다.

strategic merge patch(바꿀 부분만 YAML로 적음)와 JSON 6902 patch(op·path로 정확한 위치를 지정, 리스트 항목 수정에 유리)입니다. 지금은 patches: 필드 하나로 두 방식을 모두 씁니다.

images: 항목에 newTag를 적거나 kustomize edit set image를 씁니다. CI가 GitOps 저장소의 이 값만 바꾸는 커밋을 올리면 ArgoCD가 배포합니다.

외부에서 받아 쓰는 소프트웨어(Airflow, Kafka, 모니터링)는 공식 Helm 차트, 우리가 만든 서비스는 읽기 쉬운 Kustomize가 흔합니다. Helm으로 렌더링한 결과를 Kustomize로 다시 패치하는 조합도 씁니다.

# overlays/prod/kustomization.yaml
resources: [../../base]
images:
  - name: app
    newTag: "a1b2c3d"
replicas:
  - name: app
    count: 3
patches:
  - path: hpa.yaml
configMapGenerator:
  - name: app-config
    literals: [LOG_LEVEL=WARNING]

R 실행, S 대기, D 끊을 수 없는 I/O 대기, Z 좀비(끝났지만 부모가 wait 하지 않음), T 정지입니다. 좀비는 부모 프로세스를 고치거나 재시작해야 없어집니다. 컨테이너의 PID 1이 신호 처리와 좀비 수거를 못 하면 tini 같은 init을 씁니다.

파일과 소켓마다 파일 디스크립터를 쓰는데 프로세스 한도(ulimit -n, systemd는 LimitNOFILE)를 넘은 것입니다. /proc/<pid>/fd 개수로 확인하고, 한도를 올리기 전에 커넥션·파일 누수부터 의심합니다.

하드링크는 같은 inode를 가리키는 또 하나의 이름이라 원본을 지워도 남고, 디렉터리나 다른 파일시스템에는 못 겁니다. 심볼릭 링크는 경로를 가리키는 파일이라 원본을 지우면 깨집니다.

setuid는 실행할 때 파일 소유자 권한으로 돌게 하고(passwd), sticky bit는 /tmp처럼 누구나 쓰지만 자기 파일만 지우게 합니다. umask는 새 파일의 기본 권한을 정합니다(022면 파일 644, 디렉터리 755).

filter·nat 같은 테이블과 INPUT·OUTPUT·FORWARD·PREROUTING·POSTROUTING 체인이 있고, 규칙은 위에서부터 처음 맞는 것이 적용됩니다. Docker와 kube-proxy가 nat 테이블에 규칙을 써서 포트 포워딩과 Service를 구현합니다. 요즘 배포판은 nftables가 기본입니다.

공개키는 서버의 authorized_keys에, 개인키는 클라이언트에 두고 권한은 600입니다. sshd_config에서 비밀번호 로그인과 root 로그인을 끄고, 접속은 배스천 호스트를 거치게 하고, fail2ban으로 무차별 대입을 막습니다.

cron은 로그인 셸과 환경변수(PATH 등)가 다릅니다. 절대 경로를 쓰고, 출력을 로그 파일로 남겨(>> log 2>&1) 원인을 봅니다. 형식은 분 시 일 월 요일이고, 쿠버네티스에서는 CronJob이 같은 역할을 합니다.

맨 위에 set -euo pipefail(에러, 정의 안 된 변수, 파이프 중간 실패에서 멈춤)을 두고, 변수는 따옴표로 감싸고, trap으로 정리 작업을 하고, shellcheck로 검사합니다. CI 스크립트에서 실패가 조용히 묻히지 않게 하는 기본입니다.

namespace(pid·net·mnt·uts·ipc·user: 보이는 범위 격리), cgroup(CPU·메모리 사용량 제한), overlayfs(이미지 레이어), seccomp·capabilities(시스템 호출·권한 제한)입니다. 쿠버네티스 limits가 결국 cgroup 설정이라 메모리를 넘으면 OOMKilled가 됩니다.