모두의 프린터 개발이야기 #4

모두의 프린터 개발이야기 #4 | Ecency

이번에는 모두의 프린터 UI 에 관한 이야기를 해보도록 하겠습니다.
초기 모두의 프린터 UI는 콘솔창에서 텍스트로만 구성된 형태였습니다. 마치 DOS 시절에 어떤 무언가들이 대부분 그랬듯 그렇고 그런 인터페이스 였지요.

애초에 개인적인 사용에서 출발한 데다가 Go언어는 멀티플랫폼을 지원하는 언어이다 보니 특정 OS의 GUI에 종속된 형태가 아니라는 점도 있구요.

물론 Gtk 나 윈도우API를 끌어다 API/MFC로 개발한 것과 다름 없는 형태의 UI를 구성하는 것도 불가능하진 않지만.
그럴 것 같았으면 애초에 MFC로 개발을 시작 했을 것이고 그러지 않은 이유는

수십년간 다룬 API/MFC로 UI구성을 하는 것을 개인적으로 정말 싫어함
내부적으로 여러 서버,클라이언트 기능이 얽혀 있는 상황에서 UI를 위해 전체 기반을 교체하기 싫음

대충 2가지 정도 겠군요.

처음에는 애초에 모두의프린터가 서버기능을 포함하고 있으니 관리자용 프로그램을 따로 MFC로 만들어 배포를 할까도 생각 했습니다. 그러면 모두의프린터 구조는 크게 바뀌지 않아도 될것이라 생각 했구요. 하지만 위의 2가지 이유로 정말 그것만은 하기 싫었지요.

그리하여 생각한 것이 보통 가정용 공유기나 NAS등의 관리페이지를 생각한 것이고 대부분의 PC에는 웹브라우져가 있고 최근의 웹 브라우져들은 어느정도 웹 표준을 지키고 있다는점?

그리고 마법의 지팡이 jquery 와 수 많은 웹프레임워크, css 템플릿등이 공개되어진 축복받은 시기라는것 ^^

그리하여 모두의프린터에 관리자페이지용 웹서버 기능을 추가하게 되었습니다. 파이썬이나 Node js 등을 비롯 최근의 이런류의 언어들은 웹서버 정도야 코드 몇줄로 뚝딱 끝나지요. 그게 아니었음 전 다시 MFC를 쪼물거리고 있었을지도 모르겠습니다.

그리하여 jquery와 spectre.css 를 이용하여 관리페이지를 만들고 ajax 로 데이터를 주고 받아 관리페이지를 구성을 하게 되었는데 spectre.css 를 선택한 이유는 사실 기존에 Bootstrap 이나 기타 몇몇 가지를 사용해 본적은 있었습니다만 간단한 한 페이지의 관리페이지를 위해 저런 큰 덩치의 놈들을 사용할 이유가 없었고 단지 그냥 조금 이쁘장한 관리페이지를 생각한 지라 css 위주의 spectre.css 가 제격이었습니다. ( 사실 제가 그닥 웹쪽이 전공이 아닌지라 웹은 정말 막 짜는 편이거든요 .. 프레임워크의 구조까지 생각해가며 에너지 낭비하기 싫었습니다. )

어느정도 구성이 끝나고 난 다음에 생긴 고민은 .. 가능하면 단일 실행파일로 구성하고 싶었는데 웹페이지를 위한 폴더가 추가되고 html 코드가 그냥 노출되어 있다는 점이 맘에 안들었습니다. 물론 Go언어에도 리소스 형식으로 실행파일에 기타 데이터들을 합쳐 넣거나 패킹된 데이터를 다루는 등의 패키지가 여럿 존재 하지만 ..

어짜피 html 파일 하나라면 그냥 html 파일을 byte[] 변수로 const 하게 소스로 포함시켜 버리자! 라는 생각으로 특정 파일을 byte 변수로 소스코드로 만들어주는 프로그램을 만들고 build 단계에서 해당 프로그램을 호출하여 build전에 매번 갱신하는 방향으로 처리해 버렸습니다. 해당 웹 주소의 호출시에 이 변수 값을 쏴 버리면 그만이니까요.

근데 이게 최근버전에선 한번의 수정이 들어간것이 html 파일을 그냥 넣었더니 실행파일을 hex 에디터든 텍스트에디터든 불러서 보면 html 코드가 그냥 보여 버리더군요. 이걸 -_- 누군가가 hex 에디터로 내부에 내용을 좀 바꿔서 자기가 만든 프로그램인냥 팔아먹는 사람이 생겼습니다. "모두의프린터"를 바이트 수를 맞춰 다른 이름으로 변경해서 말이죠.

그래서 최근 버전은 몇번의 인코딩 과정을 거친 값을 포함시켜서 이런 짓은 하기 힘들도록 변경하긴 했습니다만 단순 Hex 에디터 사용이 아닌 리버스엔지니어링이 가능한 누군가라면 이것도 사실 의미는 없겠지만 그런 분이 그런짓을 할 필요가 있을까요? ㅎㅎㅎ

그리하여 v0.4 버전 즈음해서 모두의 프린터의 UI 가 조금은 이쁘장해 지기 시작했습니다.