windplatformSM 파트너용 · 2026 가을

EOS, 그대로 옮기지 말고
이번에 한 번에 정리합니다

운영체제와 WAS 의 지원 종료로 어차피 다시 까는 시스템이라면, 같은 비용으로 쿠버네티스 위로 옮깁니다. 그다음부터 운영체제 판 올리기와 보안 패치는 화면에서 클릭 한 번, 서비스를 멈추지 않고 돕니다. 당장 못 옮기는 서버는 그대로 두고 같은 화면에서 배포합니다.

I오늘몰려오는 지원 종료
II갈림길옮기기냐 정리하기냐
III옮기기한 번에 다 하지 않는다
IV운영SM 의 하루가 바뀐다
V시작시스템 하나로
I · 오늘SM 현장이 겪는 일

지원 종료는 몰려오고, 배포는 아직 손으로 한다

오래 운영한 시스템일수록 서버마다 배포 방법이 다르고, 아는 사람이 정해져 있습니다. EOS 대응은 그 구조를 새 서버에 그대로 옮기는 일이 되기 쉽습니다.

운영체제와 WAS 지원 종료가 한꺼번에 몰려온다.EOS
서버마다 배포 방법이 달라서 담당자가 바뀌면 아무도 모른다.배포
배포 이력도 되돌리기도 없어서 장애 때 손으로 되돌린다.장애
장애가 나면 어느 서버 로그를 봐야 하는지부터 찾는다.로그
I · 오늘고객이 프라이빗을 찾는 까닭

데이터는 안에 두고 싶은데, 쓰는 법은 클라우드처럼

회사가 크든 작든 우리 데이터를 밖에 맡기기는 불안합니다. 그래서 프라이빗으로 가고 싶지만, 직접 깔면 클릭 한 번에 자원이 생기지 않고 멈추지 않을지도 걱정입니다. windplatform 은 이 세 가지를 한 벌로 풉니다.

불안

「우리 데이터를 밖에 맡기기 불안하다」

고객사 서버 안에 설치합니다. 앱의 데이터는 물론 로그와 사용자 모니터링 기록까지 고객사 클러스터 밖으로 나가지 않습니다.

클러스터 안의 에이전트가 안에서 밖으로만 연결해, 고객망에 들어오는 포트를 열지 않습니다.

불편

「프라이빗은 클릭 한 번에 안 만들어진다」

DB, 캐시, 저장소, 앱 주소와 인증서를 화면에서 클릭으로 만듭니다. 접속 정보는 앱에 자동으로 들어갑니다.

개발자가 쓰는 AI 코딩 도구에게 말로 시켜도 됩니다.

안정성

「직접 운영하면 멈출까 걱정이다」

앱은 여러 노드에 나눠 돌고, 노드 한 대가 멈춰도 다른 노드에서 다시 뜹니다. 상태 확인에 답하지 않는 앱은 스스로 다시 띄웁니다.

배포와 운영체제 판 올리기도 서비스를 멈추지 않고, DB·캐시는 이중화합니다.

프라이빗의 안심, 클라우드의 편리함, 멈추지 않는 운영을  한 벌로.

II · 갈림길EOS 대응의 두 길

그대로 옮길 것인가, 이번에 정리할 것인가

EOS 대응은 어차피 다시 깔고 다시 시험하는 일입니다. 같은 일을 하면서 다음 EOS 까지 덜 아프게 만들 수 있습니다.

그대로 옮기기

새 서버에 같은 구성

  • 새 운영체제에 같은 구성을 손으로 다시 설치
  • 서버마다 다른 배포 방법도 그대로
  • 다음 지원 종료 때 같은 일을 또 반복
  • 비용은 드는데 운영은 그대로
이번에 정리하기

한 길로 모으기

  • 소스, 빌드, 배포가 한 길로 모임
  • 다음 EOS 와 보안 패치는 클릭 한 번, 무중단으로
  • 배포 이력과 되돌리기, 로그가 한곳에
  • 못 옮긴 서버도 같은 화면에서 배포
II · 갈림길옮기고 난 뒤의 EOS

다음 EOS 부터는 클릭 한 번, 무중단

VM 에서는 운영체제 판 올리기와 보안 패치가 야간 작업이었습니다. 쿠버네티스 위로 옮기고 나면 같은 일이 화면의 버튼 하나가 되고, 서비스는 그동안 다른 노드에서 계속 돕니다.

VM 에서의 판 올리기

점검 공지와 야간 작업

  • 서버마다 들어가 패키지를 올리고 재부팅
  • 재부팅하는 동안 서비스가 멈춤, 점검 시간 공지
  • 서버마다 판이 조금씩 달라짐
  • 무엇을 언제 올렸는지는 작업 대장에 손으로
  • 지원 종료 때마다 새 서버에 다시 설치
windplatform 위의 판 올리기

버튼 하나, 서비스는 그대로

  • 운영체제는 통째로 바꾸는 이미지라 판 올리기와 보안 패치가 이미지 교체 한 번
  • 화면에서 판을 고르고 누르면 노드를 한 대씩 비우고 올리고 다시 들임
  • 그동안 앱은 다른 노드에서 계속 돎
  • 쿠버네티스 판도 버튼 하나, 올리는 순서는 호환표가 계산
  • 모든 노드가 같은 판으로 맞춰지고, 기록은 제품 안에 남음
II · 갈림길무중단 판 올리기

판 올리기 버튼을 누르면 일어나는 일

사람은 시작만 누릅니다. 진행은 자동이고, 사람이 끼어들어야 할 때만 알립니다.

  1. 1판 고르기

    올릴 운영체제·쿠버네티스 판을 고릅니다. 건너뛸 수 없는 판이 있으면 순서를 계산해 보여 줍니다.

  2. 2노드 한 대 비우기

    첫 노드를 새 일을 받지 않게 하고, 그 위의 앱을 다른 노드로 옮깁니다.

  3. 3새 이미지로

    그 노드를 새 판 이미지로 올리고 다시 부팅합니다.

  4. 4쓸 수 있는지 확인

    명령이 끝난 것이 아니라 노드가 다시 쓸 수 있다고 판정돼야 다음으로 갑니다.

  5. 5다음 노드

    한 대씩 되풀이해 모든 노드를 같은 판으로 맞춥니다.

앱 판 올리기도

새 판이 선 뒤에 옛 판을 내림

앱 배포도 새 판이 준비됐는지 확인한 뒤 옛 판을 내립니다. 배포하는 동안 멈추지 않습니다.

무중단 구성

노드 여러 대, 앱 두 벌 이상

컨트롤 플레인 세 대와 작업 노드 여러 대, 앱을 두 벌 이상 띄우는 구성으로 잡습니다.

기록

EOS 대응이 이력으로

언제 어느 판으로 올렸는지 제품 안에 남아, 감사와 SM 보고의 근거가 됩니다.

II · 갈림길아키텍처

한 장으로 보는 구성도

모든 것이 고객사 사내망 안에 있습니다. 관리 클러스터는 지휘만 하고, 고객의 앱과 데이터는 워크로드 클러스터에 둡니다.

III · 옮기기옮기는 순서

한 번에 다 옮기지 않습니다

서비스를 멈추지 않고 한 걸음씩 옮깁니다. 첫 걸음부터 배포는 한 길로 모이고, 컨테이너로 옮기는 일은 앱마다 차례로 합니다.

  1. 1소스와 빌드를 한곳으로

    앱을 등록하면 Git 저장소가 생기고, 코드를 올리면 빌드됩니다.

  2. 2쓰던 서버에 그 빌드로

    옮기지 못한 서버는 그 자리에 둔 채, 같은 빌드를 같은 화면에서 배포하고 재시작합니다.

  3. 3앱을 하나씩 컨테이너로

    앱마다 Dockerfile 하나를 더해 클러스터로 옮깁니다. 주소와 인증서가 함께 붙습니다.

  4. 4DB·캐시를 매니지드로

    원하는 앱부터 관리형 DB·캐시로 옮깁니다. 쓰던 DB 를 그대로 두는 것도 됩니다.

  5. 5다 옮긴 서버는 반납

    비운 서버는 회수하거나 클러스터의 노드로 다시 씁니다.

III · 옮기기AI 와 함께

옮기는 손은 AI 가 거듭니다

SM 담당자가 쓰는 AI 코딩 도구가 windplatform 에 붙어 기존 프로젝트를 읽고, 이미지 만드는 법을 쓰고, 등록과 배포까지 합니다. windplatform 은 그 AI 에게 기존 프로젝트를 올릴 때 지킬 약속을 내려 줍니다.

AI 코딩 도구 · 대화 예시MCP → NARU
이 정산 배치 프로젝트를 컨테이너로 올려 줘.
✓ 기존 프로젝트 올리기 약속 읽음
✓ Dockerfile 작성 — 사람 확인 대기
쓰던 DB 는 그대로 두고 접속 정보만 환경변수로 넣겠습니다. 관리형 DB 로 옮길지는 따로 정해 주세요.
좋아, 올려.
✓ register_app → wait_for_build → wait_for_deploy
배포했습니다. 실행 로그에 오류는 없습니다.
  • 사용자 저장소에 요구하는 것은 Dockerfile 하나 — AI 가 이미 아는 형식
  • AI 는 쓰던 DB 를 묻지 않고 바꾸지 않습니다 — 옮기기는 사람이 동의한 뒤에만
  • 코드 올리기와 지우기는 사람이 한 번씩 허락합니다
  • AI 가 불러도 그 사람의 권한으로 똑같이 따집니다
IV · 운영SM 의 하루

정리하고 나면 SM 의 하루가 바뀝니다

배포

이력과 되돌리기

어느 판이 언제 나갔는지 보이고, 문제가 생기면 앞 판으로 되돌립니다.

로그

한곳에서 찾기

빌드 로그와 실행 로그를 앱 단위로 봅니다. 어느 서버인지 찾지 않습니다.

상태

상태 확인

앱마다 상태 확인 주소를 두고, 살아 있는지 플랫폼이 계속 살핍니다.

사용자

체감 모니터링

실제 사용자의 화면 속도와 오류, 세션 재생으로 장애를 먼저 압니다.

접속

요청 → 승인 → 기한

운영 클러스터 접속은 승인을 받고, 기한이 지나면 저절로 끊깁니다.

기록

월간 보고의 근거

배포와 변경, 승인 기록이 그대로 SM 보고서의 근거가 됩니다.

IV · 운영SM 회사가 얻는 것

EOS 대응을 현대화 사업으로

사업

포팅이 아니라 현대화로 제안

같은 EOS 예산으로 「다음 지원 종료까지 덜 아픈 구조」를 제안합니다. 플랫폼 납품과 이전 용역이 함께 생깁니다.

인력

배포에 쓰던 손을 줄입니다

서버마다 손으로 하던 배포가 한 길로 모여, 같은 인력으로 더 많은 시스템을 맡습니다.

장애

찾는 시간을 줄입니다

로그와 사용자 모니터링, 되돌리기가 한 화면에 있어 원인 찾기와 복구가 빨라집니다.

재계약

기록이 다음 계약의 근거

배포 횟수, 장애 대응, 변경 이력이 화면에 쌓여 SM 성과를 숫자로 보입니다.

IV · 운영AI 운영

이제는 AI 가 운영을 거듭니다

windplatform 은 LLM 을 품어 운영을 스스로 돌봅니다. SM 인력은 판단과 고객 응대에 더 많은 시간을 씁니다.

  • 장애가 나면 원인과 다음 걸음을 안내합니다
  • 조직이 정한 기준에 맞는지 앱과 설정을 살핍니다
  • 반복되는 운영 일을 자동으로 처리합니다
  • 사람의 승인이 필요한 일은 사람에게 묻습니다

SM 의 일은 손으로 하는 일에서 AI 에게 맡기고 판단하는 일로 옮겨 갑니다.

V · 시작PoC

EOS 대상 시스템 하나로 시작합니다

올해 지원 종료를 맞는 시스템 하나를 골라, 옮기는 순서의 첫 세 걸음을 보여 줍니다.

준비

서버 두세 대와 시스템 하나

플랫폼
windplatform 을 올릴 서버 두세 대, 사내 네트워크 대역, 도메인
대상
EOS 대상 시스템 하나의 소스와, SSH 로 닿는 운영 서버
보여 줄 것

세 걸음

1
소스를 올리면 빌드되고, 쓰던 서버에 같은 화면으로 배포
2
같은 앱을 컨테이너로 옮겨 주소와 인증서까지
3
배포 이력과 되돌리기, 로그, 사용자 모니터링
windplatform