UI5 모드
News

BTP 트라이얼 만료 — 데이터 살릴 수 있나? #shorts #SAP #BTP

수정: 2026년 8월 20일 👁 0 · ♥ 0

이 글이 답하는 질문

  • BTP 트라이얼은 언제 만료되고, 만료되면 정확히 무엇이 사라지나?
  • "정지"와 "삭제"는 다른 상태인가 — 되살릴 수 있는 구간은 어디까지인가?
  • HANA Cloud 인스턴스는 왜 며칠만 안 써도 멈춰 있나?
  • 날리기 전에 무엇을 백업해 두어야 다시 세울 수 있나?
  • 계속 쓸 거라면 트라이얼 대신 무엇을 골라야 하나?

이 글을 보기 전에

BTP 코크핏에 로그인해 서브계정을 하나라도 만들어 본 경험이면 충분합니다. Cloud Foundry나 HANA Cloud를 깊이 몰라도 됩니다. 다만 "서브계정 안에 서비스 인스턴스가 들어간다"는 구조만 머릿속에 있으면 뒤쪽 백업 이야기가 훨씬 쉽게 읽힙니다.

먼저 짚을 것 — 트라이얼과 무료 티어는 다르다

많이 헷갈리는 지점부터 정리하겠습니다. 이름이 비슷해서 같은 것으로 아는 경우가 많은데, 만료 여부가 완전히 다릅니다.

트라이얼(Trial)
  · 체험용 계정. 기간 제한이 있다
  · 기간이 끝나면 계정 자체가 정리 대상
  · 유료 전환 경로가 없다 — 새로 만들어야 한다

무료 티어(Free Tier)
  · 유료 계약(PAYG/구독) 안에서 무료 플랜을 쓰는 방식
  · 계정에 만료가 없다
  · 같은 자리에서 유료 플랜으로 올릴 수 있다 — 데이터 유지

즉 "만료되면 데이터가 어떻게 되나"라는 걱정은 본질적으로 트라이얼에만 해당합니다. 학습이 몇 달 이상 이어질 것 같다면 이 글의 결론은 하나입니다 — 처음부터 무료 티어로 시작하는 편이 낫습니다.

정지와 삭제는 다른 상태다

트라이얼이 끝난다고 그 순간 모든 게 지워지지는 않습니다. 보통 두 단계를 거칩니다.

[1] 활성      정상 사용
      │
      │  일정 기간 미접속
      ▼
[2] 정지      로그인은 되지만 리소스가 멈춤
      │       → 이 구간에서는 되살릴 여지가 있다
      │  추가 기간 경과 / 기간 만료
      ▼
[3] 삭제      서브계정과 인스턴스가 제거됨
              → 여기서부터는 복구 경로가 없다

중요한 건 2번 구간에서만 손을 쓸 수 있다는 점입니다. 정지 상태는 코크핏에 들어가 연장이나 재활성화를 눌러 되돌릴 수 있는 경우가 많습니다. 반면 3번으로 넘어가면 SAP에 문의해도 되돌려 주지 않습니다. 체험 계정은 애초에 보존을 약속하지 않는 자원이기 때문입니다.

구체적인 기간은 리전과 정책에 따라 바뀝니다. 숫자를 외우기보다 "오래 안 들어가면 멈추고, 더 두면 지워진다"는 구조를 기억하는 편이 안전합니다.

지금 내 계정이 어느 구간에 있는지는 코크핏에서 바로 확인할 수 있습니다.

BTP 코크핏 접속 후 순서대로 본다

① 글로벌 계정 화면 상단
   → 남은 기간 또는 만료 안내 배너가 뜨는지

② 서브계정 목록
   → 서브계정이 아직 보이면 삭제 전이다
   → 목록이 비어 있으면 이미 정리된 것

③ 서브계정 → 인스턴스 및 구독
   → 서비스 인스턴스가 남아 있는지
   → HANA Cloud 상태가 STOPPED인지 RUNNING인지

④ 인스턴스가 있는데 접속만 안 된다
   → 삭제가 아니라 중지다. 시작하면 된다

②에서 서브계정이 보인다면 아직 손 쓸 수 있는 상태입니다. 이 경우 가장 먼저 할 일은 연장이 아니라 백업입니다. 연장은 실패할 수 있지만 이미 받아 둔 파일은 사라지지 않기 때문입니다.

HANA Cloud는 왜 자꾸 멈춰 있나

트라이얼에서 가장 자주 나오는 질문입니다. 어제까지 잘 되던 DB가 오늘 접속이 안 됩니다.

트라이얼의 HANA Cloud 인스턴스에는 자동 중지가 걸려 있습니다. 비용이 큰 자원이라 쓰지 않는 시간에는 내려 두는 구조입니다. 이건 삭제가 아니라 중지이므로, 코크핏에서 다시 시작하면 데이터는 그대로 있습니다.

증상: JDBC 연결 실패 / cds deploy 타임아웃
확인: BTP 코크핏 → HANA Cloud → 인스턴스 상태

  STOPPED   → 시작 버튼을 누른다 (기동에 수 분)
  STARTING  → 기다린다
  RUNNING   → 이제 연결된다

다만 중지된 채로 오래 방치하면 인스턴스가 정리 대상이 됩니다. 중지는 안전하지만 방치는 안전하지 않다는 뜻입니다.

직접 해보기 — 날리기 전에 챙길 것

복구가 안 되는 자원이라면, 답은 복구가 아니라 재구축입니다. 다시 세울 수 있는 재료만 손에 있으면 계정이 지워져도 손실이 크지 않습니다.

1. 소스는 무조건 로컬과 원격 저장소에

CAP 프로젝트든 UI5 앱이든 코드가 BTP 위에만 있는 상황을 만들지 않는 것이 첫 번째입니다.

# 프로젝트 전체를 원격 저장소로
git init
git add .
git commit -m "trial backup"
git remote add origin <내 저장소>
git push -u origin main

# 최소한 이것만은 남긴다
#   package.json      의존성과 스크립트
#   db/schema.cds     데이터 모델
#   srv/*.cds *.js    서비스와 핸들러
#   mta.yaml          배포 구성
#   xs-security.json  권한 정의

2. 데이터는 파일로 빼 둔다

테이블 안의 데이터는 코드에 없습니다. 별도로 내려야 합니다.

-- 필요한 테이블을 CSV로 추출
SELECT * FROM ZTRV_EXPENSE_HEAD;
SELECT * FROM ZTRV_EXPENSE_ITEM;
-- Database Explorer → 결과 그리드 → Export

-- CAP이라면 db/data 폴더 규칙을 그대로 쓴다
--   db/data/my.app-ExpenseHead.csv
--   db/data/my.app-ExpenseItem.csv
-- 새 계정에서 cds deploy 하면 자동으로 적재된다

CAP의 db/data 규칙을 처음부터 써 두면 백업과 초기 데이터가 같은 것이 됩니다. 새 트라이얼을 만들고 배포만 하면 데이터까지 복원되므로, 사실상 재구축 비용이 사라집니다.

파일명 규칙만 지키면 되고, 별도 설정은 없습니다.

db/data/<네임스페이스>-<엔티티>.csv

my.app 네임스페이스에 ExpenseHead 엔티티라면
  db/data/my.app-ExpenseHead.csv

첫 줄은 헤더 — 엔티티 요소명과 정확히 일치해야 한다
  ID;employee;submittedAt;amount;status
  1001;E-2044;2026-08-03;182000;SUBMITTED
  1002;E-2119;2026-08-05;95500;APPROVED

구분자는 쉼표와 세미콜론 둘 다 인식된다

주의할 점은 헤더 이름입니다. 엔티티 요소명과 한 글자라도 다르면 그 컬럼은 조용히 무시되고 빈 값으로 들어갑니다. 배포 후 반드시 조회해서 값이 실제로 들어갔는지 확인하세요. 오류가 안 났다고 적재가 된 것은 아닙니다.

3. 설정은 스크린샷 말고 파일로

사람들이 가장 많이 놓치는 부분입니다. 서비스 인스턴스와 권한 설정은 코크핏 화면에만 남아 있기 쉽습니다.

# 서비스 키를 파일로 저장
cf create-service-key my-hana my-key
cf service-key my-hana my-key > backup/hana-key.json

# 역할 컬렉션과 권한은 xs-security.json에
{
  "xsappname": "trv-expense",
  "scopes":     [ { "name": "$XSAPPNAME.Approve" } ],
  "role-templates": [ {
      "name": "Approver",
      "scope-references": [ "$XSAPPNAME.Approve" ]
  } ]
}

서비스 키 자체는 계정이 사라지면 무효가 되지만, 어떤 서비스를 어떤 플랜으로 붙였는지가 기록으로 남습니다. 새 계정에서 같은 구성을 복원할 때 이 기록이 시간을 크게 줄여 줍니다.

4. 새 계정에서 되살리는 순서

재료가 갖춰졌다면 복원은 기계적인 작업입니다. 순서를 지키지 않으면 중간에 걸리므로 아래 흐름을 그대로 따르는 편이 빠릅니다.

1. 서브계정 생성 + 엔타이틀먼트 할당
   (HANA Cloud, Cloud Foundry Runtime 등 필요한 서비스)

2. Cloud Foundry 환경 활성화 + 스페이스 생성

3. HANA Cloud 인스턴스 생성
   → 기동까지 수 분 소요. 먼저 걸어 두고 아래로 진행

4. 저장소에서 코드 clone
   git clone <내 저장소> && npm install

5. 배포
   mbt build
   cf deploy mta_archives/*.mtar

6. 데이터 확인
   db/data 의 CSV가 함께 적재됐는지 조회로 검증

3번과 4번은 순서를 바꿔도 되지만, HANA 인스턴스 기동이 가장 오래 걸리므로 먼저 시작해 두면 전체 시간이 줄어듭니다. 익숙해지면 30분 안쪽에 끝납니다.

한 가지 주의할 점은 엔타이틀먼트입니다. 새 트라이얼은 이전 계정과 할당량이 다를 수 있어, 예전에 쓰던 플랜이 목록에 없을 수 있습니다. 이때는 같은 서비스의 다른 플랜으로 mta.yaml을 수정해야 배포가 통과합니다.

그래서 트라이얼을 언제까지 쓰나

판단 기준은 단순합니다.

  • 며칠짜리 실습 — 트라이얼로 충분합니다. 만료를 신경 쓸 일이 없습니다.
  • 몇 주 이상 이어지는 학습 — 백업 습관을 함께 들이거나, 무료 티어로 옮기는 편이 낫습니다.
  • 포트폴리오나 데모처럼 남겨 둘 것 — 트라이얼로 만들면 안 됩니다. 보여 주려는 날에 계정이 정지돼 있을 수 있습니다.

특히 세 번째가 실제로 자주 겪는 사고입니다. 면접이나 발표를 앞두고 며칠 손을 놓았다가, 당일에 인스턴스가 멈춰 있는 것을 발견하는 경우입니다. 남겨 둘 것이라면 처음부터 만료가 없는 쪽을 고르세요.

자주 만나는 함정

  • 연장 알림을 메일로만 기다린다 — 알림이 스팸으로 빠지거나 늦게 도착하는 경우가 있습니다. 만료 예상일을 직접 캘린더에 넣어 두는 편이 확실합니다.
  • 중지 = 삭제로 오해하고 새 계정을 판다 — 인스턴스가 STOPPED일 뿐인데 계정을 새로 만들어 그동안 만든 것을 스스로 버리는 사례가 많습니다. 상태부터 확인하세요.
  • 데이터를 화면 캡처로 남긴다 — 다시 넣을 수 없는 형식입니다. CSV로 빼야 재적재가 됩니다.
  • 무료 티어로 옮기면 데이터가 따라올 거라 기대 — 트라이얼과 무료 티어는 별개 계정입니다. 옮기는 기능이 아니라 새로 만드는 것이므로 재배포가 필요합니다.
  • 마지막 날에 몰아서 백업 — 정지 상태에서는 HANA에 접속이 안 되어 데이터를 뽑지 못할 수 있습니다. 백업은 쓰는 동안 해 두는 것입니다.

핵심 한 줄

트라이얼은 정지 구간에서만 되살릴 수 있고 삭제된 뒤에는 복구 경로가 없습니다. 그러니 복구를 기대하지 말고, 코드는 저장소에 데이터는 CSV로 빼 두어 언제든 다시 세울 수 있게 만들어 두는 것이 답입니다.

더 파볼 주제

  • 무료 티어로 시작해 유료 플랜으로 올릴 때 실제로 바뀌는 것
  • CAP의 db/data 초기 데이터 규칙과 배포 시 적재 순서
  • HANA Cloud 자동 중지 일정 조정과 비용 관계
  • mta.yaml만으로 계정을 통째로 재구축하는 배포 전략

댓글 0

아직 댓글이 없습니다.