[스팀kr] jSteem 제작기

지난 해(2017) 마지막 2개월과 올해(2018) 1월 동안 집필하느라 갖은 고생을 한 이후, 이제는 좀 쉬나 했지만, 갑자기 이곳 '스팀잇steemit'을 알게 되어, 누가 일복 타고난 팔자 아니랄까봐, 또 jSteem이라는 프로젝트를 시작해 버렸다.

사실 스팀잇을 사용한 지 채 한 달이 되지 않아서, 어떤 프로젝트를 한다는 것이 부담스럽기도 했지만, 보통 어떤 SI 프로젝트에 들어갈 때, 그 사이트의 콘텐츠를 알고 들어가진 않는다는 생각에 안심이 되었다. 보통의 개발자라면 일하면서 그 내용을 알게 되는 법이고, 그게 어쩌면 그 내용을 정확히 알 수 있는 가장 좋은 방법일 수 있다. 잘 모르면 개발할 수 없기 때문이다.

개발자 두 명과 의기투합하여 벌써 2주 째 개발에 매진하고 있는데, 그 동안 '대체, 왜 직장을 구하지 않느냐!!!'는 마누라와의 끊임없는 투쟁을 비롯하여, 여러가지 장애물들이 생기기는 했지만, 이제껏 한 번도 장애물없이 무언가를 구현해 본 적은 없기 때문에, 모든 것들은 그저 '지나가라, 지나가라'하면서, 나는 그냥 하루종일 컴퓨터 모니터를 보고 있으면 되는 것이다(뭐, 그러다 보면 대체로 좋은 일이 생긴다).

2월말을 최초 오픈으로 잡고 있기는 하지만, 완성품을 낼 예정은 없다. 2월 오픈이라는 것은 '3월부터 이용할 수 있는 기능'을 의미한다. 내가 이제껏 겪고 사용한 모든 프로그램은 '출시 후 개선'이라는 틀에서 발전해 왔고, 대대적인 출시보다는 꾸준한 개선 시스템을 갖춘 자들만이 살아 남을 수 있었다.

그래서 2월 말에 오픈할 jSteem에는 깜짝 놀랄만한 기능이 있기 보다는(누구도 그런 기대는 하지 않겠지만), 스팀잇의 단점을 개선하여 좀 더 쾌적한 사용자 경험을 할 만한 UI/UX를 선보일 예정이다.

스팀잇의 단점이라기 보다는 거의 모든 스팀 사이트(음, 스팀 사이트라기 보다는 거의 모든 사이트)에서 보여지는 단점인, 퍼포먼스 딜레이 현상이 가장 최초의 개선 포인트가 될 것이다. '퍼포먼스 딜레이performance delay'는 사용자가 예측한 결과를 보여주는 과정이 생각보다 길어서 사용자 경험을 해치는 현상을 말하는 데, 이런 현상의 원인은 '하드웨어'적 요인에서 '소프트웨어'적 요소까지 매우 다양하지만, 요새처럼 클라우드나 as a Service(aaS)가 발달한 환경에선 거의 '통신'적인 원인을 생각해 볼 수 있다.

클라이언트의 물리적 환경이나 서버의 물리적 환경이 아무리 뛰어나더라도 양측의 소통이 원할하지 않다면, 좋은 퍼포먼스를 기대하기 힘들다. 특히 as a Service처럼 다중이 집중적으로 서비스를 콜하는 환경에서는 서버의 부담이 증가하고, 또 DDos와 같은 네트워크 공격도 방어해야 하기 때문에, 일부러 서버에서 응답을 지연시키는 경우도 허다하다. 그럼으로써 공격의 가능성을 줄이고, 선의의 요청만을 걸러 낼 수 있는 것이다.

하지만, 어떤 목적이건, 그것이 사용자 경험을 해친다면, 좋은 사이트라 할 수는 없다. 보안과 안정성을 위해 아이디어를 내는 만큼이나 중요한 건 그런 좋은 의도의 프로그래밍이 사용자로부터 외면받지 않도록 주의를 기울이는 것이다. 소비자들은 매우 까다롭다. 그들은 안정성을 원하거나, 빠른 속도를 원하거나 하지는 않는다. 항상 그들은 둘 다 원한다.

그래서 아마도 이 달 말에 오픈할 사이트에서는 그런 딜레이가 거의 눈에 띄지 않거나 있더라도 매우 최소화할 수 있도록 전체적인 플로우를 구성했다. 그런 구성을 위해서 서버단에서 해야 할 일이 좀 있었고, 여하튼 스팀 api의 동작을 최적화하는 데 신경을 많이 썼다. 가령,

이 화면은 어떤 태그에 올라 온 글들의 목록을 보여준다. 그리고, 글의 내용을 보기 위해 제목을 클릭하면,

그림에서 보는 것처럼, 레이어 팝업이 생기면서 내용을 보여준다. 만약, 내용을 보기 위해 별도의 링크로 이동한다면, 통신에서 나오는 딜레이와 더불어, 이전 목록을 보기 위해 다시 링크를 거슬러 가야 하기 때문에, 이중의 딜레이가 발생할 것이다. 하지만, 지금과 같은 방식이라면 글 목록과 내용을 확인하는 데 드는 시간을 최소화 할 수 있다.

물론, 글을 화면에 출력하는 것은 쉬운 작업은 아니다. 보통 글들은 html 문서 아니면, 마크다운 문서로 작성이 되는데, html 문서는 그렇지 않지만, 마크다운 문서는 parse해서 보여 주어야 한다는 부담이 생기고, 마크다운도 하나의 작은 프로그래밍 언어라는 것을 고려해 보면, 스팀잇에서 보는 것과 완전히 같은 출력을 하기 위해서는 시간이 다소 필요하다. 다행히 대부분의 사용자들은 복잡한 마크다운을 쓰기 보다는 주로 이미지를 출력하는 데에 집중하고 있기 때문에 약 80%의 일치율로 비슷한 화면을 출력할 수 있다(현재 기준).

물론, 단지 딜레이만을 해결하기 위해서 서비스를 만드는 것은 아니다. 스팀 내부에서는 지금도 좋은 콘텐츠들을 어떻게 고르고 대우할 것인가에 대한 치열한 논쟁이 벌어지고 있다. 가급적이면 지금 만드는 서비스는 그런 부분에 있어서(즉, 좋은 글의 노출도를 높이기 위해 다양한 관점에서 검색하고, 찾아 볼 수 있도록) 개선점을 찾으려고 노력 중이다.

프로젝트를 수행하는 일은 늘 고되기 짝이 없다. 초보 때나 지금처럼 비교적 원숙한 실력을 가졌을 때나 그 고통은 거의 비슷하다. 모든 사람들은 그 나름의 지옥을 늘 갖고 다니는 것이다.

하지만, 고통은 고통일 뿐이다. 그것이 전진을 방해하진 않는다. 늘 실패하는 데 익숙한 것 만큼이나, 고통에도 익숙하다. 그래서 그런지, 어떤 작업을 하든, 자유로운 편이다.