Weekly Review 001

🧶 Experiences

현재 재직중인 회사의 프로젝트 PoC의 전체적인 개발을 진행했습니다. React.js 기반의 Frontend는 익숙했지만 MySQL DB 사용부터 Flask를 사용하는 API Server 구현은 주변 분들의 도움을 많이 받고도 중간 과정에서 잡음이 참 많았습니다. 물론 지금은 정말, 제가 최대한 꼼꼼하게 확인한 범위 내에서는, 잘 동작하고 있으니 다행입니다.

Flask using SQLAlchemy

저번 주에는 Python과 PyMySQL을 사용해 DB에 정보를 직접 보냈다면, 이번 주에는 SQL을 생성하는 ORM 중 하나인 SQLAlchemy를 사용해 DB에서 정보를 가져왔습니다. DB의 설계를 입력하면 Query를 직접 작성하지 않아도 된다는 점이 좋았지만, 정상적으로 작동하게 하기 위해선 Query를 포함해 ORM 라이브러리에 대한 이해가 선행이 필수라는 것을 배웠습니다. 만약 그런 것들이 없다면, 저처럼 요청부터 응답까지 5초 가량 걸리도록 코드를 작성하는 실수를 범해놓고 감히 ORM을 의심할 테니까요.

그리고 비록 단 하나였지만 API를 설계하고 Postman에 기록하는 과정도 경험했습니다. 그 과정에서 Postman과 같은 프로그램으로 API의 동작을 테스트하는 것이, 브라우저에 직접 요청을 보내는 것보다 몇 배는 더 편하다는 것을 깨달았습니다.

React.js with Grid.js

Grid.js라는 라이브러리를 이용해 API로 받은 데이터를 표로 보여주는 React.js 웹 어플리케이션을 만들었습니다. 빠른 개발이 필요했으므로 Create React App을 이용해 초기화를 진행했고, API를 사용해 데이터를 가져오는 로직을 작성했습니다. 더불어서 스타일링을 위해 오랜만에 SCSS를 사용하기도 했습니다.

사실, 이전에 진행했던 다른 프로젝트에서 배웠던 것들을 적용할 수 있었던 좋은 기회였기도 했습니다. 특히 API 요청을 너무 빈번하게 보내지 않도록 Lodash의 Debounce를 React.js에서 사용하는 방법에 대해 고민했습니다.

Deploying with NGINX and Gunicorn

이미 준비된 VM 서버에 제가 제작한 결과물들을 배포하는 과정도 경험했습니다. 이를 위해 Flask 프로그램이 API Server 프로젝트를 인식할 수 있도록 구조를 변경했고, NGINX 관련 설정도 짧게나마 작성했습니다. Front 프로젝트의 Build도 진행했습니다. 배포 과정이 우아하지 못했던 것은 아쉽지만, 이는 앞으로 개선해나갈 수 있는 부분이라 생각합니다.

✏️ Lessons

Directory structure of Flask project

• Flask를 사용하는 프로젝트라면 flask run 명령어로 간편하게 실행할 수 있다. 이 경우 코드 내의 Flask 객체를 인수로 넘겨주거나 Flask가 알아서 탐색할 수 있도록 프로젝트 구조를 변경해야 한다. 이 때 Module을 올바르게 import하고 있는 지 살펴보아야 한다.

• 나의 경우, 그냥 python 으로 실행할 때는 오류 없이 잘 동작했었던 코드를 Flask와 Gunicorn이 인식할 수 있도록 하는 과정에서 모든 import 문을 절대경로로 변경했다. 사견이지만, 절대경로를 사용하는 것이 개발자에게도 프로그램에게도 혼란스러움이 없는 것 같다. Python에도 경로 Alias 같은 것이 있으면 좋겠다는 생각이 드는 경험이었다.

Gunicorn

• Server를 실행하는 프로그램이다. 가볍기 때문에 상용 환경에서 실사용하기에는 무리가 있다고들 하지만, 개발 환경에서는 적절하다고 한다. 명령어를 통해 daemon 프로세스로 실행하는 것이 가능하고, worker의 개수 또한 설정할 수 있다. 즉, Background로 실행할 수 있다는 말이다.

NGINX

• Web Server를 실행하는 프로그램이다. 단순히 특정 Port를 listen해서 응답하는 것을 넘어, 특정 url을 받을 시 다른 Port로 Forward하는 것도 가능하다. 서버로 사용할 컴퓨터에 NGINX를 설치한 후 /var/etc/nginx/* 에서 관리할 수 있다.

Grid.js

• 웹에서 데이터를 받아와 표로 표현하기 위해 사용할 수 있는 라이브러리 중 하나다. Pagination을 알아서 처리해준다는 건 분명히 좋지만, 단순 포함 검색이 아닌 상세 조건 검색 기능을 제공하지 않았기 때문에 이는 직접 구현이 필요했다.

Debounce

• 상술한 상세 조건 검색 기능을 구현하기 위해 Grid.js 객체에 전달하는 URL의 Parameter를 변경하는 방식이었는데, 이때 React.js의 state를 사용했기 때문에 값이 변경되면 Grid.js의 표까지 다시 Render하며 API를 호출해버린다. 이렇듯 Input의 값이 하나씩 변할 때마다 빈번하게 호출하는 것을 막기 위해선 Lodash 라이브러리의 Debounce라는 기능이 필요했다.

• 단, React.js와 같이 사용할 경우 useEffect의 Callback의 반환값으로 cancel 메소드를 호출해줘야 한다. 컴포넌트가 unmount될 경우 debounced된 함수가 남아있는 케이스를 대응하는 것이다.

Query Tunning

• API 호출이 너무 오래 걸린다면 Query에 문제가 있을 가능성이 있다. EXPLAIN 으로 Query를 어떻게 DB가 연산할 것인지를 확인하는 것이 가능하다.

• 데이터의 추가와 삭제 및 수정보다 탐색이 상대적으로 빈번하다면 Index를 설정하는 것도 속도를 올릴 수 있는 방법 중 하나다. Index에 설정할 Column의 기준 중 하나는 값의 고유성이며, 이는 여러 Column을 엮어 Index를 생성할 때 이들의 순서를 정할 때에도 영향을 미친다.

Environment Variable

• 개발 및 사용 환경의 프로그램은 서로 달라야 하므로, 노출되면 위험한 정보들은 OS의 환경 변수로 설정하는 편이 안전하다. Build 및 실행할 때 어떤 환경을 사용할 것인지를 인수로 넘겨주면 해당 값만 변경되며 실행할 수 있게끔 프로그램을 구성하여야 한다.

Cache when build in Create React App

• React.js에서 build를 할 경우 정적 파일의 파일 이름에 날짜가 추가되므로, 브라우저와 Proxy가 이것을 보고 새로 캐시하기 때문에 사용자에게 캐시 관련 문제가 발생할 확률이 적다.

Plan

• 본질을 놓치지 않아야 한다. 그러기 위해선 계획을 세우고 행동해야 한다. 그래야 일을 모두 처리한 이후 계획에 대한 피드백도 가능하다.

Communication

• 약속한 데드라인을 준수하지 못할 것 같다면 차라리 도움을 요청하며 일찍 이야기를 하는 것이 낫다.