웹 성능 최적화 SSR + Cache 적용기 : 웹사이트의 로딩 속도는 사용자 전환율에도 영향을 주고 구글 SEO 결과에도 영향을 주므로 Wanted 사이트에서 이를 개선할 수 있는지 테스트해본 과정에 대한 글이다. Wanted에서는 Next.js를 이용해서 SSR(Server Side Rendering)을 사용하고 있는데 공통 영역을 SSR을 사용하지만 콘텐츠 영역은 CSR(Client Side Rendiering)로 구현되어 있는데 이 부분을 SSR로 변경해서 Lighthouse 결과가 어떻게 달라지는지 테스트해보았다. SSR로 변경 후 총점이 13점 올라갔고 캐시까지 적용한 후에는 30점이 올랐다. 서비스마다 다를 테지만 참고할만하다.(한국어)
On OCaml and the JS platform : 아직 상황이 명확해지지 않아서 애매하지만 그린랩스가 ReasonML에서 리스크립트로 바꾸는 이유에서도 보았듯 BuckleSciprt가 ReScript로 리브랜딩 된다는 것을 보았는데 커뮤니티에서는 논란이 있는 것으로 보인다. ReScript 메인테이너가 밝힌 대로 ReasonML의 최우선순위는 OCaml 생태계와 호환성을 맞추는 것이고 ReScript(BuckleSciprt)의 최우선순위는 JavaSciprt 개발자에게 최고의 개발 경험을 주는 것이라고 한다. 이글은 ReScript가 리브랜딩을 하면서 ReasonML과 다른 길을 가서 호환성이 깨지는 부분을 걱정하는 것으로 보인다.(영어)
그 밖의 개발 관련
Announcing Spring Native Beta! : Spring에서 1년 반의 작업을 거쳐서 Spring Native의 베타 버전을 공개했다. Spring Native는 Spring 애플리케이션을 GraalVM 네이티브 이미지 컴파일러를 사용해서 단독 실행 파일로 만들어준다. 이를 통해 빌드 시간은 길어졌지만, 런타임 최적화는 줄어들어 최초 구동 시간이 줄어들고(보통 100ms 이하) 더 적은 메모리를 사용하면서 성능도 좋아졌다고 한다.(영어)
Scripting with GitHub CLI : 1년 전에 공개된 GitHub의 공식 CLI 도구 gh를 확장해서 쓰는 방법을 소개한 글이다. gh alias set으로 자주 사용하는 명령어의 별칭을 만들 수 있고 PAGER 환경변수로 less나 delta를 연동해서 출력을 보거나 파이프로 fzf를 연동하는 방법 등을 소개하고 있다.(영어)
AppsFlyer Deferred DeepLink 적용기 : 딥링크는 모바일 앱의 특정 페이지로 바로 들어가게 하는 링크인데 딥링크는 앱이 설치된 경우에만 동작하므로 링크를 통해 앱을 설치한 후 앱을 실행하는 경우는 해당 페이지로 진입하지 못하게 된다. Wanted에서 이 문제를 해결하려고 AppsFlyer의 Deferred DeepLink를 적용해서 앱 설치 후에도 지정된 화면으로 이동하도록 구현한 과정을 설명한다. 결과도 궁금한데 글에서 나오듯이 적용한 지 오래되지 않아 적용 후 사용자 전환율의 변화 등은 자세히 나와 있지 않다.(한국어)
GitHub security update: A bug related to handling of authenticated sessions : GitHub이 보안 이슈로 지난 3월 8일 GitHub.com의 모든 세션을 만료시켜서 모든 사용자의 로그인이 풀렸다. 3월 초 외부 리포팅으로 받은 내용에 따르면 극히 드물지만, 사용자 세션이 다른 사용자의 브라우저로 라우팅 되어서 유효한 세션을 제공할 수 있다는 취약점이 발견되었다고 한다. 이는 GitHub의 인증이 침해되었다는 의미는 아니고 인증 세션의 부적절한 처리로 인해서 발생했다고 한다. 이 버그는 2월 초부터 3월 초까지 2주 정도의 시간 동안만 존재했고 0.001%의 인증 세션에만 영향을 주었다고 한다.(영어)
Git clone vulnerability announced : Git에서 Git LFS를 사용할 때 git clone을 하는 동안 지연된 체크아웃에서 발생하는 보안 취약점 CVE-2021-21300을 발견하고 새 버전 2.30.2를 릴리스했다. 이 취약점을 통해 악의적인 저장소의 원격 코드가 clone하는 동안 실행될 수 있다.(영어)
Open Distro for Elasticsearch — 로그를 활용한 장애 탐지 : 29CM에서 결재 장애를 겪은 뒤에 이러한 장애 알림을 더 빨리 받기 위해 기존에는 추적하고 있던 주문 건수를 추적한 과정이다. 이동 평균을 사용해서 실제 완료된 주문 건수가 예상한 주문 건수보다 적을 때 알림을 받는 식으로 구현을 했고 Alert 기능은 Elasticsearch에서 유료화되었으므로 Open Distro for Elasticsearch를 사용해서 이동 평균을 추적한 값을 알림으로 받을 수 있게 구현했다고 한다. 마지막에 실제로 이 과정을 따라 해 볼 수 있게 정리된 튜토리얼도 나와 있다.(한국어)
Kubernetes의 네트워크 이슈를 해결할 수 있는 network-node-manager : 카카오에서 운영 중인 Kuberentes에서 겪은 네트워크 이슈를 해결하려고 만든 network-node-manager를 설명한다. network-node-manager는 외부 서버와 통신하는 경우 응답 패킷이 잘못 전달되어 커넥션이 끊기는 "Connection Reset Issue between Pod and Out of Cluster" 문제를 해결하려고 잘못된 패킷이 전달되지 않게 필터 규칙을 추가한다. 그리고 IPVS 프락시 모드에서 외부 IP 접근 시 특정 노드에는 패킷이 전달되지 않는 문제를 해결하기 위해 DNAT을 적용해서 Cluster-IP로 변경하고 있다. 이 network-node-manager는 DaemonSet으로 띄워서 Kubernetes API 서버와 통신하게 된다.(한국어)
Testing HashiCorp Terraform : 테라폼 설정이나 모듈에 대한 테스트를 전체적으로 훑어보는 글이다. 프로그래밍 관점에서 유닛 테스트 - 계약 테스트 - 통합 테스트 - e2e 테스트 - 수동 테스트 순으로 점점 비용과 시간이 많이 드는데 단계별로 Terraform에서는 어떻게 해야 하는지 설명하고 있다.
유닛 테스트는 메타데이터가 올바른지 검사하는 용도로 간단하게는 teraform fmt -check나 terraform validate를 사용할 수 있지만 Sendinel이나 다른 프로그래밍 언어로 검사하는 것이 가능하다. 보통 실제 리소스는 만들지 않고 정확한 테스트를 위해서 terraform plan의 결과를 파싱해서 테스트하는 게 좋다.
계약 테스트는 모듈의 입력값이 맞는지 검사하는데 쉽게는 variable의 validation 규칙을 사용하면 별도의 테스트 프레임워크가 필요 없다.
통합 테스트는 실제로 리소스가 잘 생성되는지 검사해야 하므로 리소스를 생성하는 비용이 든다. 프레임워크에 따라 다르지만 terraform apply로 테스트 리소스를 생성하고 테스트를 실행한 뒤 terraform destroy로 리소스를 제거할 수 있고 Terraftest나 kitchen-terraform을 사용할 수 있다.
An Introduction to Terraform Cloud Agents : Terraform Cloud를 사용할 때 Terraform 작업을 네트워크 내부에서 수행할 수 있는 셀프 호스티드 에이전트가 추가되었고 이는 Terraform Cloud의 비즈니스 플랜에서만 사용할 수 있다. Terraform Cloud agent를 이용하면 Terraform Cloud의 접근을 열지 않고도 안전하게 사용할 수 있다.(영어)
볼만한 링크
지원자도 회사를 평가합니다. 이렇게요. : 글쓴이가 채용 담당자라고 하는데(물론 채용담당자도 이직하고 지원을 할 테니) 지원자가 회사를 평가하기 위해 할 수 있는 질문과 어떤 의도로 질문하는지를 설명한다. 궁금한 내용이 다들 다르겠지만 질문이 꽤 구체적이고 질문의 의도가 잘 나와 있어서 같은 질문을 하지 않아도 도움이 될 것 같다. "나는 면접을 보러 갈 때 항상 질문거리들을 적어간다. 회사를 골라갈 수 있는 최고의 인재들만 그럴 '자격'이 있다고는 말하지 않았으면 좋겠다."는 부분에 동의한다.(한국어)
개발자, 채용 가이드북 : 이노베이션 아카데미에서 개발자 채용과 관련된 가이드 북을 배포했다. 200 페이지 정도 되는 PDF로 개발자를 채용하는 방법과 채용 후 어떻게 관리해야 하는지를 설명하고 있다.(한국어)
평가 방법 OKR, KPI, MBO 뭐가 다른거에요? : 성능평가 방법으로 유명한 KPI(Key Performance Indicator)와 최근 뜨고 있는 OKR(Objectives and Key Results)를 비교한 글이다. 어떤 방법이 더 좋다기 보다 KPI와 OKR의 특징을 설명하고 차이점을 보여준 데 중점을 두고 있다. KPI는 "추적할 대상의 시간 경과에 따른 성과를 평가"하는 데 사용되고 KPI는 측정 가능한 것으로 정해야 한다. OKR은 "목표 달성을 추적하려고 특정 지표를 사용하는 단순한 흑백 접근법"이면서 빠르고 공격적인 성장을 위한 반복의 과정이다.(한국어)
Comments