SAP 전송 요청과 태스크: 릴리스했는데 왜 운영에 안 보일까
“태스크를 릴리스했는데 운영 화면은 그대로예요.” 이 말을 들으면 먼저 무엇을 릴리스했는지부터 확인해야 합니다. SAP의 태스크 완료, 상위 전송 요청의 릴리스, 대상 시스템의 가져오기는 서로 다른 단계입니다. 내 작업이 끝났다는 표시만으로 다른 시스템에 변경이 들어갔다고 판단할 수는 없습니다.
여기서는 SAP NetWeaver AS ABAP의 전통적인 CTS에서 전송 가능한 Workbench 요청을 예로 듭니다. 클라우드의 다른 전송 방식이나 로컬 요청까지 같은 흐름이라고 가정하지 않습니다. 아래 R·A·B와 개발·검증·운영의 상태는 개념을 설명하기 위한 가상 사례이며, 실제 회사 시스템에서 실행한 결과가 아닙니다.
1. 요청은 함께 옮길 묶음, 태스크는 그 안의 작업
조회 프로그램의 문구와 출력 항목을 고치는 변경을 생각해 보겠습니다. 담당자 A와 B가 하나의 변경 목적 아래 각자 작업한다면, 상위 요청 R 아래에 두 사람의 태스크를 두는 구조로 이해할 수 있습니다. 태스크는 담당자의 변경 오브젝트를 기록하고, 요청은 함께 전송할 변경을 관리하는 상위 단위가 됩니다.
그림에서 위아래 연결은 시간 순서가 아니라 포함 관계입니다. 요청 번호 하나와 그 아래 태스크 번호들은 서로 다른 식별자입니다. 태스크 A의 번호를 전달하면서 “이 요청이 운영에 들어갔나요?”라고 묻기보다, 상위 요청 R을 함께 확인해야 대상 시스템에서 어떤 전송 결과를 찾아야 하는지 분명해집니다.
태스크가 두 개라는 이유로 프로그램이 두 개만 들어 있다는 뜻도 아닙니다. 사람 수, 태스크 수, 변경 오브젝트 수는 일대일로 대응하지 않습니다. 요청의 설명이 “조회 문구 수정”이어도 실제 오브젝트 목록에는 예상보다 넓은 변경이 모여 있을 수 있습니다. 이름만 읽고 범위를 짐작하기보다 목록과 변경 목적을 대조하는 이유입니다.
또한 Workbench 요청과 Customizing 요청은 같은 말이 아닙니다. 개발 오브젝트와 설정 변경에는 요청 유형과 대상 클라이언트에 관한 차이가 있습니다. 이 글의 프로그램 변경 예제를 모든 설정 이관에 그대로 적용하지 말고, 우선 지금 보고 있는 요청의 유형과 전송 대상을 확인하세요.
2. 태스크 릴리스는 다른 시스템으로 보내는 버튼이 아니다
담당자 A가 태스크를 릴리스하면 그 태스크의 오브젝트 항목이 상위 요청의 목록에 모입니다. A의 작업을 상위 묶음에 넘기는 단계로 이해하면 쉽습니다. 이때 오브젝트의 잠금이 곧바로 풀리는 것은 아니며, 태스크 릴리스만으로 대상 시스템에 변경을 가져오는 작업이 수행되는 것도 아닙니다.
가상 사례에서 A는 끝났지만 B의 태스크는 아직 수정 가능 상태라고 해보겠습니다. A가 “릴리스 완료”라고 말한 것은 A의 태스크에 대한 설명입니다. 요청 R 전체가 내보내졌다는 보고로 바꾸어 읽으면 안 됩니다. 상위 요청을 릴리스하려면 그 안의 태스크들이 먼저 릴리스되어 있어야 합니다.
반대로 모든 태스크가 릴리스됐다고 해서 상위 요청까지 자동으로 릴리스된 것으로 생각해서도 안 됩니다. 태스크 목록에서 각각의 상태를 확인한 다음 상위 요청의 상태를 따로 읽어야 합니다. 화면에서 하위 줄 하나만 보고 완료를 판단하는 습관을 줄이는 것이 첫 번째 점검입니다.
3. 요청 릴리스와 내보내기 결과도 함께 확인한다
전송 가능한 요청을 릴리스하면 변경 내용을 다른 시스템으로 옮기기 위한 내보내기, 즉 export가 진행됩니다. 다만 릴리스 동작 직후에는 내보내기가 아직 끝나지 않았을 수 있습니다. “버튼을 눌렀다”, “요청 상태가 바뀌었다”, “내보내기 로그를 확인했다”를 같은 근거로 취급하지 않는 편이 정확합니다.
예를 들어 요청 R의 태스크가 모두 끝났고 요청 릴리스도 수행됐지만, 내보내기 결과는 아직 읽지 않았다고 가정해보세요. 이때 가능한 보고는 “요청 릴리스 수행, 내보내기 결과 미확인”입니다. 로그에 문제를 나타내는 메시지가 있다면 그 내용을 확인해야 하고, 확인하지 않은 상태를 성공으로 채워 넣어서는 안 됩니다.
내보내기가 끝났더라도 운영 반영 여부는 다음 질문으로 남습니다. 전송 경로와 조직의 승인 절차에 따라 어떤 대상에서 언제 가져올지가 달라질 수 있기 때문입니다. 내보내기는 출발 쪽에서 변경을 전송할 준비를 하는 단계이고, 가져오기인 import는 대상 쪽에 반영하는 단계입니다. 두 동작을 한 단어인 “반영”으로 묶으면 대화가 쉽게 어긋납니다.
4. 같은 요청도 검증과 운영에서 상태가 다를 수 있다
개발에서 내보낸 요청 R을 검증 시스템에 가져왔고, 운영으로 가져왔는지는 아직 확인하지 않았다고 해보겠습니다. 검증 화면에서 새 문구가 보인다는 사실은 검증 환경에 관한 근거입니다. 운영 화면에도 같은 문구가 보여야 한다는 결론까지 자동으로 이어지지는 않습니다. 환경을 바꾸면 다시 그 환경의 전송 결과를 확인해야 합니다.
이때는 먼저 요청 R과 대상 시스템이 맞는지 확인하고, 필요한 경우 대상 클라이언트까지 구분합니다. 이어 해당 대상의 가져오기 이력과 로그에서 어느 시점에 무엇이 처리됐는지를 읽습니다. 요청이 대상의 가져오기 대기열에 보이는 것과, 실제 가져오기를 수행한 기록이 있는 것도 다릅니다.
대기열에 있다는 이유만으로 가져오기를 임의 실행하는 것은 이 글의 해결책이 아닙니다. 실행 담당자와 승인, 다른 변경과의 선후 관계를 확인해야 합니다. 화면이 예전과 같다고 동일한 요청을 반복해서 가져오기 전에, 현재까지 확보한 근거와 아직 확인하지 못한 단계를 분리해 두는 것이 우선입니다.
가져오기 로그 확인 뒤에는 업무 동작도 대조합니다. 가상 사례라면 “프로그램이 존재한다”에서 끝내지 않고, 의도한 화면에서 새 문구와 출력 항목이 보이는지를 확인하는 식입니다. 기술적인 전송 결과와 원하는 기능이 맞게 동작하는지는 연결되어 있지만, 확인하는 대상이 다릅니다.
5. “릴리스 완료” 대신 어느 단계인지 말하기
동료에게 상태를 전달할 때는 문장을 조금만 구체화해 보세요. “태스크 A 릴리스 완료, 태스크 B 진행 중”이면 상위 요청 전송 전이라는 상황을 이해할 수 있습니다. “요청 R 내보내기 결과 확인, 검증 가져오기 확인, 운영 가져오기 미확인”이면 운영 반영까지 확인됐다는 오해를 줄일 수 있습니다.
실제 기록에는 각 근거를 읽은 시각과 대상 환경을 붙입니다. ‘미확인’은 곧 실패를 뜻하지 않습니다. 아직 읽지 않은 결과를 표시하는 말입니다. 담당자가 결과를 확인하면 그 시각과 내용을 갱신하고, 문제가 발견되면 어떤 단계의 어떤 메시지인지 좁혀 적으면 됩니다.
처음 질문으로 돌아가면 확인 순서는 명확해집니다. 내가 본 것은 태스크인가 상위 요청인가, 내보내기 결과까지 확인했는가, 어느 대상의 가져오기를 확인했는가, 그곳에서 원하는 동작을 확인했는가. 이 네 질문에 각각 답하면 “릴리스했는데 안 보인다”는 막연한 상태를 다음에 확인할 위치가 있는 구체적인 문제로 바꿀 수 있습니다.