소프트웨어 개발 프로세스 | |
---|---|
활동과 단계 | |
요구사항 분석 · 기능 명세 구조 · 설계 구현 · 테스팅 배치 · 유지보수 | |
개발 모형 | |
애자일 소프트웨어 개발 · 클린룸 DSDM · 순차점증적 개발 · 반복형 개발 RAD · RUP · 나선 모형 폭포수 모델 · 익스트림 프로그래밍 스크럼 · V 모델 · TDD | |
지원 활동 | |
구성 관리 · 문서화 품질보증 · 프로젝트 관리 사용자 경험 설계 | |
도구 | |
컴파일러 · 디버거 · 프로파일러 GUI 디자이너 · 통합 개발 환경 | |
트레이싱 (tracing)은 프로그램의 실행에 관한 정보를 기록하기 위한 로깅의 특별한 사용이다. 이 정보는 보통 프로그래머가 디버깅을 목적으로 사용된다. 또는 시스템 관리자나 기술 지원 인원 그리고 소프트웨어 감시 툴이 소프트웨어의 일반적인 문제들을 진단하기 위해서, 추가적인 자세한 트레이스 로그를 포함하는 정보로서 사용된다. 트레이싱은 횡단 관심사(cross-cutting concern)이다.
트레이싱과 로깅은 다른 형태들 사이의 명확한 구분은 없지만 트레이싱이라는 용어가 프로그램의 기능 요구 사항(functional requirement)인 로깅에 적용되는 개념은 아니다. 즉 입자물리학 실험에서의 데이터 획득 그리고 로그 선행 기입 같은 외부 소스의 데이터 로깅은 트레이싱에 포함되지 않는다. 프로그램의 사용이나(서버 로그) 운영체제의 이벤트들을 기록한 로그는 시스템 관리자에게 우선적인 관심 대상이다. 이 문서는 디버깅이나 진단 목적의 트레이싱을 다룬다.
이벤트 로깅과 트레이싱을 명확히 구분하는 것은 어렵다. 같은 기술들이 둘 다에서 사용되기 때문이다. 아래의 테이블은 중요하지만 정확하지는 않은 구분을 목록화했다.
이벤트 로깅 | 소프트웨어 트레이싱 |
---|---|
주로 시스템 관리자가 필요로함 | 주로 개발자들이 필요로함 |
"높은 수준"의 정보를 기록 (프로그램 설치의 실패 같은 | "낮은 수준"의 정보를 기록 (throw된 예외 같은) |
잡다하지 않다. (많은 중복된 것들은 유용하지 않다.) | 잡다할 수 있다. |
표준에 기반한 출력 형식이 종종 요구된다. | 출력 포맷에 대한 제한이 없다. |
이벤트 로그 메시지들은 종종 지역화된다. | 지역화는 고려 대상이 아니다. |
새로운 형태의 이벤트에 대한 추가가 빨리 이뤄질 필요가 없다. | 새로운 트레이싱 메시지들의 추가는 빨리 이루어져야 한다. |
이벤트 로깅은 시스템 관리자가 진단하고 감사하는데 유용한 정보를 제공한다. (이벤트 메시지들 중에서 기록될 것과 세부 사항에 대한) 이벤트들의 다른 클래스들은 개발 단계 이전에 고려되는 경향이 있다. 많은 이벤트 로깅 기술들은 각 이벤트의 클래스에 고유한 코드가 부여되는 것을 허용하거나 요구한다. 이것은 지역화를 가능케 하고 시스템 관리자가 발생한 문제에 대한 정보를 얻는 것을 쉽게 한다.
이벤트 로깅이 높은 수준의 정보를 기록하는 것을 요구하기 때문에 성능은 종종 비교적 덜 고려된다.
소프트웨어 트레이싱은 개발자에게 디버깅을 위한 유용한 정보를 제공한다. 이 정보는 개발 기간 뿐만 아니라 배포 후에도 사용된다. 이벤트 로깅과 다르게, 소프트웨어 트레이싱은 이벤트의 "클래스"와 "이벤트 코드"라는 개념을 갖지 않는다. 이벤트 로깅 방식이 소프트웨어 트레이싱에 적절하지 않은 이유는 다음과 같다.
소프트웨어 트레이싱의 다른 중요한 고려할 점은 성능이다. 소프트웨어 트레이싱이 낮은 수준에서 이루어지기 때문에 트레이스 메시지의 가능한 양은 훨씬 커질 수 있다. 그렇기 때문에 종종 컴파일 타임이나 실행 시간에 꺼놓을 필요가 있다. 다른 고려 사항을 보자면
소프트웨어 트레이싱:
이벤트 로깅:
둘 다에서 적절한: