초안 · 외부 작성 · 사내에서 보완 [ ] 표시는 사내에서 채우는 칸 1장만 봐도 끝. 2~4장은 질문이 나올 때
1 / 4  요약disk logging

Disk Logging 소개내부 buffer에서 끝나던 logging을 segment 단위로 disk까지 이어 붙인다

추가 · disk logging IP A IP B IP C … trace STM ETR 신규 ① seg IRQ 신규 ② hold logging 내부 memory buffer · segment 분할 seg 0 seg 1 seg 2 seg 3 비워짐 full → ① 기록 중 아직 write 중 segment FW log writer log write ① segment full → interrupt → disk write trigger ② 다음 segment가 아직 비워지지 않음 → logging hold (성능 양보, log 무손실) Host data read 서비스 disk 고객 제공 영역 그만큼 줄어듦 log 영역 read 사이에 log write가 끼어듦 → latency 영향 기존 · 각 IP → STM/ETR → 내부 buffer. buffer가 작아 남는 양이 적다 추가 · segment 단위로 disk에 기록. 큰 공간, 대신 용량·성능 trade-off
왼쪽 회색 구간은 지금도 있는 경로다. 색이 든 것만 새로 들어간다: buffer의 segment 분할, ETR의 ①②, FW의 log writer, disk의 log 영역. 호박색은 그 대가다.

무엇이 달라지나기존 → 추가

  • 기존. 각 IP가 STM/ETR을 통해 내부 memory buffer에 logging. 크기 제약으로 저장되는 양이 적다
  • 추가. buffer에 쌓인 log를 segment 단위로 disk에 기록. 상대적으로 큰 공간에 남긴다
  • 새 경로를 받치는 것이 ETR 신규 기능 ①② (오른쪽)

ETR 신규 기능둘 다 disk logging의 보조

  • ① segment full interrupt. logging buffer를 여러 segment로 나누고, segment가 찰 때마다 interrupt. 이를 신호로 disk log write를 trigger
  • ② logging hold. 다음 segment가 준비되지 않았으면 logging을 지연. 제품 성능은 떨어질 수 있지만 log는 온전히 기록된다

문제trade-off

  • 고객 용량. log 영역만큼 고객에게 제공하는 disk 용량이 줄어든다 [정도]
  • 성능, 특히 latency. 제품이 data read를 서비스하는 중에 관련 log write가 발생해 끼어든다. throughput보다 latency에 큰 영향
  • ②는 log 무손실 대신 성능을 더 양보한다. 어디까지 허용할지가 설계 변수 [정책]

활용 · AI agent 연동당장은 개발자용

  • 개발 단계에서 먼저. log를 최대한 많이 남겨 분석 시간을 줄이고, 어떤 log가 효과적인지 알아낸다. 개발용이라 위의 두 대가가 붙지 않는다
  • 많은 log는 AI agent가. 방대한 데이터의 분석·테스트·백데이터 분류를 agent와 자동화로 잇는다
  • 그다음 고객 제품. 가려낸 log만 담는다 [시점]
활용은 2장, ①② 동작 순서는 3장, trade-off 상세는 4장[작성자 · 날짜]
2 / 4  활용 방안disk logging

당장은 개발자용이다. log를 최대한 남겨 분석 시간을 줄이고, 어떤 log가 효과적인지 알아낸다

기존 · 제한된 log로 디버깅 이슈 발생 분석 log 충분한가? 예 원인 파악 아니오 log 추가한 FW 재발행 재현 · 재테스트 반복 · FW 재발행 횟수 [ ] 분석 시간 ↑ · 개발자와 고객 모두 기다린다 추가 · 개발 단계에서 disk logging 개발자 A 개발자 B 개발자 C … log 임의 추가 최대한 많이 · 쉽게 disk logging 전부 저장 개발용 disk → 고객 용량 · 성능 제약 없음 방대한 데이터 사람이 다 보기엔 비효율 AI agent 읽고 · 거르고 · 나눈다 테스트 자동화 분석 백데이터 분류 분석 시간 ↓ 효과적 log 식별 고객 제품에 꼭 담을 log만 선별
위 띠의 루프가 얼마나 도는지가 disk logging의 필요성이다. 아래 띠는 개발 단계라 1장의 두 대가(고객 용량, 성능)가 붙지 않는다. 대신 log가 너무 많아지는 새 문제가 생기고, 그 답이 AI agent다.

먼저 인지할 것이 질문에 "그렇다"일 때 논리가 선다

  • 기존 방식으로 디버깅에 어려움이 있는가? disk logging으로 개선되는가?
  • 제한된 log 양 때문에 개발자와 고객이 어떤 어려움을 겪는가?
  • log 부족으로 분석 효율이 떨어지는가? log를 새로 추가한 FW를 얼마나 재발행하고 있는가? [횟수 · 기간]

당장의 활용고객이 아니라 개발자

  • 제품 개발 과정에서 최대한 많은 log를 저장해 분석 시간을 단축한다
  • 그 과정에서 어떤 log가 효과적인지 파악한다 → 이후 고객 제품에 꼭 담겨야 할 log를 구분할 수 있다
  • 내부 개발 테스트용이므로 저장 용량 감소 문제가 없고, 성능 영향과 무관한 대상이다

log를 늘리는 방식과거와 반대로

  • 과거: 제한된 log. 무엇을 남길지 미리 골라야 했다
  • 이제: 각 개발자가 임의로, 쉽게 추가한다. 고르는 일은 나중에, 데이터를 보고 한다

AI agent 연동많은 log의 대가를 치르는 곳

  • 너무 많은 log는 방대한 데이터가 되어 사람의 분석에는 오히려 비효율이 될 수 있다
  • 이를 AI agent의 도움으로 해결한다. 그래서 이 과정에서 agent와 연동되고, 테스트 · 분석 · 백데이터 분류 등 자동화와 연계가 필요하다
개발자용으로 시작해 효과적 log를 가려낸 뒤 고객 제품으로. 순서는 4장 계획1장 4번째 칸 상세
3 / 4  부가 · ETR 신규 기능 ①②의 동작disk logging

segment가 차면 ① interrupt로 write를 걸고, 다음 segment가 아직 안 비었으면 ② 기록을 멈춘다

ETR 기록 ① IRQ FW disk write seg A 채움 seg B 채움 ② hold seg A 채움 seg B 채움 A full B full A full B full A write host read와 겹쳐 길어짐 B write A write A write 끝 → hold 해제, A 다시 채움 시간 → segment 2개(A·B) 예시. 실제 개수 [ ]
B가 찼는데 A의 disk write가 끝나지 않았다. ②가 없으면 ETR은 A를 덮어써 log를 잃는다. ②가 있으면 write가 끝날 때까지 기록을 멈춘다. 그 시간만큼 제품이 느려질 수 있다.
기능무엇을언제얻는 것 / 대가
① segment full IRQlogging buffer를 여러 segment로 나누고, segment가 찰 때마다 interrupt를 낸다segment full 시점FW가 "지금 이 segment를 disk에 써라"를 알게 된다. buffer 전체가 찰 때까지 기다리지 않는다
② logging hold다음 segment가 아직 준비되지 않았으면 ETR logging을 지연시킨다다음 segment가 disk write 중일 때log 무손실 / 그동안 제품 성능 저하 가능
segment 크기·개수, hold 허용 시간은 설계 변수 [ ]1장 ①② 상세
4 / 4  부가 · trade-off와 계획disk logging

큰 공간을 얻는 대신 고객 용량과 latency를 내준다

문제원인 → 영향

문제원인영향사내에서 채울 것
고객 용량 감소disk 일부를 log 영역으로 떼어 둔다고객에게 제공하는 용량이 그만큼 준다[log 영역 크기 · 비율]
성능 영향 — latency제품이 data read를 서비스하는 중에 관련 logging의 log write가 같은 disk에 발생한다throughput보다 latency에 큰 문제. read 응답 사이에 write가 끼어든다[영향 정도 · 측정 조건]
hold에 의한 성능 저하② logging hold가 다음 segment가 빌 때까지 기록을 멈춘다log는 온전하지만 그 시간만큼 제품이 느려질 수 있다[hold 허용 정책]

이 대가가 붙지 않는 곳개발 단계

2장의 활용은 내부 개발 테스트용이다. 개발용 disk라 고객 용량이 줄지 않고, 성능 영향과 무관한 대상이다. 위 표는 고객 제품에 실을 때의 문제다.

향후 계획순서

  • 개발 단계에서 log를 최대한 남기고 AI agent와 연동 [시점]
  • 효과적 log를 가려내 고객 제품에 담을 log를 선별 [시점]
  • 고객 제품 적용 시 위 표의 용량·latency 정책 결정 [시점 · 정책]
수치는 사내에서. 여기서는 방향만1장 문제 상세 · 2장 활용의 뒷면