공식 Doconut 기능 카탈로그에서는 브라우저 인쇄와 PDF 내보내기를 뷰어 기능으로 명시하고 있습니다. 이러한 기능에 대한 접근을 제어하려면 두 가지 별도 결정을 내려야 합니다. 첫 번째는 Doconut이 해당 동작을 UI에 표시할지 여부이고, 두 번째는 호스트 애플리케이션이 현재 사용자와 문서에 대해 해당 작업을 허가할지 여부입니다.

설치된 빌드에서 지원되는 정확한 제어 항목을 확인하려면 Doconut 문서를 시작점으로 삼고, 공식 Doconut 다운로드 페이지에서 제공되는 패키지 샘플을 참고하십시오. 관련 없는 버전이나 검증되지 않은 기사에서 구성 키나 소스 코드를 복사하지 마세요.

1. 인쇄 정책 먼저 정의하기

툴바를 변경하기 전에 누가 어떤 조건에서 인쇄할 수 있는지 명확히 적어 두세요. 유용한 정책은 다음과 같은 질문에 답합니다.

인쇄가 모든 뷰어에 허용되는가, 특정 역할에만 허용되는가, 혹은 특정 문서에만 허용되는가?
결정이 테넌트, 케이스 상태, 문서 분류 또는 만료 여부에 따라 달라지는가?
인쇄 가능한 출력물에 워터마크가 필요합니까?
인쇄 이벤트를 감사해야 합니까?
사용자가 오래된 문서 리비전을 인쇄할 수 있습니까?
미리보기가 열려 있는 동안 권한이 변경되면 어떻게 해야 합니까?

실제 규칙이 상황에 따라 달라지는 경우 전역 Boolean 하나에 의존하지 마세요. 인쇄를 별도의 작업으로 모델링하여 보기와 다운로드와는 독립적으로 인증할 수 있도록 설계합니다.

2. UI 상태와 인증을 분리하기

호스트 페이지는 애플리케이션이 소유한 권한 결과를 받은 뒤에 인쇄 컨트롤을 표시할지 여부를 결정할 수 있습니다. 이렇게 하면 인쇄가 불가능한 사용자는 UI에서 바로 인식할 수 있어 명확성이 높아집니다.

하지만 컨트롤을 숨긴다고 해서 인증 경계가 생기는 것은 아닙니다. 사용자는 여전히 알려진 엔드포인트를 직접 호출하거나 이전 요청을 재전송하거나, 화면에 표시된 내용을 브라우저 인쇄 기능으로 출력할 수 있습니다. 인쇄 가능한 출력을 생성하는 모든 서버 라우트는 동일한 정책을 강제해야 합니다.

UI에서는 다음과 같이 상태를 구분해서 사용합니다.

상태	뷰어 동작	서버 동작
인쇄 허용	지원되는 인쇄 동작 표시	요청된 출력물을 권한 부여하고 생성
인쇄 거부	명확한 설명과 함께 동작을 숨기거나 비활성화	Forbidden 응답 반환
정책 미확인	권한 로드 중에 동작을 사용할 수 없게 유지	출력물 생성 안 함
세션 만료	사용자에게 재인증 요청	만료된 요청 거부

3. 인쇄 엔드포인트 보호하기

인쇄를 수행하거나 인쇄 가능한 출력을 반환하는 애플리케이션 로직을 보호해야 합니다. 인증 결정에는 테넌트 소속, 소유권, 문서 분류, 워크플로 상태 및 문서 리비전이 모두 고려되어야 합니다. 클라이언트가 제공한 경로나 저장소 URL을 받아들이지 말고, 서버 측에서 문서를 직접 확인하십시오.

애플리케이션이 PDF를 생성하지 않고 뷰어 전용 라우트를 통해 인쇄를 수행한다면, 해당 라우트를 호출하기 전에 동일한 인증 절차를 적용하십시오.

4. 설치된 뷰어 버전 구성하기

서버 규칙이 마련되면, 해당 버전과 샘플 파일에 문서화된 정확한 옵션을 사용해 Doconut UI를 설정합니다. Doconut 라이브 데모를 통해 특정 통합을 결정하기 전에 지원되는 뷰어 동작을 미리 확인할 수 있습니다. 다음 항목을 반드시 검증하세요.

옵션이 설정되는 위치: 서버 구성, 뷰 모델, 혹은 클라이언트 초기화 코드.
옵션이 툴바 항목을 숨기는지, 동작을 비활성화하는지, 혹은 생성된 출력에 영향을 주는지.
값이 뷰어 인스턴스별로 적용되는지 전역적으로 적용되는지.
인쇄와 내보내기가 별개의 작업으로 구분되는지.
업데이트로 옵션 이름이나 기본값이 변경되었는지.

공식 샘플을 진리의 원천으로 삼으세요. 겉보기에는 타당해 보이는 속성 이름만으로는 설치된 뷰어가 이를 인식한다는 증거가 되지 않습니다.

5. 브라우저 인쇄를 솔직하게 다루기

뷰어 설정만으로는 화면에 표시된 정보가 절대 인쇄되거나 캡처되지 않을 것을 보장할 수 없습니다. 브라우저는 호스트 페이지 자체를 인쇄할 수 있고, 사용자는 스크린샷이나 사진을 찍을 수도 있습니다. 키보드 가로채기와 인쇄 전용 CSS는 사용자 경험을 어느 정도 개선하지만, 클라이언트 측에서 완전히 차단할 수는 없습니다.

호스트 페이지에서 실제로 유용한 종이 사본이 생성되지 않도록 하려면, 애플리케이션이 자체적인 인쇄 전용 프레젠테이션을 제공해 미리보드를 설명 메시지로 교체하도록 할 수 있습니다. 이 동작은 Doconut이 문서화한 뷰어 제어와는 별도로 유지하십시오.

이를 “문서 보호”라고 표현하지 마세요. 위험 평가 결과에 따라 서버 측 렌더링, 인증, 제어된 내보내기 및 눈에 보이는 워터마크를 활용하십시오.

6. 다운로드, 내보내기, 인쇄를 별도로 유지하기

사용자와 개발자는 종종 이 네 가지 동작을 하나의 “읽기 전용” 스위치로 취급하지만, 실제로는 서로 다른 데이터 흐름을 가집니다.

View: 렌더링된 콘텐츠를 표시합니다.
Download: 원본 파일 또는 다른 저장 파일을 반환합니다.
Export: 파생 형식을 생성합니다.
Print: 인쇄 가능한 표현을 생성하거나 브라우저 인쇄를 호출합니다.

각 작업에 대해 명시적으로 인증을 부여하십시오. 인쇄가 금지된 사용자는 여전히 다운로드가 허용될 수 있고, 그 반대 상황도 가능합니다. 툴바는 서버의 인증 결과를 반영해야 하며, 서버가 정의한 정책을 대체해서는 안 됩니다.

7. 유용한 감사 이벤트 추가하기

인쇄가 민감한 경우, 문서 자체를 로그에 남기지 않으면서 인증 결정을 기록하십시오. 이벤트에는 사용자, 테넌트, 문서 식별자, 리비전, 정책 결과, 타임스탬프 및 연관 ID가 포함될 수 있습니다.

성공과 거부 시도 모두를 기록하고, 인쇄 서비스가 임시 파일을 생성한다면 정리 여부도 함께 기록하십시오. 파일 경로, 토큰, 개인 데이터가 포함된 문서 제목 및 인쇄 가능한 내용은 일반 로그에 남기지 않도록 주의합니다.

8. 누락된 버튼을 넘어 테스트하기

툴바가 보이는 여부만으로는 충분히 검증되지 않습니다. 전체 작업 흐름에 대한 테스트를 추가하십시오.

인증된 사용자

의도된 인쇄 동작이 화면에 표시됩니다.
허용된 문서에 대해 인쇄 요청이 성공합니다.
올바른 리비전이 사용됩니다.
생성된 출력물에 필요한 워터마크가 표시됩니다.
감사 이벤트에 성공이 기록됩니다.

인증되지 않은 사용자

해당 동작이 없거나 비활성화됩니다.
인쇄 라우트에 대한 직접 요청이 Forbidden 응답을 반환합니다.
문서 ID를 변경해도 정책을 우회할 수 없습니다.
인증된 세션에서 복사한 URL을 부적절하게 재사용할 수 없습니다.
거부 응답이 다른 테넌트가 문서를 소유했는지 여부를 드러내지 않습니다.

상태 변화

세션 중 권한이 회수되면 다음 인쇄 요청에 즉시 적용됩니다.
세션이 만료되면 인쇄가 불가능합니다.
삭제되거나 대체된 문서는 제어된 오류를 반환합니다.
임시 인쇄 출력은 설정된 보존 규칙을 따릅니다.

브라우저 자동화를 활용하면 가시적인 UI 상태와 HTTP 응답 코드를 검증할 수 있습니다. 통합 테스트에서는 정책 평가와 문서 수준 인증을 독립적으로 확인해야 합니다.

일반적인 질문

인쇄 버튼을 숨겨도 브라우저의 인쇄 단축키를 막을 수 있나요?
아니요. 이는 설치된 뷰어가 해당 동작을 구현한 경우에만 의도된 뷰어 액션을 제거합니다. 브라우저 인쇄와 화면 캡처는 별도의 고려가 필요하며, 클라이언트 측 코드만으로는 완전히 차단할 수 없습니다.

인쇄 권한을 뷰잉 URL에 포함시켜야 하나요?
인증된 사용자, 문서 및 작업에 연계된 서버 측 인증 결정을 사용하는 것이 바람직합니다. 임시 참조가 권한을 포함해야 할 경우, 범위를 최소화하고 로그와 리퍼러에서 보호하며, 민감한 작업을 수행하기 전에 반드시 재검증하십시오.

기밀 문서에 대해 인쇄 비활성화만으로 충분한가요?
아니요. 인쇄 비활성화는 사용성 또는 억제 제어 중 하나에 불과합니다. 기밀 워크플로에는 저장소 보호, 객체 수준 인증, 제어된 내보내기, 보존 규칙, 모니터링 및 허용 가능한 잔여 위험 모델이 추가로 필요합니다.

결론

신뢰할 수 있는 Doconut 인쇄 제어 구현은 서버에서 시작해 인터페이스에서 마무리됩니다. 정책을 정의하고, 작업을 보호하며, 설치된 뷰어에 대해 문서화된 옵션만 구성하고, 사용자에게 결과를 명확히 안내하며, 직접 요청과 툴바 가시성을 모두 테스트하십시오. 구현 소스로는 공식 기능 페이지, 문서, 다운로드 및 데모를 활용하고, 기사에서 제품 코드를 재작성하지 마세요.