최근 프로젝트를 하면서,
17년 동안 SAP ERP 프로젝트를 해오며 처음 겪는 상황을 마주했다.
개발자에게 구현 내용을 리뷰하면서 몇 가지를 지적했는데,
돌아온 답변이 이랬다.
“그건 스펙에 없는 기능이라 개선사항입니다.”
순간 내가 잘못 들은 건가 싶었다.
웹 SI 프로젝트라면 이해할 수도 있겠지만,
SAP ERP 프로젝트에서, 그것도 FD 기반 개발에서 듣게 될 말은 아니었기 때문이다.
내가 문제라고 느꼈던 구현 사례들
구체적으로 이런 것들이었다.
- 코드 선택 필드가 콤보박스가 아니라 자유 입력
- 통화키(WAERS)도 입력 가능한 필드
- 상태값, 코드값에 대한 기본적인 validation 없음
이걸 보고 “이건 나중에 반드시 사고 난다”는 생각이 먼저 들었다.
그래서 수정이 필요하다고 이야기했는데,
개발 쪽에서는 이렇게 정리했다.
“FD에 명시돼 있지 않으니 개선사항입니다.”
그럼 이제 FD에 이런 것까지 다 써야 하는 걸까?
솔직히 고민이 됐다.
“이제는 FD에
콤보박스 여부, 입력 가능/불가능,
텍스트 입력 길이, 제한 조건까지
전부 적어야 하는 걸까?”
하지만 곰곰이 생각해보면,
나는 그렇게 해본 적도 없고, 그렇게 배운 적도 없다.
SAP에서 FD란 원래 어떤 문서였나
지금까지 내가 경험해온 SAP 프로젝트에서
FD는 이런 문서였다.
- 업무 프로세스를 설명하는 문서
- 데이터가 어디서 오고, 어디로 가는지 정리한 문서
- 필드의 업무적 의미와 책임을 정의하는 문서
반대로, 이런 것들은 FD의 영역이 아니었다.
- 입력 박스의 길이(px)
- 콤보박스인지 드롭다운인지
- 텍스트 최대 입력 길이
이런 건 보통
- DDIC 도메인
- 체크 테이블
- Value Help
- (요즘이라면) CDS Annotation과 Fiori 표준
에서 자연스럽게 결정됐다.
즉,
UI는 설계 대상이라기보다, 데이터 모델의 결과였다.
Fiori Elements라서 달라진 걸까?
이번 프로젝트는
Fiori Elements + Extension 구조였다.
그래서 처음엔 나도 잠깐 헷갈렸다.
“혹시 요즘은 다른 건가?” 싶어서.
그런데 다시 생각해보면,
오히려 Fiori Elements이기 때문에 더더욱 그렇지 않다.
Fiori Elements의 전제는 명확하다.
UI는 메타데이터에서 자동 생성된다.
그래서 정상적인 전제는 이런 것들이다.
- 코드, 통화, 상태값은 자유 입력이 아니다
- Value Help가 있으면 선택 UI가 된다
- 필드 길이와 입력 제한은 도메인에 따른다
이걸 하나하나 FD에 다 적기 시작하면,
그건 SAP 프로젝트가 아니라
웹 화면 외주 명세서에 가까워진다.
이게 요즘, 2026년 AI 시대의 뉴노멀일까?
내 결론은 아니다다.
AI 시대일수록 더 중요해지는 건 오히려
- 데이터 무결성
- 표준
- 도메인 지식
지금 겪은 상황은
시대가 앞서가서 생긴 문제가 아니라,
ERP 경험과 기준이 중간에서 끊긴 결과에 가깝다고 느꼈다.
마치며
17년 동안 해오던 방식이
어느 날 갑자기 통하지 않는 느낌을 받을 때가 있다.
그럴 때
“내가 뒤처진 건가?”라는 생각도 들지만,
이번 경험을 통해서는 오히려 이렇게 느꼈다.
사람이 바뀐 게 아니라, 기준이 사라지고 있다는 신호일 수도 있겠구나.
#SAP프로젝트 #스펙작성 #FD #TD #구현단계이슈 #구현단계
