Archyl Cloud의 데이터 보안: 무엇을, 어떻게 보호하며, 무엇을 주장하지 않는가

벤더 보안 질문지 어딘가에는 "고객 데이터가 저장 시 암호화됩니까? 예 / 아니요"라는 항목이 있습니다. Archyl Cloud에 대한 정확한 답은 "예, 그리고 정확히 어떤 필드인지는 이렇습니다"입니다. 아키텍처의 텍스트(이름, 설명, ADR, 문서)와 자격 증명은 데이터베이스가 보기도 전에 저희 애플리케이션이 암호화합니다. 업로드된 파일은 스토리지 제공업체가 암호화합니다. 식별자, 타임스탬프, 다이어그램 위치, 계정 이메일은 평문으로 남습니다. 데이터베이스가 이들을 인덱싱하고 join해야 하기 때문입니다. 무엇이 어느 쪽인지 밝히지 않고 "예"에 체크하는 벤더는, 질문지의 나머지를 그냥 믿어 달라고 요구하는 셈입니다.

이 글은 그 긴 답변입니다. 무엇을 어떻게 암호화하는지, 데이터가 어떻게 이동하는지, 누가 무엇에 접근할 수 있는지, AI 제공업체가 무엇을 받는지, 어떻게 테스트하는지, 그리고 GDPR에 따라 여러분이 무엇을 할 수 있는지를 다룹니다. 아직 도달하지 못한 부분도 분명히 밝힙니다. Archyl은 현재 어떤 보안 인증도 보유하고 있지 않습니다.

여기에 적힌 모든 내용은 Security Whitepaper(v3.0) 및 데이터 처리 계약(DPA)과 일치합니다. 두 문서 모두 2026년 9월 27일에 업데이트되었고, 둘 다 신뢰 센터에 링크되어 있습니다. 만약 이 글의 한 문장과 그 문서의 한 문장이 서로 어긋난다면 알려 주세요. 둘 중 하나는 틀린 것이기 때문입니다.

요약

지금 바로 양식을 작성하고 계신 분들을 위해:

이 글의 나머지는 각 항목 뒤에 있는 세부 내용입니다.

저장 시 암호화, 필드별로

Archyl은 데이터베이스에 기록되기 전에 애플리케이션에서 필드를 암호화합니다. 고객 콘텐츠를 담는 모든 모델에는 저장 훅이 있어, 기록할 때 텍스트 필드를 AES-256-GCM으로 암호화하고, 이에 대응하는 훅이 읽을 때 복호화합니다. 암호화할 때마다 새로운 무작위 nonce를 사용하므로, 같은 값을 두 번 저장해도 서로 다른 두 개의 암호문이 만들어집니다.

여기에는 시크릿뿐 아니라 아키텍처 콘텐츠도 포함됩니다:

• C4 모델: 시스템, 컨테이너, 컴포넌트, 코드 요소(이름, 설명, 태그), 관계(설명, 태그)
• Architecture Decision Records: 제목, 맥락, 결정, 결과, 태그
• 문서: 제목, 내용, 파일 경로, 태그, 그리고 문서에 달린 댓글
• API 계약: 이름, 설명, 내용, 엔드포인트, 버전
• 플로우와 화이트보드: 이름, 설명, 기술 레이블
• 그 밖에: 오버레이, 이벤트 채널, 인사이트, 릴리스, 적합성 규칙, 변경 이력, 스냅샷

그리고 Archyl이 저장하는 모든 자격 증명과 시크릿:

• GitHub, GitLab, Bitbucket의 OAuth 토큰
• API 키
• MFA 시크릿과 복구 코드
• 통합 및 마켓플레이스 자격 증명
• 저장소 액세스 토큰
• 클라우드 연결 설정

이 기능은 항상 켜져 있습니다. 암호화 키는 설정된 시크릿으로부터 Argon2id로 파생되며, 그 시크릿이 없거나 32자보다 짧으면 서버는 시작 시 종료됩니다. Archyl이 실행되면서 이 필드들을 평문으로 기록하는 설정은 존재하지 않습니다.

실질적인 결과는 이렇습니다. 데이터베이스 사본만으로는 데이터의 형태는 보여도 그 내용의 단어는 보이지 않습니다. 서비스 이름, ADR에 담긴 논리, 문서 본문, GitHub 토큰, MFA 시크릿은 모두 키가 추가로 있어야 읽을 수 있습니다.

또한 자격 증명은 API를 통해 다시 나오는 일이 없습니다. 통합 설정은 읽을 때마다 가려집니다. Archyl에 키를 한 번 붙여 넣으면, 인터페이스는 키가 저장되어 있다는 사실은 알려 주지만 그 키를 다시 보여 줄 수는 없으며, 어떤 API 호출도 조직 내 다른 누구에게 그 키를 반환하지 않습니다.

이것이 다루지 않는 것

데이터베이스는 행을 찾고, 정렬하고, join할 수 있어야 하는데, 암호문으로는 그렇게 할 수 없습니다. 그래서 일부 필드는 평문으로 남습니다:

• 식별자와 요소 간 링크. 데이터베이스는 요소 A가 컨테이너 B에 속하고 요소 C와 관계가 있다는 것은 압니다. 그중 어느 것의 이름도 알지 못합니다.
• 타임스탬프와 다이어그램 위치.
• 계정 이메일 주소와 이름 및 성. 이메일에는 고유 인덱스가 있어 두 계정이 같은 주소를 사용할 수 없습니다.

이 필드들은 아래에서 설명하는 접근 제어와 전송 중 TLS로 보호됩니다. 이 글은 데이터베이스의 디스크 수준 암호화에 대해서는 어느 쪽으로도 주장하지 않습니다.

업로드된 파일

문서에 첨부한 파일(이미지, PDF, 기타 문서)은 데이터베이스에 저장되지 않습니다. 파일은 Google Cloud Storage에 저장되며:

• 버킷은 비공개입니다. 그 안의 어떤 것도 공개적으로 읽거나 목록을 조회할 수 없습니다.
• 파일은 저장 시 AES-256으로 암호화됩니다. 암호화는 Google Cloud Storage가 수행하며, 키는 제공업체가 관리합니다.
• 파일은 수명이 짧은 서명된 URL을 통해서만 제공됩니다. 각 링크는 하나의 파일에만 접근을 허용하고 생성 후 곧 만료되므로, 티켓이나 채팅에 복사된 링크는 영구적인 공개 URL이 되는 대신 작동을 멈춥니다.
• 기본 리전은 EU입니다: 벨기에, europe-west1.

전송 중 암호화

브라우저, 사용하시는 도구, Archyl Cloud 사이의 트래픽은 TLS 1.3을 사용합니다. 애플리케이션에서 PostgreSQL 데이터베이스로의 연결에는 SSL이 필수이므로, 애플리케이션은 데이터베이스와 평문으로 통신하지 않습니다.

누가 들어올 수 있는가

사람

• 다중 인증은 TOTP, 즉 인증 앱의 6자리 코드를 사용합니다. 각 MFA 챌린지는 한 번만 사용할 수 있으며, 복구 코드는 bcrypt 해시로 저장되므로 검증은 가능하지만 다시 읽어 낼 수는 없습니다.
• 싱글 사인온은 SAML 2.0과 OpenID Connect를 지원합니다. 로그인은 항상 Archyl에서 시작되며(SP-initiated만 지원), ID 제공업체의 응답을 해당 요청에 연결하는 state는 요청을 시작한 브라우저에 묶여 있고 한 번만 유효합니다. 설정 방법은 SSO 글에서 다룹니다.
• OAuth 로그인은 GitHub, GitLab, Bitbucket으로 사용할 수 있습니다.
• 비밀번호를 변경하거나 MFA를 제거하면 이전의 모든 세션이 취소됩니다. 비밀번호가 유출되었다고 생각되면, 비밀번호를 변경하는 것만으로 그 비밀번호를 사용하던 다른 모든 기기에서 로그아웃됩니다.
• 비밀번호 재설정은 계정의 존재 여부를 드러내지 않으며, 재설정 링크는 한 번 사용하면 더 이상 작동하지 않습니다.
• 로그인, MFA, 비밀번호 재설정에는 rate limit이 적용됩니다. 제한은 여러 계층으로 구성되어 있어, 하나의 IP, 하나의 계정, 하나의 챌린지 각각에 대해 시도할 수 있는 횟수가 제한됩니다.

머신: API 키와 AI 에이전트

• API 키는 기본적으로 읽기 전용입니다. 쓰기 권한은 별도로 부여해야 하며, 키를 특정 프로젝트로 제한할 수 있습니다. 한 프로젝트의 모델만 읽는 CI 작업에 준 키는 정확히 그 일만 할 수 있습니다.
• MCP 서버는 AI 에이전트가 아키텍처를 읽고 업데이트할 때 사용하는 것으로, OAuth와 필수 PKCE로 인증합니다. 모든 변경 작업에는 쓰기 scope가 필요하므로, 아키텍처에 관한 질문에 답하도록 연결한 에이전트는 쓰기 권한을 부여하지 않는 한 아키텍처를 변경할 수 없습니다.

테넌트 격리

모든 멀티 테넌트 제품이 설계 단계에서 막아야 하는 실패는 설명하기 간단합니다. 서버가 사용자가 로그인했고 어떤 조직에 속해 있는지만 확인한 뒤, 요청에 들어 있는 식별자는 무엇이든 신뢰하는 것입니다. URL의 ID를 바꾸면 다른 사람의 데이터를 읽게 됩니다.

Archyl은 모든 요청을 해당 요청이 접근하는 리소스를 기준으로 인가합니다. 다이어그램, 문서, 키를 요청한다는 것은 단지 로그인했는지가 아니라, 바로 그 리소스를 소유한 프로젝트나 조직에 사용자가 접근 권한이 있는지를 확인한다는 뜻입니다. 같은 규칙이 HTTP API와 MCP 서버 모두에 적용됩니다.

이것이 시간이 지나도 유지되도록 하는 두 가지 속성이 있습니다:

• 인가는 fail closed 방식입니다. 리소스의 소유자를 확인할 수 없으면 답은 '거부'입니다.
• 자동화된 테넌시 테스트가 CI에서 실행되며, 인가 검사가 제거되면 누군가 알아차리기를 기다리지 않고 빌드를 실패시킵니다.

AI가 보는 것

Archyl Cloud의 AI 기능은 OpenAI를 사용하며, 조직이 자체 키를 설정하지 않는 한 다른 AI 제공업체는 사용하지 않습니다.

저장소를 읽고 C4 모델을 제안하는 아키텍처 발견에서는 소스 코드 대신 코드 시그니처를 보냅니다. 다음은 저장소에 있는 그대로의 파일입니다:

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

그리고 다음은 아키텍처 발견이 이 파일로부터 만들어 내는 섹션으로, 프롬프트에 들어가는 내용입니다:

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

승인 규칙, 임계값, Finalize의 본문은 포함되지 않습니다. 포함되는 것은 저장소 이름, 파일과 디렉터리 구조, 그리고 이 시그니처들(import, 타입 및 함수 선언, export된 상수)입니다. 이 정도면 결제(billing) 컴포넌트가 Stripe와 통신한다는 것을 파악하기에 충분합니다. 그렇다고 아무것도 아닌 것은 아닙니다. 함수 이름과 타입 이름은 여러분의 시스템을 설명하므로, 공유하는 데이터로 취급하세요.

이 설명을 실제보다 넓게 해석하지 않도록 두 가지 한계를 밝혀 둡니다:

• 이는 아키텍처 발견이 소스 코드를 다루는 방식을 설명한 것입니다. 아키텍처 발견이 저장소에서 Markdown으로 작성된 Architecture Decision Records를 찾으면, 이를 구조화된 결정으로 바꾸기 위해 그 텍스트를 보내고, 문서 파일에 제목을 붙이기 위해 그 첫 몇 줄을 보냅니다.
• 다른 AI 기능은 각자의 작업에 필요한 것을 보냅니다. 예를 들어 코딩 에이전트는 자신이 변경하는 파일로 작업하므로 그 파일들을 봅니다.

코드를 계약을 맺은 제공업체에만 보낼 수 있다는 정책이 있다면, 조직은 자체 AI 키를 사용할 수 있습니다. 그러면 AI 요청은 여러분의 계약에 따라 해당 제공업체로 전송됩니다. 네트워크 밖으로 아무것도 나가서는 안 된다면, 셀프 호스팅 Archyl에서 자체 하드웨어의 Ollama로 모델을 실행할 수 있습니다.

테스트 방법

파이프라인에서

CI 파이프라인에서는 네 가지 보안 스캐너를 실행합니다:

• govulncheck: 실제로 호출하는 Go 의존성의 알려진 취약점
• CodeQL: 자체 코드의 정적 분석
• gitleaks: 실수로 커밋된 시크릿
• Trivy: 컨테이너 이미지와 인프라 구성의 취약점

플랫폼에서

• 외부로 나가는 요청을 검사합니다. 사용자가 제공한 URL을 호출하는 모든 통합(셀프 호스팅 Git 서버, webhook, AI 엔드포인트)은 서버 측 요청 위조(SSRF)로부터 보호되므로, 그 URL을 이용해 Archyl이 자체 내부 네트워크에 접근하게 만들 수 없습니다.
• 브라우저는 저희가 배포한 스크립트만 실행합니다. 엄격한 Content-Security-Policy가 모든 인라인 스크립트를 해시로 나열하고, CDN에서 로드하는 스크립트에는 Subresource Integrity 해시가 붙어 있어 변조된 사본은 거부됩니다.
• 컨테이너는 잠겨 있습니다. 비 root 사용자로, 읽기 전용 파일 시스템에서, Linux capabilities를 제거한 상태로 실행됩니다.
• 보안 이벤트가 기록됩니다. 로그인 실패, MFA 시도 실패, 거부된 토큰 등이 포함됩니다.

침투 테스트

2026년 7월부터 9월까지 내부 침투 테스트를 10회 실시했습니다. 모든 발견 사항은 수정되었고 회귀 테스트로 커버되어, 같은 문제가 다시 나타나면 탐지됩니다.

'내부'란 말 그대로의 의미입니다. 이 테스트는 저희가 직접 수행했으며, 독립된 외부 업체는 관여하지 않았습니다. 독립 침투 테스트는 SOC 2 감사의 일환으로 계획되어 있습니다.

GDPR에 따른 여러분의 권리

• 내보내기. 데이터를 JSON으로 내보낼 수 있습니다.
• 삭제. 계정을 삭제하면 그 계정에 속한 모든 것이 삭제됩니다. 삭제는 데이터 전체로 연쇄적으로 이루어지며, 객체 스토리지에 업로드된 첨부 파일도 포함됩니다.
• 모든 고객에게 DPA 제공. 데이터 처리 계약은 모든 고객이 이용할 수 있습니다.
• 72시간 이내 침해 통지.
• 하위 처리자 변경 전 30일 사전 통지. 변경이 이루어지기 전에 이의를 제기할 수 있습니다.

현재 하위 처리자는 다음과 같습니다:

DPA에는 각 하위 처리자의 위치와 법적 보호 조치가 명시되어 있습니다.

아직 주장하지 않는 것

강점만 나열하는 보안 페이지는 빈틈을 여러분이 직접 찾도록 남겨 둡니다. 여기 그 빈틈이 있습니다:

• 인증 없음. Archyl은 SOC 2 인증도, ISO 27001 인증도 받지 않았습니다. SOC 2 Type I의 경우 준비도 평가(readiness assessment)는 완료되었고 독립 감사는 대기 중입니다. ISO 27001은 계획되어 있습니다. 감사 보고서가 나오면 신뢰 센터에 그렇게 밝힐 것이며, 그때까지는 저희가 발행하는 어떤 내용도 그와 다른 인상을 주어서는 안 됩니다.
• 아직 독립 침투 테스트는 없습니다. 위에서 설명한 10회의 테스트는 내부 테스트였습니다. 독립 테스트는 SOC 2 감사와 함께 진행됩니다.
• 모든 컬럼이 암호화되는 것은 아닙니다. 위에서 설명했듯이 식별자, 타임스탬프, 다이어그램 위치, 이메일, 이름은 평문으로 남습니다.

여러분의 프로세스가 Archyl이 아직 갖추지 못한 인증을 요구한다면, 그것은 실제 제약입니다. 구매 검토 6주 차에 알게 되시는 것보다 지금 알려 드리는 편이 낫다고 생각합니다.

다음 단계

• 신뢰 센터에 관련 문서가 한곳에 모여 있습니다.
• Security Whitepaper는 rate limit과 저희가 기록하는 보안 이벤트를 포함해 각 통제를 더 깊이 다룹니다.
• 데이터 처리 계약은 위 GDPR 섹션의 계약 버전입니다.
• 데이터 보호 관련 질문이나, 이 글에서 답하지 않은 질문지 항목은 privacy@archyl.com으로 문의해 주세요.
• 취약점을 신고하려면 security@archyl.com으로 연락해 주세요. 24시간 이내에 접수를 확인해 드립니다.

여러분이 Archyl을 승인해야 하는 사람이라면, 대부분의 질문에 자신 있는 답을 얻기보다 모든 질문에 정확한 답을 얻으시기를 바랍니다. 여기 있는 내용 중 검토에 충분히 정확하지 않은 부분이 있다면 물어봐 주세요. 정확하게 만들어 드리겠습니다.