회의를 시작한 지 10분도 안 됐는데 이런 말이 연달아 나온다.

“이건 버그인가요, 기능 개선인가요?”

“Agentless에서는 타임아웃이 어디에 걸리죠?”

“Entra ID는 SAML하고 SCIM을 같이 써야 하나요?”

“DB는 지원한다면서 왜 View와 Export는 안 되죠?”

처음 듣는 사람에게는 여러 나라의 외계어가 한 회의실에서 동시에 들리는 것 같다. 하지만 하나씩 풀어보면 모두 같은 질문이다.

이 요청은 어느 통로로 들어와서, 어떤 근거로 판단되고, 어디까지 지원되는가?

오늘은 엔터프라이즈 소프트웨어의 티켓 리뷰 미팅을 이해하는 데 필요한 기본 지식을 재미있게 정리해보려고 한다. 특정 회사나 사건 이야기가 아니라, 어떤 B2B 제품팀에서도 반복해서 만나는 운영 원리 이야기다.

1. 버그와 기능 개선은 생김새부터 다르다

버그와 기능 개선은 모두 “제품이 내 기대와 다르다”에서 출발한다. 그래서 처음에는 구분이 어렵다.

하지만 둘은 약속의 종류가 다르다.

버그는 이미 제공하기로 한 기능이 약속대로 동작하지 않는 상태다.

  • 버튼을 눌렀는데 오류가 난다
  • 같은 조건에서 세션이 반복적으로 멈춘다
  • 문서에 지원한다고 적힌 기능이 실행되지 않는다

기능 개선은 현재 약속 밖에 있는 새로운 동작을 원하는 것이다.

  • 기존에 없던 설정 옵션을 추가해달라
  • 역할을 바꿔도 세션을 유지해달라
  • CLI에서 새로운 목록을 조회하게 해달라

식당으로 비유하면 쉽다.

주문한 김치찌개가 차갑게 나왔다면 버그다. 메뉴에 없는 크림 김치찌개를 만들어달라는 요청은 기능 개선이다. 둘 다 손님의 목소리지만 주방이 처리하는 방식은 다르다.

버그는 재현과 수정이 중심이다. 기능 개선은 제품 방향, 다른 사용자에게도 필요한지, 개발·QA·운영 비용, 납기와 계약을 함께 판단해야 한다.

그래서 성숙한 팀은 지원 티켓과 기능 개선 접수 채널을 분리하기도 한다. 지원 티켓은 현재 제품의 장애와 사용 문의를 빠르게 해결하는 통로로 두고, 기능 개선은 별도 메일이나 제품 요청 절차로 받는 식이다.

이건 귀찮게 문을 두 개 만드는 일이 아니다. 응급실과 건강검진 센터를 나누는 일에 가깝다. 모든 요청이 응급실로 몰리면 정말 급한 문제도 느려진다.

2. “안 돼요”는 버그 보고서가 아니다

버그처럼 보이는 현상도 근거가 없으면 개발팀이 바로 움직이기 어렵다.

예를 들어 한 티켓에 이런 내용이 한꺼번에 들어왔다고 해보자.

  • 웹 터미널에서 문자가 이상하게 붙는다
  • 특정 명령 뒤에 화면이 멈춘다
  • SSH 설정을 읽지 못한다
  • CLI 연결이 실패한다

겉으로는 모두 “터미널 문제”지만 실제 원인은 전혀 다를 수 있다. 브라우저의 붙여넣기 처리, 터미널 제어문자, 네트워크, SSH 설정 문법, 운영체제 차이가 각각 범인일 수 있다.

이걸 하나의 티켓에 넣는 건 병원에서 “머리도 아프고 발목도 아프고 소화도 안 됩니다”라고 말한 뒤 한 번에 수술해달라는 것과 비슷하다.

좋은 버그 티켓에는 최소한 다섯 가지가 필요하다.

1. 제품과 클라이언트 버전
2. 운영체제·브라우저·네트워크 등 실행 환경
3. 재현 절차
4. 기대한 결과와 실제 결과
5. 발생 시각의 화면과 로그

로그는 개발자를 위한 숙제가 아니다. 사고 현장의 CCTV다. 화면 캡처가 “무슨 일이 보였는지” 알려준다면 로그는 “내부에서 어떤 순서로 일이 일어났는지” 보여준다.

그리고 서로 다른 증상은 가능하면 나눠야 한다. 그래야 하나를 수정했을 때 무엇이 해결됐는지 검증할 수 있다. 버그 티켓의 품질은 문장 길이가 아니라 재현 가능성으로 결정된다.

3. Agentless는 ‘설치가 없다’는 뜻이지 ‘중간 경로가 없다’는 뜻이 아니다

엔터프라이즈 접근제어 제품에서는 Agent와 Agentless라는 말을 자주 쓴다.

Agent 방식은 사용자 PC에 전용 프로그램을 설치하고, 그 프로그램이 인증과 연결을 중개한다.

Agentless 방식은 전용 프로그램 없이 기존 DB 도구나 표준 클라이언트가 제품의 Proxy에 직접 연결한다. 설치 부담이 줄고 자동화하기 좋지만, “아무것도 거치지 않는다”는 뜻은 아니다.

연결 경로에는 여전히 여러 주자가 있다.

사용자 도구 → 사내 네트워크 → 로드밸런서 → 보안 Proxy → 대상 시스템

그래서 장시간 쿼리가 끊겼다고 해서 곧바로 제품의 세션 타임아웃이라고 단정하면 안 된다.

타임아웃은 릴레이 경기와 비슷하다. 주자 중 한 명이라도 “너무 오래 기다렸다”며 바통을 내려놓으면 연결은 끝난다.

  • 클라이언트의 query timeout
  • 방화벽이나 NAT의 idle timeout
  • 로드밸런서의 connection timeout
  • Proxy의 세션 정책
  • 대상 DB의 statement timeout

장기 작업을 점검할 때는 “제품에 타임아웃이 있나요?”보다 “전체 경로의 각 구간에 어떤 제한이 있나요?”라고 물어야 한다.

또 하나 중요한 것은 인증 정보의 수명이다. Agentless 연결을 오래 열어둘 수 있더라도 사용하지 않는 인증 정보까지 계속 살려둘 필요는 없다. 장기 작업 가능성과 인증 정보 회수 정책은 별개의 문제다.

4. Entra ID, SAML, SCIM은 각각 무슨 일을 할까

Microsoft Entra ID는 기업의 사용자 계정과 로그인을 관리하는 서비스다. 예전 이름은 Azure Active Directory, 줄여서 Azure AD였다.

회사에 입사하면 업무용 Microsoft 계정이 생기고, 부서가 바뀌면 그룹이 바뀌고, 퇴사하면 계정이 비활성화된다. Entra ID는 이런 신원 정보를 관리하는 인사 명부이자 출입증 발급소에 가깝다.

여기에 SAML과 SCIM이 등장한다.

SAML: “이 사람은 우리 회사 직원이 맞아요”

SAML은 로그인 인증을 연결한다.

사용자가 제품에 직접 비밀번호를 입력하는 대신 회사 로그인 화면에서 인증한다. 인증이 끝나면 Entra ID가 제품에 전자 확인서를 보낸다.

호텔로 비유하면 프런트가 신분을 확인하고 객실 키를 발급하는 과정이다. 제품은 모든 투숙객의 신분증을 직접 검사하지 않고, 믿을 수 있는 프런트의 확인을 신뢰한다.

SCIM: “직원 명단이 바뀌었어요”

SCIM은 사용자와 그룹의 생명주기를 동기화한다.

  • 신규 직원 계정 생성
  • 이름·이메일·부서 변경
  • 그룹 추가·제거
  • 퇴사자 비활성화

즉 SAML이 오늘 문 앞에 온 사람이 누구인지 확인한다면, SCIM은 아예 사내 출입 명부를 최신 상태로 유지한다.

둘은 경쟁 기술이 아니다. 역할이 다르다.

SAML = 로그인
SCIM = 사용자·그룹 관리

그래서 기업 환경에서는 SAML로 SSO를 구성하고 SCIM으로 계정과 그룹을 자동 관리하는 조합을 많이 검토한다.

다만 실제 연동에서는 사용자 식별 기준, 이메일 변경, 그룹 매핑, 퇴사자 처리, externalId, 수정 요청 방식 같은 세부 규칙이 중요하다. “SAML과 SCIM을 지원합니다”라는 한 문장만으로는 구축을 완료할 수 없는 이유다.

5. “이 DB를 지원한다”는 말에는 적어도 다섯 개의 뜻이 있다

데이터베이스 지원 범위는 티켓 리뷰에서 가장 자주 생기는 오해 중 하나다.

어떤 DB에 연결할 수 있다고 해서 그 DB의 모든 기능을 지원한다는 뜻은 아니다.

자동차가 고속도로에 진입할 수 있다고 해서 모든 휴게소의 전기 충전기, 하이패스, 주차 기능을 전부 쓸 수 있다는 뜻은 아닌 것과 같다.

DB 지원은 최소한 다음 축으로 나눠 봐야 한다.

  1. 연결: Web 또는 Proxy를 통해 접속 가능한가
  2. 쿼리: SQL 실행과 결과 조회가 가능한가
  3. 메타데이터: Table, View, Schema 구조를 읽을 수 있는가
  4. Export: 결과나 구조 정보를 파일로 내보낼 수 있는가
  5. 보안 기능: 마스킹, 구문 제어, 감사 로그, 변경 전후 데이터 보관을 지원하는가

여기에 제품 버전과 DB 버전까지 붙는다. 같은 DB라도 특정 릴리즈에서 Proxy가 추가되고, 다음 릴리즈에서 HTTPS가 지원되고, 또 다른 릴리즈에서 일부 오류가 수정될 수 있다.

그래서 좋은 지원 문서는 “지원/미지원” 한 칸짜리 표로 끝나면 안 된다.

DB 종류와 버전
제품 버전
Web Editor
Proxy
Table / View 메타데이터
Export
마스킹·감사·스냅샷
제약사항과 우회 방법

이런 기능표가 있으면 CS는 매번 코드를 뒤지지 않아도 되고, 고객은 “연결은 되는데 왜 Export는 안 되나요?”라는 혼란을 줄일 수 있다.

문서는 설명서이면서 동시에 제품의 계약서다. 지원 범위가 정확할수록 티켓도 정확해진다.

6. Draft는 왜 감사 Export에서 빠질 수 있을까

워크플로우에는 Draft, 즉 임시 저장 상태가 있다.

Draft는 아직 제출하지 않은 신청서다. 승인자도 비어 있을 수 있고, 내용도 계속 바뀔 수 있다. 책상 위에 연필로 작성 중인 문서에 가깝다.

반면 감사 로그와 Export는 보통 “실제로 일어난 행위”를 증명하는 데 쓰인다.

  • 누가 요청했는가
  • 누가 승인했는가
  • 언제 실행됐는가
  • 어떤 결과가 남았는가

아직 제출되지 않은 Draft를 정식 감사 이력처럼 취급하면 데이터 구조가 어색해질 수 있다. 승인자가 없는데 승인자 정보를 찾다가 오류가 날 수도 있다.

이런 경우 해결책은 무조건 빈칸을 채우는 것이 아니다. 제품 정책상 Draft를 감사 Export 대상에서 제외하는 편이 더 자연스러울 수 있다.

여기서 배울 점은 간단하다.

오류를 고친다는 것은 코드가 죽지 않게 만드는 것만이 아니라, 그 데이터가 원래 결과에 포함돼야 하는지 정의하는 일이다.

7. 티켓을 닫는 건 문제를 지우는 일이 아니다

티켓을 완료 처리하면 가끔 불안하다.

“요청을 무시하는 것처럼 보이지 않을까?”

하지만 접수 채널과 처리 기준을 명확히 안내한 뒤 티켓을 닫는 것은 문제를 지우는 일이 아니다. 오히려 올바른 통로로 보내는 교통정리다.

버그는 증상별 근거와 함께 지원 티켓으로 들어온다. 기능 개선은 별도 요청 채널에서 제품성과 비용을 검토한다. 사용 문의는 현재 지원 범위와 문서로 답한다.

세 종류를 한 바구니에 넣으면 모든 요청이 “일단 검토 중”이 된다. 이 표현은 편하지만 위험하다. 주인이 없고, 기한이 없고, 종료 조건도 없는 요청이 쌓이기 때문이다.

좋은 종료에는 다음 내용이 남아야 한다.

왜 현재 티켓에서 처리하지 않는가
어느 채널로 다시 요청해야 하는가
다시 접수할 때 어떤 정보가 필요한가
현재 제품에서 가능한 범위는 어디까지인가

이 네 줄이 있으면 완료는 거절이 아니라 다음 행동을 알려주는 표지판이 된다.

외계어를 한 문장으로 다시 번역해보자

이제 회의의 표현을 일상어로 바꿔보자.

  • “버그와 기능 개선을 분리하자”는 말은 응급실과 제품 제안 창구를 나누자는 뜻이다
  • “로그와 재현 절차가 필요하다”는 말은 추측 대신 CCTV를 확보하자는 뜻이다
  • “Agentless 타임아웃을 확인하자”는 말은 연결 전체 릴레이에서 누가 바통을 놓는지 보자는 뜻이다
  • “Entra ID의 SAML·SCIM 가이드가 필요하다”는 말은 로그인과 직원 명부 동기화를 따로 설명하자는 뜻이다
  • “DB 지원 범위를 정리하자”는 말은 연결 가능과 기능별 사용 가능을 구분하자는 뜻이다
  • “Draft를 Export에서 제외한다”는 말은 작성 중인 종이를 확정된 감사 증거와 섞지 말자는 뜻이다

결국 좋은 티켓 리뷰는 어려운 기술 용어를 많이 아는 회의가 아니다.

요청의 종류, 판단에 필요한 근거, 실제 지원 범위, 다음 통로를 명확히 만드는 회의다.

티켓 수가 줄어드는 건 그 다음에 따라오는 결과다. 진짜 목표는 모든 요청이 자기에게 맞는 길을 찾게 만드는 것이다.