트레이싱 (tracing)은 프로그램의 실행에 관한 정보를 기록하기 위한 로깅의 특별한 사용이다. 이 정보는 보통 프로그래머가 디버깅을 목적으로 사용된다. 또는 시스템 관리자나 기술 지원 인원 그리고 소프트웨어 감시 툴이 소프트웨어의 일반적인 문제들을 진단하기 위해서, 추가적인 자세한 트레이스 로그를 포함하는 정보로서 사용된다. 트레이싱은 횡단 관심사(cross-cutting concern)이다.

소프트웨어 개발 프로세스
활동과 단계
요구사항 분석 · 기능 명세
구조 · 설계
구현 · 테스팅
배치 · 유지보수
개발 모형
애자일 소프트웨어 개발 · 클린룸
DSDM · 순차점증적 개발 · 반복형 개발
RAD · RUP · 나선 모형
폭포수 모델 · 익스트림 프로그래밍
스크럼 · V 모델 · TDD
지원 활동
구성 관리 · 문서화
품질보증 · 프로젝트 관리
사용자 경험 설계
도구
컴파일러 · 디버거 · 프로파일러
GUI 디자이너 · 통합 개발 환경

트레이싱과 로깅은 다른 형태들 사이의 명확한 구분은 없지만 트레이싱이라는 용어가 프로그램의 기능 요구 사항(functional requirement)인 로깅에 적용되는 개념은 아니다. 즉 입자물리학 실험에서의 데이터 획득 그리고 로그 선행 기입 같은 외부 소스의 데이터 로깅은 트레이싱에 포함되지 않는다. 프로그램의 사용이나(서버 로그) 운영체제의 이벤트들을 기록한 로그는 시스템 관리자에게 우선적인 관심 대상이다. 이 문서는 디버깅이나 진단 목적의 트레이싱을 다룬다.

이벤트 로깅 대 트레이싱 편집

이벤트 로깅과 트레이싱을 명확히 구분하는 것은 어렵다. 같은 기술들이 둘 다에서 사용되기 때문이다. 아래의 테이블은 중요하지만 정확하지는 않은 구분을 목록화했다.

이벤트 로깅 소프트웨어 트레이싱
주로 시스템 관리자가 필요로함 주로 개발자들이 필요로함
"높은 수준"의 정보를 기록 (프로그램 설치의 실패 같은 "낮은 수준"의 정보를 기록 (throw된 예외 같은)
잡다하지 않다. (많은 중복된 것들은 유용하지 않다.) 잡다할 수 있다.
표준에 기반한 출력 형식이 종종 요구된다. 출력 포맷에 대한 제한이 없다.
이벤트 로그 메시지들은 종종 지역화된다. 지역화는 고려 대상이 아니다.
새로운 형태의 이벤트에 대한 추가가 빨리 이뤄질 필요가 없다. 새로운 트레이싱 메시지들의 추가는 빨리 이루어져야 한다.

이벤트 로깅 편집

이벤트 로깅은 시스템 관리자가 진단하고 감사하는데 유용한 정보를 제공한다. (이벤트 메시지들 중에서 기록될 것과 세부 사항에 대한) 이벤트들의 다른 클래스들은 개발 단계 이전에 고려되는 경향이 있다. 많은 이벤트 로깅 기술들은 각 이벤트의 클래스에 고유한 코드가 부여되는 것을 허용하거나 요구한다. 이것은 지역화를 가능케 하고 시스템 관리자가 발생한 문제에 대한 정보를 얻는 것을 쉽게 한다.

이벤트 로깅이 높은 수준의 정보를 기록하는 것을 요구하기 때문에 성능은 종종 비교적 덜 고려된다.

소프트웨어 트레이싱 편집

소프트웨어 트레이싱은 개발자에게 디버깅을 위한 유용한 정보를 제공한다. 이 정보는 개발 기간 뿐만 아니라 배포 후에도 사용된다. 이벤트 로깅과 다르게, 소프트웨어 트레이싱은 이벤트의 "클래스"와 "이벤트 코드"라는 개념을 갖지 않는다. 이벤트 로깅 방식이 소프트웨어 트레이싱에 적절하지 않은 이유는 다음과 같다.

  • 소프트웨어 트레이싱은 저수준이기 때문에 많은 종류의 메시지 형식들이 있으며, 이것들은 코드의 한 부분에만 사용될 수 있다. 이벤트 로깅 파라다임은 이런 "한번만 사용되는" 메시지들로 인한 개발 오버헤드가 발생케 한다.
  • 개발 기간 동안 기록된 메시지들의 종류는 종종 이벤트 로깅보다 불안정한 편이다.
  • 트레이싱의 결과는 개발자들이 사용하는 것이기 때문에 메시지는 지역화될 필요가 없다. 그러므로 트레이싱 메시지를 다른 지역화가 필요한 자원들과 분리하는 것은 중요하다.
  • 한번도 보지 못한 메시지들도 있다.
  • 트레이싱 메시지들은 코드 안에 있어야 한다. 왜냐하면 이것들은 코드의 신뢰도를 높일 수 있기 때문이다. 이것은 이벤트 로깅 해결책에서는 가능하지 않을 수 있다.

소프트웨어 트레이싱의 다른 중요한 고려할 점은 성능이다. 소프트웨어 트레이싱이 낮은 수준에서 이루어지기 때문에 트레이스 메시지의 가능한 양은 훨씬 커질 수 있다. 그렇기 때문에 종종 컴파일 타임이나 실행 시간에 꺼놓을 필요가 있다. 다른 고려 사항을 보자면


  • 사유 소프트웨어에서, 트레이싱 데이터는 소스 코드에 대한 민감한 정보를 가질 수 있다.
  • 만약 트레이싱이 실행 중에 활성화 되거나 비활성화 된다면, 트레이싱의 많은 방식들이 많은 양의 추가적인 데이터를 바이너리에 포함될 것을 필요로 하며, 이것은 성능을 감소시킨다.
  • 만약 트레이싱이 컴파일 타임에 활성화되거나 비활성화 된다면, 고객 머신의 문제에 대한 트레이스 데이터를 얻는 것은 고객이 특별한 버전의 소프트웨어를 설치할 수 있는가에 달려있으며, 이후에 문제를 복사할 수 있다. 
  • 운영체제에서, 트레이싱은 부팅 때 같은 상황 같이 이벤트 로깅이 활성화되지 못할 때 유용하다.

기술과 기법 편집

소프트웨어 트레이싱:

  • 트레이싱 매크로
  • 디버거에 출력
  • 관점 지향 프로그래밍과 related instrumentation 기법
  • Windows software trace preprocessor (WPP)
  • ftrace를 통한 리눅스 커널 트레이싱
  • Kernel Markers와 LTTng을 통한 리눅스 시스템 레벨과 사용자 레벨 트레이싱

이벤트 로깅:

둘 다에서 적절한:

같이 보기 편집

외부 링크 편집