과천, "인프라 엔지니어(온프레미스)" 공고 지원용. 문항당 1500바이트 제한.

v3 — 실제 지원서 폼에 붙여넣어 인코딩 확인함

v2에서 사용자가 실제로 지원서 폼에 붙여넣은 스크린샷을 확인한 결과, 폼이 표시하는 바이트 수가 UTF-8 인코딩 기준과 훨씬 가깝다는 게 실측으로 확인됐다(EUC-KR 기준이었다면 훨씬 적은 바이트로 표시됐어야 함). 이후 전부 UTF-8 바이트 기준으로 1500 이내를 맞춘다.

또한 문단 사이 빈 줄(v2에서 없앴던 것)은 실제 폼에서도 자연스럽게 보이고 바이트 손해가 크지 않아 다시 복원했다. 대신 각 문항에 남는 여유 바이트만큼 구체적인 수치·사례를 추가로 채워 넣었다(VMware 실측 수치, Prometheus/Grafana 모니터링 구성 배경 등).

v1에서 고친 것 — 가장 중요한 정정 (계속 유효)

기존 초안 1번 문항은 "재부팅 후 사라진 네트워크 브리지"라고 flannel VXLAN 인터페이스 소실 사건을 재부팅이 원인인 것처럼 썼는데, 실제 트러블슈팅 기록(K3s-Flannel-VXLAN-Node-Outage-Troubleshooting.md)엔 **"왜 server1에서만 이 인터페이스가 사라졌는지 근본 원인은 아직 특정하지 못했다"**고 명시돼 있다. 대신 실제로 재부팅이 트리거였던 사건(추석 연휴 중 배터리 방전으로 홈서버 전체가 다운됐다가 전원 복구 후 재부팅, Chuseok-Power-Outage-Recovery.md)으로 1번 문항의 훅을 교체했다.

2번 문항의 "C로 TCP/UDP 소켓 통신 구현 + 정보처리기사/리눅스마스터 준비" 문장은 사용자 요청으로 제거하고, 그 자리를 최근 실제로 한 작업인 Prometheus/Grafana 모니터링 스택 구축(Lightweight-Prometheus-Grafana-Monitoring.md)으로 채웠다 — 1번 문항 마지막의 "장애를 사전에 감지하는 체계를 만들겠다"는 약속과 자연스럽게 이어진다.

최종본 (v3)

1. 지원 동기와 목표

[서비스 아래층을 책임지는 엔지니어가 되고 싶습니다]

홈랩에 쿠버네티스 클러스터를 직접 구축하며, 서비스 안정성은 결국 서버·네트워크·OS 계층에서 결정된다는 것을 체감했습니다. 정전으로 홈서버가 다운됐다가 재부팅됐을 때 대부분은 GitOps 체계로 스스로 복구됐지만, AI 서비스 하나는 계속 죽어 있었습니다. 원인은 코드가 아니라 모든 컴포넌트가 동시에 재시작되며 생긴 기동 순서 경쟁이었고, 헬스체크마저 실제 상태와 무관하게 항상 정상으로 응답하고 있었습니다. 이후 관리형 클라우드가 가려주던 영역을 직접 다루는 온프레미스 인프라 엔지니어를 목표로 삼았습니다.

코오롱베니트는 델 테크놀로지 총판으로 서버·스토리지 공급부터 구축, 운영까지 인프라 전 주기를 경험할 수 있는 곳입니다. 개인 인프라를 VMware에서 경량 가상화로 전환하며 하이퍼바이저 선택이 운영 안정성에 미치는 영향을 실측했습니다. 가상화 라이선스 정책 변화로 온프레미스를 다시 설계하려는 고객이 늘어나는 지금, 이 경험을 바탕으로 성장하고 싶습니다.

입사 후에는 데이터센터 운영 표준과 장애 대응 절차를 빠르게 익히고, 모니터링·자동화 경험을 살려 장애를 사전에 감지하는 체계를 만들겠습니다.

2. 노력과 준비

[제한된 자원에서 인프라를 설계하고, 때로는 "하지 않기로" 결정했습니다]

Ubuntu VM 3대로 K3s 클러스터를 구성하고 Tailscale로 노드를 연결, ArgoCD GitOps로 배포했습니다. 크로스노드 통신 장애 때는 언더레이-VXLAN 포트-오버레이 순으로 계층을 격리해 특정 노드의 flannel 인터페이스 소실을 찾았습니다. 로드밸런서 도입도 검토했지만 Tailscale 인터페이스가 ARP를 지원하지 않는 구조라 L2 방식과 맞지 않음을 확인하고, 되돌리기 어려운 변경 전에 진단만으로 판단을 멈췄습니다.

같은 메모리 제약에서 VMware와 경량 가상화(QEMU)를 비교해, VM 스펙보다 하이퍼바이저 오버헤드 차이가 더 크다는 것을 실측했습니다(호스트 여유 메모리 260MB에서 스왑 없이 안정 운영으로 개선). 디스크 온라인 리사이즈 불가로 실제 장애도 겪으며 용량 계획의 중요성을 배웠습니다.

Prometheus·Grafana로 노드·파드·앱 지표를 함께 보는 모니터링 체계도 구축했습니다. 메모리가 빠듯한 클러스터에 맞춰 꼭 필요한 지표만 가볍게 구성했습니다.

캡스톤 프로젝트 Sofly에서는 Nginx 블루-그린 무중단 배포와 자동 롤백을 구성했고, k6 부하 테스트로 p95 30ms, 에러율 0%를 확인해 교내 경진대회 장려상을 받았습니다.

3. 받고 싶은 질문과 답변

[질문] 직접 해결한 장애 중 가장 기억에 남는 것과 원인을 찾은 과정은?

특정 서비스가 "예전엔 됐는데 갑자기 안 된다"는 회귀 증상으로 시작됐습니다. 포트를 확인하니 타임아웃이 아니라 즉시 거부였고, 이는 리스닝 프로세스 자체가 없다는 신호였습니다. 같은 배포의 파드가 노드에 따라 결과가 달라, 원인을 노드 간 차이로 좁혔습니다.

디버그 파드를 특정 노드에 고정해 검증했습니다. 파드 간 기본 핑조차 100% 유실이었고, 호스트 네트워크로는 정상이었습니다. 언더레이와 VXLAN 포트는 살아있는데 오버레이만 실패한다는 걸 확인해, 한 노드에만 flannel 인터페이스가 없다는 걸 찾아 복구했습니다. 다만 왜 사라졌는지 근본 원인까지는 특정하지 못해 재발 감지를 후속 과제로 남겼습니다.

더 중요한 발견은 그다음이었습니다. 네트워크 복구 후에도 서비스가 접속되지 않아 확인해보니, 원래 접속이 임시 포트 포워딩에 의존하고 있었습니다. ArgoCD가 저장소와 클러스터를 지속 동기화하는 환경이라 클러스터를 직접 고치지 않고 GitOps 저장소에 영구 노출 설정을 반영했습니다.

이 경험으로 계층을 독립적으로 격리하면 원인은 반드시 좁혀진다는 것과, "지금 동작한다"와 "구성이 올바르다"는 다르다는 것을 배웠습니다.

참고한 원본 문서