운영 환경에서 로그는 비상등처럼 먼저 깜빡인다. 지연이 올라가거나 에러율이 튀면, 개발자와 SRE는 대시보드보다 먼저 로그를 열어본다. 그런데 로그가 흩어져 있거나, 필요한 필드가 없거나, 비용 때문에 오래 보관하지 못한다면 대응은 늘 한발 늦어진다. 키스타임넷 같은 실시간 서비스에서는 지연 200 ms가 결제 실패로 이어지고, 곧바로 CS와 매출 지표에 반영된다. 결국 로그 관리 체계는 성능과 신뢰, 비용의 균형을 설계하는 문제다.
여기서는 키스타임, 키스타임넷, 키탐넷처럼 트래픽이 일정 이상인 서비스 조직을 가정하고, 현장에서 반복적으로 검증된 저장, 분석, 시각화 전략을 실전 감각으로 정리한다. 구체적 도구 이름은 예시로만 제시하되, 원리는 도구를 바꿔도 유효하도록 설명한다.
무엇을 남기고, 무엇을 지울 것인가
모든 로그를 영구 보관하는 선택지는 거의 항상 실패한다. 비용이 기하급수적으로 오르고, 쓸모없는 데이터가 쿼리를 느리게 만든다. 보관 정책은 우선순위에 따라 층을 나눠야 한다. 보통 다음 세 가지 계층으로 정리한다.
첫째, 운영 트러블슈팅을 위한 핫 티어. 3일에서 14일 정도, SSD 기반의 빠른 스토리지, 높은 인덱싱 비용을 감안한 구조. 여기에는 API 게이트웨이 액세스 로그, 핵심 서비스의 애플리케이션 로그, 주요 배치 잡의 에러 로그가 들어간다.
둘째, 감사, 과금, SLA 증빙을 위한 웜 티어. 30일에서 180일, 또는 규정 준수에 따라 1년까지. 쿼리가 자주 발생하지 않으므로 압축률이 높은 포맷과 저렴한 스토리지를 사용한다. S3 호환 오브젝트 스토리지, 컬럼 지향 엔진, 혹은 로그 전용 엔진의 아카이브 기능이 여기에 해당한다.
셋째, 모델링과 추세 분석을 위한 콜드 티어. 6개월에서 수년. 이벤트 수준 원본을 다 보관하기보다, 요약 테이블이나 주간 롤업을 유지하는 편이 낫다. 예를 들어 API 호출을 경로, 상태 코드, 테넌트, 5분 버킷 기준으로 집계해 크기를 1퍼센트 이하로 줄인다.
규정 준수 요구가 있는 조직은 별도의 보관 정책이 추가된다. 삭제 불가능 기간, 암호화, 접근 기록이 필요하다. 이때 핵심은 운영 로그와 감사 로그의 파이프라인을 분리하는 것이다. 같은 데이터라도 목적과 제약이 다르면 스키마와 보관 정책이 달라진다.
로그의 형태, 가치, 그리고 스키마 결정
텍스트 로그, 구조화된 JSON 로그, 메트릭, 트레이스를 같은 선상에서 비교할 필요가 있다. 각각은 관찰성의 다른 얼굴이고, 보관과 분석의 전략이 다르다. 텍스트 로그는 자유도가 높지만 검색 비용이 높다. JSON 로그는 파싱과 필터링이 명확해지고, 다운스트림 분석이 쉬워진다. 메트릭은 수치 요약으로 비용 대비 정보량이 좋다. 트레이스는 계보를 제공해 원인 파악이 빠르다.
키스타임넷에서는 애플리케이션 로그를 JSON으로 강제했고, 필수 키를 표준화했다. Timestamp, level, service, env, trace id, spanid, tenant, request id, route, status, latencyms, msg 같은 필드는 모든 마이크로서비스에서 공통으로 남긴다. 필드 네이밍을 통일하면 인덱싱과 시각화가 단번에 정리된다. 특히 tenant와 route 같은 필드는 카디널리티가 높아질 수 있으니, 전체 로그에 인덱스를 거는 대신 핫 티어에서만 부분 인덱스를 사용했다. 이벤트의 본문이나 PII는 별도 필드에 암호화하거나 마스킹 규칙을 적용한다. 영수증 번호, 전화번호, 이메일 같은 값은 규칙 기반 마스커로 제거했고, 원복이 필요한 경우에는 KMS로 암호화한 토큰만 남겼다.
한 번은 고객 조사 중에 이메일 주소가 평문으로 수집되어 안티바이러스 엔진에 걸린 일이 있었다. 사후 마스킹은 힘이 세지 않다. 조기 마스킹이 정답이다. 수집 에이전트 단계에서 정규식과 해시를 적용하고, 스토리지 계층에서는 추가로 동형 규칙을 적용해 중복 보호를 걸었다.
수집 파이프라인, 제일 많은 장애가 나는 구간
라이브러리, 사이드카, 에이전트, 게이트웨이, 메시지 버스 중에서 무엇을 선택하느냐가 운영 난이도와 안정성, 비용을 좌우한다. 키탐넷의 초기에는 애플리케이션에서 로그를 직접 중앙 스토리지로 전송했다. 이벤트 폭주 상황에서 백프레셔가 올바르게 걸리지 않아 서비스 지연을 키웠다. 두 달 만에 에이전트 수집 모델로 바꿨다. 노드당 하나의 경량 에이전트가 애플리케이션 로그를 읽어내고, 일시 버퍼링하며, 메시지 버스를 통해 전송했다. 이렇게 하면 트래픽 피크 때도 애플리케이션 스레드가 안전해진다.
수집 파이프라인을 고를 때는 아래 사항만 체크하면 실패 확률이 크게 줄어든다.
- 전송 실패 시 디스크 스풀링 지원 여부, 최대 스풀 크기, 드롭 정책 필드 파싱과 마스킹의 현지 적용 가능성, 예외 시 로깅 차단 옵션 멱등성 키 지정, 중복 방지, 리플레이 기능 부하 분산 전략, 파티셔닝 키, 순서 보장의 범위 관찰성 제공, 자체 로그와 메트릭 노출 정도
이 다섯 가지만 확실히 한다면 도구 선택은 크게 중요하지 않다. Filebeat, Fluent Bit, Vector, OpenTelemetry Collector 같은 에이전트를 섞어 쓰더라도 원칙이 살아 있으면 운영은 단순해진다. 특히 순서 보장은 트레이스와 이벤트 상관관계에 결정적이다. 완전한 순서를 보장하지 못하더라도 같은 request id나 traceid 기준으로는 파티션을 고정하는 편이 좋다.
저장 전략, 인덱스의 욕심을 줄이는 법
로그 저장은 대체로 세 가지 길이 보인다. 검색 엔진 계열, 컬럼 지향 데이터베이스, 오브젝트 스토리지 기반 데이터 레이크. 각각 장단점은 뚜렷하다. 검색 엔진은 자유도가 높고 쿼리가 쉬우나 인덱스 비용이 비싸고, 카디널리티가 높으면 성능이 급격히 떨어진다. 컬럼 지향 엔진은 집계와 필터가 빠르고 비용 효율이 좋지만, 풀 텍스트 검색은 약하다. 오브젝트 스토리지는 싸고 튼튼하지만, 대화형 쿼리는 느리거나 별도 레이크 엔진이 필요하다.
현실적으로는 혼합 모델이 가장 많이 쓰인다. 키스타임넷에서는 핫 티어는 검색 엔진, 웜 티어는 오브젝트 스토리지에 Parquet 포맷, 그리고 컬럼 지향 엔진으로 필요한 범위만 페더레이션 쿼리를 붙였다. 인덱스는 최소주의를 택했다. 시간과 서비스, 레벨, 상태 코드, 테넌트, 라우트 정도만 색인했다. 메시지 본문은 색인을 하지 않거나, 역색인을 얕게만 걸었다. 색인 필드는 많을수록 초기 색인 비용과 디스크 사용량이 크게 올라가며, 쓰기 성능이 흔들린다. 반대로 색인을 과도하게 줄이면 검색이 느려진다. 타협점은 트러블슈팅에 자주 쓰는 필드만 색인하고, 나머지는 필터링 전에 프리샘플링을 두는 것이다.
압축과 세그먼트 관리도 중요하다. 시간 파티셔닝을 30분 또는 1시간 단위로 두면 배치 머지 비용을 예측하기 좋다. 하루 단위로 묶으면 관리가 편하지만, 컬드 티어 이전 시 작은 조각으로 옮기기 어려워진다. 실제 운영에서는 세그먼트가 너무 작아서 쿼리 파싱만으로 리소스를 태우는 경우가 잦다. 반대로 너무 크면 특정 세그먼트에 스파이크가 쏠린다. 평균 유입량, 피크 대비 95퍼센타일, 병렬성 정도를 감안해 단위를 잡는다.
시간, 타임존, 그리고 순서가 뒤엉키는 문제
현장에서 자주 겪는 문제는 두 가지다. 클럭 드리프트와 다중 타임존. NTP가 약간만 틀어져도 트레이스 상관관계가 끊어진다. 모든 노드에서 단일 시간 소스를 강제하고, 애플리케이션에서 생성하는 timestamp 대신 수집 에이전트에서 수신 시간을 별도 필드로 기록해 두면 역추적이 쉬워진다. 필드 예시는 ts app, tscollector, ts_ingest처럼 단계별로 남긴다. 타임존은 UTC를 고정하되, 시각화에서만 현지 시간으로 변환한다. 저장 시 현지 시간을 쓰면 쿼리와 보관 정책에서 반복해서 실수한다.
순서 문제는 메세지 버스와 파티셔닝에서 결정된다. 테넌트 기준으로 파티션을 고정하면 멀티테넌시에서 분리도와 순서가 동시에 좋아진다. 단, 특정 대형 테넌트가 핫 파티션이 되지 않도록 추가 키, 예를 들어 route 해시를 섞는다. 파티션 키에 trace_id를 넣으면 트레이스 상관관계는 뛰어나지만 분산 효율이 떨어질 수 있다. 트래픽 특성에 따라 선택이 갈린다.
분석 쿼리, 현장에서 자주 쓰는 패턴
유용한 쿼리는 반복해서 쓰인다. 에러율 상승 탐지, 특정 테넌트의 지연 이상, 릴리스 이후 에러 패턴 변화, 백오프 재시도 폭주 탐지, 외부 API 장애 판단 같은 쿼리다. 쿼리 작성의 절반은 스키마 설계에서 끝난다. 예를 들어 다음과 같은 패턴을 정기화했다.
- 최근 15분, 상태 코드 5xx 비율이 1시간 평균의 2배를 넘는 라우트를 찾는 집계 trace_id 기준으로 3회 이상 재시도한 요청의 상위 원인 라우트 특정 릴리스 태그 이후 증가한 에러 메시지 n-gram 테넌트별 p95 지연이 SLA 임계치를 초과한 시간대
분산 엔진에 따라 문법은 달라지지만, 핵심은 사전에 필요한 키탐넷 필드를 남겨뒀는지다. 라우팅 키, 테넌트, 릴리스 태그, 버전, 리전이 없다면 사후 상관관계는 매우 어렵다. 메시지 본문 검색만으로 원인을 찾는 일은 거의 없다. 구조화된 필드가 실전에서 힘을 발휘한다.
시각화, 대시보드의 절제와 자동화
대시보드는 많을수록 관리가 어렵다. 실무에서 살아남는 대시보드는 다음 세 가지 흐름을 담는다. 흐름 하나, 실시간 헬스 체크. P50, p95, p99 지연, 에러율, RPS, 상위 에러 라우트. 흐름 둘, 릴리스 검증. 배포 전후 비교, 에러 메시지 상위 변화, 실패한 요청의 샘플, 주요 테넌트 영향. 흐름 셋, 고객 지원. 특정 테넌트, 사용자, 주문 ID를 기준으로 최근 24시간의 시퀀스를 복원하는 뷰.
헬스 체크는 즉시 판단이 가능해야 한다. 파형 그래프와 단일 지표 카드, 상위 테이블 정도만 사용한다. 색상과 임계치 규칙을 과하게 쓰지 않는다. 릴리스 검증은 시간 범위를 고정해 전후를 나란히 보여주고, 동일한 필터가 양쪽에 적용되도록 설정한다. 고객 지원 뷰는 검색 상자 하나로 모든 필터를 거는 단일 레이아웃이 좋다. 이 세 가지를 기본으로 두고, 팀별 특화 대시보드를 추가한다.
자동화는 알림 피로를 좌우한다. 임계치형 경보만으로는 과탑재가 온다. 베이스라인 대비 편차, 주기성 고려, 주중과 주말의 상이한 패턴 등을 반영하면 알림 수가 절반 이하로 줄어든다. 간단한 예로, 지난 4주치 같은 요일, 같은 시간대의 에러율 평균과 표준편차를 구해 동적 임계치를 만든다. 원시 모델이지만 효과는 크다. 이상을 감지하면 샘플 로그와 관련 트레이스 링크를 함께 전송해, 알림에서 바로 재현에 들어갈 수 있게 한다.
보안과 규정 준수, 편집증이 낫다
PII와 결제 관련 데이터는 수집 단계에서 마스킹하고, 적어도 두 단계에서 중복 마스킹을 권장한다. 저장 시에는 필드 단위 암호화를 적용하고, 키 관리는 KMS 같은 중앙 시스템으로 일원화한다. 접근 통제는 두 겹으로, 스토리지 계층의 ACL과 분석 도구의 역할 기반 권한을 모두 적용한다. 운영 콘솔 접근에는 세션 레코딩과 명령 감사 로그를 활성화한다. 로그 자체에 로그를 남기는 셈이다.
규정 준수는 누락보다 과잉이 안전하다. 보존 기간을 항상 상한으로 설정하고, Legal hold가 걸릴 수 있는 워크플로를 준비한다. 삭제 요청이 들어오면 원본 로그와 롤업 데이터의 동기 삭제가 가능해야 한다. 불가능하다면 원본 삭제 후 롤업에 대한 매핑 테이블을 분리해 보관하고, 조회 시 익명화한다. 감사를 받을 때는 시스템 전체 구조도와 데이터 흐름 다이어그램, 접근 통제 목록, 보관 정책, 삭제 절차, 샘플 로그를 준비하면 대응 시간이 크게 줄어든다.
운영 자동화, SLO와 예산의 언어로 묶기
로그 플랫폼도 SLO를 가져야 한다. 지표는 간단할수록 운영이 잘 된다. 인덱스 지연, 쿼리 p95, 데이터 유실률, 에이전트 실패율, 스토리지 사용률. 다섯 가지를 월 단위 에러버짓으로 잡는다. 예를 들어 인덱스 지연 p95 2분 이하, 데이터 유실률 0.1퍼센트 이하, 에이전트 실패율 1퍼센트 이하 같은 식이다. 이 목표와 비용을 연결하면 경영진과도 같은 언어로 대화가 된다.
자동화는 두 줄기다. 하나는 스케일링. 수집 레이어, 인덱싱 레이어, 쿼리 레이어를 각각 자동으로 수평 확장한다. 다른 하나는 수명 주기 정책. 일정 기준을 만족하면 핫에서 웜, 웜에서 콜드로 자동 이동하고, 압축과 머지를 예약한다. 스케줄 머지는 야간에만 돌리는 것보다, 수집량이 적은 10분 윈도우를 탐지해 그때만 돌리는 편이 안정적이었다. 주간 배치와 겹치면 전체 레이턴시가 흔들린다.
비용 최적화, 숫자로 말하기
논의가 추상적이면 항상 과투자나 과소투자로 흐른다. 간단한 가정을 세워 계산해 보자. 키스타임넷의 하루 로그 유입이 2 TB, 압축 후 400 GB라고 하자. 핫 티어 7일, 웜 티어 90일, 콜드 티어 365일을 목표로 한다.
핫 티어는 SSD 기반 검색 엔진을 사용한다. 색인 오버헤드와 복제본을 포함하면 저장 대비 1.5배에서 3배를 본다. 보수적으로 2배라고 잡으면, 400 GB x 7일 x 2배, 약 5.6 TB다. 노드 비용이 월 단가로 TB당 N이라면 핫 티어만 월 5.6 x N.
웜 티어는 오브젝트 스토리지에 Parquet로 보관한다. 압축률을 2에서 5배로 본다. 400 GB x 90일을 3배 압축으로 계산하면 12 TB 정도다. 오브젝트 스토리지는 GB당 비용이 낮아 월 비용은 상대적으로 작다. 쿼리 시에는 레이크 엔진의 스캔 비용이 추가된다. 일 조회량을 5퍼센트라고 잡으면, 월 스캔량은 약 18 TB다. 카탈로그 파티셔닝을 잘하면 이 비용을 절반 이하로 깎을 수 있다.
콜드 티어는 롤업을 적용해 1퍼센트 수준의 요약만 남긴다. 400 GB x 365일 x 1퍼센트, 약 1.46 TB다. 이 정도는 거의 무시해도 되는 비용으로 떨어진다.
가정마다 배율이 달라지니, 조직의 관측값으로 치환해 계산하면 우선순위가 보인다. 그리고 이 숫자가 스키마와 인덱스 전략, 수명 주기 정책, 대시보드 절제와 맞물린다.
키스타임넷 사례, 장애 하루의 기록
한여름 밤, 키스타임넷의 일부 테넌트에서 결제 실패율이 갑자기 뛰었다. 알림은 에러율 기준이 아니라, p95 지연의 전주 대비 편차로 먼저 울렸다. 대시보드에서 테넌트를 필터하자 외부 결제 게이트웨이로 나가는 라우트의 지연이 원인이었다. 동일 시간대에 외부 API 상태 페이지는 멀쩡했다. 로그에서 trace_id로 따라가니, 재시도 로직이 공격적으로 동작하며 큐를 메우고 있었다. 릴리스 태그를 기준으로 전후 대시보드를 비교했더니 바로 전일에 재시도 지수 백오프의 최대 대기 시간이 줄어든 것이 보였다.
핫 티어의 인덱싱 지연은 30초 수준이었고, 수집 에이전트는 스풀링을 하고 있었다. 샘플 로그를 보니 특정 BIN 대역 카드에서만 실패가 증가했다. 고객 지원 뷰에서 해당 테넌트의 주문 ID로 시퀀스를 복원해 주자, CS는 현장 대응을 바로 시작했다. 운영팀은 배포 롤백, 백오프 파라미터 복구, 해당 테넌트에만 임시 완화 정책을 적용했다. 웜 티어에서 지난 분기 유사 사례를 비슷한 패턴 쿼리로 찾아내고, 재발 방지 문서를 업데이트했다.
이때 살린 시간의 대부분은 스키마와 대시보드의 절제에서 나왔다. 특정 필드를 미리 남겨두지 않았다면, 텍스트 검색으로 밤을 새웠을 것이다.
멀티테넌시, 분리와 공존의 기술
키스타임이나 키탐넷처럼 고객별 격리가 중요한 조직은 멀티테넌시 전략이 곧 보안 전략이다. 저장소 수준에서 테넌트별 인덱스 또는 파티션을 분리하면 접근 제어가 쉬워지지만, 스토리지 조각화와 관리 오버헤드가 커진다. 공용 인덱스에 tenant 필드를 필수로 남기고, 역할 기반 권한으로 행 수준 필터를 적용하면 비용과 성능이 균형을 잡는다. 다만 쿼리 최적화에서 tenant가 항상 첫 필터가 되도록 쿼리 DSL을 템플릿화해 둔다. 테넌트별 상위 에러 라우트, 지연 분포, 알림 임계치도 분리해 과탑재를 막는다.
데이터 주권 이슈가 있는 리전은 파이프라인을 복제하기보다, 수집과 저장을 리전 로컬로 유지하고, 시각화 계층에서 페더레이션 조회를 붙인다. 이렇게 해야 데이터를 이동하지 않고도 전사 대시보드를 만들 수 있다.
배포, 버전, 그리고 롤백 친화적 로그
릴리스 태그와 버전 정보는 모든 로그에 포함되어야 한다. 태그가 없다면 배포 전후 비교가 어렵다. 카나리 배포에서는 카나리 라우팅 플래그를 로그에 심어야 한다. 카나리 실패를 빨리 감지하려면 지표뿐 아니라 에러 메시지 트렌드 변화가 중요하다. 메시지 텍스트를 n-gram으로 요약하고, 전일 대비 분포 차이를 산출하면 릴리스 리스크를 조기에 잡는다. 텍스트 기반 비교는 노이즈가 많지만, 배포 직후 30분이라는 짧은 창에서 신호 대 잡음비가 괜찮게 나온다.
롤백 후에는 지연과 에러율뿐 아니라 인덱싱 지연도 모니터링한다. 배포 과정에서 로그 볼륨이 증가하면 스토리지 레이어가 숨을 헐떡일 수 있다. 라우트 추가로 카디널리티가 튀는 경우가 대표적이다. 사전 검토 때 예상 라우트 수와 인덱스 필드 추가 여부를 체크리스트에 포함해 둔다.
현장에서 자주 겪는 함정
줄글로 적으면 훨씬 기억에 남는다. 첫째, 개발 환경 로그를 프로덕션 파이프라인과 섞는 실수. 편하지만 곧 지옥이 된다. 설정 하나를 잘못 바꾸면 테스트가 프로덕션 인덱스를 오염시킨다. 둘째, 메시지 본문에 구조화된 정보를 우겨 넣는 습관. 파싱 규칙이 깨지는 순간, 분석이 멈춘다. 셋째, 알림을 너무 많은 채널로 보내는 것. 슬랙, 메일, SMS를 동시에 울리면 결국 누구도 보지 않는다. 넷째, 시간 동기화를 가볍게 보는 태도. 트레이스를 맞출 수 없으면 로그의 절반 가치는 사라진다. 다섯째, 비용을 뒤늦게 보는 태도. 인덱스 필드 하나 추가로 월 비용이 수십 퍼센트 오를 수 있다.
점진적 개선 로드맵, 현실적인 다섯 걸음
처음부터 완벽할 필요는 없다. 중요한 것은 매주 나아지는 것이다. 아래 다섯 단계만 순서대로 밟아도 체감 품질이 급격히 좋아진다.
- 공통 스키마를 정하고, 모든 서비스에 배포한다. 필수 필드는 최소 10개 내외로, 필드 정의서와 샘플을 제공한다. 수집 에이전트를 표준화한다. 스풀링, 마스킹, 파티셔닝 키를 조직 표준으로 고정한다. 핫 - 웜 - 콜드의 수명 주기 정책을 코드로 정의하고, 자동 이전을 붙인다. 대시보드를 세 개의 핵심 흐름으로 재구성한다. 헬스 체크, 릴리스 검증, 고객 지원. SLO와 예산 지표를 정하고, 월간 리뷰에서 로그 플랫폼도 제품처럼 다룬다.
중간에 도구를 바꾸어도, 이 다섯 가지는 그대로 가져갈 수 있다. 실제로 키스타임넷도 저장 엔진을 교체했지만, 스키마와 파이프라인 원칙이 자리 잡혀 있어 이관이 매끄러웠다.
마이그레이션, 중단 없는 이전의 요령
이전은 항상 불안하다. 동시에, 이전을 미루면 더 큰 비용을 지불한다. 중단 없이 옮기려면 단계가 또렷해야 한다.
- 미러링 수집을 먼저 붙인다. 새로운 파이프라인으로도 동일 로그가 흐르게 하고, 손실률과 지연을 비교한다. 스키마 호환 레이어를 둔다. 필드 매핑과 타입 차이를 중간에서 흡수해, 대시보드 수정이 최소화되게 한다. 읽기 전환을 점진적으로 한다. 쿼리 혹은 대시보드별로 새 백엔드를 참조하게 하고, 지표를 비교한다. 수명 주기 이전을 앞당겨 구 인덱스 양을 줄인다. 핫 티어 데이터부터 웜 티어로 밀어, 가동 중단 위험을 낮춘다. 마지막으로 쓰기 전환을 한다. 전환 직후 과감한 로드 테스트로 숨은 병목을 찾는다.
이 과정에서 가장 중요한 것은 가시성이다. 이전 중의 성능, 비용, 오류를 숫자로 보여주면, 조직은 불안을 견딜 수 있다. 숫자가 없으면 감정이 프로젝트를 흔든다.
마무리 대신, 기준을 세우는 문장 하나
좋은 로그 시스템은 팀이 밤에 덜 깨게 만들고, 문제가 생겨도 말이 아닌 숫자로 이야기하게 만든다. 저장은 간결하게, 분석은 목적 있게, 시각화는 절제 있게. 키스타임과 키탐넷, 그리고 키스타임넷이 겪은 시행착오의 결론은 단순했다. 처음부터 다 갖추려 하지 말고, 스키마와 파이프라인의 원칙을 문장 하나로 요약해 팀이 함께 외울 수 있게 하자. 예를 들어 이런 문장이다. 중요한 것은 빨리 찾을 수 있게 남기고, 오래 남겨야 할 것은 작게 만들고, 보이면 안 되는 것은 결코 저장하지 않는다.
그 문장이 팀의 기준이 된다. 기준이 있으면 선택이 빨라지고, 선택이 빨라지면 대응이 빨라진다. 로그는 그때 비로소 가치가 생긴다.