00pen

spring이나 django를 쓰다보면 한 view에서 쿼리를 여러 번 날려야하고, 여러 개의 쿼리 중 어떤 부분이 잘못 되었을 때 모두 롤백을 해야하는 상황이 생긴다. spring에서 @transaction을 써서 처리할 수 있듯이 django에서도 transaction.atomic()과 같은 context를 쓰면 여러 개의 쿼리를 하나 즉, atomic이니까 더이상 나눌 수 없는 transaction으로 만들 수 있다.

django에서 model을 다룰 때 .save(commit=False)을 유용하게 쓰듯이 transaction.atomic()도 잘 사용하면 유용하게 쓸 수 있다.

아래 링크는 공식문서로 자세한 내용을 확인할 수 있다.(django 3.2)

https://docs.djangoproject.com/en/3.2/topics/db/transactions/

가끔 django와 관련된 글들을 보면 django가 mvc 패턴을 따르도록(?) 되어있다고 되어있는데 반은 맞고 반은 틀린 말 같다.

왜냐하면 동작하는 방식은 mvc 패턴이 맞는데 사용하는 단어들은 mvc패턴과 약간 다르기 때문이다. spring을 보면 mvc 패턴을 따르게 만들면 사용하는 클래스들의 이름도 model, view, controller다. 근데 django에는 controller가 없다. view도 그 view가 아닌 것 같다(!) django에서는 urls, views들이 합쳐져서 controller의 역할한다고 봐도 무방할 것 같다. 그리고 mvc pattern에서 view는 사용자가 보는 걸 지칭하는데 django에서는 template이 그 역할을 한다. 이런 것들이 django mvc라고 검색을 하면 mvt(model, view, template)라는 단어가 같이 등장하는 이유라고 볼 수 있을 것 같다.

또 django에서는 단순히 template가 view만을 대체하는 게 아니라 forms를 포함시킬 수도 있다. django rest framework가 아닌 순수한 django를 사용하게 되면 template를 만들 때 forms.py를 이용해서 form을 만듦과 동시에 validation을 수행할 수도 있다.특히 이걸 잘 다루기 위해서 jinja2라는 언어(?)를 알아두면 좋다. spring에서는 thymeleaf라는 모듈이 있듯이. 근데 백엔드 개발을 하다보면 오히려 이런 template 언어를 다뤄야할 때 어려움을 겪는 것 같다...ㅋㅋㅋ

최근에는 python의 django에서 벗어나 다른 언어와 프레임워크를 맛보고자 spring을 공부하기 시작했다. java의 spring framework가 웹 개발에 있어서는 가장 주된 프레임워크라서 참고자료도 많고, 배워두면 좋을 것 같아 spring을 택했다.

어떤 프로젝트에 어떤 프레임워크를 선택할지는 회사 내부 개발자들의 스펙, 프레임워크의 장점과 단점 또는 지향하는 바 등을 보고 고르게 되는 것 같다. 띠라서 spring이 가장 많이 쓰이는 이유도 java 개발자 풀이 제일 크고, 프레임워크가 완성도가 높아서인 것 같다. 프레임워크의 성숙도가 높아서 spring을 배우면서 좋았던 점은 "이런이런 상황이 닥쳤을 땐, 이렇게 하는데 보통 괜찮더라" 이런 가이드라인이 있어서 좋았다. django를 배우면서 약간 아쉬웠던 점은 validation을 model 단에서 할 수도 있고, serializer 단에서도 할 수 있고, 여러가지 방법 들이 있는데 너무 다양해서 어느 것을 선택할지가 많이 고민이 되었다.(요즘에는 거의 하나로 통일시키고 있지만)

아무튼 django로 개발을 하면서 어떤 view들을 만들 때 앞에서는 validation이나 authorization을 해야하고, 마지막에서는 pagination들을 해야하는 경우들이 많이 발생하는데 앞의 authorziation을 python의 decorator을 이용해서 개발을 했었다. 근데 spring을 배우면서 aop(aspect oriented programming)이라는 패러다임(?)을 보게 되었는데 이게 사실 python decorator 안에 wrapper 함수와 매우 비슷하더라. 근데 spring-aop 모듈은 그보다 더 나아가서 after, before, around 등으로 시점을 지정해줄 수도 있고, @annotation, bean과 같은 파라메터로 어떤 곳에서 쓸지도 한 번에 지정할 수도 있어서 놀라웠다.

특히나 intellij에서 spring-aop가 적용된 곳을 한 번에 볼 수 있게 해준다거나, 어떤 method에 지금 spring-aop가 적용되어 있다는 사실들을 보여준다거나 하는게 꽤나 편리하게 작용할 것 같았다. 이런 것들을 볼 때마다 intellij가 참 잘 만들어졌고, 왜 다들 intellij로 개발을 하는지 알 것 같았다.

원래는 CI/CD보다도 AWS lambda와 CloudWatch를 통해 Cron job과 같은 걸 만들어보기 위해 개인 프로젝트를 시작해 보았습니다. 그런데 lambda 안의 코드의 관리를 어떻게 해야하나 고민하다가 요즘엔 container로 배포를 하는 것도 지원한다고 되어 있어서 이왕 하는거 AWS ECR(docker repo), lambda, Github Actions를 이용하여 CI/CD를 경험해 보아야 겠다고 생각하였습니다. 제가 예상(?)하는 CI/CD pipeline은 다음과 같습니다.

1. 코드는 github에서 관리, github actions를 이용해 master에 push할 때마다 CI를 진행

2. 무사히 테스트를 마치면 AWS ECR에 image를 빌드 후 push

3. lambda가 자동적으로 새 이미지를 가지고 코드를 돌리기 (이건 바로 되는지 테스트가 필요)

4월부터 기존에 다니던 회사에서 퇴사하고 나서 무얼 해볼까 고민을 많이 했다. python으로 개발을 배우기 시작하고, 빠르게 배워서 취업을 했었던 나로서는 처음부터 CS(computer science) 지식이 부족한 것 때문에 그것에 대한 갈망이 있어 CS 관련 강의를 들어보고 싶기도 했고, 금융권으로 취직을 하고 싶어 C++을 배워보고 싶었는데 그 발판으로 무얼 할까 고민을 했었다. 그 와중에 실무 프로그래밍 입문 강의를 접하게 되었고, "실무"에 적합한 지식을 가르치고 프로그래밍 기초를 가르친다는데에서 들어보기로 했다. 물론 처음엔 20만원 정도하는 강의라서 조금 비싸다고 생각했다. 강의를 다 들은 지금도 그 생각에 변함은 없지만 강의 내용은 굉장히 마음에 든다.

이 강좌가 마음에 들었던 이유는 사실 python으로 개발을 하면서 왜 이런 기능이 있는지에 대한 의문을 해소해 주었기 때문이다. 예를 들어 "class에서 decorator로 @staticmethod를 써보면서 그냥 instance로 만들고 method를 호출하는 거랑 뭐가 다른가?" 라던지 "한 번만 쓸 로직인데 이걸 가독성을 위해서 함수로 만들어야하나 말아야하나..." 등등 이런 의문을 예시를 들어주면서 해소시켜줘서 굉장히 마음에 들었다. 개인적으로 프로그래밍을 하면서 실수를 줄일 수 있는 방향으로 코드를 짜야 한다는 말이 마음에 와닿았다. 파이썬으로 웹 개발을 하다보면 깊이 생각을 안 하고 코드를 짜게 될 때가 있는데 워낙 무거운 프로그램이 아니다보니 그냥 실행시켜보고 오류나면 다시 고치는 걸 반복할 수 있기 때문이다. 이러다보면 내가 테스트해보지 않은 부분에서 오류/예외가 날 수도 있다는 생각에 불안불안한 마음 한편에 있었는데 이런 걸 방지하기 위해 실수를 줄일 수 있는 방향으로 코드를 짜는 방법을 가르쳐줘서 마음에 들었다.

결론적으로 가격 때문에 조금 망설여지긴 했지만 충분히 좋은 강의라고 생각한다. 그리고 좀 쉬면서 고민을 해보고 다음주에는 COMP1000: 소프트웨어 공학용 수학을 결제하고 들어볼 생각이다.