Clickjacking Attacks and How to Prevent Them : Clickjacking 공격은 사용자를 UI로 속여서 사용자가 클릭 혹은 다른 동작을 했지만 실제로는 상품 구매나 좋아요 클릭 등 다른 동작이 이뤄지도록 하는 공격 방법으로 Likejacking, Cookiejacking, Filejacking, Password manager attacks 등 다양한 변형이 있다. Clickjacking 공격 예제를 제공하는 데 이를 보면 유효한 사이트를 iframe으로 띄워서 투명하게 만들 뒤 사용자가 클릭할 버튼과 겹치게 만들어서 실제로 다른 버튼을 공격하게 만든다. 이는 CSRF 공격과 비슷해 보이지만 CSRF와 달리 공격자가 따로 요청을 보내는 것은 존재하지 않는다는 점이 다르다. 이를 막으려면 X-Frame-Options: sameorigin나 X-Frame-Options: deny 헤더를 지정해서 Content-Security-Policy: frame-ancestors 'self' 헤더를 지정해서 iframe내에서 사이트가 못 뜨도록 할 수 있고 최신 브라우저에서만 지원하는 sameSite을 strict로 쿠키에 지정해서도 막을 수 있다.(영어)
Why not use GraphQL? : Apollo에서 올린 Why use GraphQL?에 대한 응답으로 올린 글인데 이글도 GraphQL을 지지하는 입장의 글이다. 사실 두 글 모두 GraphQL 관련 업체이기 때문에 글에 자사의 입장이 어느 정도는 들어가 있지만 GraphQL과 REST의 특징을 이해하는데 도움 될 부분이 있다.
Apollo 글에서 얘기한 데이터를 불필요하게 많이 가져오고 중첩 데이터의 워터폴 네트워크 문제는 BFF(backend for frontend)를 만들면 대부분 해결가능하고 REST에는 304 응답을 이용한 캐시도 있어서 오히려 더 효율적일 수 있다고 한다.
Apollo 글에서 REST는 너무 많은 버전이 생길 수 있지만 GraphQL은 버전이 하나밖에 없다고 한 부분은 REST도 너무 많은 버전이 생긴다면 조직의 문제가 아닌지 봐야 하고 GraphQL의 스키마 추적 기능도 Apollo의 유료 기능이지 GraphQL에서 제공하는 기능이 아니기 때문에 사실상 버전 관리를 안 하면 똑같고 어차피 브레이킹 체인지가 발생하면 안 되고 호환되도록 업데이트를 해야 하는 게 양쪽 다 마찬가지라고 얘기하고 있다.
GraphQL이 엄격한 타입으로 안정적이라고 한 것도 REST에서 Open API 명세 같은 API 문서를 제공하지 않는 것과 비교하는 것을 말이 되지 않고 GraphQL도 응답은 자유롭게 할 수 있기 때문에 클라이언트가 명세대로 올 것이라고 믿어야 하는 건데 이는 API 문서와 사실 같은 상황이라고 하고 한다.
문서 작성에 드는 시간이 적고 API 찾기 쉽다고 한 부분은 비교를 문서 파일로 비교해서 그렇고 Open API를 쓰면 보통 개발자 포털에 배포해서 사용하기 때문에 검색이 쉬운 데다가 Open API는 여러 서비스 간에도 참조를 할 수 있고 빌드를 한꺼번에 하는 것도 가능하다. 그리고 Open API나 GraphQL 스키마가 있다고 문서화가 잘 되었다고 할 수는 없고 인증을 어떻게 해야 하는지, 좋은 방법은 무엇인지 등 다양한 설명이 있어야 처음 사용할 때 편한데 Open API에는 이러한 기능을 많이 지원하는 데 반해 오히려 GraphQL 도구들에는 이런 기능이 보통 빠져있다고 한다.
싱페어 (SPA) 의 피로감 : React를 이용한 SPA(Single Page Application)는 개발자의 생산성은 올려주었지만 서버 사이드 렌더링(SSR)이 쉽지 않고 느린 데다가 상태 주입이 어렵기 때문에 그 미래가 밝지 않다고 설명하는 글이다.(한국어)
ES Modules in Depth : ES Modules의 사용 방법을 설명하는 글이다. export default의 사용법과 다양하게 export하는 방법을 설명하고 import 할 때도 전체로 가져오거나 일부만 가져오는 방법을 설명한다. 앞부분에는 정적으로 import하는 방법을 설명하고 뒤에는 동적 import라고 부르는 비동기로 가져오는 방법을 설명한다.(영어)
How to Boost Docker with WSL2 : Windows에서 Docker를 개발환경으로 보통 사용하는 대부분의 환경에서는 큰 문제가 없지만, 종종 성능 이슈가 생기는 경우가 있다. 이는 Windows가 Linux를 지원하지 않음으로 Docker Desktop for windows가 Hypervisor를 이용해서 VM을 띄우고 파일을 주고받기 때문에 이 부분에서 성능 저하가 일어난다. WSL2를 이용하면 Linux 파일 시스템을 VM 없이 바로 이용할 수 있기 때문에 이런 성능 저하가 일어나지 않지만 두 파일 시스템 간의 통신으로 성능이 저하될 수 있다. 이를 위해 WSL2를 설치한 뒤에 Ubuntu를 설치하고 Docker에서 설정으로 Ubuntu를 활성화한 뒤에 VS Code에서 "Remote WSL"을 이용하면 작업은 윈도우에서 하면서 코드 수정은 Linux에서 일어나도록 할 수 있다고 한다.(영어)
How we open sourced docs.github.com : 최근 GitHub이 문서 사이트를 오픈소스로 공개했는데 이 과정을 설명한 글이다. 문서 사이트는 처음에는 Ruby on Rails로 만들어졌지만 이를 정적 사이트 생성기인 Jekyll, 그다음엔 또 다른 정적 사이트 생성기인 Nanoc를 이용했고 지금은 Node.js 웹서비스로 만들어졌다. 이를 오픈소스화하더라도 내부에서 해야 할 작업이 필요했고 공개 저장소와 비공개 저장소를 동기화하기 위해 비슷한 Actions를 만든 사람과 협업해서 Repo Sync 액션을 만들어서 공개했고 Liquid 템플릿을 이미 많이 쓰고 있었지만 적당한 npm 모듈이 없어서 많은 컨트리뷰터들과 liquid 모듈을 만들어 공개했다고 한다.(영어)
유연하고 테스트 가능한 Go 코드 작성하기 : 당근마켓의 플랫폼 팀이 Go로 서비스를 만들면서 Go의 인터페이스가 메서드의 집합이라는 부분을 활용하여 인터페이스로 클라이언트의 의존성 없이 모킹해서 작성한 로직의 테스트 코드를 작성하는 방법을 보여준다.(한국어)
코드에서 암호를 안전하게 사용할 방법을 찾아서… : 코드에 하드 코딩해서 넣기 어려운 데이터베이스 비밀번호 같은 비밀 정보를 관리하기 위해 S3에 올리거나 환경 변수로 관리하는 시도를 해보다가 AWS의 Parameter Store를 사용해 봤으나 주기적인 암호 변경이 필요해서 AWS Secret Manager로 넘어가서 관리하게 되는 과정과 각 단계의 장단점을 적어놨다. Secret Manager는 Parameter Store와 사용법은 비슷하지만, 주기적으로 암호가 변경되도록 설정할 수 있다.(한국어)
복잡한 커밋 로그를 정리해줄 구원자, gitmoji : Atom 프로젝트 등에서 사용하던 커밋 앞에 커밋의 종류를 구분하기 위한 이모지를 붙이는 방법을 설명한 글이다. 커밋 앞에 docs, feat같은 식으로 붙이기도 하는데 이 대신 약속한 이모지를 붙이는 것이고 이를 통해 커밋 히스토리를 보면 쉽게 구분이 가능하다는 장점이 있지만, 규칙을 모르면 이모지만으로는 알 수 없다는 문제가 있다.(한국어)
The new pricing model for travis-ci.com : travis-ci.com이 11월 2일부터 가격정책을 변경했다. Linux와 Windows를 사용하는 사용자는 변경이 없고 macOS는 크레딧을 구매해서 사용해야 하고 어뷰저가 많아져서 무료체험을 Linux 1,000분의 빌드 시간을 제공하는 것으로 바꾸었다. 오픈소스 프로젝트도 1,000분의 빌드 시간을 제공하고 추가로 필요하면 별도로 신청해야 한다.(영어)
일 잘 하는 개발자는 왜 비즈니스까지 신경쓸까? : 개발자가 기술적으로 좋은 설계에 관해 관심을 많이 가지고 이게 주 역할이지만 고용된 사람으로서 개발자의 시간도 비용이 들기 때문에 어느 정도 노력을 들일 건인지 비즈니스의 관점에서 적절하게 판단할 수 있어야 한다는 글이다. 개발자에 다양한 타입이 있고 처한 상황도 다양하겠지만 이 글에서 주장하는 비즈니스까지도 같이 고려해야 한다는 점에 동의하는 편이다.(한국어)
인턴쉽 : 탈중앙 온라인 게임을 만드는 플라네타리움의 인턴으로 합류해서 게임 론처 부분에 기여한 경험을 적은 글이다. 인턴쉽에 지원하면서 자신의 관심 있는 영역과 회사의 상황을 묻고 피드백 받는 부분이 흥미롭다. 인턴쉽을 하면서 팀을 위해서 테스트를 자동화하고 론처의 UX를 개선하고 접근성 작업을 하다가 팀원과의 협의를 통해 중단하는 등 인턴쉽을 알차게 보내셨다는 생각이 든다.(한국어)
Comments