ASP.NET에 플러그인 없이 문서 뷰어 삽입하기
2026. 7. 10.

ASP.NET에 플러그인 없이 문서 뷰어 삽입하기

ASP.NET Core, MVC 또는 WebForms 프로젝트에 Doconut App의 보안된 무플러그인 문서 뷰어를 삽입해야 하는 .NET 엔지니어를 위한 단계별 가이드.

플러그인 없이 문서 뷰어를 ASP.NET Core, MVC 또는 WebForms 애플리케이션에 삽입하면 사용자가 아무것도 설치하도록 요구하지 않을 수 있습니다.
계약서, 도면, 디자인 자산 등을 제공하는 기업은 기업 보안 정책을 준수하고 레거시 브라우저 플러그인을 강제로 설치시키지 않는 뷰어가 필요합니다. Doconut 은 브라우저 기반 PDF, Office, CAD, 이메일 및 이미지 워크플로를 위한 .NET 문서 뷰어 SDK를 제공합니다. 이것은 호출하는 호스팅 서비스가 아니라 여러분의 애플리케이션에 설치하여 그 안에서 렌더링하는 형태입니다. 이 글에서는 버전‑특정 샘플 코드를 사용하지 않고 통합 결정을 설명합니다.

먼저 한 가지를 명확히 해야 합니다. 두 제품은 쉽게 혼동될 수 있습니다. Doconut.app 은 무료 웹 뷰어이며 — 하나의 파일을 브라우저 탭에서 열고 이후 삭제됩니다. 이것은 삽입하는 것이 아니라 서비스 형태입니다. 여러분이 삽입하는 것은 Doconut Viewer SDK이며, 아래 내용은 모두 그것에 관한 것입니다.

제어된 ASP.NET 백엔드와 연결된 임베디드 문서 뷰어
제어된 ASP.NET 백엔드와 연결된 임베디드 문서 뷰어

1. .NET 웹 앱에서 보안 및 무플러그인 렌더링이 중요한 이유

현대 기업은 모든 문서를 잠재적인 데이터 유출 위험으로 간주합니다. ActiveX, Flash 또는 네이티브 클라이언트에 의존하는 뷰어를 삽입하면 다음과 같은 세 가지 위험을 물려받게 됩니다:

위험.NET 애플리케이션에 미치는 영향Doconut App이 이를 제거하는 방법
플러그인 의존성사용자가 브라우저 플러그인을 설치하거나 활성화해야 하며, 이는 지원 티켓과 컴플라이언스 문제를 야기합니다.Doconut은 HTML5/Canvas 전용으로 동작해 플러그인 제로를 보장합니다.
암호화되지 않은 전송파일이 HTTP를 통해 전송되거나 평문으로 저장되어 GDPR, HIPAA, 내부 정책을 위반할 수 있습니다.SDK가 여러분의 애플리케이션 내부에서 실행되므로 전송 및 저장은 이미 적용된 TLS와 암호화 정책을 그대로 사용합니다. Doconut은 새로운 홉을 추가하지 않습니다.
제어되지 않은 수명 주기파일이 서버에 남아 있어 침해 표면이 확대됩니다.보관 정책은 여러분이 직접 설정합니다. 문서는 절대 외부 환경을 떠나지 않으며, 임시 렌더링 결과는 여러분이 지정한 위치에 저장되고 일정에 따라 정리됩니다.

핵심적인 아키텍처 사실은 SDK가 여러분 자체 환경에 설치되고 Doconut 서버와 전혀 통신하지 않는다는 점입니다. 데이터 맵에 추가할 제3자 프로세서도 없고, 여러분의 보관 정책과 충돌할 공급업체 보관 정책도 없습니다.


2. .NET 프로젝트 준비하기

프로젝트에 맞는 Doconut 버전에 해당하는 패키지, 문서 및 예제를 사용하십시오. 공식 Doconut 다운로드 페이지 가 가장 신뢰할 수 있는 시작점입니다.

통합 전에 대상 .NET 런타임을 확인하고, 패키지 버전을 기록하며, 라이선스 구성을 소스 컨트롤 외부에 보관하고, 대표 문서로 테스트를 시작하십시오. ASP.NET Core, MVC, WebForms는 각각 다른 애플리케이션 수명 주기를 가지므로 설정을 동일하게 취급하면 안 됩니다.


3. 안전한 업로드 엔드포인트 구축 – AES‑256, SSL, 자동 삭제

SDK는 물리 경로, 스트림, 바이트 배열, 데이터베이스, URL, 인트라넷 위치 또는 S3, Azure Storage, Google Cloud, Dropbox와 같은 클라우드 제공자를 통해 문서를 읽을 수 있습니다. 브라우저가 선택한 경로를 직접 읽게 해서는 안 됩니다. 요청과 문서 사이에 권한 검사를 두어 소스가 무엇이든 관계없이 보호하십시오. 아래는 ASP.NET Core에서 흔히 사용되는 엔드포인트 형태이며, 동일한 아이디어를 MVC와 WebForms에도 적용할 수 있습니다.

// 여기부터 코드 블록은 번역되지 않습니다.

서버‑사이드 워크플로우

  1. 업로드된 파일 수락 – 표준 IFormFile(WebForms에서는 HttpPostedFile)을 사용하여 클라이언트로부터 문서를 받습니다.
  2. AES‑256으로 파일 암호화 – 스트림을 영구 저장하기 전에 System.Security.Cryptography.Aes와 같은 검증된 라이브러리를 사용해 암호화합니다. 암호화된 블롭을 안전한 위치에 저장합니다(예: 서버‑사이드 암호화가 활성화된 Azure Blob Storage 또는 SSE‑AES256이 적용된 S3 버킷).
  3. 단기간 유효한 서명된 URL 생성 – 몇 분(예: 5 분) 동안 유효한 URL을 만듭니다. URL은 HTTPS이며 Doconut이 검증할 수 있는 암호 토큰을 포함해야 합니다. 대부분의 클라우드 스토리지 제공자는 이 요구에 맞는 “프리‑사인드 URL” 기능을 제공합니다.
  4. 서명된 URL을 클라이언트에 반환 – URL을 포함한 JSON 응답을 보냅니다. 클라이언트는 이 URL을 Doconut 뷰어에 전달합니다.
  5. 자동 삭제 예약 – 서명된 URL이 만료된 후, 백그라운드 작업(Hangfire, Azure Functions 등)이 암호화된 블롭을 삭제하여 파일이 서버에 남지 않도록 보장합니다.

MVC / WebForms 등가물

  • MVC – 동일한 로직을 일반 컨트롤러 액션에 넣고 JsonResult를 반환합니다.
  • WebForms – 같은 단계를 따르는 .ashx 핸들러 또는 페이지 메서드를 구현합니다: Request.Files[0]을 수신하고, 암호화하고, 프리‑사인드 URL을 생성한 뒤 JSON 응답을 작성합니다.

유일한 차이점은 라우팅 구문뿐이며, 보안 워크플로우는 동일하게 유지됩니다.


4. 설치된 SDK를 통해 문서 렌더링

문서 접근을 서버에 유지하고 파일이나 스트림을 처리하기 전에 권한을 확인합니다. 정확한 렌더링 및 UI 초기화 순서는 버전마다 다르므로, 검증되지 않은 전역 JavaScript API를 복사하기보다 설치된 빌드와 함께 제공되는 공식 문서를 따르세요.

모든 .NET 버전에서 작동하는 이유

  • ASP.NET Core Razor – 초기화 코드는 업로드 폼을 호스팅하는 동일한 뷰에 존재하므로, 고려할 페이지가 하나뿐입니다.
  • MVC – @section Scripts를 사용해 동일한 스니펫을 삽입합니다; 컨트롤러는 MVC의 $.ajax가 사용할 수 있는 JSON을 반환합니다.
  • WebForms – 업로드가 완료된 후 ClientScript.RegisterStartupScript로 스크립트를 등록하고, 동일한 방식으로 launchViewer를 호출합니다.

렌더링은 서버에서 수행되며, 이것이 핵심입니다. 브라우저는 원본 문서가 아니라 렌더링된 페이지를 받기 때문에 AutoCAD나 Photoshop이 설치되지 않은 머신에서도 DWG나 PSD가 열립니다. 서버 용량을 적절히 잡으세요 — 300페이지 스캔 PDF는 실제 작업 부하이며, 이제 해당 작업을 담당하는 계층이 됩니다.


5. 포털에 맞게 뷰어 맞춤 설정

기업은 일반적으로 뷰어가 외부의 창이 아니라 자체 제품의 일부처럼 보이길 원합니다. 뷰어의 외관과 제공되는 컨트롤 집합은 설정 가능하며, 사용 가능한 옵션은 설치된 빌드에 따라 달라집니다.

옵션 이름은 블로그 게시물이 아니라 해당 버전과 함께 제공되는 문서에서 확인하세요. 뷰어 설정 화면은 릴리즈 사이에 이름이 바뀌는 경우가 많으며, 두 버전 이전의 기사에서 복사한 스니펫은 라이선스 문제처럼 보이는 오류를 일으킬 수 있습니다.

문서를 열기 전에 결정해야 할 중요한 사항은 각 역할이 어떤 컨트롤을 볼지입니다. 사용자가 인쇄, 다운로드, 혹은 문서 페이지 넘기기만 할 수 있는지는 이미 애플리케이션이 알고 있는 권한 질문입니다. 모든 컨트롤을 노출하고 누군가 클릭하기를 기대하기보다, 해당 권한에 맞게 뷰어를 설정하세요.


6. 성능 및 확장성 – 빠른 사용자 경험 유지

고 트래픽 포털에 뷰어를 삽입하면 두 가지 실용적인 문제가 발생합니다: 로드 시간과 동시 렌더링. Doconut App은 기본적으로 두 문제를 해결하지만, 몇 가지 .NET 전용 트릭으로 성능을 더욱 강화할 수 있습니다.

문제점대응 방안
첫 페이지 지연페이지 자동 로딩을 사용하면 나머지 페이지가 준비되는 동안 독자는 첫 페이지를 바로 볼 수 있습니다. 정적 파일 압축(app.UseResponseCompression())을 활성화하고 클라이언트 자산을 캐시하세요.
동일 파일 반복 조회자주 열리는 문서는 한 번 렌더링한 뒤 캐시된 출력으로 제공할 수 있어 요청마다 다시 렌더링할 필요가 없습니다. FAQ에서 바로 이 경우를 위한 .DCN 옵션을 다룹니다.
렌더링 비용렌더링은 서버 작업입니다. 품질이 크게 중요하지 않은 경우 이미지 해상도를 낮추는 것이 가장 큰 효율 향상 방법이며, 이는 코드 변경이 아닌 설정 변경으로 가능합니다.
동시성부하가 걸렸을 때 타임아웃 및 AutoClose 설정을 검토하고, 단일 노드가 충분하다고 가정하기 전에 웹 팜 예제를 읽어보세요. 업로드 엔드포인트에 속도 제한을 적용합니다.

직접 문서를 사용해 측정하세요. 5 MB 텍스트 기반 PDF와 동일 보고서의 5 MB 스캔은 전혀 다른 동작을 보이며, 합성 벤치마크에서는 하나만 나타납니다.

핵심 요약

  • Doconut Viewer는 플러그인 없이 동작하는 .NET SDK로, ASP.NET Core, MVC, WebForms와 함께 사용할 수 있습니다. 사용자는 아무것도 설치할 필요가 없습니다.
  • 귀하의 환경에 설치되며 Doconut 서버에 호출하지 않으므로 문서는 이미 제어하고 있는 경계 내에 머무릅니다.
  • 전송 보안, 저장 시 암호화 및 보존 기간은 직접 설정할 수 있습니다. 파일이 인프라를 떠나지 않기 때문에 Doconut은 데이터 맵에서 프로세서가 되지 않습니다.
  • SDK 카탈로그에는 18개 패밀리의 75개 파일 확장자가 포함됩니다 — PDF, Office, CAD, Visio, Project, 이메일, eBook 및 이미지, 그리고 자체 플러그인을 통한 DICOM.
  • 렌더링은 서버에서 수행됩니다. 이것이 브라우저가 DWG 파일을 열 수 있게 하는 이유이며, 또한 규모를 결정해야 할 항목이기도 합니다.
  • 사용자가 볼 수 있는 제어(인쇄, 다운로드, 페이지 전환 등)는 애플리케이션이 이미 보유하고 있는 권한에 따라 결정되어야 합니다.
  • 구성 옵션 이름은 설치된 버전의 문서에서 확인하고, 절대 기사에서 가져오지 마세요.

일반적인 질문

Q1: 서버에 무언가를 설치해야 하나요?
A: 예. Doconut Viewer는 애플리케이션에 설치하는 .NET SDK입니다 — 다운로드 페이지에서 시작하여 선택한 버전의 패키지와 문서를 사용하세요. 호출할 호스팅 엔드포인트가 없으며, Doconut CDN에서 제공되는 내용도 없습니다.

Q2: 보기 후 파일을 누가 삭제하나요?
A: 직접 삭제합니다. 문서와 모든 임시 렌더링 출력이 귀하의 환경에 존재하기 때문에 보존은 벤더의 약속이 아니라 애플리케이션의 설정입니다. 프로덕션에 적용하기 전에 임시 파일이 어디에 기록되고, 누가 삭제할지 결정하세요.

Q3: 사용자가 문서를 인쇄할 수 있나요?
A: 인쇄는 뷰어 기능이며 사용자별로 허용하거나 제한할 수 있습니다. 제어된 인쇄는 뷰어 자체의 일부이며, 주석, 변환기, DICOM, 검색 네 가지 라이선스 플러그인 중 하나가 아니라는 점을 유념하세요.

Q4: 문서를 다른 형식으로 변환할 수 있나요?
A: 이는 별도로 라이선스되는 Converter 플러그인입니다. 보기와 변환은 여기서 서로 다른 제품이며, 워크플로우에 실제로 필요한 것이 무엇인지 명확히 하는 것이 좋습니다.


플러그인 없이 .NET 애플리케이션에 문서 뷰어를 삽입할 준비가 되셨나요? Doconut 다운로드 페이지에서 시작하세요 — 체험 라이선스는 무료입니다. 그리고 오늘 한 파일만 열고 싶다면, Doconut.app에서 브라우저 탭으로 열 수 있으며, 사용 후 자동으로 삭제됩니다.