개요
8개월간의 공백기가 있었다.
독서나 사이드 프로젝트 같은 것들을 하면서 코딩을 놓으려 하진 않았고, 뭔가를 개발하면서 지냈다고 생각했는데 역시 실무와의 격차는 다르다.
회사가 어떤 사업을 하는지, 어떤 제품을 만드는지, 그리고 이 제품이 어떻게 고객에게 전달되는지를 듣다 보면 어느새 뇌의 용량이 다 차버린다.
이런 내용들은 회사 특유의 정보라 개인 블로그에 올릴 수 있는 범위가 제한적이지만, 이틀째 다니면서 경험한 것들 중 일부만 찝어서 기록해보려고 한다.
레거시한 파이썬
생각보다 오래된 파이썬 버전을 사용하고 있어서 약간 당황했다. 이 버전을 가지고도 서비스가 운영되는구나 싶어서 신기할 따름이다. 그래서 그런지 개발 환경을 세팅하는 것부터 거의 처음 겪는 수준이었다. 공개 저장소에서 패키지를 다운로드하는 게 아니라, 인계받은 *.whl 파일을 수동으로 설치해야 했으며 특정 버전의 OS에 종속적이기도 했다. 한 번은 버전을 잘못 설치한 OS 때문에 시간을 날려버리기도 했다.
OS를 잘못 설치한 것에도 약간의 에피소드가 있다. 지급받은 장비는 Mac과 Windows인데, 회사의 스탠다드한 설정은 Windows에 WSL을 설치해서 사용하는 것이라는 설명을 들었다. 그래서 WSL을 설치하고 보니 가이드 문서에 적힌 OS 버전이 이미 지원 종료된 상태였다. 그래서 일단 최신 버전을 받고 안 되면 그때 가서 생각하자는 식으로 접근했는데, 이게 또 하나의 삽질을 만들었다.
Docker는 역시 닉값을 한다.
문제는 Mac에 개발 환경을 세팅하면서부터였다. Mac에 Python 2.7을 설치하고 *.whl로 패키지까지 설치한다고 해도, 결국 "그래서 잘 돌아가나?"라는 의문을 해결해야 했다. 게다가 개발 환경 자체가 특정 OS를 기반으로 돌아가야 했기 때문에 Mac에서 이런 조건을 만족하도록 세팅하는 방법이 무엇일까 고민하게 됐다.
답은 역시 Docker였다. Mac에서는 Python 2.7과 PyCharm으로 코드만 수정하고, Docker를 이용해 개발 환경을 구성하니 예상보다 빠르게 환경을 구축할 수 있었다. 이 과정에서 PyCharm이 Docker Container의 Python 가상환경을 이용할 수 있도록 Remote Interpreter를 사용하는 방법도 조사해서 대책을 세워놨는데, 막상 해보려고 하니 Pro 버전에서만 지원되는 기능이었다. 결국 이 방법은 써먹지 못했다. 그래도 Docker 설정만으로 문제를 해결할 수 있었다.
대환장 Django의 향연
Django 문서를 보면 프로덕션 서버에서 runserver 명령어를 이용하지 말라거나, DEBUG 옵션을 켜지 말라는 내용이 나온다. 그런데 이 Django 프로젝트는 이 안내를 무시한다. 이 두 가지 옵션을 사용해도 별다른 이슈가 없다거나, 메인이 백엔드가 아니라는 선임자의 이야기가 있었는데… 그러려니 하면서도 "알게 모르게 문제가 많이 쌓이는 거 아닌가?"라는 생각이 든다.
예전에 Django를 사용할 때는 static 파일을 서빙하기 위해 Nginx를 붙이곤 했는데, 정작 왜 그렇게 했는지는 까먹고 있었다. 그런데 이번에 개발 환경을 세팅하면서 runserver로 서버를 띄우고 DEBUG 옵션을 켰을 때 로컬에서 정적 파일이 연결되는 걸 보고 "아, 이런 이유가 있었지" 하고 떠올랐다. 그동안 쌓았던 개발 경험은 어디다 팔아먹었나 싶을 뿐이었다.
마치며
써놓고 보니 그렇게 큰일은 아닌 것 같으면서도, 오랜만에 회사를 다닌다는 감각이 재밌어서 그런지 하나하나가 꽤 재미있게 느껴진다.
아니면 뭔가 스스로 이 경험 자체를 생동감 있게 받아들이고 있는 걸지도 모르겠다.
앞으로의 회사 생활을 기대하며 이만 글을 마치겠다.