요약

  • Salesforce는 사용자 정의 필드를 삭제할 때 고유성과 필수 입력 속성을 제거한다. 복구 후 필요한 속성은 관리자가 다시 설정해야 한다.
  • 되살린 수식 필드는 편집하고 저장하기 전까지 비활성 상태다. 바뀐 화면 배치와 제거된 의존 관계도 복구 작업에 포함된다.
  • 필드와 데이터는 영구 삭제하거나 15일이 지나기 전까지만 복구할 수 있다. 할당량을 확보하려는 정리 작업은 이 선택권을 먼저 끝낼 수 있다.

복구 담당자가 가장 듣고 싶은 말은 “값이 다시 보입니다”일 것이다. 업무 담당자가 한 번 더 물어야 할 말은 덜 반갑다. “같은 번호를 또 넣으면 이번에도 막힙니까?”

Salesforce의 사용자 정의 필드에서는 두 질문이 서로 다른 답을 받을 수 있다. 필드와 데이터는 돌아왔는데, 그 필드가 맡았던 거절 기능은 아직 돌아오지 않은 상태다. 복구가 화면에서는 끝났고 업무에서는 계속되는 지점이다.

삭제한 필드 속성을 수동으로 복구하는 공식 안내는 이유를 구체적으로 적고 있다. Salesforce는 필드를 삭제하면서 고유성 속성과 필수 입력 속성을 자동으로 제거한다. 필드를 되살린 뒤에도 필요하다면 사람이 다시 설정해야 한다. 한때 체크해 둔 두 칸이 업무에서 어떤 역할을 했는지는 복구 버튼이 판단해 주지 않는다.

돌아온 열보다 빠진 규칙이 비싸다

주문 식별자를 담는 필드를 예로 들어보자. 실제 고객 사고가 아니라 문서의 동작을 적용한 가정이다. 이 필드의 고유성 속성이 같은 식별자의 중복 입력을 막아 왔다면, 복구할 때 그 속성을 다시 적용하는 일이 남는다. 별도의 검증이 있는지도 살펴야 한다. 필요한 값이 비어서는 안 됐던 필드라면 필수 입력 속성 역시 같은 문제를 안고 있다.

기존 주문 번호가 화면에 모두 보인다는 사실은 과거 자료를 찾았다는 증거다. 다음 주문이 중복되거나 비어 들어오지 못한다는 증거는 별도로 만들어야 한다. 그 차이를 놓치면 복구 비용이 사라지는 대신 다른 부서로 옮겨간다. 운영팀은 충돌한 값을 대조하고, 보고서 담당자는 숫자가 왜 맞지 않는지 설명한다. 원인은 복구 과정에 있었어도 비용표에는 평범한 데이터 정리 업무로 찍힐 수 있다.

따라서 인수 기준에는 성공한 입력뿐 아니라 거절된 입력도 있어야 한다. 정상적인 새 값이 저장되는지 확인하고, 예전에 금지했던 빈 값이나 중복 값이 여전히 거절되는지 확인하는 것이다. 이때 필요한 것은 테스트 건수를 늘리는 열성보다 어떤 거절이 업무상 중요했는지 아는 사람이다.

필드를 되살릴 권한을 가진 관리자와 그 필드가 왜 존재하는지 아는 담당자는 같은 사람일 필요가 없다. 복구 절차가 그 둘을 다시 만나게 해야 한다. 그렇지 않으면 체크박스의 기술적 상태는 복원해도, 그 체크박스에 담겼던 사업상의 요구는 놓칠 수 있다.

수식은 돌아와도 계산대에 앉지 않는다

삭제된 사용자 정의 필드 관리 문서에 따르면 수식 필드는 복구 후 비활성 상태로 남는다. 편집하고 저장하기 전까지 값 대신 #Error!가 표시된다. 저장할 때 구문 검사가 이뤄지며, 오류가 있으면 해결해야 한다.

원래의 계산식이 존재한다는 것과 현재 데이터를 계산하고 있다는 것 사이에 수동 작업이 들어간다. 복구한 열이 다시 보인다고 보고서의 계산 결과까지 돌아왔다고 넘겨짚기 어려운 이유다.

이름에도 흔적이 남는다. 삭제 시 개발자 이름 뒤에 _del이 붙으며, 같은 개발자 이름을 가진 삭제 필드가 이미 있는 경우는 예외다. 복구해도 붙은 문자는 남는다. 관리 화면의 익숙한 표시 이름만 보고 끝내지 말고 실제 개발자 이름과 관련 구성을 맞춰 봐야 한다.

검색 결과는 즉시 따라오지 않을 수 있다. 복구한 필드와 데이터가 검색에 나타나기까지 잠깐 시간이 걸린다는 것이 공식 설명이다. 검색, 계산, 입력 제약은 각각 다른 상태를 보여 준다. 어느 하나가 정상이라는 이유로 나머지까지 완료 처리하면 복구 보고서가 제품보다 낙관적이 된다.

삭제 중에 누군가 화면 배치를 바꿨다면 그 배치에 필드를 다시 넣어야 한다. 변경하지 않은 보고서와 페이지 배치에는 복구한 필드가 남는다. 제거된 필드 의존 관계도 다시 정의해야 한다. 관계를 원래의 마스터-디테일 관계로 돌리려면 해당 레코드에 필요한 데이터가 있어야 한다. 결국 돌아갈 곳도 삭제 기간 동안 움직였을 수 있다.

사용처 목록에도 사각지대가 있다

정리 작업을 시작하기 전에 사용처 찾기를 누르는 것은 도움이 된다. 공식 기능은 레이아웃, 수식, Apex, 활성 검증 규칙, 보고서 등의 참조를 보여 준다. 다만 그 결과에는 제품이 명시한 범위가 있다.

일부 외래 키 관계를 통해 필드를 사용하는 보고서는 목록에 나오지 않는다. 조회한 사용자가 접근할 수 없는 보고서도 반환되지 않으며, 조인 보고서는 지원하지 않는다. 구독 조직의 관리형 패키지 안에 있던 참조는 제외되지만 설치 후 현지에서 새로 만든 참조는 나타날 수 있다. 목록은 참조 유형 순으로 정렬한 첫 2,000개까지다.

“아무것도 안 나온다”는 결과를 “아무도 안 쓴다”는 결재로 바꾸면 곤란하다. 눈에 보이는 참조를 정리하는 일과 조직의 용도를 조사하는 일은 범위가 다르다. 특히 다른 팀의 비공개 보고서까지 한 화면이 대신 기억해 줄 것으로 기대해서는 안 된다.

Salesforce에는 삭제를 제한하는 조건도 있다. 다른 필드, 필드 업데이트 또는 Apex에서 참조하는 사용자 정의 필드는 삭제할 수 없으며, 백그라운드 작업이 필드를 갱신하는 동안에도 삭제가 막힐 수 있다. 이 제한은 알려진 충돌을 막는다. 업무 책임자가 용도를 확인할 필요까지 대신 없애 주지는 않는다.

복구 기한을 지우는 사람과 손해를 보는 사람

복구할 수 있는 기간은 영구 삭제 또는 15일 경과 중 먼저 오는 시점까지다. 그 안에서는 필드와 데이터를 되살릴 수 있다. 하지만 그 시간을 새로운 프로젝트가 기다려 줄지는 다른 문제다.

삭제한 필드는 하드 삭제가 끝날 때까지 사용자 정의 필드 할당량에 포함된다. 해당 필드 유형의 한도에도 계속 잡힐 수 있다. 새 필드를 만들 자리가 급한 팀에게는 삭제 목록이 미처 치우지 않은 짐처럼 보일 것이다. 기존 업무 담당자에게 같은 목록은 아직 포기하지 않은 복구 선택권이다.

Purge 절차는 준비된 필드를 하드 삭제 과정으로 보낸다. 처리가 시작됐다고 즉시 끝나는 것은 아니며, 완료 시간은 시스템 수요에 따라 달라진다. Background Jobs에서 진행 상태를 확인할 수 있다. 복구 선택권을 버리고도 할당량이 즉시 풀린다고 장담할 수 없는 셈이다.

또 하나의 범위는 필드 생성 오류가 계속될 때의 지원 절차에 있다. 조직 ID와 운영·샌드박스 구분을 제출하고 물리 삭제를 승인해야 한다. 문서는 이 사용자 정의 필드 물리 삭제를 특정 객체 하나로 한정할 수 없으며 조직 전체 범위로 수행한다고 설명한다. 한 객체에서 시작된 용량 문제가 더 넓은 정리 승인으로 이어질 수 있다는 뜻이다.

어떤 보호가 빠졌는지 확정하려면 실제 조직의 저장된 필드 정의, 의존 관계 목록과 업무 검증 결과가 필요하다. 그 자료를 모을 책임은 지금 정할 수 있다. “복구 완료”는 오래된 값이 보이는 순간이 아니라, 필요한 계산과 거절 규칙이 다시 일하는 순간에 붙이는 편이 정확하다.