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를 짜야할 것 같은데 더 좋은 방법이 있는지는 잘 모르겠다.

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

 최근에 미국을 따라 한국도 금리 인상을 단행하면서 외화유출이 되고, 한국장이 많이 빠지고 있는 것 같다.
 지수 추종 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를 선택한 이유와 여러가지 좋은 내용을 써놓은 글이 있어서 참고하면 좋을 것 같다.