SAP ABAP 개발을 Claude Code 데스크톱에 맡겨 본 한 달

FI 쪽 ABAP 유지보수는 대부분 작은 수정입니다. 컬럼 하나 추가, 조건 하나 변경, 덤프 원인 찾기 같은 것들이죠. 그런데 그 작은 수정에도 SE80을 열고, 운송 요청을 고르고, 소스를 찾고, 활성화하고, 테스트하는 반복이 매번 따라붙습니다. 이 반복을 한 달 동안 Claude Code 데스크톱에 맡겨 봤습니다. SAP ADT를 MCP로 연결하는 오픈소스 브릿지 vibing-steampunk의 문서(2026년 10월 9일 v2.61.0)와 나란히 놓고, 어떤 플래그와 도구로 무엇을 막고 무엇을 맡겼는지 정리합니다. 화면은 모두 재구성했고 시스템 ID·계정·운송번호·프로그램명은 가렸습니다.

무엇을 못 하게 할지부터 정했다

조건은 하나였습니다. 운영에 사고를 내지 않을 것. 그래서 처음부터 "무엇을 할 수 있게 할까"보다 "무엇을 못 하게 막을까"를 먼저 정했습니다.

구성은 세 부분입니다. Claude Code 데스크톱은 대화 창이자 작업자이고, 전역 지침(CLAUDE.md), 커맨드 파일, 훅, 메모리를 여기에 둡니다. 브릿지는 Go로 만든 vibing-steampunk(vsp)입니다. 문서는 스스로를 "ADT ↔ MCP 브릿지"라고 소개하고, ADT가 켜진 7.50 이상 시스템이면 쓸 수 있다고 적어 둡니다. Eclipse ADT가 쓰는 API를 그대로 쓰니까 SAP 쪽에 따로 설치할 것이 없고, GetSource, EditSource, SyntaxCheck, RunUnitTests, RunATCCheck, RunQuery 같은 도구가 MCP로 열립니다. 문서가 권하는 hyperfocused 모드는 이 기능들을 SAP(action, target, params) 도구 하나로 묶습니다.

SAP 시스템은 시스템마다 브릿지를 따로 등록하고 권한을 다르게 줬습니다. vsp의 안전 장치는 플래그로 켭니다. --allowed-packages는 쓸 수 있는 패키지를 와일드카드로 제한하고, --read-only는 쓰기 계열을 거절하며, --expect는 SID.CLIENT를 고정해 다른 시스템에서는 일하지 않게 합니다. 운송 요청의 생성·릴리스는 --enable-transports를 켜지 않으면 막혀 있습니다.

SAP 노트

시스템마다 다른 권한으로 등록했다

시스템 ID와 계정은 가렸고, 플래그 이름은 vibing-steampunk v2.61.0 문서 기준

• 개발

  --allowed-packages "Z*,Y*,$*"

  • 사용자 범위로 등록
  • 읽기·쓰기·활성화·단위테스트
  • 쓰기는 Z*·Y*·$* 패키지만

• 품질

  --read-only

  • 사용자 범위, 읽기 전용
  • 읽기와 테스트만
  • 반입 결과를 검증하는 자리

• 운영

  --read-only + rule: no tests

  • 프로젝트 범위에만, 읽기 전용
  • 원인 조사용 조회만
  • 테스트도 돌리지 않음

--read-only는 일반 단위테스트 실행을 막지 않습니다(문서: 위험·치명 등급 테스트가 든 실행만 거절). 그래서 운영 금지는 커맨드 파일 규칙으로 따로 둡니다.

운영은 원인 조사 때 데이터와 소스를 확인하는 용도로만 씁니다. 하나 주의할 점은 --read-only가 모든 실행을 막지는 않는다는 겁니다. v2.59.0 변경 내역을 보면 읽기 전용에서도 위험·치명 등급 테스트가 든 단위테스트 실행만 거절하고 "일반 실행은 그대로 동작"합니다. 그래서 "운영에서는 테스트하지 않는다"는 규칙을 커맨드 파일에 따로 적어 뒀습니다.

개발 루프: /sap-dev

반복 작업은 커맨드 파일 하나로 묶었습니다. /sap-dev <오브젝트> <변경 내용>을 입력하면 아래 순서로 진행됩니다.

1. 프리플라이트: GetSystemInfo로 개발 시스템과 클라이언트가 맞는지 확인합니다. 다르면 바로 멈춥니다. vsp의 --expect를 쓰면 같은 확인을 브릿지 단에서도 걸 수 있습니다.
2. 기준본 저장: 수정 전 소스 전문을 로컬에 저장합니다. 나중에 diff를 볼 기준입니다.
3. 운송 선택: 수정 가능한 요청 중에서 고릅니다. 여러 개면 사람에게 묻고, 하나도 없으면 멈춥니다. 운송 요청 생성은 일부러 막아 뒀습니다.
4. ATC 베이스라인: 수정 전 ATC 결과를 저장합니다. 원래 있던 지적 때문에 게이트가 실패하지 않게 하려는 겁니다.
5. 수정: EditSource로 바꿀 부분만 치환합니다. 기존 줄은 지우지 않고 1열 *로 주석 처리한 뒤, 바로 아래에 새 코드와 변경 태그를 넣습니다.
6. 검증: 미활성 오브젝트 확인 → ABAP Unit → ATC 차등 비교 → 서버 소스를 다시 받아 diff.
7. 사람 체크포인트: 여기서 멈춥니다. 운송 릴리스와 품질 시스템 반입은 사람이 합니다.

SAP 노트

/sap-dev 한 번이 도는 순서

/sap-dev <오브젝트> <변경 내용> · 개발 시스템 안에서만

1. 01

   1 프리플라이트

   GetSystemInfo

   • 시스템·클라이언트 확인
   • 다르면 바로 멈춤
2. 02

   2–4 준비

   GetSource · RunATCCheck

   • 수정 전 소스 전문 저장
   • 수정 가능한 운송 선택(생성은 막음)
   • 수정 전 ATC 결과 저장
3. 03

   5 수정

   EditSource

   • 바꿀 부분만 치환
   • 기존 줄은 1열 *로 주석
   • 아래에 새 코드와 변경 태그
4. 04

   6 검증

   RunUnitTests · RunATCCheck · GetSource

   • 미활성 오브젝트 확인
   • ABAP Unit · ATC 차등 비교
   • 서버 소스를 다시 받아 diff
5. 05

   7 사람 체크포인트

   STOP

   • 여기서 멈춤
   • 운송 릴리스·품질 반입은 사람이

도구 이름은 vibing-steampunk 문서의 이름입니다. 운송 생성·릴리스는 --enable-transports 없이는 막혀 있습니다.

7번이 핵심입니다. 에이전트가 개발 시스템 안에서는 자율적으로 움직이지만, 시스템 경계를 넘는 일은 하지 않습니다. 5번의 주석 처리 방식은 소스 변경 이력을 눈으로 남기는 기존 관행을 그대로 따르게 한 것입니다.

검증 게이트: /sap-qa

반입이 끝나면 /sap-qa <오브젝트> qas로 품질 시스템에서 같은 게이트를 돌립니다. 이 커맨드는 --read-only로 등록한 브릿지만 쓰므로 쓰기 권한이 없습니다. 결과는 단계마다 PASS / FAIL / WARN 한 줄로 나오고, 판정 규칙은 커맨드 파일에 고정해 두었습니다.

• 단위테스트 결과가 classes == []면 통과가 아니라 실패(테스트 없음)입니다.
• ATC는 새로 생긴 P1만 실패로 봅니다. 새 P2는 사람이 검토합니다.
• 선택화면 리포트 실행, 스풀 확인처럼 이 구성에서 자동화하지 않은 항목은 "자동화됨"으로 보고하지 않고 사람이 할 일로 따로 적습니다.

가장 큰 교훈: 조용한 초록

한 달 동안 가장 많이 배운 건 도구가 성공이라고 해도 실제로 성공한 건 아닐 수 있다는 점이었습니다. 직접 확인한 사례들입니다.

• Activate는 존재하지 않는 오브젝트에도 success: true를 돌려줬습니다.
• 같은 메인 프로그램의 인클루드가 여러 개 비활성 상태면, 서버는 "같이 활성화할 목록"을 돌려주는데 브릿지가 이걸 빈 응답으로 읽습니다. 결과는 success: true인데 실제로는 아무것도 활성화되지 않았습니다.
• EditSource가 실패해도 MCP 오류로 오지 않습니다. success: false가 담긴 정상 응답으로 옵니다. 다른 사람 운송 요청이 오브젝트를 잡고 있을 때가 대표적인 경우입니다.
• 인클루드 URL로 SyntaxCheck를 하면 깨진 소스에도 항상 "오류 없음"이 나옵니다. 메인 프로그램 URL로 검사해야 실제로 검사됩니다.
• 신규 오브젝트를 만들 때 테스트 클래스에 구문 오류가 있었는데도 생성과 활성화가 "성공"으로 보고된 적이 있습니다.

SAP 노트

success: true를 다른 길로 다시 확인한다

한 달 동안 직접 겪은 '조용한 초록'과 그때마다 붙인 확인

• 활성화

  → GetInactiveObjects

  • 없는 오브젝트에도 success: true
  • 인클루드 여럿 미활성 → 빈 응답
  • 실제로는 아무것도 활성화 안 됨

• 저장

  → GetSource + diff

  • 실패가 MCP 오류로 오지 않음
  • 정상 응답 안의 success: false
  • 다른 사람 운송이 잡고 있을 때

• 문법 검사·테스트

  → main program · class+method alerts

  • 인클루드 URL 검사는 늘 '오류 없음'
  • 메인 프로그램 URL로 검사
  • classes == []는 실패(테스트 없음)

브릿지 버전에 따라 고쳐졌을 수 있습니다. 쓰는 버전에서 같은 확인을 직접 돌려 보세요.

그래서 원칙을 하나 세웠습니다. 성공 플래그를 믿지 말고 결과를 다른 경로로 다시 확인한다. 활성화는 미활성 오브젝트 목록으로, 저장은 서버 소스를 다시 받아 diff로, 테스트는 클래스 레벨 경보와 메서드 레벨 경보를 둘 다 봅니다. vsp는 릴리스가 잦아서(10월 초에만 v2.59.1, v2.60.0, v2.61.0) 이 중 일부는 이미 고쳐졌을 수 있습니다. 그래도 확인을 빼지는 않았습니다. 이런 함정을 하나 밟을 때마다 커맨드 파일과 메모리에 규칙으로 추가했고, 다음 세션의 Claude는 같은 함정을 밟지 않습니다.

사람 손이 남은 곳과, 문서가 넓혀 둔 곳

처음 구성할 때는 브릿지로 할 수 없다고 보고 사람 몫으로 둔 일이 꽤 있었습니다. 지금 문서와 맞춰 보면 그중 일부는 브릿지가 이미 할 수 있고, 남은 것은 대부분 일부러 열지 않은 것입니다.

• 텍스트 풀(선택 텍스트, 텍스트 기호): 문서에는 vsp texts와 MCP i18n(texts_get/texts_set)으로 ADT 위에서 읽고 쓰는 기능이 있습니다. 쓰기 결과는 먼저 계획으로 보여 주고, 잠금·쓰기·해제·활성화를 한 번에 처리합니다. 프로그램 활성화만으로는 텍스트가 활성화되지 않는다는 주의도 적혀 있습니다. 저는 코드에 '라벨'(042)처럼 리터럴과 텍스트 기호를 같이 써서, 기호를 만들기 전에도 화면에 글자가 나오게 하는 습관을 유지합니다. 이 기능을 쓰는 버전이라면 기호 생성도 /sap-dev 안으로 들어올 수 있습니다.
• 디버거·RFC: 문서는 디버거가 Eclipse와 같은 SAP 자체 ADT 리소스로 돌고 서버에 아무것도 설치하지 않는다고 설명합니다. 예전에 필요하던 WebSocket 핸들러(ZADT_VSP)는 이제 디버깅이나 함수 모듈 호출에 필요하지 않습니다. 다만 리포트 실행과 RFC 호출은 원격 코드 실행 경로라서 이 구성에서는 켜지 않았습니다. --read-only 쪽에서도 RunReport, RFC call은 거절됩니다. 기능 검증은 ABAP Unit 통합 테스트와 RunQuery 집계 비교로 대신합니다.
• 화면(다이나프로)·GUI 상태: 소스에서 없는 화면을 CALL SCREEN해도 문법 검사와 활성화는 통과합니다. 실행할 때 비로소 터집니다. 그래서 화면이 필요한 변경은 인수인계 문서에 "화면 생성 전 실행 불가"라고 적습니다.
• 운송 릴리스·반입: vsp에는 --enable-transports로 여는 운송 기능이 있지만, 처음부터 사람 몫으로 정했고 켜지 않았습니다.

가드레일 세 겹과 메모리

정리하면 세 겹입니다. 첫째, 전역 지침(CLAUDE.md): 위험한 명령은 명시적 승인 없이 실행하지 않고, 파일을 덮어쓰기 전에는 대상을 먼저 확인합니다. 둘째, 커맨드 파일의 하드 룰: 쓰기는 개발 시스템의 Z*/Y*/$* 패키지에만 합니다(브릿지에서도 --allowed-packages로 같은 범위를 겁니다). 다른 사람의 잠금은 강제로 풀지 않습니다. 실패를 통과로 요약하지 않습니다. 셋째, 훅: 셸 명령이 실행되기 전에 파괴적인 명령을 걸러 내는 스크립트가 돕니다.

마지막 규칙인 "부분 성공은 부분 성공이라고 쓴다"가 생각보다 중요했습니다. 에이전트는 결과를 좋게 요약하는 경향이 있는데, SAP에서 "대체로 됐다"는 보고는 반입 후 운영 사고로 이어집니다.

Claude Code의 파일 기반 메모리에는 실측한 사실을 한 건씩 남깁니다. 브릿지 함정, 시스템별 클라이언트 구성, 특정 프로그램의 업무 규칙, 결정 이력과 그 이유 같은 것들입니다. 예를 들어 "품질 시스템에서 데이터가 0건이면 클라이언트를 지정하지 않은 건 아닌지 먼저 의심하라"는 메모가 있습니다. 실제로 이걸 놓쳐서 "데이터 없음"이라고 잘못 판단한 적이 있습니다. 이런 메모가 쌓이면서 같은 실수가 줄었습니다.

한 달 써 보니

잘 되는 일은 원인 조사(소스 추적 + 테이블 조회 + 덤프 확인), 작은 수정과 검증 반복, 수정 전후 비교, 운송 요청 내용 정리입니다. 특히 조사 단계가 가장 빨라졌습니다. 여전히 사람 몫인 일은 업무 판단, 운송 반입, 화면 작업, 실제 트랜잭션 실행 테스트입니다.

가장 중요했던 것은 에이전트에게 권한을 많이 주는 것보다 실패를 실패로 보고하게 만드는 것이었습니다. 브릿지가 할 수 있는 일은 릴리스마다 늘어나지만, 무엇을 켤지는 문서가 아니라 우리 쪽 규칙이 정합니다. 개발 시스템 안의 반복 작업은 에이전트가 맡고, 경계를 넘는 결정은 사람이 합니다. 이 선을 분명히 그어 두니 오히려 안심하고 많이 맡길 수 있었습니다.