이전까지는 사이드 프로젝트나 토이 프로젝트를 할 때 혼자 했었다. 근데 이제는 프론트엔드 개발자와 디자이너, 기획자 분들과 함께 하다보니 프로젝트가 온전히 나의 것이 아닌 상황이 되었고, 이 프로젝트를 위한 aws 계정을 파는 것까지는 아니더라도, 회사에서 쓰는 것처럼 내 계정을 root 계정으로 돌리고, 다른 분들께 aws console에 접속할 수 있는 권한과 관리자 권한을 드려야 한다는 생각이 들었다. 나도 이제 시작이지만 처음 이런 상황에 마주하게 되어서 조그마한 프로젝트지만 혼자하는 프로젝트가 아닌 분들께 도움이 되지 않을까 하는 생각에 기록해본다.

1. aws organization을 사용할 상황은 아니다.
 처음에는 막막해서 그냥 회사 dev aws에 내 계정은 어떻게 설정되어 있는지를 보았다. 들어가기 전에는 organziation을 만들어야 하는건가 싶었는데 그건 조직이 커졌을 때 devops 조직과, 그냥 개발팀을 나눈다던지, 결제 관련해서 나누어야 하는 상황일 때 쓰는 것이였다. 그래서 이건 pass.

2. 일단 토이프로젝트라서 아무 것도 만들어져있지 않은 상황이기 때문에 어느정도 개발된 후에 aws를 만들어도 된다.
 백도 프론트도 이제 처음 시작이기 때문에 github로 코드를 공유하면서 local에서 개발한 후, 어느정도 기반이 되었을 때에나 aws에 서버를 만들어도 늦지 않을 것 같다.

3. iam을 통해 관리자 group을 만들고, 자신을 user에 추가하고, 동료분들도 user에 추가한다.
 내 계정엔 admin이라는 user group을 만들고, user에 자신의 계정도 새로 만들어서 개발할 때 iam 계정을 통해 사용하도록 한다.( root 계정은 특별한 경우가 아니면 쓰지 않도록 아마존에서도 권장하는듯) 동료 분의 계정을 추가하기 위해 add user을 통해 user이름을 적고 아무 비밀번호를 적거나 auto generated password로 한 후에 required password reset을 체크한다. 다른 방법으로는 access key를 이건 sdk, api를 통해 aws를 사용하는 user를 위한 설정인듯 하니 pass. 
(auto generated password로 설정하면 계정을 만든 후에 welcome email(?)을 보내도록 하는 페이지가 뜰 때 거기에 auto generated password가 있다.)
 
 iam으로 접속할 때 12자리 계정 id가 아닌 별칭을 쓰고 싶다면 iam dashboard에서 오른쪽 사이드바(?)에 별칭 설정이 있다. 그걸 바꿔주면 된다.

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

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를 사용해보니 장점이 많이 보이는 것 같기도 하다. 근데 항상 새롭게 배우면 장점이 많이 보이고, 오랫동안 사용하면 할수록 단점들이 보이는 것 같다. 이런 걸 많이 경험해보면 어떤 상황에 어떤 걸 선택해야하는지 안목도 생기지 않을까 하는 생각이 든다 :) 

이미지 출처: wikipedia

 일단 굳이 모든 경우에 soft delete를 하는 건 안 좋은 것 같다. 대충 생각해보면 isDeleted라는 컬럼이 true, false로 나뉘는 거니까 경우에 수가 두 배로 늘어나고, 생각해야할 것도 늘어난다. 코드도 늘어난다. 그래서 적재적소에 잘 쓰되 좀 간편하게 사용하기 위해서 repository나 manager같은 데이터를 다루는 객체에서 삭제되지 않은 것만 가져오도록 따로 만들어 놓는 것도 좋은 생각같다. 예시로는 화해 기술블로그에 나와있다.

 위에서 말한 적재적소는 고객 cs가 많거나 log데이터 같은 걸 가지고 있으면 좋을 때인 것 같다. 고객 cs가 많은 업종 같은 경우에는 history가 있을 때 상황을 이해하고 설명하기 좋기 때문이다. log 데이터 같은 걸로 이용하기 위해서 soft delete를 사용해 놓으면 데이터분석에도 좋을 것 같다. hard delete로 지워버리면 나중에 데이터 분석을 하고 싶을 때 그 시점에 데이터는 비워져 버리는 거니까.

 번외로 왜 컬럼명, 변수명을 지을 때 type, state이런 걸로 안 짓는지 프로젝트 진행하면서 잘 알게 되었다. 나중에 다른 field가 추가될 때, 또 다른 타입, 상태 같은 걸 추가하고 싶을 때 아주 찝찝한 상황이 온다. 그런 상황에서는 씁쓸하게 comment를 남겨 놓았지만, 다른 테이블 볼 때 comment가 없으면 '이건 이건가..?'라고 추측하거나 만든 사람한테 물어봐야해서 좀 귀찮은 상황이 오더라...

최근에 회사에서 백오피스를 만들면서 백엔드 개발 + 간단한 프론트 작업을 병행해야 했다.
근데 아주 plain한 html, css, javascript의 기초지식만 알다보니까 event handler이런건 vue에서 어떻게 달아야 하는건지 몰랐다.
프론트엔드 분들 코드를 봐도 모르겠어서 이건 기초강의를 봐야겠다는 생각이 들었다.

그 와중에 유튜브에서 코딩애플 채널을 통해 vue.js 강의 앞 부분만 올린게 있어서 봤는데 흡수력이 좋더라...
말을 너무 재밌게 해서 고급 프론트엔드 개발자가 아닌 초심자가 듣기에는 안성맞춤인 강의 같다.
강의도 엄청 길지 않고 짤막짤막하게 되어있어서 퇴근하고 두세편 보기 딱 좋아서 2주일 정도에 다 봤다.

처음 vue.js를 맛보고 싶다던지
내가 백엔드 개발잔데 개인프로젝트 하면서 프론트도 내가 하고 싶다던지
이런 사람들에게 추천하고 싶은 강의다.

그리고 강의료가 좀 있는데 처음부터 강의를 끊지 말고, 유튜브에 강의 몇 개가 올라가 있으니
그걸 보고 계속 듣고 싶으면 유튜브 설명란에 할인쿠폰도 있으니 그걸 가지가서 결제를 하면 될 것 같다.

https://codingapple.com/course/vue-js/

번외로 최근에 vue가 option api -> composition api로 넘어가는(?),
사실 넘어가지 않을 수도 있지만, 그런 과도기에 있는 것 같아서
강의 후반에도 나오지만 option api와 composition api의 차이점 / 변경점들을 찾아보면서 공부하면 더 좋을 것 같다.
https://velog.io/@bluestragglr/Vue3-%EB%AC%B4%EC%97%87%EC%9D%B4-%EB%B0%94%EB%80%8C%EB%82%98%EC%9A%94

 

원래는 어떤 모델의 instance를 생성할 때 foregin key field가 있으면 .get()으로 객체를 가져와서 넣어주거나 serializer을 통해 넣어줘야했었다. 근데 최근에 일단 validation을 통과하지 못할 객체를 만들고, custom 전처리 함수를 통해 필드들을 전처리 후에 validation과 생성을 하고 싶은 상황이 생겼다. 근데 이 때 프론트에서 주는 데이터를 일단 instance에 넣고, 전처리 함수와 validation을 통해서 valid한 instance가 되게 하려는데 foreign key field가 integer가 아닌 model을 받아야 된다고 예외를 던져줘서 방법을 찾아봤더니

{foreign_key}_id라는 field가 따로 있어서 그 필드에 일단 integer을 넣고, 생성을 하게 하면 django model이 foreign key field에 {foreign_key}_id라는 걸 참조해서 model을 넣어준다. serializer을 통하지 않고, 객체를 따로 불러와서 넣어주지 않으면서 integer로 일단 필드값을 넣어주고 싶을 때 이 방법을 사용하면 괜찮을 것 같다.

'Programming' 카테고리의 다른 글

django를 쓰다가 spring을 쓰면서 느낀 점  (0) 2022.05.14
soft delete를 해보면서 느낀 점  (0) 2022.04.16
django의 transaction  (0) 2022.02.03
spring mvc vs. django mvc(mvt?) 패턴  (0) 2022.02.02
python decorator와 spring AOP  (0) 2022.02.01

+ Recent posts