보안 인증을 제품에 내장하기: 고객사의 인증 부담을 대신 지는 설계

평범하게 잘 짠 코드가 인증기준을 이미 위반하고 있다면 그 사실은 언제 알게 되는 게 가장 쌀까요. 저희 답은 "개발 첫날"이었고, 그래서 인증기준을 문서로 두는 대신 플랫폼 기본값과 자동 검사 안으로 밀어 넣었습니다.

잘 짠 코드가 이미 인증기준을 위반하고 있었습니다

국내에서 인터넷에 연결되는 기기를 상용으로 내놓으려면 정보보호인증을 받아야 하는 경우가 있고, 정보통신망법에 근거가 있으며 KISA가 시험하고 발급합니다. 쉽게 말하면 이 기기와 앱이 해킹에 최소한의 대비를 하고 있는지 국가 기관이 확인해주는 검사입니다.

문제는 이 검사를 언제 준비하느냐인데, 가장 흔한 순서는 기획하고 개발하고 출시를 준비하다가 "아, 인증 받아야 하네"에서 시작하는 것입니다. 여기서 두 가지 일이 벌어지는데, 두 번째가 훨씬 나쁩니다.

인증기준을 한 줄씩 대조하다가 뒤늦게 확인한 것인데 저희 설계 중 세 군데가 아무 문제 없어 보이는데도 기준 위반이었습니다.

우리가 하려던 것	왜 상식적인가	그런데 기준은
원하는 버전으로 되돌리는 롤백	펌웨어 업데이트가 잘못되면 이전 버전으로 돌리는 건 당연한 안전장치	"보안취약점이 있는 구 버전으로 롤백하는 기능은 지원하지 않아야 한다"
IP 허용 목록을 대역으로 입력	`203.0.113.0/24`처럼 회사 전체 대역을 한 줄로 넣는 게 관리자 입장에서 편함	"IP주소는 1개씩만 추가 가능해야 하고, 범위 지정·와일드카드는 금지"
감사 기록도 데이터니 관리 화면 제공	목록·조회·삭제를 갖추는 건 어떤 데이터든 하는 일	"인가된 사용자라도 감사기록을 삭제·변경할 수 있는 인터페이스가 제공되지 않아야 한다"

왼쪽이 "부실하게 만든 것"이 아니라는 점을 봐주세요. 왼쪽은 어느 팀이든 당연히 넣을 기능이고 오른쪽은 그 기능을 만들지 말라고 말하므로, 화살표가 기능 추가가 아니라 기능 제거 방향으로 흐릅니다.

세 개 다 기능을 더 잘 만들려던 것이 위반이 된 사례입니다. 특히 세 번째는 성격이 다른데, 감사 기록은 "누가 언제 무엇을 했는지"의 마지막 증거라 지울 수 있는 버튼이 존재한다는 사실 자체가 그 증거의 가치를 없앱니다. 그 버튼을 아무도 안 눌러도 마찬가지입니다.

보안 요구사항을 "기능 추가 목록"으로만 읽으면 이 세 가지는 절대 안 보입니다. 여기서 요구되는 건 기능을 만들지 않는 것이라, 체크리스트를 나중에 훑는 방식으로는 잡히지 않습니다. 이미 만든 화면과 API를 도로 걷어내야 하니까요.

개인정보를 다루면 Lite를 신청할 수 없습니다

첫 번째로 벌어지는 일은 구조를 다시 짜야 한다는 것입니다. 인증 유형은 단순 해킹 대응인 Lite(6주~ / 약 600만원), 중요정보 접근차단·노출방지인 Basic(8주~ / 약 1,300만원), 고도 해킹 대응인 Standard(12주~ / 약 2,000만원) 셋인데 여기에 함정이 하나 있습니다.

왼쪽 갈래인 Lite가 사실상 닫혀 있다는 점을 봐주세요. 기기가 개인정보를 조금이라도 다루면 Lite를 신청할 수 없는데 사용자 계정으로 기기를 등록하는 순간 대부분의 IoT 제품은 개인정보를 다루게 되므로, 사실상 Basic 이상이 강제됩니다. 그리고 Basic 기준에는 비밀번호 최소 길이나 로그인 실패 잠금 횟수 같은 수치가 못 박혀 있는데, 이런 값은 코드 한 줄이 아니라 로그인 흐름 전체와 데이터베이스 스키마와 앱 화면에 흩어져 있어 다 만든 뒤에 바꾸면 재작업입니다.

규칙을 문서에 두면 사람이 바쁠 때 깨집니다

언제 어떻게 대응할지를 놓고 세 가지를 비교했습니다.

방식	어떻게 하는가	장점	결정적 한계
① 제품 완성 후 대응	출시 직전에 컨설팅 받고 맞춤	초기 개발 속도가 빠름	위 세 가지 같은 구조적 위반은 재작업. 시험 일정이 개발 일정에 물림
② 설계 문서에만 반영	규약 문서에 "8자 이상" 등을 적어 둠	비용 0. 즉시 가능	문서와 코드가 갈라집니다. 사람이 지키는 규칙은 사람이 바쁠 때 깨집니다
③ 기본값 고정 + 자동 검사	SDK 기본값을 기준값으로 못 박고, 위반을 CI가 자동 차단	코드를 새로 쓰는 사람도 모르는 채로 지키게 됨	초기 설계 비용. 기준이 바뀌면 기본값도 따라 바꿔야 함

맨 아래 칸의 주체가 누구인지를 봐주세요. ①과 ②는 마지막 단계를 사람이 책임지고 ③만 기계가 책임지는데, ②는 규칙이 적혀 있다는 점에서 안심되지만 실제로 막아 주는 것은 아무것도 없습니다. 규약 문서에 "MD5 쓰지 말 것"이라고 적어 두는 것과 MD5를 쓰면 코드를 합칠 수 없게 막아 두는 것은 결과가 완전히 다릅니다.

바깥도 함께 봤습니다. ThingsBoard·Magistrala·OpenRemote·EMQX·Mender·Golioth·Memfault 등 여러 플랫폼과 기능 범위를 대조했더니 인증·접근제어·감사 로그 같은 일반적인 보안 기능은 대부분 갖추고 있었지만, 국내 보안 인증 대응 기능은 대조한 어느 플랫폼에도 없었습니다. 국내 인증기준이 요구하는 수치와 금지 항목과 제출 서류는 해외 플랫폼의 관심사가 아니기 때문인데, 즉 이 부분은 저희가 직접 만들지 않으면 고객사가 통째로 떠안는 영역이라 ③으로 가기로 했습니다.

인증기준 50개 중 24개가 플랫폼 몫이었습니다

인증 해설서는 시험 범위를 "정보보호인증 대상의 운영환경인 데이터 전송구간 등이 시험대상 범위에 포함된다"고 정의하는데, 기기 하나만 검사하는 게 아니라 앱과 클라우드와 기기 전 구간이 검사 대상이라는 뜻입니다.

시험 대상이 기기 한 대가 아니라 화살표 전체라는 점을 봐주세요. 앱과 기기는 우리 SDK를 통해서만 클라우드에 붙으므로 화살표 대부분이 우리 플랫폼을 지나갑니다. 그래서 인증기준 50개를 하나씩 읽고 "이건 누가 책임지는가"를 표로 매핑했습니다.

가장 굵은 갈래가 플랫폼 쪽이고 그 갈래에 붙은 빨간 상자가 이 결정의 이유입니다. 절반 가까이가 플랫폼 몫이었고 뒤집어 말하면 SDK가 기준을 어기면 그 SDK를 쓰는 모든 고객사 제품이 인증에 떨어지는데, 이건 고객사가 자기 코드를 아무리 잘 짜도 막을 수 없는 실패입니다.

고객사에 남는 일은 29개 중 6개입니다

앞서 봤듯 실질적으로 Basic 등급이 강제되고 Basic의 필수 항목은 29개인데, 이 29개만 다시 매핑하면 플랫폼·SDK가 충족하는 것이 19개, 공동이 4개, 기기 전담이 6개입니다.

🏢 고객사 상자에 붙어 있는 짐의 크기를 비교해 주세요. 왼쪽은 29개가 전부 고객사에 붙어 있고 오른쪽은 19개가 플랫폼 쪽으로 옮겨 가서 고객사에는 6개와 연결 작업만 남는데, 인증 준비의 부담은 항목 수보다 어디부터 손대야 하는지 모르는 상태에서 오므로 29개짜리 미지의 목록과 6개짜리 명확한 목록은 체감이 다릅니다.

덧붙이면 핵심 부품 형상이 같고 보안 기능에 영향 없는 외형 변경은 파생모델 제도로 저비용 인증이 가능한데, 같은 펌웨어와 같은 SDK 버전을 여러 모델에 쓰는 구조가 이 제도에 정확히 맞아서 SDK를 공유하는 것 자체가 인증 비용 절감 수단이 됩니다.

기준이 못 박은 수치를 기본값으로 고정하고 완화를 막았습니다

해설서가 숫자로 명시한 항목들을 뽑아 SDK 기본값으로 고정했습니다.

항목	고정값
비밀번호 최소 길이	8자 이상
비밀번호 문자 조합	영문 대·소 / 숫자 / 특수문자 중 3종 이상
숫자 전용 비밀번호(도어락 등)	8자리 이상
일회용 인증번호(OTP)	6자리 이상 · 유효시간 2분 이내
초기 비밀번호	최초 접속 시 강제 변경. 불가하면 기기마다 서로 다른 랜덤값
연속 인증 실패 한계	5회 이하
잠금 해제 대기	5분 이상
잠금 상태	기기·서버를 재시작해도 유지
세션 유휴 타임아웃	10분 이하
비밀번호 저장	사용자마다 다른 값을 섞은 일방향 해시: 평문·복호화 가능 암호화 금지

여기서 중요한 건 값 자체가 아니라 어느 방향으로만 바꿀 수 있는가입니다. 테넌트는 이 값을 강화만 할 수 있고 완화할 수 없어서, 비밀번호 최소 길이를 10자로 올리는 것은 되지만 6자로 내리는 것은 API 자체가 거부합니다.

아래쪽 상태로 가는 길이 모두 막혀 있다는 점을 봐주세요. 고객사가 설정을 어떻게 만지든 도달할 수 있는 값은 기본값이거나 그보다 강한 값뿐이고 기준선 아래로는 내려갈 수 없습니다. "잠금 상태가 재시작 후에도 유지되어야 한다"는 항목도 눈여겨볼 만한데, 5회 틀리면 잠기게 만드는 건 쉽지만 그 상태를 서버 메모리에만 두면 서버가 재시작될 때 풀리기 때문에 기준이 이걸 명시적으로 막습니다.

위험한 것은 "못 하게"가 아니라 "없게" 만들었습니다

앞에서 본 세 가지 함정의 해법이 여기 있고, 공통점은 선택지 자체를 없앤 것입니다.

무엇	어떻게 없앴나
비승인 암호 알고리즘	승인 목록(보안강도 112비트 이상) 밖의 암호 방식은 개발자에게 보이는 목록에 아예 넣지 않습니다. 이미 깨진 옛 방식은 "쓰지 마세요"가 아니라 선택할 방법이 없습니다
감사 기록 삭제	감사 로그는 읽기 전용입니다. 삭제·수정 메서드를 SDK·API·관리자 화면 어디에도 만들지 않았고 보존기간이 지난 기록은 자동 만료로만 사라집니다
IP 허용 목록	대역 형식을 입력하면 저장이 거부됩니다. `0.0.0.0/0`, `192.168.1.*` 모두 검증 실패
취약 버전 롤백	"최소 안전 버전" 개념을 도입해 롤백 대상은 이 버전 이상만 고를 수 있고, 롤백 자체는 살아 있되 위험한 롤백만 사라집니다

오른쪽에는 "하지 마세요"라는 문장이 아예 없다는 점을 봐주세요. 왼쪽은 규약이 지켜지길 기대하지만 오른쪽은 개발자가 규약을 몰라도 위험한 선택지가 손에 잡히지 않고, 감사 기록에 삭제 버튼이 없다는 사실 자체가 기록의 증거 가치를 지킵니다. 네 번째가 특히 마음에 드는 해법인데, 기준을 지키려고 롤백 기능을 통째로 없애면 운영이 불편해지지만 "어느 버전으로든"을 "안전한 버전 중에서"로 좁힌 것만으로 기준과 운영 편의가 둘 다 성립합니다.

인증 실패 응답을 하나로 만들었습니다

같은 발상의 예입니다. 로그인이 실패했을 때 친절한 서비스는 "존재하지 않는 계정입니다", "비밀번호가 틀렸습니다", "잠긴 계정입니다"라고 안내하는데, 친절하지만 공격자에게는 "이 이메일은 가입되어 있다"는 정보를 공짜로 주는 것입니다. 실제로 이메일 목록을 넣어보며 가입 여부만 수집하는 공격이 흔합니다.

로그인 실패 · 비밀번호 재설정 · OTP 검증 실패
→ 사유와 무관하게 항상 같은 응답: "아이디 또는 비밀번호를 확인하세요"

계정이 없든 비밀번호가 틀렸든 잠긴 상태든 응답 본문이 바이트 단위로 같아야 하고, 비밀번호 찾기도 계정 유무와 관계없이 항상 같은 응답을 돌려줍니다. 친절한 안내 문구를 줄이는 일은 저희도 마지막까지 아쉬웠고, 같은 고민을 하고 계신 분이라면 한 번은 저울질하게 되는 지점이라고 생각합니다.

사람이 아니라 CI가 검사하고 서류를 자동으로 만듭니다

규칙을 문서에만 두지 않고 코드를 합치기 전 자동 검사로 옮겨서, 하나라도 걸리면 병합이 막힙니다.

사람의 리뷰가 첫 관문이 아니라 마지막 관문이라는 점을 봐주세요. 기계가 통과시킨 것만 사람에게 오고 세 검사 중 하나라도 걸리면 병합 자체가 되지 않습니다. 통과 조건은 비승인 암호 알고리즘 0건, 보안 용도의 비암호학적 난수 0건, 코드에 박아 넣은 비밀키 0건, 감사 로그 삭제·수정 경로 0건, 인증 실패 응답 단일화 테스트 통과, 로그아웃한 토큰 거부, 취약 버전 롤백 차단, IP 대역 입력 거부, 고위험 취약점 0건, 그리고 운영 빌드 잔여물 부재입니다.

마지막 항목이 미묘한데 중요합니다. 기준은 "불필요한 기능·코드 제거"를 요구하는데 설정 플래그로 꺼 둔 것은 제거가 아니어서, 검사도 "플래그가 off인가"가 아니라 "빌드 결과물에 그 코드가 아예 없는가"로 잡습니다.

그리고 서류를 자동으로 만듭니다. 인증 지연의 가장 큰 원인은 시험 자체가 아니라 제출 서류라, 플랫폼이 만들 수 있는 것은 플랫폼이 만들게 했습니다. 제품 사양과 운영환경 설명서, 데이터 정보(수집·저장·전송 데이터와 각각의 경로·암호화 방식), 인증기준 적용 명세서, 보안약점 진단 결과 보고서, 알려진 취약점 진단 결과 보고서, 암호키 관리대장이 자동 산출 대상이고 하드웨어 설계도만 기기 담당입니다.

데이터 인벤토리는 손으로 쓰지 않고 스키마와 인프라 정의에서 생성하는 것을 원칙으로 했는데, 손으로 쓰면 시간이 지나면서 제품과 어긋나고 "제출물과 실제 제품이 다르다"는 지적이 나오기 때문입니다. 이게 보완 요청의 전형적인 경로입니다.

로그아웃해도 출입증이 살아 있었습니다

돌아보면 여기서 가장 오래 헤맸습니다. 우리가 쓰는 로그인 토큰은 무상태 방식이라 서버가 세션 목록을 들고 있지 않고 토큰 안에 서명된 정보만으로 검증하는데, 서버가 가벼워지고 잘 확장되는 좋은 방식이지만 로그아웃해도 그 토큰은 만료 시각까지 계속 유효합니다. 기준은 "사용된 세션ID는 재사용할 수 없도록 로그아웃 시 폐기해야 한다"고 요구하니 정면 충돌이고, 비유하자면 출입증을 반납했는데 문이 계속 열리는 상황입니다.

"반납했는데 문이 계속 열리는" 구간이 사라지는 지점을 봐주세요. 로그아웃 시점에 번호가 목록에 올라가고 그 다음 호출부터는 토큰이 만료되지 않았어도 거부됩니다. 갱신 토큰 회전은 덤으로 얻는 이점이 큰데, 이미 사용한 갱신 토큰이 다시 등장한다는 건 누군가 그 토큰을 훔쳤다는 강한 신호라 그 순간 계열 전체를 끊으면 탈취 피해가 그 시점에서 멈춥니다. 폐기 목록이 무한정 커지는 문제는 토큰 만료 시각을 자동 삭제 시각으로 설정해 해결했습니다.

기준 두 개가 서로 반대 방향을 가리켰습니다

한 기준은 인증 실패 사유를 응답에 노출하지 말라고 하고 다른 기준은 인증 실패를 반드시 기록하라고 하는데, 둘 다 지키는 방법은 경로를 나누는 것이었습니다.

사용자에게 가는 응답  → 사유 없음. 항상 같은 문구
감사 기록에 남는 내용  → 사유 · 시각 · 주체 · 결과를 전부 기록

이 두 줄이 두 기준을 동시에 만족시키는 유일한 방법입니다. 대신 감사 기록에는 비밀번호나 암호키 같은 중요정보를 절대 넣지 않는다는 제약이 함께 붙는데, 기록이 상세해지다 보면 어느 순간 그 자체가 유출 경로가 되기 때문입니다.

기준을 만족해도 증명하지 못하면 보완 요청을 받습니다

설계를 하다 보니 계속 확인하게 된 사실입니다. 기준을 충족하는 것과 충족했음을 증명하는 것은 별개의 일이라, 심사에서 실제로 묻는 것은 "이 값이 8자입니까"가 아니라 "그 값이 8자라는 걸 어디서 확인할 수 있습니까" 와 "누가 언제 그 값을 정했습니까" 입니다. 코드에 상수로 박혀 있으면 답할 수 없습니다.

그리고 시간 압박이 있습니다. 보완 요청을 받으면 14일 이내에 회신해야 하고 넘기면 반려되는데, 2주 안에 흩어진 증적을 모아 서류를 만드는 건 현실적으로 어렵습니다. 그래서 서류 자동화가 선택이 아니라 필수였고, 앞의 제출물 자동 산출은 편의 기능이 아니라 이 14일에서 역산해 나온 요구사항입니다. 같은 이유로 보안 설정 화면에는 값뿐 아니라 정책 변경 이력을 함께 두기로 했는데, 값보다 이력이 증적이기 때문입니다.

"완전삭제"는 물리적으로 보장하기 어렵습니다

기준은 중요정보를 복구 불가능하게 완전히 삭제할 것을 요구하는데, 실제 클라우드 환경에서는 백업 스냅샷이나 객체 버전이나 조회 결과 캐시 등 사본이 여러 곳에 남아 "모든 사본을 물리적으로 지웠다"를 보장하기가 어렵습니다.

그래서 데이터를 주체별로 서로 다른 열쇠로 암호화해 두고 삭제 시 그 열쇠를 폐기하기로 했습니다. 남아 있는 암호문은 열쇠가 없으므로 영구히 읽을 수 없어서, 보관함을 다 뒤져 없애는 대신 열쇠를 부수는 방식입니다. 삭제 결과는 파기 증명서로 발급해 보관하며 이 증명서가 그대로 심사 제출물이 됩니다.

지금 손에 있는 것을 그대로 적습니다

현재 이 영역은 설계 확정 + 동작하는 화면 프로토타입 단계이고 실제 인증 신청과 시험은 아직 진행하지 않았습니다. 지금까지 이야기한 것을 한 장으로 모으면 이렇습니다.

화살표가 전부 아래로, 고객사 쪽으로 흐른다는 점을 봐주세요. 위에서 기본값과 부재와 자동 검사로 눌러 둔 만큼 가운데 플랫폼이 책임을 흡수하고 맨 아래 고객사에는 6개만 남습니다.

구현이 따라야 하는 계약으로 고정한 것은 인증·세션 기본값 14종, 구간별 최소 요건과 금지 목록을 담은 전송 구간 규약, 보안강도 112비트 이상만 허용하는 승인 암호 알고리즘 목록, 기능 유무와 관계없이 무조건 기록해야 하는 필수 감사 이벤트 목록, 그리고 각각 "무엇을 어떻게 측정해 통과를 판정하는가"까지 정의한 인증 대응 체크리스트 17개 항목입니다.

프로토타입은 클릭되는 화면으로 만들어 자동으로 만든 제출물을 사람이 확인·수정·내보낼 자리가 실제로 성립하는지를 봤습니다. 동의 화면에서는 동의와 미동의와 철회를 3상태로 분리했는데 철회를 미동의와 합치면 증빙이 안 되기 때문이고, 정보주체 요청 화면에서는 요청 큐를 법정 기한 임박순으로 정렬하고 파기 증명서를 발급합니다. 데이터 인벤토리 화면에는 수집 항목과 저장 위치와 법적 근거와 보유기간 표, 암호키 관리대장, 제출 서식 내보내기가 들어가고 인증 자산 화면에는 만료 임박 경고와 적용 명세서와 취약점 조치 이력이 들어갑니다.

특히 유용했던 것은 보안 리포트의 제출물 매핑표입니다. "정적분석 결과 = 보안약점 진단 결과 보고서", "취약점 스캔 = 연장 시험 필수 제출물"처럼 개발 산출물과 심사 서류를 1:1로 이어 뒀더니, 이것만으로 비개발자도 무엇이 준비됐고 무엇이 비었는지 볼 수 있게 됐습니다.

화면이 규약을 따라오지 못한 곳이 하나 남아 있습니다

정직하게 남깁니다. 설정 화면의 IP 허용목록은 프로토타입에서 아직 대역 입력 형태로 남아 있는데, 앞에서 지적한 바로 그 위반입니다. 규약과 검사 항목에는 단일 IP만 받는 것으로 확정돼 있는데 화면이 따라오지 못했고, 상식적인 형태가 얼마나 자연스럽게 다시 기어들어오는지를 보여주는 사례라 그대로 적어 둡니다.

검증 산출물로는 인증기준 50개 책임 주체 매핑표, 현행 설계와의 충돌 3건 목록, 외부 IoT 플랫폼 대조, 화면-기능 전수 대조가 남았습니다. 마지막 항목이 뜻밖의 것을 잡았는데 컴플라이언스 모듈은 12개 기능이 전부 정의돼 있는데 관리자 화면이 0개였습니다. 스펙에는 결함이 없으니 문서끼리 대조하는 방식으로는 원리적으로 잡히지 않고, 자동으로 만든 제출물을 확인·내보낼 화면이 없으면 자동 산출은 의미가 없어서 이 발견이 화면 신설 1순위가 됐습니다.

보안 요구사항의 상당수는 만들지 않는 것이었습니다

가장 크게 바뀐 관점입니다. 보안을 기능 추가 목록으로 읽으면 롤백이나 대역 입력이나 감사 기록 관리 화면 같은 항목은 끝까지 안 보이는데, 잘 만들려는 노력이 그대로 위반이 되기 때문입니다. 그래서 규약에 "무엇을 만들 것인가"만이 아니라 "무엇을 만들지 않을 것인가" 를 같은 무게로 적었고, 감사 로그 삭제 API 부재와 비승인 알고리즘의 API 표면 부재와 운영 빌드의 디버그 코드 부재는 셋 다 부재가 요구사항입니다.

기준을 지키는 것과 지켰음을 증명하는 것이 다른 일이라는 것도 배웠습니다. 설계 초기에는 기준을 충족하면 끝이라고 생각했지만 심사는 증적을 보고 보완 회신 기한이 14일이라 평소에 자동으로 쌓여 있어야 하는데, 그래서 화면마다 정책 변경 이력과 어느 시점의 코드를 검사한 결과인가를 함께 남기는 설계가 나왔습니다.

고객이 얻는 것	근거
인증 준비 범위가 6개로 좁혀짐	Basic 필수 29개 중 23개를 플랫폼·SDK가 충족하거나 크게 줄임
구조를 다시 짤 일이 없음	기준이 명시한 수치가 처음부터 SDK 기본값
모르는 채로 지켜짐	비승인 알고리즘·감사 로그 삭제·취약 버전 롤백은 선택지 자체가 없음
제출 서류의 상당 부분이 자동으로 준비됨	데이터 인벤토리 · 암호키 관리대장 · 진단 보고서 · 적용 명세서
여러 모델을 낼 때 인증 비용이 줄어듦	같은 펌웨어·같은 SDK 버전 공유 → 파생모델 제도 활용
설정을 잘못 만져 기준 아래로 내려갈 수 없음	완화 방향의 설정이 API에 없음 (강화만 허용)

마지막 줄이 이 설계에서 가장 신경 쓴 부분입니다. "할 수 있지만 하지 마세요"는 언젠가 누가 하지만, "할 수 없습니다"는 아무도 못 합니다.

인증기준 50개를 한 줄씩 대조하면서 가장 많이 적어 내려간 것은 새로 만들 기능이 아니라 만들지 않기로 한 것의 목록이었고, 그 목록을 개발 첫날에 손에 쥐고 있느냐가 몇 주를 갈랐습니다.

읽어주셔서 감사합니다.

보안 인증을 제품에 내장하기: 고객사의 인증 부담을 대신 지는 설계