2019년 회고

블로그를 시작하면서 올해 했던 일들을 정리하고. 이제껏 제 노션에 정리했던 자잘한 것들을 모두 블로그에 옮기는 작업부터 하려고 합니다.

올해 진행했던 굵직한 일들을 나열해보자면,

Projects

1. 영상 내 텍스트 검출기
   • opencv와 InceptionV3를 이용한 text detection
2. 실시간 질문답변 서비스 honeypot
   • React Native로 iOS 앱 만들기
   • Django-rest-framework로 API 서버 만들기
3. 유튜브 채널 데이터 creatorhunt
   • Django Celery로 비동기 태스크 큐 애플리케이션 만들기
4. 결핵환자 관리 챗봇 - cole-rochman
   • 카카오 i 오픈빌더로 카카오톡 챗봇 만들기
   • Django-rest-framework로 좀 더 규모있는 API 서버 만들기
5. 백엔드 스터디 @ 창업 동아리 CEOS

많이 한 것도 같고 별로 한 게 없는 것도 같습니다. 관련해서는 상세히 정리할 것이고, 아래서는 간략히 회고해보도록 하겠습니다.

Django와 친해졌습니다

전체적으로 Django에 많이 친숙해진 시간이었습니다. 대신 Django를 SSR하는 프론트엔드로 이용하기 보다는 API 서버로서 많이 활용했던 시간이었습니다. 아무래도 react가 대세를 차지하다 보니 프론트엔드 서버로는 Node.js를 많이 선호하는 것 같습니다.

감히 Django를 평가하자면, 빠르게 웹 어플리케이션을 빌드하기에 좋은 프레임워크라는 생각이 듭니다.

• db를 간편하게 연결할 수 있고, ORM이 내장되어 있음
• admin이 내장되어 있고, 다양한 기능을 제공하면서도 깔끔하게 디자인 되어 있음
• Django Rest Framework를 이용하면 손쉽게 RestAPI를 구축할 수 있음
• 파이썬의 장점이 그렇듯, 역시나 라이브러리가 많음

등이 매력적인 것 같습니다.

특히나 프로젝트가 개발자 본인만 쓰는 것이 아니라면 비개발자를 위한 인터페이스를 제공해주는 것이 필수적이라 admin 기능이 킬링피쳐로서 자리매김하는 것 같습니다.

어드민 기능을 구축하는데 프로젝트를 구축하는 시간 만큼이나 시간을 소모한다면 그것만큼 지치는 일도 없겠죠? 😡

Node 쪽에도 편리하고 아름댜운 admin 라이브러리가 많은 것으로 알고 있지만 내장되어 있는 점에서 메리트가 있습니다.

특히 아래 코드만으로 어드민을 바로 띄울 수 있다는 점이 내장 라이브러리의 장점이 아닌가 싶습니다. 모델 class를 바로 이용하는 것이니까요.

@admin.register(User)
class UserAdmin(admin.ModelAdmin):
    pass

DRF와 Rest API

아직도 Rest API를 명쾌하게 설명하기는 어렵습니다.

URL 패턴과 http 메소드, http status code 이 세 가지를 보면 대강 Restful 한지 아닌지 감은 오지만 누군가에게 설명하기는 참 어렵습니다. (나중에 블로깅을 해보도록 할까 봐요)

그래도 Django-rest-framework(이하 drf)를 통해 Rest API를 빠르고, 안정적이게 구축하는 것이 가능해졌습니다. drf의 generics를 이용하다보면 그들이 정의한 CRUD 패턴에 맞춰서 api 설계를 하기 때문에 안정적인 것 같습니다.

하지만 serializer와 각 generics API를 명확히 이해하지 않고 짠 코드는 다소 drf의 의도와 맞지 않게 되었습니다.

‘일단 구현하고 나서 이해하자’는 제 버릇이 안 좋게 작용한 사례였습니다.

웹 서버와 production 환경

여름에 인턴을 했던 경험을 통해 개발 환경을 나누는 방법과 그 이유를 알게 되었습니다.

보통의 어플리케이션 환경에서 development와 production 환경이 나누어져 있음은 알았지만 어떻게 나누어져 있는지를 몰랐습니다. 파일이나 환경변수를 통해서 분리하고 있다는 걸 알게 되었고, 협업을 해야 하는 환경에서는 어떻게 관리하면 좋은지도 알게 되었습니다.

그리고 django 그 자체는 웹 서버가 아님도 깨달았습니다.

django가 기본으로 채택하고 있는 wsgi와 nginx를 이용해서 웹 서버를 띄우는 경험을 몇 번 해보고 나니 django와 웹 서버와의 관계를 어느 정도 이해한 것 같습니다. 조만간 nginx와 wsgi, 그리고 spring의 tomcat 등 다른 프레임워크의 웹 서버 환경을 비교하는 포스팅을 해볼까 합니다.

AWS와도 많이 친해졌습니다. EC2 인스턴스를 10번 정도 띄우는 경험을 통해, nginx를 세팅하는 과정이 손에 익었지만, 이젠 docker가 필요한 것 같습니다. 환경 설정하기가 너무 귀찮더군요.

production 환경에 대해 더 얘기하자면, production 환경에서의 디버깅이 너무 복잡하다는 깨달음이 있었습니다. 물론 개발 환경에서 충분한 테스트를 통해 버그를 잡고 가야겠지만, 외부 API를 이용하거나 예상치 못한 유저 데이터 때문에 어쩔 수 없이 디버깅을 해야 했는데, 로그가 시원찮게 남아 있으니 대응하기가 어려웠습니다.

인턴을 했던 회사에서 papertrail과 sentry를 사용하는 걸 기억해내고 부랴부랴 적용해보긴 했지만, 그래도 production의 디버깅은 상당히 시간이 많이 들어가는 작업이었습니다.

다양한 케이스의 유저 데이터 등을 고려한 섬세한 Testing이 뒷받침되었더라면 어땠을까 하는 생각을 해봅니다. 그리고 아직도 비동기 태스크 큐 작업을 테스트하는 좋은 방법을 찾지 못했습니다. 😭

TDD를 신봉하자

개발환경을 나누는 가장 큰 이유 중 하나인 것 같습니다. 코드가 점점 복잡해지고 프로젝트의 규모가 커질 수록 테스트 코드의 위력을 실감할 수 있었습니다.

cole-rochman 프로젝트를 진행하면서 유닛 테스트 케이스를 100개 정도 짜보고 나니, 대부분의 버그를 방지할 수 있었습니다.

그리고 그 정도를 짜보고 나니 이제 코드를 짜기전에 테스트 코드를 먼저 짜는 습관이 붙게된 것 같습니다. 초보 개발자에게 참 어려운 부분이었는데, 습관이 약이더군요.

하지만 아직도 테스트 코드를 디버깅하느라 씨름하는 소모적인 상황을 어떻게 하면 해결할 수 있을까에 대한 답은 명쾌하게 있지 않습니다.

스터디 == 블로깅

남을 가르치는 일을 해보면 자신이 얼마나 부족한지 알게 되는 것 같습니다.

망신당하지 않으려고 스터디 전에 공부했던 경험이 개인적으로 많이 남았습니다. 구현만을 위해 공부한다기 보다는 ‘다른 대안은 없을지’, ‘이게 필요한 근거는 무엇인지’를 고심하며 공부했기 때문에 좀 더 폭이 넓고도 깊게 깨닫게 되었습니다.

---

기본기를 많이 쌓았던 한 해였습니다. 이외에도 학교에서 자료구조를 배웠던 것이 양분이 되었습니다 코딩 테스트는 왜 해야 하는지 모르겠지만

위 프로젝트에 대해서 더 자세한 내용은 다른 글에서 다루겠습니다.