00pen

 직장 내 디자이너 분과 밥을 먹다가 이런저런 얘기를 나누면서 그 분이 '이런 걸 만들어보고 싶다.' 라는데서 시작했다. 회사에서 개발하다보면 개발 스펙이나 방향에 아쉬움이 남을 때가 있었는데 그런 아쉬움을 해소할 수 있으면서 재미도 있을 것 같아 그 얘기를 가슴에 담아두었다. 나는 백엔드 개발을 하다보니 프론트엔드 개발을 해줄 사람이 필요했고, 마침 잘한다고 생각하는 프론트 개발자분에게 말씀을 드렸더니 좋다고 하셔서 진행하게 되었다.

 나와 프론트엔드 개발자 분은 진짜 사이드 프로젝트처럼 지식을 쌓으려고 시작했다면 디자이너 분은 사업적인 영역까지 생각하고 있었다. 그래서 은근히 진지모드로 진행했고, 오히려 그게 책임감을 갖게해서 진행하는데 도움이 되었던 것 같다. 사실 이제 경력이 막 2년된 내가 잘 할 수 있을지 걱정이 되긴 했지만 분명히 내가 도움이 될 수 있는 부분이 있었다.

특히 이 프로젝트의 성공을 떠나서 나중을 위해서 디자이너분과 프론트엔드 개발자 분에게 다른 방면으로도 도움을 줄 수 있을 거라고 생각했다. 협업을 하면서 백엔드 개발이 어떤 거고, 백엔드 개발자가 어떤 생각을 하는지 알려드릴 수 있는 기회라고 생각했다. 두 분은 실력적으로나 다른 면으로나 신뢰할 수 있는 사람이라고 생각했고, 이번 프로젝트가 아니더라도 다른 멋진 프로젝트를 할 수 있는 분들이라고 생각했다. 그래서 가비아에서 aws에 도메인을 어떻게 연결하는지, 서버를 어떻게 구성하려는지 디자이너 분께 설명드렸다. 그리고 프론트엔드 개발자 분은 백엔드의 어느정도 지식이 있고, 프론트 개발자지만 백엔드 관련한 지식이 충분하다고 생각했기 때문에 로컬에서 spring application을 올릴 수 있도록 설치해주면서 가끔 spring security를 만지면서 이런 걸 넣으면 이렇게 변하더라 라는걸 말씀드렸다. 회사에서 vue.js를 이용해 백오피스를 만들어보면서 얕은 지식이지만 프론트 관련 지식을 쌓은게 프론트엔드 분들과 협업할 때 많이 도움이 되었던 것처럼 이런 게 추후에 내가 아니더라도 다른 분들과 협업할 때 도움이 될 것이라고 생각했기 때문이다.

며칠 전에 다행히 public하게 모든 걸 띄워놓는 것까지 완성할 수 있었다.
서비스는 이제 시작이지만, 처음부터 끝까지 서버를 만들면서 front 배포할 때는 어떤 것들을 고려하면 좋을지도 많이 고민할 수 있었고, spring에서 유용하게 쓰이는 패턴들을 익히고, 사내에서도 조금씩 적용하는 등 많은 것을 배울 수 있어서 좋은 경험이었다. aws 비용을 줄이기 위해 처음에 ec2 한 대로 front, back 서버를 같이 띄우고, 배포할 때도 green-blue 전략을 채택하지 않고 기존 container를 stop & remove하고, 새로 올리는 방식을 채택하기도 했다. 그리고 처음 live에 홈페이지를 띄울 때 nginx 설정 관련해서 우여곡절도 있어서 이와 관련해서는 나중에 시간나면 다른 포스팅으로 기록해 놓으려고 한다.

서버를 구성할 때 고를 수 있는 언어는 다양한데 각자 장단점이 있는 것 같다. java의 spring framework를 잘 쓰시는 분들이 워낙 많아서 특이사항이 없으면 spring을 고르는게 좋은 것 같지만 그래도 다른 언어의 프레임워크를 쓰면 좋을 만한 상황이 있는 것 같다. 그 중에 파이썬으로 구성하면 두 가지 상황에서 강점을 발휘한다.

1. 머신러닝, 데이터 사이언티스트와 같이 협업하기 좋다.
  머신러닝 개발자나 데이터 사이언티스트라면 파이썬에 익숙할 것이다. 그러면 머신러닝 개발자가 모델을 서빙하는 서버를 구축해야한다던가, 데이터 사이언티스트가 데이터 파이프라인을 만드는데 있어서 서버도 같이 본다던가, 그런 유도리있는(?) 개발이 가능하다. 협업이라고 하기엔 조금 이상한 것 같은데 아무튼 유연한 상황들이 있어서 좋은 것 같다. 그래서 머신러닝에만 집중하는 회사들은 파이썬으로 서버를 만드는 경우가 많은 것 같다.

2. 스크립트 언어답게 일회성으로 뭔가 만들어야 할 때 좋다.
  가끔은 일회성으로 해야 할 것들을 코드로 짜는 경우도 있는데 이럴 때 참 편한 것 같다. 컴파일도 프로젝트 생성도 필요없이 스크립트 짜서 뭔가 하게 하는 것도 좋은데 django 같은 경우에는 python manage.py shell < main.py 과 같이 django 내부에 정의되어 있는 모델, 함수들을 바로 쓸 수 있어서 편하더라. 컴파일 언어 같은 경우에는 batch나 내부에 따로 일회성 api를 짜야할 것 같은데 더 좋은 방법이 있는지는 잘 모르겠다.

그리고 뭐 바로바로 실행하면서 함수를 테스트할 수 있는 것도 좋은 점이긴 한데 그건 스크립트 언어들의 장점이니까 '파이썬'으로 서버를 구성했을 때의 장점은 아니다. 아무튼 쓰면 쓸 수록 귀여운 언어인 것 같다. 뭔가 개구쟁이 같은 느낌이다.

예전에 s3에 이미지를 올려놓고, 퍼블릭에서 엑세스 가능하도록 개발을 하는 경우가 많았는데 그럴 때마다 모든 퍼블릭 엑세스 차단을 풀고, ACL(엑세스 제어 목록)에 모든 유저를 열어서 개발한 적이 있었는데 생각해보면 보안상 문제가 있을 것 같으므로 이번에 사이드 프로젝트를 하면서 어떻게 하면 퍼블릭 유저가 할 수 있는 걸 최소화할 수 있을까 고민해 봤다.

일단 ACL에서는 모든 유저에게 어떤 권한도 주지 않았다. 버킷에 유저가 접근 가능해야하는 파일과 접근 불가능해야하는 파일이 같이 있을 수도 있기 때문에 그렇게 하였고, 오직 버킷 소유자만 객체, 객체 ACL에 읽기,쓰기가 가능하도록 해놓았다. 그리고 퍼블릭 액세스를 가능하게 해야하는 파일들은 파일을 업로드 하는 어플리케이션 서버에서 지정하도록 해놓았다. (Spring 서버에서 putObject할 때 PublicRead로 객체 읽기를 열어두도록 지정해줄 수 있다.)

새 ACL, 임의의 ACL을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단은 풀어놔야 publicRead로 객체를 만들 수 있었다. 액세스 지점 정책은 따로 endpoint를 두어서 S3에 대한 접근을 관리할 수 있는 기능 같은데 사용하고 있지는 않기 때문에 그냥 차단해 놓았다.

영어를 번역해 놓아서 그런지 ACL(엑세스 제어 목록), 객체, 객체 ACL 등등 말이 되게 어렵게 되어있는 것 같다.

참고글
S3 개념 및 용어 관련 정리
https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-S3-%EB%B2%84%ED%82%B7-%EC%83%9D%EC%84%B1-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%8B%A4%EC%A0%84-%EA%B5%AC%EC%B6%95#ACL_(Access_Control_List)

spring에서 s3에 이미지 업로드
https://www.sunny-son.space/spring/Springboot%EB%A1%9C%20S3%20%ED%8C%8C%EC%9D%BC%20%EC%97%85%EB%A1%9C%EB%93%9C/

이제 막 배우는 단계다 보니 새롭게 느끼는 점이 많아서 기록해 놓고 싶어서 써본다. 

1. 컴파일러 때문에 실수가 많이 준다.
  이건 django -> spring이 아니라 python -> java에 해당하는 점. python을 쓰다보면 오타를 냈다던가, 1 * 5을 생각하고, 코드를 짰는데 테스트하다보면 '1'이 들어와서 '11111'이 반환되는 경우들이 생긴다. 근데 java를 쓰다보면 오타라던지 동적 타입 때문에 생기는 실수들이 매우 많이 준다.

2. spring을 사용해보면 제공되는 무언가가 굉장히 많다...
 이거는 장점이 될 수도, 단점이 될 수도 있는 것 같다. django를 가지고 개발할 때는 환경세팅할 때 고려해야할 것이 많지는 않았던 것 같다. 근데 spring을 가지고 개발할 때는 이 spring만을 위해서 제공되는 무언가들이 굉장히 많은 것 같다. spring이 발전해서 spring-boot가 생겨났다던지, spring-boot-initiatior라는 페이지가 있다던지, test 툴들도 선택지도 많고, java를 간편하게 개발하도록 lombok이 있다던지...
 근데 선택지가 많아서 뭐를 선택해야 하는지 구글링이나 고민도 해야하고, 빌드 툴도 gradle, maven이 있고, 더 나아가서 버전에 따라 문법도 달라지더라. 아무튼 spring, java의 생태계는 엄청 넓은 것 같다...

사족으로 오랫동안 django, python을 사용하다가 spring, java를 사용해보니 장점이 많이 보이는 것 같기도 하다. 근데 항상 새롭게 배우면 장점이 많이 보이고, 오랫동안 사용하면 할수록 단점들이 보이는 것 같다. 이런 걸 많이 경험해보면 어떤 상황에 어떤 걸 선택해야하는지 안목도 생기지 않을까 하는 생각이 든다 :) 

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/