전편에 이어서 작성한다.
내부 처리와 클라이언트 대응을 위한 API 서버와 일반 대중들을 대상으로 하는 웹 어플리케이션을 개발했다.
당연히 기능 추가나 보완해야 할 부분이 많지만, 깡통 찬 아저씨가 백지에서 두 달 만에 굴러가는 수준의 앱을 만들었다는 이야기를 정리해본다.
개요는 웹사이트를 핸들링하여 데이터를 가져와 구조를 만들고 내부에서 여러가지 라이브러리로 처리한다는 내용이다. 클라이언트는 서버가 주는 가공된 데이터를 시각화 하고 키워드만으로 상호작용 하는 것이 전부인 앱이다. 사용자는 여럿인데 사이트에 접근할 수 있는 세션은 여러개 둘 수 없기 때문에 사용자 접근을 추상화해 하나뿐인 세션을 관리하려고 앱을 개발하게 됐다.
설계라고 할 것도 없지만 생각해보기
제대로 할 줄 아는 언어가 없어 그것도 부족한데 프로젝트 설계도 해야했다. 특히 개발 우선순위에서 인증, 로깅 등의 부가적인 것들은 일단 기존에 구축된 인프라를 충분히 활용하기로 하고 서버와 클라이언트가 하는 일에 대해 명확하게 선을 긋고 시작하기로 했다. 예를 들어 인증의 경우 VPN을 사용하기 때문에 규모가 커지기 전 인증 대부분을 일시적으로 회피할 수 있다. 로깅은 대충 텍스트로 쌓기로 하는 둥 일을 빨리 처리하기로 했다. 물론 실제로 이렇게 하면 안된다.
2월 초. 서버와 클라이언트가 할 일을 명확하게 정해야 했다. 서버에서 추가적인 작업이 필요 없을 정도로 충분히 가공을 해서 클라이언트는 API 호출에 의한 응답만 받아 표시만 해주게끔 설계를 하는것이 목표였다. 클라이언트에는 서버 내부에서 처리될 때 사용하는 어떤 정보도 넘어가지 않도록 설계하려고 했다. 예를 들면 핸들링의 대상인 웹사이트의 URL조차 감추고 이미지의 경우 자체적으로 캐싱하여 API서버에서만 가지고 가게끔 만드는 것이다. 완전한 고립 상태를 만들어 사용자가 추적하더라도 API서버 주소 하나만 탈취 되도록 만들기로 했다. 이렇게 되면 서버와 클라이언트 사이의 상호작용은 완전히 분리하여 고민할 수 있다고 생각한다. 그러나 지금 와서 생각해보면 당연한 일이였다.
최대한 쉽고 간단하게 작동하기
기술 스택은 최대한 쉽고 복잡하지 않게 가려고 했다. DB조차 없애 최대한 내부 서비스 간 의존도를 줄이고 하나의 프로그램으로만 작동하길 원했다. 오래된 스크립터들이 다 그렇듯 처음엔 한번의 트랜잭션으로 작동하는 코드만 생각했으나 이 시기에 병행한 프로그래밍 스터디에서 배운 여러 패러다임을 접목하…려고 노력은 했다. 나름대로 접속하는 사용자를 위한 뒷단의 인스턴스도 유연하게 세션으로 관리하는 서버다.
사용자 경험을 매끄럽게 만들기
웹사이트의 상호작용을 감추는 것만이 전부가 아니라 후속 동반되는 복잡한 사용자 경험을 대부분을 단순화 시키는 것이 목적이였다. 페이지 반응과 더불어 뒷단 어플리케이션들의 상호작용을 통합 시켜야 했다. 기존에는 웹브라우저에서 링크를 작동할때 반응하는 어플리케이션의 응답도 사용자가 처리해줘야 하는 식이였다. API서버가 파이썬으로 이루어진 것은 뒤의 어플리케이션들의 API가 파이썬 모듈로 작성돼있었고 내가 원하는 수준에서 충분히 활용 가능했기 때문이다. 또한 flask와 selenium을 사용하면서 막막하다는 생각은 해본적이 없었다. 3월이 오기전 프로토타입을 넘어선 완전체에 가까운 서버를 새웠다.
이해할 수 없는 nodejs 생태계
그러나 클라이언트 제작은 난관이였다. 리엑트나 앵귤러보다 역사가 짧다는 VueJS지만, 파생된 라이브러리의 관리 또는 그 스택의 선택 때문에 2~3회 프로젝트를 갈아 엎었다. 이것이 무슨말인가. VueJS로 프론트엔드 개발을 한다고 해도 electron 등의 warpper에 순순히 대응하지 않으며 html에 도가 튼 나도 이번에 공개 템플릿을 사용해봤는데 이것 역시 vuejs 하위 프로젝트가 아니면 에셋을 관리하기가 매우 곤란했다. 마음에 드는 라이브러리가 있다고 해도 개발 주기가 끝나거나 죽은 프로젝트가 수두룩 빽빽하며 살아있는 것 중에 고를 수 있는게 그다지 많지 않았다. 그래서 프로젝트 진행 중에 필요한 모듈이 있을때는 특정 node버전에서 작동하는지, electron 안에서 작동하는지, vuejs에서 작동하는지, 해당 bootstrap에서 작동하는지 등 여러번 검증이 필요했다. 그럴려면 npm과 github issue와 stackoverflow를 달고 살아야 한다. 이 과정 때문에 4월까지 밀렸다. 그야말로 잘 모르고 덤볐다는 말이 딱 맞는 것 같다. 지금도 마음으론 nodejs에 대해 거부감이 많이 들고 머리로만 그러려니 한다. 이제 어떻게 하면 코드를 갈아엎을 일이 없을지 알게 되었지만 일로 하라 그러면 안하고 싶다.
비동기와 순서제어로 한번 더!
JS의 특징이자 콜백지옥 같은 난개발의 원인이 되는 대목이다. JS는 비동기 방식의 대표적인 언어다. ajax로 서버에 요청을 하고 나서 서버의 응답을 당연히 기다려 주는줄 알았지만 그런거 없고 다음 코드, 또는 아무 코드나 무작위로 실행될 때 당혹스러웠다. 이것을 방지하기 위해 순서제어라는 개념인 promise를 사용하는데 생각만큼 자유도가 없고 promise 코드 안에서조차 자기들 멋대로니 작동 자체가 부자연스러워지고 결과적으로 사용자 경험 자체가 내가 원하는 수준에서 하향되지 않았나 생각해본다.
첫번재 결론
1차 개발을 끝내고 실제로 배포를 해보니 반응이 괜찮았다. 사용자들이 한 세션에 서로 접속하겠다고 충돌할 일이 없는 환경이 만들어졌다. 인증과 성능개선 등 해야할 작업이 아주 없는 것은 아니지만 결론적으로 목적에 부합했고 완전히 대성공했다.
정리해보면 다른 것 없이 flask와 vuejs만으로 서버-클라이언트 개발이 가능하고 nodejs 고유의 뒷통수 후리는 빡침만 주의한다면 그럭저럭 나같은 늙어빠진 프린이도 가능성이 있다는것이 오늘의 결론이다.
마지막으로 프로젝트 감수에 도움을 준 박종훈님께 감사의 인사를 전한다.