기기 1,000대가 쏟아내는 데이터 감당하기: 저장과 조회 설계기

저희는 저장소를 먼저 고르려다 두 번 되돌아왔습니다. 하루 864만 건을 어디에 담을지보다 그 데이터를 어떤 화면이 어떻게 꺼내 쓰는지를 먼저 세어야 했고, 순서를 뒤집고 나서야 선택이 단순해졌습니다.

---

온습도계 한 대가 1년이면 31억 건이 됩니다

IoT 제품의 요구사항 문서에는 거의 항상 "대시보드에 최근 1개월 평균을 보여주세요"라는 한 줄이 들어갑니다. 기획자 입장에서는 평범한 요구인데, 이 한 줄이 저장소 설계 전체를 결정합니다.

범위	데이터 건수
기기 1대 · 하루	8,640건
기기 1,000대 · 하루	864만 건
기기 1,000대 · 1년	약 31억 건

왼쪽 끝의 "10초마다 1건"이 오른쪽 끝에서 "화면 한 번 여는 데 25만 건"으로 되돌아온다는 점을 봐주세요. 기기가 늘어난 만큼 저장이 늘어나는 것까지는 예상한 일이지만, 진짜 문제는 화면 한 장을 여는 비용까지 같이 커진다는 쪽이었습니다. 그리고 기기 1,000대는 큰 규모도 아니어서 아파트 한 단지나 중형 매장 체인 하나면 나오는 수입니다.

잘못 만들면 사용자가 겪는 증상은 네 가지입니다. 시간이 갈수록 화면이 느려져서 오픈 첫 달은 빠르던 화면이 반년 뒤 눈에 띄게 느려지는데 코드는 그대로이고 데이터만 쌓인 것입니다. 요금이 조용히 올라 기기 수는 그대로인데 저장 비용만 매달 증가하고 줄일 방법이 없으며, 기본 조회가 전체 뒤지기가 되고, 엑셀 다운로드를 눌렀는데 브라우저가 멈추다 결국 타임아웃으로 실패합니다.

기본 조회가 "전체 뒤지기"가 되는 게 가장 위험합니다

관계형 데이터베이스에 익숙하면 "기기 표에서 장소가 우리집인 행을 골라와"라고 짜고, 관계형 DB에서는 그 컬럼에 색인만 걸면 빠릅니다. 그런데 저희가 쓰는 저장소는 키-값 저장소라 도서관에 비유하면 책 번호를 알면 즉시 꺼내오지만 "표지가 파란 책"으로는 못 찾는 구조여서, 미리 그런 목록을 만들어 두지 않았다면 서가를 전부 훑는 수밖에 없습니다.

실제로 기존 사내 구현체 하나를 열어봤더니 기기 조회 코드에 "일단 다 가져와서 코드로 걸러낸다"는 방식이 남아 있었는데, 기기가 수십 대일 때는 아무도 눈치채지 못합니다. 문제는 이 조회가 실시간 처리의 핵심 경로라는 점입니다. 기기 접속·해제 처리, 같은 장소의 앱들에게 상태 뿌리기, 접속 권한 재발급이 전부 "이 장소에 어떤 기기가 있나"를 묻기 때문에 여기가 느리면 실시간이 실시간이 아니게 됩니다.

---

한계가 어디에 붙는지를 먼저 봤습니다

후보는 넷이었고 판단 기준은 비용·운영 인력·조회 유연성 셋이었습니다.

후보	어떤 방식인가	장점	결정적 한계
① 관계형 DB 한 벌	표와 표를 조인해서 조회	조회가 가장 자유롭고 개발자에게 익숙	초당 수천 건 쓰기에 튜닝·증설이 필요. 상시 켜 두는 서버라 기기가 0대여도 요금 발생
② 키-값 저장소 단일 테이블	키로 꺼내는 방식. 관계를 한 테이블에 목록으로 저장	쓰기량이 늘어도 성능 유지. 쓴 만큼만 과금. 운영할 서버가 없음	미리 설계하지 않은 조회는 불가능. 부분일치·임의 조건 조합 불가
③ 시계열 전용 DB	시간축 데이터에 특화	센서값 압축·구간 집계가 강력	관계는 못 다룸. 결국 다른 DB를 하나 더 둬야 함
④ 혼합	관계는 관계형, 시계열은 전용 DB	각각 가장 잘하는 걸 씀	운영 대상이 2~3종. 장애 지점·백업·인력 부담이 전부 배수로

한계가 붙는 위치가 서로 다르다는 것이 이 그림의 요점입니다. ①③④의 한계는 운영과 요금에 붙어 있어 시간이 갈수록 계속 나가는 비용이지만, ②의 한계는 설계 단계에서 미리 정해야 한다는 한 번의 숙제입니다. 저희가 뒤집을 수 있는 쪽은 후자였으니, 저장소 후보를 저울질하고 계신다면 장단점 목록보다 이 "한계가 어디에 붙는가"를 먼저 보시길 권합니다.

그들이 저장소를 여러 개 두는 이유는 설치형 제품이기 때문입니다

성숙한 오픈소스 IoT 플랫폼들을 보면 대체로 ④ 혼합입니다. ThingsBoard는 엔티티를 관계형 DB에 두고 센서 데이터는 별도 시계열 저장소를 골라 연결하고, OpenRemote는 관계형 DB에 시계열 확장을 얹으며, Magistrala는 시계열 저장소를 갈아끼울 수 있는 구조입니다.

여기서 두 가지를 읽었습니다. 첫째로 관계 데이터와 시계열 데이터를 분리하는 것은 업계 공통인데, 관계는 양이 적고 자주 바뀌고 정확해야 하는 반면 시계열은 양이 압도적으로 많고 한 번 쓰면 안 바뀌어 성격이 다르기 때문입니다. 둘째로 그들이 저장소를 여러 개 두는 이유는 설치형 제품이기 때문인데, 고객사 서버에 직접 설치되는 소프트웨어라 어떤 DB를 쓸지 선택권을 줘야 합니다. 저희는 클라우드에서 저희가 운영하는 플랫폼이라 선택권이 아니라 운영 부담을 줄이는 쪽이 이득이어서, 질문이 이렇게 바뀌었습니다.

"분리는 하되, 저장소 종류를 늘리지 않고 분리할 수 있는가?"

---

테이블을 만들기 전에 화면 103개가 무엇을 묻는지 세었습니다

②를 고르되 그 안에서 관계용·원본용·집계용 테이블을 나눴으니 운영해야 할 저장소는 여전히 한 종류입니다. 그런데 이 결정보다 먼저 한 일이 있고, 이번 설계에서 가장 중요한 작업이었습니다.

키-값 저장소는 미리 만들어 둔 색인으로만 조회할 수 있습니다. 나중에 색인을 추가할 수는 있지만 키 설계 자체가 틀렸으면 테이블을 다시 만들어야 하므로, 화면이 무엇을 물어볼지를 먼저 전부 모았습니다. 관리자 콘솔 43개와 모바일 앱 60개를 합쳐 103개였고, 화면 하나하나에 대해 어떤 조건으로 무엇을 정렬해서 몇 건을 가져오는지를 적은 다음 커버됨·색인 필요·불가능 셋으로 판정했습니다.

이 저장소로 불가능한 것 네 가지

이게 이 작업의 진짜 산출물이었습니다. 못 하는 것을 미리 아는 게 할 수 있는 것을 아는 것보다 값쌉니다.

#	화면이 원한 것	왜 불가능한가	확정한 대안
1	중간 글자 검색 ("홍길동"을 "길동"으로 찾기)	중간 일치는 전체를 훑어야 함	앞부분 검색으로 축소. 정규화한 검색용 키에 색인. 이메일은 인증 서비스의 접두 검색 활용
2	임의 컬럼 조합 필터	조합마다 색인이 필요해 무한히 늘어남	주요 조합만 색인으로 지원. 나머지는 페이지 내 필터, 대량은 내려받기로 유도
3	전체 기간 통계 리포트	대량 훑기	미리 계산해 둔 집계본 + 대용량은 비동기 분석
4	임의 컬럼 정렬	정렬은 미리 정해 둔 정렬키로만 가능	정렬키 고정. 그 밖의 정렬은 현재 페이지 안에서만

1번은 기획과 합의가 필요한 항목이라 별도로 확인을 요청했는데, "홍길동을 길동으로 검색"을 포기하는 것은 기술 결정이 아니라 제품 결정이기 때문입니다. 되돌리는 조건도 함께 적어서, 전문 검색이 실제로 필요해지면 검색 전용 엔진 도입을 재논의합니다.

이 목록이 없으면 구현 막바지에 "이 화면 검색이 안 되는데요?"가 나오고 그때는 테이블을 다시 만들어야 합니다.

화면 103개를 세는 데 며칠, 나중에 발견하면 몇 주입니다.

관계는 한 테이블에 인접 리스트로 담았습니다

사람과 장소와 방과 기기의 관계를 관계 전용 테이블 하나에 넣었고, 방식은 인접 리스트입니다. 어려운 말 같지만 주소록에 "이 집에 사는 사람 / 이 집에 있는 방 / 이 집에 있는 기기"를 같은 페이지에 나란히 적어두는 것과 같습니다.

PK: POOL#a1b2   SK: USER#u-100     ← 이 장소의 멤버
PK: POOL#a1b2   SK: ROOM#r-01      ← 이 장소의 방
PK: POOL#a1b2   SK: DEVICE#d-77    ← 이 장소의 기기

왼쪽이 보관함 이름이고 오른쪽이 그 보관함 안의 칸 이름이라, 같은 장소에 관한 것은 전부 같은 보관함에 들어갑니다. 그래서 "이 장소의 기기 전부"는 보관함 하나를 열어 DEVICE#로 시작하는 칸만 훑으면 끝나고 색인이 필요 없습니다.

각 줄의 마지막 칸만 비교하면 됩니다. 왼쪽은 데이터가 쌓일수록 느려지고 가운데는 기능이 늘수록 색인이 늘지만, 오른쪽만 둘 다 늘지 않습니다.

효과가 실제 숫자로 나왔습니다. 화면 103개를 대조했을 때 필요한 색인이 6개로 집계됐는데 관계를 인접 리스트로 다시 그리자 관계 관련 색인이 전부 흡수되어 2개로 시작할 수 있게 됐습니다. 이 저장소의 색인 개수 한도가 20개이니 여유를 18개 확보한 셈이고, 고객이 얻는 것은 기능이 늘어도 저장소 구조를 다시 손대지 않는다는 점입니다. 관계가 하나 추가될 때마다 색인을 늘려야 하는 구조는 언젠가 한도에 부딪혀 전면 재설계가 됩니다.

---

원본은 90일 뒤 사라지고 화면은 집계본만 읽습니다

센서값 원본은 관계 테이블에 넣지 않고 별도 테이블에 담은 뒤 두 가지 규칙을 걸었습니다. 첫째로 원본에는 유통기한이 있어 90일이 지나면 자동으로 사라지는데, 지우는 배치를 저희가 돌리는 게 아니라 저장할 때 만료 시각을 함께 적어두면 저장소가 알아서 치웁니다. 둘째로 데이터가 들어오는 즉시 집계본을 만들어 두고 5분·1시간·1일 세 종류를 유지합니다.

원본 테이블에서 화면으로 가는 화살표가 하나도 없다는 점을 봐주세요. 쓰기는 원본으로 들어오지만 읽기는 언제나 집계본에서만 나가고, 이 차이를 앞의 "지난 한 달 평균"으로 계산해 보면 이렇습니다. 측정치가 아니라 산술 계산입니다.

무엇을 읽나	기기 1대·한 달 기준 읽는 건수
원본 (10초 주기)	259,200건
5분 집계	8,640건
1시간 집계	720건
1일 집계	30건

8,640분의 1이고, 더 중요한 건 이 30건이 1년 뒤에도 30건이라 원본이 아무리 쌓여도 화면이 읽는 양은 늘지 않는다는 점입니다. 과거 데이터를 버리는 것도 아니어서 원본은 소멸 전에 파일 저장소로 내보내 장기 보관하고, 90일이라는 숫자도 고정값이 아니라 정책값이라 더 긴 보관이 필요한 고객사는 값을 늘리면 됩니다. 중요한 건 보관 기간이 설계에 명시적으로 존재한다는 것인데, 이게 없으면 비용은 무조건 우상향합니다.

큰 리포트는 접수하고 나중에 알려줍니다

"작년 1년치 전체 기기 데이터를 엑셀로 주세요"는 집계본으로도 즉시 응답할 수 없습니다. 즉시 응답 방식은 다 만들 때까지 화면이 멈추고 대부분 타임아웃으로 실패하는데 실패하면 처음부터라, 고민 끝에 동기 응답을 포기하고 요청을 받으면 "접수했습니다"를 즉시 돌려주기로 했습니다.

두 번째 화살표에서 이미 사용자가 풀려난다는 점이 요점입니다. 우체국 등기와 같아서 창구에서 배달이 끝날 때까지 기다리지 않고 접수증을 받고 나오는 것이며, 평소 조회 경로와 완전히 분리되어 있으므로 누가 1년치 리포트를 돌려도 다른 사용자의 화면은 영향을 받지 않습니다.

PostgreSQL도 Redis도 도입하지 않았습니다

혼합 구성을 택하면 관계형 DB 하나와 캐시 서버 하나가 늘어나는데 도입하지 않기로 하고, 대신 그 둘이 하던 일을 각각 어떻게 대체할지를 전부 적어놓고 시작했습니다.

관계형 DB·캐시가 하던 일	우리 대체 방식
기간 집계·통계	들어올 때 미리 계산해 둔 집계본 3벌
목록 검색·정렬·필터	화면 대조로 확정한 조합에 색인 사전 설계
엑셀·대용량 내려받기	비동기 처리 + 완료 알림
캐시 (Redis 대체)	실행 환경 메모리 캐시 + API 게이트웨이 캐시 + CDN 캐시 3단
분산 락·카운터	저장소의 조건부 쓰기 기능
전문 검색	미지원. 필요해지면 그때 검색 엔진 도입 재논의

마지막 줄을 그대로 적어둔 게 중요합니다. "안 되는 것"을 문서에 적어두면 나중에 사고가 아니라 결정이 됩니다. 캐시 서버를 두지 않는 것이 이상해 보일 수 있지만 캐시가 실제로 필요한 대상은 자주 읽히고 거의 안 바뀌는 값들이라 서버 메모리·게이트웨이·CDN 세 단계에서 이미 걸러집니다.

이 결정이 고객에게 주는 값은 성능이 아니라 안정성과 가격입니다. 저장소가 3종이면 장애가 날 수 있는 곳도 백업·버전업 대상도 필요한 운영 인력도 3배가 되고, 관계형 DB와 캐시는 상시 켜 두는 서버라 기기가 하나도 안 붙어 있는 새벽에도 요금이 나갑니다. 우리 구성에는 상시 가동 서버가 없어 쓴 만큼만 나가는데, 이 차이는 규모가 작은 고객사일수록 큽니다.

---

같은 실측 데이터가 정반대 결론을 지지했습니다

이 설계에서 가장 뼈아팠던 경험입니다. 먼저 기존 사내 구현체의 실제 데이터를 재봤더니 장소당 방 개수가 평균 1.2개에 최대 5개, 장소 데이터 한 건의 크기가 평균 585바이트로 한 건 크기 한도의 0.3%, 장소당 기기 수가 평균 4.5대에 최대 10대였습니다.

이 숫자를 근거로 처음 내린 결론은 "지금 구조를 그대로 유지한다"였고, 여유가 300배 이상 있는데 굳이 재설계할 이유가 없다는 판단이었습니다. 그런데 프로젝트 전제가 "기존 시스템 개선"에서 "신규 구축"으로 바뀌자 같은 숫자가 정반대 결론을 지지하기 시작했습니다. 원래 결론의 진짜 근거는 측정값이 아니라 기존 테이블 33개를 재설계하는 비용이었는데, 신규 구축에서는 재설계할 테이블이 없어 그 비용이 0이 되기 때문입니다.

맨 위 상자와 맨 아래 상자가 하나씩뿐이라는 점을 봐주세요. 데이터는 하나였고 결론도 하나여야 했는데 중간에 끼어든 전제 상자가 갈림길을 만들었고, 원래 결정 문서에는 이 전제 상자가 적혀 있지 않았습니다. 그래서 결정 기록 양식을 바꿔서 이제는 근거만이 아니라 그 근거가 성립하는 전제를 같이 적고, 전제가 바뀌면 어떤 결정을 다시 열어봐야 하는지 검색으로 찾을 수 있게 했습니다.

측정값이 운영 규모를 대표하지 않았습니다

돌아보면 그 실측값에는 함정이 하나 더 있었는데 개발 환경의 테스트 데이터였고, 조사 과정에서 운영 환경 테이블 자체가 존재하지 않는다는 것도 확인했습니다. "장소당 방 1.2개"는 실제 사용자가 만든 값이 아니라 개발자가 테스트로 만든 값이라, 이걸 근거로 "방은 몇 개 안 되니 장소 안에 그냥 넣자"고 결정하면 운영에서 방을 50개씩 만드는 고객사가 나타나는 순간 무너집니다.

그래서 측정값에 유효 범위를 명시하고 재검토 트리거를 숫자로 박았습니다. 예를 들어 "방 정보를 장소 데이터 안에 함께 저장한다"는 결정에는 장소당 방이 50개를 넘거나 장소 데이터 한 건이 100KB를 넘으면 분리를 재검토한다는 조건이 붙어 있습니다.

재검토로 넘어가는 화살표에 숫자가 적혀 있다는 점이 핵심입니다. "나중에 커지면 다시 보자"는 이 화살표가 아예 없는 상태이고, 그러면 재검토는 장애가 대신 알려줍니다.

중간 글자 검색 포기는 기술이 아니라 제품 결정이었습니다

앞의 불가능 4건 중 1번입니다. 개발 관점에서는 "저장소가 지원하지 않으니 어쩔 수 없다"로 끝나지만 운영자 입장에서는 "홍길동"을 "길동"으로 못 찾는 어드민이라, 이걸 기술 제약으로 조용히 넘기지 않고 기획 확인 항목으로 올렸습니다.

올릴 때 세 가지를 같이 붙였습니다. 대체안인 앞부분 검색과 페이지 내 필터, 실제 영향인 "대부분의 관리자 검색은 앞부분으로 충분하고 정확한 식별은 이메일·시리얼로 한다", 그리고 되돌리는 조건입니다. "안 됩니다"가 아니라 "이렇게 하면 되고, 이 조건이면 다시 봅니다"로 닫는 것이 핵심이었습니다.

단일 테이블을 어디까지 밀 것인가

"관계를 한 테이블에" 원칙에 취해서 모든 것을 한 테이블에 넣으려는 유혹이 있었고 실제로 초안에는 센서값까지 같은 테이블에 넣는 안이 있었습니다. 문제는 성격인데, 관계 데이터는 양이 적고 자주 바뀌고 영구 보존이지만 센서값 원본은 양이 압도적으로 많고 한 번 쓰면 안 바뀌고 90일이면 소멸해서, 이 둘을 같은 테이블에 넣으면 센서값이 관계 조회의 성능과 비용을 끌고 갑니다.

관계 테이블에는 관계만 담는다. 엔티티 본문·시계열·로그·콘텐츠는 각자 테이블을 갖는다.

기기 목록·센서값·집계본·감사 로그·자동화·접속 상태는 전부 별도 테이블입니다. "단일 테이블"은 저장소를 하나로 줄이자는 뜻이지 테이블을 하나만 만들자는 뜻이 아니었습니다. 다만 어디까지를 한 테이블에 담을지는 지금도 더 나은 경계가 있을 것 같고, 비슷한 고민을 하고 계신 분들의 기준도 궁금합니다.

---

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

현재 이 구조는 설계 확정 + 동작하는 화면 프로토타입 단계이고 부하 측정은 아직 하지 않아 아래에 성능 수치는 없습니다. 지금까지 이야기한 것을 한 장으로 모으면 이렇습니다.

파란 상자 안이 전부 한 종류의 저장소라는 점을 봐주세요. 쓰기는 계속 밀려들어오지만 화면으로 나가는 ③은 집계본과 관계 테이블에서만 나오고, 무거운 ④·⑤는 점선으로 평소 조회 경로 밖에 빠져 있습니다.

구현이 따라야 하는 규약으로 고정한 값들입니다.

항목	확정 내용
관계 저장 방식	인접 리스트. 사람↔장소↔방↔기기를 관계 테이블 하나에
테넌트 격리	모든 데이터에 고객사 식별자. 조회는 항상 고객사 조건 강제
전체 훑기 금지	키 또는 색인을 통하지 않는 조회는 코드 리뷰에서 반려
색인	초기 2개로 시작 (한도 20개)
센서값 원본	별도 테이블 · 기기별 시간순 · 90일 자동 만료
집계본	5분 · 1시간 · 1일 3벌. 들어오는 즉시 생성
대용량 리포트	비동기 접수 → 완료 시 알림 + 만료형 다운로드 링크
도입하지 않는 것	관계형 DB · 캐시 서버 (대체 수단 각각 명시)

프로토타입은 클릭되는 관리자 콘솔로 만들었고 목적은 이 저장 구조로 이 화면이 성립하는지를 눈으로 확인하는 것이었습니다. 사용량 화면에서는 청구 주기별 사용량 5종을 한도 대비 비율로 표시하고 초과 시 동작까지 정책 표로 붙였으며, 로그 화면에서는 감사·시스템·기기 로그 3종 탭의 필터가 사전 설계된 조합만 노출되는지 확인했습니다.

이 화면들이 특히 유용했던 지점은 화면이 저장소가 못 하는 것을 요구하고 있지 않은지를 역으로 검증한 것입니다. 로그 기간 조회는 시간을 정렬키로 두면 범위 조회로 해결되어 커버되고, 로그 필터는 화면의 필터 항목이 사전 정의된 목록뿐이라 임의 조합 요구가 없으며, 사용량 추이는 원본이 아니라 집계본을 읽는 화면임을 확인했습니다. 비개발자도 이 대조에 참여할 수 있었는데, "이 필터 목록에 없는 조건으로 찾고 싶은 경우가 실제로 있나요?"는 개발 지식 없이 답할 수 있는 질문이기 때문입니다.

빨간 상자 네 개가 전부 초록 상자로 이어져 있고 끊긴 화살표가 없다는 점이 이 산출물의 핵심입니다. 왼쪽만 있고 오른쪽이 비어 있으면 그건 산출물이 아니라 사고 예고이고, 구현 막바지에 발견했다면 이 화살표들은 그릴 시간이 없었을 것입니다.

---

저장소 설계는 테이블이 아니라 화면에서 시작합니다

관계형 DB에 익숙하면 테이블부터 그리는데, 조회는 나중에 SQL로 어떻게든 되기 때문입니다. 키-값 저장소에서는 그 순서가 통하지 않아서 화면이 무엇을 물어볼지를 먼저 모으지 않으면 테이블을 다시 만들게 됩니다. 화면 103개를 세는 데 며칠이 걸렸고 코드를 한 줄도 쓰기 전이었는데, 결과적으로 가장 값싼 며칠이었습니다.

"못 하는 것" 목록이 "할 수 있는 것" 목록보다 값지다는 것도 배웠습니다. 이번 조사의 핵심 산출물은 색인 설계가 아니라 불가능 4건이었고, 이걸 미리 알았기 때문에 기획과 미리 합의할 수 있었고 대안을 설계에 포함할 수 있었으며 되돌리는 조건까지 미리 정할 수 있었습니다. 구현 막바지에 발견했다면 셋 다 불가능했을 것입니다.

그리고 결정에는 근거와 함께 전제와 숫자로 된 재검토 조건을 적어야 합니다. 같은 실측 데이터가 전제가 바뀌자 정반대 결론을 지지한 경험이 가장 컸는데, 근거만 적힌 결정은 왜 다시 봐야 하는지를 알 수 없습니다. 같은 이유로 측정값에는 출처와 유효 범위를 적는데, 개발 환경 테스트 데이터를 운영 규모의 근거로 쓰는 것이 가장 흔한 사고입니다.

고객이 얻는 것	근거
데이터가 쌓여도 화면 속도가 그대로	화면은 사전 집계본만 읽음. 읽는 양이 누적 데이터에 비례하지 않음
보관 비용이 선형으로 늘지 않음	원본 90일 자동 만료 + 집계본은 원본의 수천분의 1
큰 리포트를 눌러도 서비스가 멈추지 않음	비동기 처리로 평소 조회 경로와 분리
실시간 처리가 규모와 무관하게 유지됨	장소↔기기 조회를 인접 리스트가 색인 없이 해결
운영 비용·장애 지점이 적음	운영 저장소 1종, 상시 가동 서버 없음(쓴 만큼 과금)
못 하는 것을 미리 알고 계약할 수 있음	불가능 4건과 대안이 문서로 확정

마지막 줄이 저희가 가장 신경 쓴 부분입니다. 할 수 있는 것만 적힌 문서는 신뢰의 근거가 되지 못하고, 못 하는 것과 그 대안 그리고 언제 다시 볼지를 함께 적은 문서가 됩니다.

읽어주셔서 감사합니다.