Search Results for 'trac'

1 POSTS

  1. 2007.02.02 Trac의 실수: 정보 은닉의 실패

Trac의 실수: 정보 은닉의 실패

Posted 2007. 2. 2. 03:43
Trac는 현재 가장 많이 쓰이는 오픈 소스 이슈 트래킹(issue tracking) 도구 중에 하나입니다. Trac에서 각각의 이슈는 티켓(ticket)이라는 이름으로 관리합니다. 각 티켓은 버그 리포트가 될 수도 있고 해야 할 일이나 제안이 될 수도 있는데, 일반적으로 다음과 같은 항목을 가집니다.

  • id
  • time
  • changetime
  • component
  • severity
  • priority
  • owner
  • reporter
  • cc
  • version
  • milestone
  • status
  • resolution
  • summary
  • description

트랙은 이런 티켓을 묶어서 관리하는 방법으로 리포트(report)라는 개념을 사용합니다. 리포트는 특정 조건을 만족시키는 티켓 만을 보여주는 논리적인 뷰(view)라고 할 수 있습니다. Trac에서 View Ticket 메뉴를 누르면 Trac에 미리 정의된 리포트를 보여주는데 다음과 같습니다.


Report Title
{1} Active Tickets
{2} Active Tickets by Version
{3} Active Tickets by Milestone
{4} Assigned, Active Tickets by Owner
{5} Assigned, Active Tickets by Owner (Full Description)
{6} All Tickets By Milestone (Including closed)
{7} My Tickets
{8} Active Tickets, Mine first


이는 어떤 티켓을 보여줄 것인지 미리 정의해놓은 것입니다. 예를 들어 {7}번의 경우 나에게 할당된 티켓만을 보여달라는 옵션이고, {6}은 특정 마일스톤에 해당하는 티켓만 보여달라는 뜻입니다.

Trac는 이 시스템을 좀 더 확장해서 사용자가 원하는 리포트를 직접 작성할 수도 있도록 하였습니다. Trac의 리포트는 티켓이 저장되는 DB 테이블을 SQL 문으로 직접 얻어오는 방식을 사용합니다. 예를 들어, 모든 티켓의 모든 필드를 얻어오고 싶다면 select * from ticket이라고 입력해 주면 됩니다.

하지만 TracReports의 노트를 보면 이런 디자인 결정이 실수라고 이야기하고 있습니다. 티켓의 테이블은 세부 구현 사항에 해당하는데, 리포트를 구현하기 위해 티켓 테이블을 외부로 노출시켰기 때문입니다. 따라서 이후 버전에서 티켓 테이블의 구조를 변경해야 하거나 최적화가 필요할 경우 이를 수정할 수 있는 유연성이 떨어지게 되는 것이죠.

이 문제를 해결하기 위해 Trac은 원하는 티켓을 검색해주는 트랙 질의(Trac Query) 모듈을 별도로 만들었습니다. 트랙 질의 모듈은 티켓 테이블에 직접 접근하는 방식에서 벗어나 사용자가 원하는 정보를 몇 가지 필터를 적용해 얻어올 수 있도록 하였습니다. 티켓 테이블이라는 내부 구현을 숨겼기 때문에 이후 버전에서 변경의 용이성이 생긴 셈입니다.

Trac은 현재는 두 가지 버전(SQL 이용, 질의 모듈 이용)을 모두 지원하지만, 앞으로는 질의 모듈을 사용할 것을 강력히 권고하고 있습니다. 이는 정보 은닉(information hiding)과 관련된 잘못된 디자인이 소프트웨어의 유지 보수(maintenance)에 어떤 영향을 미치는지를 보여주는 좋은 사례라 할 수 있습니다.