SAP BOX

'26/10/29 UPDATE

ABAP / FIELD NOTES

Code Inspector·ATC 경고, 코드에서 숨기는 것과 면제받는 것은 무엇이 다를까

Code Inspector는 검사할 대상과 검사 변형을 묶고, ATC는 개발 중·전송 릴리스·중앙 점검의 세 관문에서 검사를 돌릴 수 있고 실행마다 전역 Code Inspector 검사 변형을 씁니다. 경고를 소스 안에서 숨기는 프라그마·의사 주석과 품질 관리자의 승인을 거치는 면제가 무엇을 어디서 누가 덮는지 나란히 봅니다.

가상의 Z 프로그램을 ATC로 점검했더니 경고가 하나 남았다고 해 봅시다. 바로 고치기 어려운 경고라면 길은 두 갈래입니다. 소스 코드에 ##나 "#EC로 시작하는 표시를 달아 그 자리에서 숨기거나, 면제를 신청해 품질 관리자의 승인을 받는 것입니다. 이 글을 읽고 나면 Code Inspector와 ATC가 어떻게 이어져 있는지, 그리고 프라그마·의사 주석·면제가 각각 어떤 경고를 어디서 누가 덮는지 구분해, 경고 하나마다 어느 쪽이 맞는지 고를 수 있습니다.

예시의 프로그램 ZDEMO_ATC_MASKS, Z 테이블, 검사 이름(ZDEMO_…)은 모두 지어낸 것이고 코드는 실제 시스템에서 실행하지 않았습니다. 프라그마와 의사 주석은 ABAP 키워드 문서 7.58판, ATC와 Code Inspector의 절차는 SAP NetWeaver 7.5 도움말을 기준으로 정리했습니다. 문서는 영어이고, 메뉴 이름과 화면은 릴리스에 따라 다를 수 있습니다.

Code Inspector는 무엇을, 무엇으로 검사할지 묶는다

Code Inspector(트랜잭션 SCI)는 저장소 오브젝트를 정적으로 검사하는 도구입니다. 성능, 보안, 문법, 이름 규칙을 봅니다. 검사 하나는 세 조각으로 짭니다. 먼저 오브젝트 집합이 무엇을 검사할지 정합니다. 프로그램, 함수 그룹, 클래스, DDIC 오브젝트를 패키지·응용 컴포넌트·담당자 같은 조건으로 고릅니다. 조건만 저장해 두면 검사를 돌릴 때마다 목록을 새로 만들기 때문에, 오브젝트가 자주 생기고 지워지는 패키지에 알맞습니다.

다음으로 검사 변형이 무엇으로 검사할지 정합니다. 쓸 검사 항목을 켜고 필요한 속성을 넣습니다. 시스템에는 DEFAULT라는 전역 검사 변형이 있어서, SE11·SE24·SE37·SE38·SE80에서 Code Inspector를 부르면 이 변형을 씁니다. 다만 사용자가 로컬 검사 변형 DEFAULT를 만들면 그것을 대신 씁니다. 전역 검사 변형은 전송 가능으로 표시해 다른 시스템으로 옮길 수 있습니다. 마지막으로 검사 실행(Inspection)이 둘을 묶어 돌립니다. 재사용 검사는 정의와 결과를 저장해 두고 다시 돌리거나 백그라운드 작업으로 예약할 수 있습니다. 대상이 50개를 넘으면 재사용 검사를 써야 합니다.

SAP 노트

Code Inspector 검사는 세 조각으로 짠다

트랜잭션 SCI · SAP NetWeaver 7.5 도움말 기준

  1. 오브젝트 집합

    Package ZDEMO_*

    • 무엇을 검사할지 묶는다
    • 패키지·응용 컴포넌트·담당자로 고른다
    • 조건만 저장하면 실행 때 목록을 새로 만든다
  2. 검사 변형

    ZDEMO_VARIANT / DEFAULT

    • 무엇으로 검사할지 고른다
    • 검사 항목을 켜고 속성을 정한다
    • 전역 변형은 다른 시스템으로 전송할 수 있다
  3. 검사 실행(Inspection)

    ZDEMO_INSP

    • 대상과 검사 변형을 묶어 돌린다
    • 재사용 검사는 정의와 결과를 저장한다
    • 대상이 50개를 넘으면 재사용 검사로

이름(ZDEMO_…)은 가상입니다. 화면 이름과 메뉴는 릴리스마다 다를 수 있습니다.

Code Inspector는 검사할 대상(오브젝트 집합)과 돌릴 검사(검사 변형)를 따로 만들고, 검사 실행이 둘을 묶습니다. SE38 같은 편집기에서 부르는 점검은 전역 DEFAULT 검사 변형을, 사용자가 같은 이름의 로컬 변형을 만들었으면 그것을 씁니다.

ATC는 개발 흐름의 세 관문에서 검사를 돌릴 수 있다

ABAP Test Cockpit(ATC)은 저장소 오브젝트에 여러 검사를 돌리고 결과를 평가하는 틀로, ABAP Workbench·ABAP Development Tools와 전송 시스템(CTS)에 붙어 있습니다. 둘의 관계를 한 줄로 말하면, ATC는 실행할 때마다 전역 Code Inspector 검사 변형 하나를 씁니다. 어떤 검사를 돌릴지는 여전히 Code Inspector 검사 변형이 정하고, ATC는 그 검사를 언제 어디서 돌리고 결과를 누가 다룰지를 맡습니다. 확장 프로그램 검사(SLIN)의 ATC 관련 검사도 ATC의 프로그램 검사에서 함께 돕니다.

ATC가 검사를 돌릴 수 있는 자리는 셋입니다. 개발 중에는 개발자가 편집기에서 바로 돌리고, 그 결과는 개발자 자신의 확인용입니다. 전송 점검을 켜 둔 시스템에서는 전송 요청을 릴리스할 때 시스템이 요청에 든 오브젝트를 백그라운드에서 자동으로 검사하고, 그 결과가 릴리스를 멈출 수 있습니다. 그래서 릴리스 전에 직접 한 번 돌려 보는 것이 권장 단계입니다. 이 점검은 SE03에서 허용하는데, 늘 점검하도록(Globally activated) 둘 수도 있고 사용자가 허락할 때만 점검하도록(Set by User) 둘 수도 있습니다. 결과가 나와도 개발자가 넘기고 릴리스하게 둘지, 고치거나 면제받을 때까지 막을지, 점검을 끌지는 트랜잭션 ATC의 Configure ATC에서 정합니다. 셋째는 품질 관리자가 보통 통합(integration)이나 컨솔리데이션(consolidation) 시스템에서 돌리는 중앙 점검으로, 이것이 '공식' 결과입니다. 결과마다 우선순위가 붙는데, 우선순위 1과 2는 대개 빨리 고쳐야 할 심각한 문제를 뜻합니다. 중앙 점검 결과는 개발 시스템으로 복제해 개발자가 보게 할 수 있습니다. 전송 요청과 릴리스가 낯설다면 전송 요청과 태스크를 다룬 글을 먼저 보셔도 됩니다.

SAP 노트

ATC는 세 관문에서 검사할 수 있다

ATC 실행마다 전역 Code Inspector 검사 변형을 쓴다

  1. 개발 중

    ATC check (local)

    • 개발자가 편집기에서 바로 점검한다
    • 결과는 자기 확인용이다
    • 고친 뒤 다시 점검한다
  2. 전송 요청 릴리스

    Release -> ATC

    • 요청 안의 오브젝트를 자동으로 점검한다
    • 결과가 릴리스를 멈출 수 있다
    • 릴리스 전에 직접 돌려 보길 권한다
  3. 품질 시스템 중앙 점검

    Priority 1, 2

    • 품질 관리자가 일괄 점검을 돌린다
    • 결과를 개발 시스템으로 보낼 수 있다
    • 우선순위 1·2는 대개 빨리 고칠 문제

SAP NetWeaver 7.5 ATC 도움말 기준입니다. 릴리스 점검을 켤지, 늘 돌릴지 사용자가 허락할 때만 돌릴지, 막을지는 설정으로 정합니다.

ATC는 개발 흐름의 세 자리에서 검사를 돌릴 수 있고, 실행마다 전역 Code Inspector 검사 변형을 씁니다. 개발 중의 결과는 개발자 몫이고, 중앙 점검 결과가 품질 관리자가 보는 '공식' 결과입니다.

소스 안에서 숨기기: 프라그마와 의사 주석

결과를 고칠 수 없거나 고칠 까닭이 없을 때 가장 가까운 방법은 소스 코드에 표시를 다는 것입니다. 무엇을 다는지는 경고를 낸 검사에 따라 다릅니다. 문법 검사와 확장 프로그램 검사의 경고는 프라그마로 숨깁니다. 프라그마는 ##NEEDED처럼 ##로 시작하는 프로그램 지시어이고, 그 문장, 곧 다음 마침표나 쉼표에서 끝나는 문장에만 효력이 있습니다. 어떤 프라그마를 쓸지는 그 메시지의 설명에 나옵니다.

확장 프로그램 검사의 경고는 예전에는 "#EC NEEDED 같은 의사 주석으로 숨겼습니다. 프라그마가 들어오면서 이런 의사 주석에는 모두 대응하는 프라그마가 생겼고, 확장 검사용 의사 주석은 폐기된 문법이 되었습니다. 대응표는 프로그램 ABAP_SLIN_PRAGMAS가 보여 줍니다. 프라그마로 경고를 끄는 프로그램에서는 의사 주석 "#EC *와 SET EXTENDED CHECK 문을 더 쓸 수 없고, 쓰면 끌 수 없는 확장 검사 경고가 납니다.

반면 Code Inspector의 경고는 지금도 의사 주석으로 숨깁니다. "#EC CI_BUFFJOIN처럼 CI_로 시작하는 약어를 문장 뒤에 붙이면 그 문장에서 해당 경고가 사라집니다. 이 의사 주석은 아직 프라그마로 바뀌지 않았습니다. 한 줄에는 의사 주석을 하나만 쓸 수 있어서, 한 문장에서 경고 여러 개를 숨기려면 문장을 여러 줄로 나눠야 합니다. ABAP 프로그래밍 지침은 의사 주석을 작성자가 이 경고를 확인했고 이유가 있어 일부러 숨겼다는, 읽는 사람을 위한 표시로 봅니다. 그 이유는 일반 주석으로 함께 적어 둘 수 있습니다.

SAP GUI ABAP 편집기 화면에 번호 세 개가 있다. 1은 DATA lv_unused TYPE string ##NEEDED.의 프라그마, 2는 DATA lv_old TYPE string. 뒤의 옛 의사 주석 "#EC NEEDED, 3은 zdemo_head와 zdemo_item을 INNER JOIN하는 SELECT 줄 끝의 "#EC CI_BUFFJOIN이며 바로 위 줄에 애플리케이션이 직접 버퍼링한다는 일반 주석이 있다.
프라그마, 확장 검사용 옛 의사 주석, Code Inspector 의사 주석을 한 화면에 놓은 예시. ZDEMO_ATC_MASKS와 Z 테이블·필드는 가상이고 코드는 실행하지 않았으며, 각 표시가 숨기는 경고는 문서의 규칙으로 따진 것이다.

소스 밖에서 덮기: 면제는 승인을 거친다

소스 안의 표시로 숨길 수 없는 경고도 있고, 표시를 달기보다 승인 기록을 남겨야 할 경우도 있습니다. 문서가 드는 예는 다음 개발 주기에 고치기로 한 문제이거나, 테스트 프로그램에만 해당하는 경우입니다. 이때 ATC에서는 면제(exemption)를 신청합니다. 신청할 때는 면제의 범위를 정하고 승인자와 이유를 적습니다. 품질 관리자가 승인하면 면제가 그 오류나 경고를 덮어, 새 ATC 결과에 미해결로 나오지 않습니다. 면제는 임시로도 영구로도 걸 수 있습니다.

범위에는 하한이 있습니다. 가장 좁게 잡아도 한 서브오브젝트, 곧 인클루드 하나나 클래스의 메서드 하나 안에 있는 그 검사 메시지 전부가 대상입니다. 문장 하나만 덮는 프라그마·의사 주석보다 넓습니다. 또 면제는 중앙 점검의 활성 결과에 대해 신청해야 이후의 중앙 점검에 반영됩니다. 개발 중에 직접 돌린 결과에 신청하는 것은 의미가 없습니다. Code Inspector에도 같은 구조가 있습니다. 의사 주석으로 숨길 수 없는 경고는 예외(exception)를 신청하고 품질 관리자가 승인합니다. 결과 화면에 예외 아이콘이 없는 메시지는 어떤 방법으로도 덮을 수 없습니다.

SAP 노트

숨기는 자리와 정하는 사람이 다르다

소스 안의 두 가지, 소스 밖의 한 가지

  • 프라그마 ##…

    DATA lv_x TYPE string ##NEEDED.

    • 문법 검사·확장 프로그램 검사 경고
    • 그 문장에만 효력이 있다
    • 쓸 프라그마는 메시지 설명에 나온다
  • 의사 주석 "#EC CI_…

    "#EC CI_BUFFJOIN

    • Code Inspector 경고
    • 그 문장에만, 한 줄에 하나
    • 아직 프라그마로 바뀌지 않았다
  • 면제(예외)

    approver + reason

    • 소스 밖에서 신청한다
    • 품질 관리자가 승인해야 효력이 난다
    • 최소 범위는 한 서브오브젝트의 그 메시지 전부
    • 임시로도 영구로도 덮을 수 있다

ABAP 키워드 문서 7.58(Pragmas, Pseudo Comments)과 NW 7.5 ATC·Code Inspector 도움말 기준입니다.

프라그마와 의사 주석은 개발자가 소스에 직접 적고 그 문장에만 듣습니다. 면제는 소스에 남지 않고 품질 관리자의 승인을 거칩니다.

경고 하나를 앞에 두고 고르는 순서

세 가지를 나란히 놓으면 차이는 자리와 결정하는 사람입니다. 프라그마와 의사 주석은 개발자가 소스에 직접 적고, 코드와 함께 남아 다음 사람이 읽습니다. 면제는 소스에 흔적이 남지 않는 대신 품질 관리자의 승인을 거치고, 덮는 범위가 서브오브젝트 단위로 넓습니다. 그러니 먼저 고칠 수 있는지 보고, 고칠 수 없다면 그 경고가 이 문장에 한해 정당한지 따져 봅니다. 그렇다면 메시지 설명에 나온 프라그마나 의사 주석을 달고, 아니라면 면제로 승인을 받는 쪽을 검토합니다.

숨기는 쪽에도 선이 있습니다. 확장 프로그램 검사 지침은 실제 문제를 가리키는 경고는 프라그마로 숨기지 말고 고치라고 하고, 범위를 가리지 않는 의사 주석이나 프라그마가 검사의 효과를 지울 수 있다고 적습니다. 소스 구간 전체의 확장 검사 메시지를 끄는 SET EXTENDED CHECK OFF는 쓰지 말라고 합니다.

오늘 할 일은 하나입니다. 숨기려는 경고가 있다면 표시를 달기 전에, 그 이유를 바로 옆 한 줄 주석으로 적어 보세요. 한 줄로 적기 어렵다면 고칠 수 있는지 먼저 다시 보고, 그래도 고칠 수 없다면 그 경고는 소스가 아니라 면제 신청에서 품질 관리자와 함께 다룰 일일 가능성이 큽니다.

끝 · END OF NOTE
RSS 구독목록으로
COMMENTS BOX

이 기록에 대화를 더해 주세요.

궁금한 점, 다른 접근, 직접 해 본 결과를 나눠 주세요.

최신순

로그인 상태 확인 중…

댓글을 불러오는 중…