00pen

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

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

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

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

 최근에 미국을 따라 한국도 금리 인상을 단행하면서 외화유출이 되고, 한국장이 많이 빠지고 있는 것 같다.
 지수 추종 etf에 투자하고 있지는 않지만 개별주식도 어느정도는 시장 영향을 받는게 당연하니까 몇 가지 지표들을 보고 있다. 우리나라는 개인 자산에서 부동산 비율이 높으므로 부동산 지표도 봐야겠지만 일단 8월 기준으로 kospi의 PER, PBR이 10, 1 아래로 떨어졌다. 글을 쓰는 지금 시점(2022년 9월 30일)에는 훨씬 더 떨어져있는데 중요한 건 PBR이 1 아래로 떨어졌다는 점에서 진짜 시장은 미래가 밝지 않다고 느끼는 것 같다.
 그래도 PBR 0.9 아래 부터는 지수를 분할매수해도 괜찮지 않나? 라고 생각되는 지점 같다.

그리고 부동산 관련해서는 LTV(주택 담보인정비율)와 DTI(총 부채상환비율)를 참고해서 어느 수준이 개인들이 대출 금리를 감당할 수 있을지 생각해보았다. 과거 수치로는 평균이 40%대였다고 한다.
 과열지구니 어쩌구해서 비싼 주택은 대출을 잘 안해주긴 했지만 그런 주택만 있는 건 아니니까 최근까지도 40%정도라고 생각한다면 현재 주택 가격이 내려간 상태라서 주택에서 대출이 차지하는 비율이 평균적으로 50%가 넘을거라고 생각한다. 현재 기준으로 평균 DTI도 찾지는 못했는데 DTI 규제가 40~60%정도라는 걸 감안했을 때 빌렸을 때 당시의 DTI가 40%정도라고 생각하기로 했다.(규제가 60%라도 DTI가 50~60%면 빌리기로 마음먹기 쉽지 않지 않았을까?).
 마지막으로 가처분소득에서 생계유지비로 쓰는 비율이 약 35%정도 될 것 같다. 그렇다면 가처분소득은 그닥 늘지 않고, 생계유지비만 늘었을텐데 물가상승률을 감안했을 때 생계유지비로 쓰는 가처분소득이 이제 40%를 넘을 수도 있을 것 같다.

 그럼 계산을 해보자.
 대출이자가 4%~5%대에서 6~7%가 되었다고 생각하면 DTI가 40%에서 1.5배인 60% 정도 되었을 것 같다. 그리고 인당 개인총소득과 가처분소득 수치를 참고하면 소득에서 가처분소득이 차지하는 비중은 25%정도 될 거라고 예상된다. 그럼 이제 남은 건 소득에서 15% 밖에 안 남는데 금리가 조금 더 올라서 DTI가 70~80%가 되고, 가처분소득도 줄게되면 이제 버티려고 해도 버틸 수가 없는 때가 오지 않을까..
 내가 생각하기에는 다음 금리 인상하게 되면 거의 확정이고, 변동금리 상품의 갱신시기가 되면 개인들에게 부담이 지워질텐데 그 때까지 장이 하락할 것 같고, 그 이후에 금리가 낮아지는 건 아니니까 그 상태로 횡보하지 않을까 싶다.

 그래서 결론적으로 다음 금리 인상 때까지는 특별히 생각이 바뀌지 않는 한 현금을 모으고, 10월에 중앙은행이 금리 인상을 한 후에 경기가 힘들다는게 다 반영된 후에 분할 매수를 시작하면 안전할 것 같다.

(참고 링크: http://data.krx.co.kr/contents/MDC/EASY/visualController/MDCEASY200.cmd
 https://www.hani.co.kr/arti/economy/economy_general/1055556.html,
 https://kosis.kr/statHtml/statHtml.do?orgId=101&tblId=DT_2KAA910_OECD,
 https://www.index.go.kr/unify/idx-info.do?idxCd=4221)

1. VOO 전량 매도, tiger200 전량 매도
  원래는 마음 편한게 지수추종으로 맘편히 오랫동안 가져갈 생각을 했었는데
  금리인상을 얼마나 하게 될지, 경기 침체가 얼마나 오래갈지 등등 매크로를 예상할 수 없다는 것 때문인지
  마음이 편치 않아서 투자의 목적인 '맘편히 오랫동안 가져가기'가 안되서 전량 매도.
  오히려 '내가 사업을 이해할 수 있고, 내가 생각하기에 경제적 해자가 있고, 너무 고평가되지 않은' 따라서 내가 믿을 수 있는 기업으로
  몇 개만 골라서 가져가기로 함.

2. 애플 매수
  VOO를 매도 한 걸로 아주 소량의 애플 주식을 삼. S&P500 보다 나스닥의 하락폭이 큰 걸 보아 기술주가 지금 상황에서 취약해보임.
  그래도 개발자인 내가 사업을 이해하고, 돈을 오랫동안 많이 벌 수 있고, 믿을 수 있는 기업을 추려보니
  아마존(aws는 기가 막힌 제품같다.), 애플(M1칩을 생산하기 전에는 엄청난 기업이라고 생각안했는데 M1칩의 성능은 혁신적인 것 같다)
  근데 아마존은 PER이 100을 넘어서 부담스럽고, 애플만 매수하기로 함.
  또한 충성고객들이 많아서(맥북만 쓰지만 나도 애플 제품이 좋아보임) 오랫동안 가지고 있을만 하다고 판단하고 매수

3. 삼성화재, NH투자증권 매수
  우리나라에서는 생각보다 위에 서술한 기준에 맞는 기업들을 찾기 힘들었음.
  근데 보험계리사 준비해보고, 개발자를 하고 있기 때문에 IT, 금융쪽에서 반도체주, 보험/은행/증권(금융)주를 살펴봤음.
  삼성전자/하이닉스를 살까도 생각했지만 애플을 매수하기로 하기도 했고, 애플보다는 매력적이지 않아 보여서 그냥 놔두는 걸로.
  두번째로 금융주에서는 삼성화재, NH투자증권을 선택. 일단 그 분야에서 가장 큰 기업이기도 하고
  (NH투자증권과 미래에셋대우 중 하나가 제일 큰 증권사인듯)
  삼성화재를 고른 이유는 손해보험사 중 가장 큰 삼성화재가 좋은 인재들을 데려가고 있을 거라고 판단.
  그러면 순보험료를 잘 측정하고, 리스크를 잘 관리할테니까 별 일 없으면 캐시카우라고 생각했다.
  인플레이션을 어느정도 방어할 수 있는 사업이고,
  PER/PBR (특히 PBR은 왜 이렇게 낮은지 잘 모르겠다)을 봤을 때 고평가라고 생각되지는 않았다.

  NH투자증권 같은 경우에는 삼성화재와 비슷한 이유로 투자를 했다.
  다른 면으로는 농협과 연관된 곳인데 지방에 계신 분들이 충성고객이 될 수 있어 보였고, 경재적 해자가 있다고 생각했다.
  그리고 내가 NH투자증권의 나무 앱을 쓰고 있는데 (환전 수수료를 무료로 해줘서)
  그거를 빼고도 앱이 사용성도 좋고 잘 만들었다고 생각했다.

결론적으로 맘 편하게 직장을 다니면서 투자를 하고 싶은데 생각했던 것 보다 지수 추종 투자가 마음이 편하지는 않더라.
그래서 오히려 내가 잘 알고, 믿을만 하고, 고평가되지 않을 걸로 골라서 매수했다.

java로 사이드 프로젝트를 진행해보면서 로컬환경과 ec2에 java를 깔면서 openjdk를 제공하는 여러 벤더사꺼 중에 뭘 선택해야하는지 궁금하기도 했고, 차이가 있나 궁금해서 조금 리서치를 해보았다. 그 와중에 https://whichjdk.com/ 라는 사이트를 발견하게 되었고, 간단하게 설명되어 있어 좋았다.

위 사이트에 따르면 tl;dr(Too long, didn't read)라는 요약으로 이클립사 foundation에서 제공하는 Termurin을 쓰는 것이 권장된다고 써있다. 왜냐하면 high-quality, vendor-neutral, TCK-tested under permissive license 이기 때문이라고 설명되어 있다. 찾아보면 생각보다 많은 벤더사들이 제공하고 있는데 자신에게 맞는 것을 고르거나 위에서 말한 termurin을 쓰는 것이 맞는 것 같다. (저자는 aws ec2에 서버를 올리는게 보편적이고, 혹시 미래에 'amazon linux2 같은 곳에 default로 그냥 openjdk가 아닌 corretto가 깔려있을 수도 있지 않나?' 라는 생각에 corretto 11을 쓰고 있다.) 참고로 github actions에서 java를 setup 때 제공되는 openjdk는 아래와 같고, 모든 openjdk를 제공하지는 않는 모습이다.

라인사의 기술블로그에 openjdk를 적용하는데 있어서 redhat이 배포하는 openjdk를 선택한 이유와 여러가지 좋은 내용을 써놓은 글이 있어서 참고하면 좋을 것 같다. 

예전에 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/