그레이트 테이블스의 디자인 철학

 (posit-dev.github.io)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Great Tables는 데이터 분석 흐름을 Python 코드 안에 유지하면서도, 20세기 중반 인쇄 표의 정교한 표현력을 되살리려는 테이블 제작 패키지임
  • 표는 단순한 행·열 격자가 아니라, 열 순서·레이블·구분선을 통해 값을 찾고 비교하기 쉽게 만드는 정보 표현 형식임
  • 고대 수메르 점토판부터 _Manual of Tabular Presentation_까지 표는 정보 밀도와 형식을 함께 발전시켰지만, 초기 스프레드시트는 계산 편의성에 비해 표현력이 부족했음
  • Great Tables는 표를 6개 구성요소로 나누고, tab_*, fmt_*, opt_*() 계열 API로 구조·서식·스타일링을 분리함
  • 이 패키지는 대용량 인터랙티브 탐색보다 논문·책·보고서에 들어가는 정적 요약 표의 출판·발표 품질을 높이는 데 초점을 둠

Great Tables가 풀려는 표 제작 딜레마

  • 표는 플롯처럼 정보를 제시하는 마지막 단계에서 중요하며, 효과적인 표 설계에는 예상보다 많은 정교함과 뉘앙스가 있음
  • 오늘날 데이터 작업자는 보통 두 선택지 사이에서 타협해야 함
    • Excel 같은 도구로 데이터를 복사해 표를 다시 만들기
    • 다듬어지지 않은 표를 그대로 표시하기
  • Great Tables는 이 딜레마를 Python 코드 기반 인터페이스로 해결하려는 패키지임
  • 데이터 수집, 분석, 요약 표 생성까지 Python 안에서 처리하면서도 표현력 있는 표를 만드는 것이 목표임

표의 기본 정의와 가독성 요소

  • 표는 두 가지 기본 규칙으로 요약됨
    • 데이터가 열과 행으로 표현됨
    • 데이터가 주로 텍스트로 표현됨
  • 예시 표는 사람을 행으로, 이름·주소·도시·우편번호·생년월일·키·몸무게 같은 특성을 열로 배치함
  • 이런 배치는 개별 값을 찾거나 행과 열을 넘나들며 비교하기 쉽게 만듦
  • 행 사이의 가로선은 필수 조건은 아니지만, 개별 행을 시각적으로 구분하는 보강 역할을 함
  • 열의 순서도 가독성에 직접 영향을 줌
    • Name 열이 오른쪽 끝에 있으면 각 레코드의 주체가 즉시 보이지 않아 독자가 더 혼란스러울 수 있음
    • 열 레이블은 각 열에 어떤 데이터가 들어 있는지 알려주며, 대부분의 경우 추측을 줄여줌

고대 표의 역사

  • 표는 정보를 담을 수 있는 컨테이너인 정사각형 격자에서 출발함
  • 프랑스 Lascaux와 Niaux 동굴 벽에는 약 2만 5천 년 전 격자 표현이 남아 있음
  • 기원전 2세기 Hipparchus는 위도와 경도로 천체와 지상 위치를 나타냈고, 서기 150년 무렵 Ptolemy의 _Geographia_는 격자를 활용한 지도 제작 방법을 포함함
  • 로마의 centuriation은 도로·운하·농경지를 통해 정사각형 격자를 형성하는 토지 측량 체계였음
  • 농업이 널리 퍼진 약 1만 년 전 이후, 농업·가축·노동 분업 관련 경제 거래를 기록하고 관리할 필요가 커짐

수메르와 메소포타미아의 표 구조

  • 기원전 4천 년기 메소포타미아 도시들은 먼 왕국들과 교역하며 기록을 보관해야 했고, Uruk에서 발견된 점토판에는 초기이지만 정교한 표가 남아 있음
  • 기원전 3200~3000년경 Uruk 점토판은 맥주 생산을 위한 보리와 맥아 배송량을 기록함
    • 오른쪽에서 왼쪽으로 읽는 구조임
    • 각 칸에는 단어·개념을 나타내는 표의문자와 수량을 나타내는 숫자가 들어 있음
    • 약 두 개의 행은 각각 한 사람에 대응함
    • 오른쪽 두 열은 맥아와 보리 수량을 담음
    • 세 번째 열은 개인별 소계를, 왼쪽 끝 열은 총계를 표시함
    • 맨 아래 행에는 담당 관리의 이름이 있어 푸터처럼 동작함
  • 약 천 년 뒤의 Nippur Enlil 신전 점토판은 수입원과 50명 신전 인력의 월별 지출을 담음
    • 더 규칙적인 격자가 보임
    • 월 이름 형태의 열 제목과 개인 이름·직업 형태의 행 제목이 있음
    • 정보가 없는 빈 셀, 숫자 값, 6개월 단위 소계, 총계, 설명 주석이 포함됨
  • 이후 표의 매체는 점토에서 밀랍판, 파피루스, 종이로 바뀌었고, 쓰기 기술과 표 디자인도 함께 변화함

20세기 중반 표 디자인의 정점

  • 20세기 중반은 표 디자인이 특히 강했던 시기로 다뤄짐
  • 오프셋 인쇄, 타자기, varitype 같은 문서 제작 기술이 표 요소를 정밀하게 조판할 수 있을 만큼 발전함
  • 페이지 공간 제약은 있었지만, 표를 한 페이지에 맞추거나 여러 페이지에 나누는 다양한 해결책이 존재했음
  • 고도화된 인쇄 기술과 표 디자인 지식이 결합되면서 아름다운 표를 만들 수 있었음
  • 미국 인구조사국의 Manual of Tabular Presentation는 정보 밀도가 높은 표의 이상적 설계를 상세히 다룬 작업임
    • 표의 여러 부분을 명명하고 엄밀하게 설명함
    • 다양한 표 작성 상황에서 해야 할 것과 하지 말아야 할 것을 강하게 권고함
    • 표가 보기 좋으면서도 많은 정보를 담을 수 있음을 보여줌
  • Great Tables는 이 문서의 표 디자인 원칙을 많이 차용하며, 그 원칙이 지금도 유효하다는 전제에서 출발함

스프레드시트 이후의 후퇴와 한계

  • 1970~1980년대 컴퓨팅 기술이 접근 가능해지면서 사람들은 전자 형태와 인쇄 형태로 표를 만들 수 있게 됨
  • 계산 가능한 표의 대중화는 1979년 VisiCalc와 함께 시작된 것으로 볼 수 있음
  • VisiCalc는 값을 빠르게 계산할 수 있었지만, 발표용 표를 만들기에는 표현력이 제한적이었음
    • 격자 셀에 발표용 테두리 스타일을 줄 수 없었음
    • 값을 서식화할 수 없었음
    • 표를 인쇄할 수도 없었음
  • 이후 10~15년에 걸쳐 스프레드시트 표는 보기 좋아짐
    • 1990년대 초 Excel은 표에 테두리를 칠할 수 있었음
    • 타이포그래피 지원이 나아짐
    • 값 서식 기능도 더 갖춰짐
  • 그래도 최근 30년의 Excel 표는 _Manual of Tabular Presentation_의 수준에 미치기 어려웠다고 평가됨
  • 데이터 분석이 Excel 밖에서도 이루어지면서 세 가지 비효율적 시나리오가 생김
    • Python 안에서 분석과 표 생성을 모두 처리하지만 표 품질이 낮음
    • Excel 안에서 분석과 표 제작을 모두 처리하지만 분석 유연성이 낮음
    • Python에서 분석하고 Excel로 복사해 표를 만들지만 재현 가능하지 않음

Great Tables의 표 모델

  • Great Tables는 20세기 중반 표의 우아함을 코드 인터페이스의 힘과 결합하려는 Python 패키지임
  • 표를 6개의 독립 구성요소 조합으로 표현함
    • Table Header: 제목과 부제목을 넣어 표 내용을 간결하게 설명하는 공간
    • Column Labels: 각 열의 내용을 정의하며, spanner는 여러 열 그룹 위에 놓이는 제목
    • Stub Head: 왼쪽 위 위치로, 다양한 방식의 레이블을 둘 수 있음
    • Row Stub: 행 정보와 행 그룹 레이블을 위한 영역
    • Table Body: 셀을 포함하며 데이터가 위치하는 영역
    • Table Footer: 표 내용과 관련된 추가 정보를 담는 공간
  • Great Tables는 코드로 표 본문을 만든 뒤 스타일링, 서식, 다른 구성요소를 반복적으로 추가하는 방식으로 사용함
  • 예시 코드는 GT(simple_table, rowname_col="Name")에서 시작해 제목, stub head, column spanner, source note, 날짜·정수 서식, 스타일 옵션을 추가함
  • 예시 표에서는 파란 row stub가 행 레이블을 표 본문과 구분함
    • 각 사람이 고유한 관측값이므로 행의 주체를 강조함
    • 제목은 표에 담긴 내용을 설명함
    • Location과 Personal Characteristics spanner는 열을 의미 있는 그룹으로 묶음
    • 파란 선과 셀 배경의 일관된 사용은 전문적인 외형을 만듦
  • 표 구성요소를 추가하는 메서드는 tab_로 시작함

서식화와 nanoplots

  • 표 구조화만으로는 충분하지 않으며, 분야마다 값 표시 요구사항이 다름
  • 숫자 하나도 공동체의 규범과 기대에 따라 여러 방식으로 표시될 수 있음
  • 날짜, 시간, 통화까지 포함하면 서식화 범위는 더 넓어짐
  • 원시 값 134,000은 요구사항에 따라 다르게 표현될 수 있음
  • 값이 이미지나 플롯으로 전달되어야 할 때 서식화 문제는 더 커짐
  • 의료 분석가가 환자 검사 결과의 개선·악화 추세를 전달해야 한다면, 행 전체의 숫자 시퀀스를 읽는 방식은 해석을 늦출 수 있음
  • fmt_nanoplot()은 nanoplots를 통해 표 안에서 작은 추세 시각화를 제공함
    • 데이터 포인트에 마우스를 올리면 각 날짜의 값을 볼 수 있음
    • nanoplots는 플롯의 빠른 시각적 해석과 표의 컴팩트함 사이의 균형을 목표로 함
  • Great Tables의 서식 메서드는 fmt_로 시작함
  • 패키지는 다양한 사용자의 요구에 맞춰 많은 서식 메서드와 유용한 옵션을 제공하려 함

출판·발표용 정적 요약 표에 집중

  • Great Tables는 테이블과 상호작용하는 여러 방식 중 출판과 발표용 표시에 초점을 맞춤
  • 데이터베이스 분석에서는 수백, 수천, 또는 그 이상의 레코드를 탐색하고 필터링하는 단순 테이블 표시가 적합할 수 있음
  • 결과 출판은 다른 작업이며, 여기서는 구조화·서식화·스타일링이 중심임
  • 아름다운 표 표시는 다음을 충족해야 함
    • 정보를 더 쉽게 소화하게 만듦
    • 필요한 곳에 추가 맥락을 제공함
    • 문서나 조직의 스타일을 따름
  • 대상 사용 사례는 저널 논문, 책, 보고서에서 볼 수 있는 방식의 데이터 제시임
  • Great Tables는 정적 요약 표가 별도 초점을 받을 만한 영역이라고 보고, opt_*() 메서드로 독자에게 더 좋은 표를 제공하기 쉽게 만들려 함
  • 패키지의 성공 기준은 만들어낼 수 있는 표의 품질이며, API 개선 작업을 계속할 계획임
  • 커뮤니티 피드백을 위해 Discord Server를 열어두고 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들
  • Great Tables는 Python/Jupyter 테이블 쪽에서 꽤 훌륭한 작업을 해왔고, 그래픽 문법(grammar of graphics)처럼 테이블 문법을 거의 만들고 있는 것처럼 보임
    더 많은 프로젝트가 이런 식으로 철학과 목표를 설명해주면 좋겠음
    Jupyter용으로 Buckaroo라는 다른 테이블 라이브러리를 만들었는데, 접근 방식은 다름
    Buckaroo는 대화형으로 작업하면서 여러 형식과 후처리 함수를 빠르게 돌려 보며 테이블에서 중요한 통찰을 얻도록 만드는 것을 목표로 함
    기본적인 탐색적 데이터 분석을 할 때 같은 명령을 반복해서 입력하게 되니, 그런 명령과 통찰이 테이블 안에 들어가야 한다고 봤음
    Great Tables는 발표용 테이블을 수동으로 서식 지정하기 위해 만들어진 쪽에 가까워 보임
    https://github.com/paddymul/buckaroo
    https://youtu.be/GPl6_9n31NE
    • Buckaroo 작업에 고마움. Jupyter의 print()와 IPython display()는 죽은 정적 출력이라는 한계가 있고, 예전 printf 디버깅처럼 느껴지는데 Buckaroo가 그걸 해결하려고 만들어진 걸로 알고 있음
      Visidata의 단축키와 조작 방식은 어떻게 보는지 궁금함
      예전에 Visidata를 썼고, 데이터프레임 탐색용으로 왜 Jupyter 안에 결국 들어갈 수 없는지 늘 궁금했음
      Great Tables가 테이블 문법을 공식화하려는 또 다른 시도로 보인다는 데 동의하며, 표 형식의 힘과 R/pandas/Arrow/polars 생태계를 통한 데이터프레임 개념의 확산을 생각하면 이런 접근은 환영함
      다만 이 용어는 원래 90년대 통계 언어 S에서 처음 쓰였던 것으로 알고 있음
      [1] https://towardsdatascience.com/preventing-the-death-of-the-d...
  • Great Tables 예시는 내 취향에는 너무 복잡함. 제목 위아래의 가로줄은 불필요해 보이고, 첫 번째 열인 행 레이블에 맞춘 것도 별로임
    아래쪽에 약간의 여백을 두고 굵은 글꼴을 쓰면 잡음 없이 시각적 계층을 줄 수 있을 듯함
    행 레이블 배경은 너무 어둡고 글꼴 두께 때문에 읽기 어려워서, 아주 연한 파란색이 더 낫겠음
    행 그룹 레이블인 “Name”을 기울임꼴로 둔 것도 마음에 들지 않음
    가운데에 떠 있는 상위 열 레이블은 테이블을 훑기 어렵게 만들며, 왼쪽 정렬이 훨씬 나을 것 같음
    마지막으로 글꼴도 정말 마음에 들지 않는데, 이건 브라우저 탓일 수도 있음
    몇 가지 변경을 반영해 목업을 만들었고, 이쪽이 훨씬 읽기 쉬운 테이블이라고 봄
    https://i.imgur.com/iMMf5vo.png
    • Edward Tufte의 Beautiful Evidence를 읽어보면 좋겠음
      읽기 쉬움과 데이터의 메시지나 핵심을 방해하는 요소 같은, 방금 언급한 내용을 다룸
      스파크라인을 본 적이 있다면, 그 용어를 만든 사람도 Tufte임
      UI 리뷰를 할 때마다 우리가 놓친 게 있는지 보려고 이 책을 뒤적이게 되고, 아무 페이지나 펼쳐 읽어도 흥미로운 책임
      게다가 PowerPoint가 왜 형편없는지에 대한 긴 논고도 있음
      [1] https://www.edwardtufte.com/tufte/books_be
      [2] https://en.wikipedia.org/wiki/Sparkline
    • 테이블 제목은 위쪽 가운데 정렬이거나 아래쪽 캡션이어야 함
      어떤 열 위에 왼쪽 정렬하면, 대체로 사실이 아니거나 의도하지 않은 방식으로 그 제목이 테이블 정보 계층의 최상위처럼 보임
      위의 현대주의식 수정안에서는 제목이 “names, addresses, characteristics”라고 해놓고 정렬상으로는 이름을 제외하는 듯 보여 바로 불편했음
      반대로 인구조사 매뉴얼은 거의 모든 레이블을 해당 박스 안에서 가운데 정렬하고, 그렇지 않을 때도 대부분 들여쓰기 때문임
      또한 레이블이 아니라 데이터에 맞춰 열 너비를 정하고, 들여쓰기와 하이픈 처리를 맞추는 데 주저하지 않음
      결과적으로 가로로 조밀하면서도 직관적으로 이해 가능해짐
      더 생각해보니 제목 자체도 별로임
      제목과 캡션은 맥락, 범위, 목적을 전달해야 하며, 그러지 못한다면 자기 존재를 정당화하지 못했다는 편집상의 죄로 아예 생략해도 됨
      지금 제목은 정보나 일반성을 잃지 않고 “Table 1”로 바꿀 수 있음
      표 표현을 제1원리부터 논의하고 재구성하려는 글치고는 다소 실망스러움
      테이블 제목이 정보 카탈로그의 중요한 층을 이루므로, 인구조사 매뉴얼이 제목 구성에 한 장 전체를 할애한 것도 놀랍지 않음
      다소 도메인 특화적이고 고풍스러운 문체이긴 해도 볼 가치가 큼
    • 각 행이 자체 레코드라는 느낌을 강화하기 위해 가로줄이나 줄무늬 같은 요소가 왜 없는지 이해가 안 됨
    • 네 목업이 개선된 버전임. 글의 예시는 테이블 안 모든 문자와 숫자의 시각적 무게가 균일해서 문제가 있음
    • 더 밀어붙여도 된다고 봄. 제목은 나머지가 열 이름과 중복되니 “remote correspondents”로 줄이면 됨
      파란색 강조도 이제 제목과 중복되니 전부 빼고, “personal characteristics”와 “location” 구분도 조직화에 의미 있게 도움 되지 않으니 제거하는 편이 좋음
  • 역사 이야기가 흥미로운 좋은 글임
    더 최근 역사로는 CALS 테이블 제작이 있음: https://en.wikipedia.org/wiki/CALS_Table_Model
    Datalogics https://en.wikipedia.org/wiki/Datalogics는 CALS 테이블 구상에 깊이 관여했음
    Datalogics 직원들은 SGML을 만드는 ISO 위원회에 참여했고, 문서화에 관여한 미 국방부 직원과 계약업체를 포함해 많은 사람에게 SGML을 교육했음
    SGML 기반 문서 편집기를 만든 팀에 참여했는데, 그 기능 중 하나가 해당 요소의 SGML 문맥에 따라 요소 서식을 지정하는 것이었음
    이는 XSLT와 그 계열이 나오기 전이었음
    Datalogics 출신들은 Microsoft가 XML을 이해하도록 도왔음. “아니요, XML 요소 태그의 대소문자를 마음대로 바꿀 수 없습니다” 같은 식이었음
    TeX 사용자들도 테이블 서식에 대해 꽤 정교한 생각을 갖고 있음
    특이한 곁가지로, 당시 어느 전투기 문서를 전부 출력하면 항공기 자체보다 무겁고 축구장 크기의 서류 캐비닛 묶음을 채울 정도였다고 배웠음
    그리고 오늘날 많은 사람이 XML을 좋아하지 않지만, SGML 세계에서 온 입장에서는 XML은 큰 축복임
    • Visicalc에 대해 “격자 셀은 발표용 테두리 스타일을 줄 수 없었고, 값은 서식 지정할 수 없었으며, 테이블은 출력조차 할 수 없었다”고 되어 있는데 전부 맞지는 않는 듯함
      첫 버전에도 제한적이지만 서식 지원은 있었던 것으로 기억함
      http://www.bricklin.com/history/refcard3.htm에 따르면 /F 명령으로 정렬을 지정하고 숫자 형식을 예컨대 달러와 센트로 설정할 수 있었음
      이 문서는 1.35 버전 기준이지만, 첫 출시 버전도 최소한 달러와 센트 표시 정도는 지원했던 것 같음
  • 테이블의 달러 금액 같은 숫자 데이터에서 늘 거슬렸던 점은, 수량 비교가 시각적으로는 선형이 아니라 로그처럼 보인다는 것임
    예를 들어 비용이 $1500, $130, $110, $210이면 마지막 세 행의 텍스트는 첫 행 텍스트의 4/5 크기처럼 보임
    하지만 셋을 합쳐도 맨 위 금액의 1/3에 불과함
    사람들은 숫자의 자릿수를 시각적으로 보는데, 이는 대략 log10과 비슷함
    이런 문제가 너무 자주 있어서, 금융 관련 스프레드시트에는 매번 셀 안 막대그래프를 넣기 시작했음
    그렇지 않으면 회의가 절대금액 기준으로 가장 큰 비용에 비하면 완전히 사소한 항목을 두고 논쟁하느라 산으로 감
    실제로 월 라이선스 비용만 $15K인 데이터베이스 엔진을 돌리는 VM에서, 클라우드 서버 로그 수집 월 $15 비용을 두고 여러 회의를 쓴 적이 있음
  • Great Tables 공동 유지보수자 중 한 명임
    Rich Iannone과 함께 관리하고 있음
    패키지 철학을 설명해달라고 했을 때 테이블 표시의 5,000년 역사를 들려줄 소프트웨어 개발자는 Rich밖에 모름
  • 멋짐. 공유 고마움
    점점 나빠지는 데이터 테이블 표현을 이렇게 오래 방치해온 게 신기함
    글에서 지적한 20세기 중반 모던 테이블들은 정말 빛나는 예시로 보임
    Python으로 데이터 분석을 다시 해보고 싶어졌고, 만들고 싶은 API 개선과 확장도 몇 가지 떠오름
  • 이 패키지를 좋아해서 R에서 몇 년째 쓰고 있음
    HTML 테이블을 만들기에는 훌륭하지만, PDF와 DOCX 출력은 조금 덜 다듬어진 편임
    최근 Python 버전을 R 버전 수준으로 끌어올리는 쪽으로 방향이 옮겨가면서 R 개발 속도가 느려진 것 같아 걱정되긴 함
    그래도 어떤 언어를 쓰든 확인해볼 만함
  • 훌륭함. 90년대에 동료와 함께 대부분이 테이블로 된 책인 EBRI Datebook on Employee Benefits를 썼음
    SAS 외에 주 도구는 Table Producing Language, 줄여서 TPL이라는 오래된 언어였음
    1970년대까지 거슬러 올라가지만, 문법만 파악하면 TPL은 믿기 어려울 만큼 유연하고 표현력이 좋고 효율적이었음
    Great Tables 설계자들은 TPL을 살펴보면 좋겠음
    Great Tables가 목표로 하는 모든 것을 다루고, 몇 가지 더 많은 재주도 있을 수 있음
    https://www.ojp.gov/pdffiles1/Digitization/68013NCJRS.pdf
    어쨌든 Great Tables를 만들어줘서 고마움
    Python에서 테이블 생성 품질을 훨씬 좋게 만드는 데 큰 도움이 됨
  • 이 사람은 상을 받아야 함. 1) 훌륭한 작업, 2) 세부사항에 대한 집중, 3) 깊이 있는 조사, 4) “그래서 이게 정확히 뭔데?”, “어떻게 시작하지?”, “예시 좀 줄 수 있나?” 같은 흔한 질문을 피하게 해주는 뛰어난 발표 방식까지 갖췄음
    Show HN에 올리는 사람들은 보고 배워야 함
  • 이 주제에 관한 책도 있음: https://en.wikipedia.org/wiki/The_History_of_Mathematical_Ta...
    흥미로운 곁가지로, 스프레드시트로 학습한 AI 모델은 문맥을 이해하려면 열 이름, 헤더 같은 “좋은 테이블”이 필요함
    Fortap이 그런 예시임: https://arxiv.org/abs/2109.07323
답변달기