ping은 되는데 클러스터 조인만 실패했다.
ping 응답 정상context deadline exceeded
DF 비트를 켜고 크기별로 확인하니 ping -M do -s 8972 는 100% 유실, -s 1472 는 정상이었다. 원인은 OPNsense VLAN 서브인터페이스의 MTU가 기본값 1500이었던 것. 오제원 · 플랫폼 · DevOps 엔지니어 지망.
개인 홈랩에는 AI 도구로 만든 것과 자료를 찾아 적용한 것이 섞여 있습니다. 구분하지 않으면 면접에서 한 번에 무너지는 종류의 것이라, 항목마다 표시했습니다.
기술 목록보다 이쪽이 실제에 가깝습니다.
2026-08 · 앞선 사건 A의 정확한 날짜는 기록이 남아 있지 않습니다
크로스 VLAN에서 K3s 조인이 실패해 경로 MTU를 9000으로 올려 해결했습니다. 몇 달 뒤 빠져 있던 물리 노드를 다시 클러스터에 넣던 중, 같은 설정에서 점보 프레임이 100% 유실됐습니다.
앞서 올려둔 값이 실제로는 적용돼 있지 않았습니다. 1500으로 정합시키고, 저장소 문서에 드리프트 경고를 커밋했습니다.
● ethtool -S 로 물리 계층을 배제하고, DF 비트 ping으로 MTU를 확정한 것
○ 재전송 증상에서 MTU를 의심하게 된 것 — 검색으로 알게 됐습니다
문서를 믿지 않고 실측한다. 고친 뒤엔 문서까지 고친다.
홈랩 운영 중 · 정확한 시점 미확인
스냅샷 설정 문제였지만, 어느 설정이었는지는 기록을 남기지 않아 지금 말하지 못합니다. 설정을 바로잡고, 이후로는 백업 구성을 바꿀 때마다 스냅샷 안에 실제 파일이 있는지 확인하고 복구까지 한 번 해보고 넘어갑니다. 목록만 보고 넘어가지 않는 것이 핵심이었습니다.
● 직접 겪고 절차를 바꾼 것
백업이 됐다고 믿는 것과 실제로 되는 것은 다르다. 복구까지 해봐야 백업이다.
2026-05 이후
먼저 온 신호는 메트릭이 아니라 메모리였습니다. VM마다 메모리를 미리 잡아 두니 호스트 메모리에 여유가 없어졌고, 그제야 사용률을 보니 그만한 부하가 없었습니다. 제어 노드를 하나로 줄이고 워커도 통합했습니다. 되돌릴 수 있었던 건 구성을 코드로 관리하고 있었기 때문입니다.
제어 노드를 셋으로 둔 건 부하를 예측해서가 아니라 노드가 죽어도 서비스가 사는지 보려는 것이었습니다. 규모를 재지 않고 먼저 구성했고, 제어 노드를 실제로 꺼 보는 시험도 하지 않았습니다. 실무라면 순서가 반대여야 한다는 걸 그때 알았습니다. 재보고 줄인 것이 아니라 부딪히고 나서야 줄였습니다.
● 축소 판단과 실행
크게 구성하기는 쉽고, 줄이려면 구성이 코드로 관리되고 있어야 한다.
개인 홈랩(온프레미스)입니다. 직접 구매·설치한 장비 위에서 혼자 운영합니다.
PCB 코팅 공정용 CAM 데스크톱 앱. 현장 책임자가 컨트롤러로 위치를 맞춘 뒤 티칭 버튼으로 좌표를 등록하던 작업을, 도면에 영역을 그려 G-code를 생성하는 방식으로 바꿨습니다. 자동화가 가능했던 건 코팅 위치가 애초에 도면에서 정해지기 때문이었습니다. 코드는 AI 코딩 도구를 함께 써서 만들었고, 요구사항 정리와 구조 결정, 현장 검증은 직접 했습니다. 비개발자 사용자의 요구를 실제로 쓰이는 도구로 옮긴 경험입니다.
식단과 운동 기록 서비스(doeatfit.org). 아는 사람과 둘이 만들고 있습니다. 2024년에는 Spring Boot 백엔드 API를 직접 개발했고, 2025년부터는 AI 코딩 도구를 함께 씁니다. 구조를 정한 뒤 왜 그렇게 잡았는지 팀원에게 설명하는 일이 개발만큼 컸습니다. 지금은 인프라 매니페스트를 주로 맡고, 빌드는 제 홈서버의 러너가 돌립니다.
교내 중고의류 경매. 남은 기간에 비해 기능이 많고 팀원마다 필수라 여기는 것이 달랐습니다. 어느 기능이 나은지 다투는 대신 마감이라는 공통 제약으로 필수와 선택을 갈랐고, 결정과 이유를 회의록에 남겼습니다. 4개월 안에 입찰·낙찰과 학교 계정 기반 학생 인증을 마쳤습니다.
먼저 적어둡니다. 물어보시면 같은 내용으로 답합니다.