12월 6일에 공개된 API이니 이미 좀 된 얘기지만, 이글루스의 연말 블로그 통계 결산을 보면서
“저런식의 통계를 쉽게 못낼까”
라고 생각하다가, 월 초에 봤던 Google Chart API가 떠올랐다. 그래서 좀 만지작만지작 대다가 이 앞 두 포스팅이 나오게 된 것.
쓰면서 느낀 점, 특히 강점은 우선 별다른 클라이언트 코드가 필요치 않다는 것. 가끔 쓰는 정도면 별도의 툴이나 스크립트 없이 손으로 쓱쓱 작성하고 웹에 링크하 - 고 잊어버리 - 면 된다. 그리고 웹로깅 툴의 통계툴이나 간단한 그래프를 그릴 때에는 복잡한 과정없이 그래프를 그릴 수 있다는 점이 좋다. PHP GD 툴 같은 걸 쓸 때의 삽질이랑 비교하면 거의 GD 라이브러리 같은 것으로 그래프를 그리는 거랑 난이도를 비교하면 정말 하늘과 땅 차이 선을 어떻게 그리고, 틱간 간격 잡고, 이런거 다 신경쓸 필요가 없다는 것은 무척 좋다. 자동화 되는 부분이,
- 그래프 출력 그 자체
- 틱;tick(눈금) 레이블 그리기, 축;axis 레이블 그리기 등의 작업, 다중 레이블링
- 그래프로 나뉜 영역의 색칠, 파이형 그래프에서 각 구간 그려주기
- 영역의 색, 그래프의 선 색 등의 조절
- 벤다이어그램을 그릴 수 있다!
그렇지만 단점이 없는 것은 아니다. 우선 각 축의 축척;scale을 사용자가 조절할 수가 없다. 일상적인 그래프에서는 흔하지 않지만, 약간만 공학적인 그래프로 들어가면 단순히 선형 증가하는 축이 아니라 로그 스케일로 증가한다거나 제곱;square/세제곱;cube 스케일의 축이 필요한 경우가 생긴다. 이런 경우에 대한 대응은 괴롭다. 각 축에 붙는 틱 표시를
시작 - (중간 1) - (중간 2) - … - 끝
같은 형태로 하게되는데, 이 때 중간 틱의 레이블은 시작/끝의 등간격으로 찍히게 된다. 그래서 로그 스케일 등 선형 스케일이 아닌 경우에는 제대로 표시하려면 일일이 지정해줘야 한다. (혹은 틱 레이블 자체를 해당 단위계의 단위 좌표로 하던가)
데이터를 전달하는 방법이 3종류인데, 각각 62 / 1000 / 4096의 해상도를 갖는다. 문제는 데이터를 전달하는 방법을 선택했으면 축의 최대 크기는 무조건 저 값에 비례해서 계산된다. 만약 4096 해상도를 선택하고 10이란 값을 보내면 10/4096 에 해당하는 지점에 찍히기 때문에 그래프를 그리는 사람이 적절히 정규화;normalization 를 수행해줘야 한다. (처음에 이걸 모르고 그래프가 안 그려진다고 생각했다) 그리고 간단하지 않은 데이터 / 많은 데이터의 경우 값 변화도 좀 귀찮은 일이 된다. 62나 4096 해상도의 경우 urlencode를 했을 때 불변인 일부 알파벳문자/숫자/일부 문장부호를 사용해서 만들어낸 인코딩이라 변환함수가 거의 반드시 필요하다.
또한 처음에 무지 고민하면서 디버깅 했던 문제인데 chart legend를 그리는 위치가 고정되어 있다.(그래프 오른쪽 공간으로) 그런데 바 타입 그래프를 좀 넓게 그려지게 해놨더니, 이게 아예 안 그려져서 내가 인자를 잘못 주고있나 계속 확인했다. 단순히 좌우 폭을 넓혔더니 바로 그려지더라 -_-;; 디버깅 기능이나 유효성 확인 기능도 좀 있었으면 좋겠다.
일정 이상 큰 크기의 그래프 (30만 픽셀 이상)의 그래프는 그릴 수 없다. 대충 600 x 500 정도는 그릴 수 있으니 아주 큰 문제는 아니다.
뭐 이러니 저러니 불평을 하긴 했지만 Origin이나 GNU Plot 수준의 기능을 기대하는 것은 아니니 적당한 기능 집합에 상대적으로 _간편하고 단순한 인터페이스_라서 chart까지도 검색에 포함시키겠다는 구글의 야망도 어느 정도 성공하지 않을까 생각한다. 결정적으로 가지고 놀기에도 나름대로 재미있다. 그래서 오늘 하려던 레몬펜 테스트는 안드로메다로