May 10, 2020 - 벌써 5월이라니

그 좋다던 20대가 다 가고 반 년 남았다. 근데 난 가난하고 ㅈ도 모르는 20대보단 돈 있고 짬도 찬 30대가 더 좋은 시절이 아닐까 싶다.💲

사람은 깨달아야 바뀐다.

그러니 오늘의 깨달음을 곱씹을 수 있도록 자주 글로 남겨두는 건 어떨까? 먼저 폰으로도 포스팅하기 쉬운 구조로 개편하면 좋을 것 같다.

슈카월드 구독/좋아요 👍

보면 유튜브 슈카월드만큼 유익한 채널이 없다. 주말이면 정주행하느라 바쁜데

  1. 주말 내내 들어도 참고 들을만한 재미가 있고
  2. 단순 설명이 아니라 배경/비교 분석으로 맥을 잘 짚어주는 양질의 컨텐츠

모두에게 완전 추천한다 👍

이상형

요즘은 협업 부서 여자분하고 자주 보는데 말을 참 예쁘게하고 자기 컨트롤을 잘하는 사람으로 보인다. 참 오랫만에 이런 사람이면 연애해도 좋겠다는 생각이 들었다. 아직까지 내 이상형은 하는 짓이 예쁜 사람인 것 같다.

게임이 재미 없는 날도 오는구나

게임은 재미없다며 생산적인 활동을 더 좋아하는 친구가 있었다. 그 때 나는 사람이 저럴수도 있구나 하면서도 전혀 이해가 안됐다. 근데 이젠 내가 그러고 있네. 딱히 막 게임이 싫고 그런건 아닌데 뭔가 운동도 하고 뉴스도 보고 그렇게 된다… 요즘은 슈카월드 보는게 제일 재밌다 😁

Apr 24, 2020 - Considering Backend Architecture

search service application architecture를 very seriously하게 study 하다보니 english가 편안할 지경이다. 아무나 내 고민좀 들어줬으면 좋겠다.


요구사항은 1. cloud 환경일 것이다..? 2. kubernetes 환경 3. dynamic하게 code 수정 가능 4. 아직은 검색만 하지만 향후 추천 서비스도 가능하도록 확장성 있게 (?) 5. dynamic하게 api 생성/삭제/수정 (?)

앞으로 elasticsearch 기반 추천 시스템을 상상하면서 검색과 추천 서비스를 한 묶음으로 갈 예정인가보다.


처음 개발을 시작했을땐 요구사항 1~3만 알고 있었기 때문에 cloud를 잘 쓰는 법에만 관심이 있었다. 약 1달 간 aws를 겪으며 애플리케이션이 들어갈 환경 구성을 성공적으로 마무리했다 😙 그런데 요금통지서 쌔게 맞았다고 혼나고 다 삭제하니 남은건 yaml 파일 몇개 뿐이더라…


그리고 애플리케이션을 고민한다. 일단 rest api가 뭔지부터 또 구글링을 엄청 한다. 그 와중에 golang으로 api 만드는게 아주 좋아보였다. 나랑 같이 일하는 사람이 사실상 1명이다보니 빠르게 go를 공부해가며 개발 착수했다.

가장 기본이 되는 elasticsearch 조회, redis 조회 모듈부터 만들었다. 슬슬 go convention이라던가, 패키지 구조라던가, 디자인 패턴을 알아서 찾게 된다.


이제 api스럽게 web framework를 입힌다. 처음에 go-gin을, 나중엔 fasthttpfiber를 썼다. 설계도에 api 게이트웨이를 추가한다. latency를 의식하고 네트워크를 고려하기 시작한다. 서비스 code를 어떻게 분리해야하는지 고민한다. 점점 답이 없다는 인상을 받는다….


요구사항 4~5번을 알게 됐다.. dynamic하게 config, source code 수정을 어떻게 하면 좋을지 구글링하다가 이젠 뭔가 신기술 없는지 마구잡이로 찾는다.

go-micro를 보니 msa가 분명 장점은 있는 것 같은데 비즈니스 환경은 모놀리식이 어울리는 것 같기도 하고… 어차피 프론트쪽에서 rpc 통신 못하니까 평범하게 갈까 생각도 든다. 그제야 깨달은건 api와 web은 좀 다르다는 것..;;


knative를 발견한다. 역시 서버리스가 대세지. 여기에 ingress로는 gloo를 더하면 그림이 괜찮아보인다. 그런데 현실적으로 회사에서 컨테이너 기반으로 개발하는 사람이 거의 없기 때문에 (근데 왜 k8s 환경으로….🙄?) 쉬운 방법이 낫겠지.. kubeless는 code 올리고 커맨드만 돌리면 api가 뜨니까 엄청 간편해보인다. 아직까지는 kubeless가 제일 적당한 것 같다!!


2월부터 3달동안 정말 많이 공부했지만 사실 cloud 환경 DevOps가 정착된 회사라면 보면서 금방 따라할 수 있는 정도인 것 같다. 이번에 피부로 따갑도록 느낀건, 내가 주어진 일을 열심히 하려해도 회사에서 최소한의 서포트도 없으니 정말 영혼 없이 회사 다니게 되더라. (다시 한번 느끼지만 데이터 과학을 제대로 하려면 it 베이스 회사로 가야한다.😕) 가장 안타까운건 제일 큰 경력이 하필 서비스 개발이란게 나중엔 어떨지 몰라도 지금은 그리 만족스럽지 않다……

Apr 19, 2020 - 나는 Gopher

요새 검색 & 추천(은 coming soon) 서비스 개발 언어로 go를 쓰고 있다. 1도 모르는걸 꾸역꾸역 배워서 쓰는중 ㅋㅋ..

go를 사용한 경험을 가볍게 정리해보자.

ide

vscode로도 쓸만한 것 같다. goland는 회사에서 안 사줄거니까😂

체감한 장단점

장점

java 대비 아주 편하며(5배정도?) 가볍고 빠르고 러닝커브가 완만하다. a tour of go만 봐도 개발 투입 가능. microservice 만들기 딱 좋다고 생각한다.

단점

신생 언어이며 빠르게 발전하는 중이고 자유도가 높기 때문에 믿고 복사할(😋) 레퍼런스가 적은 것 같다. 구글링을 많이해야 그럴듯한 코드가 나온다. 가끔 근본없는 에러가 떠서 랭귀지가 아닌 오픈 소스로 개발하는(…) 느낌을 받는다.

구글링 팁

go는 최신 검색 결과 위주로 보는게 확실히 더 좋았다. 구글 검색에 최근 1년 날짜 필터를 걸어놓자.

개발포인트

꼭 module 단위로 생각하자

아무리 하찮은 함수여도 module로 설계해놓지 않으면 나중에 은근히 import가 꼬이고 가져다 쓰기 힘들다. 왠만하면 go mod init을 생활화하자.

무조건 test 코드를 만들자

개발 도중에 테스트 함 돌려볼까? 라는 안일한 생각으로 python처럼 대충 실행문을 짜서 돌리면 생각보다 잘 안된다… tdd의 마음가짐으로 처음 개발할 때부터 테스트 코드를 생각하는게 더 빠르고 오히려 편하다.

내부망을 쓴다면 일단 이렇게

나는 내부 gitlab을 쓰고 있어서 심플하게 push하고 주소를 고대~~로 가져다 쓰면 import가 잘 된다. 단 GOPROXY라는 환경변수가 필요하다. gitlab 주소가 corp.gitlab.gs라면 export GOPROXY=corp.gitlab.gs/*

의존성 관리를 위해 nexus등이 필요하지 않나는 우려도 있었는데 go mod vendor 기능으로 외부망 통신없이 외부 패키지를 쓸 수 있다. (아직 제대로 써보진 않았다)