리눅스 서버도 호그와트처럼 특정 조건이 부합할 때만 접근할 수 있는 9와 4분의 4 승강장이 있다면 어떨까요? 혹시라도 뚫고 들어온 머글이 있다면, 어떻게 들어왔는지 흔적을 빨리빨리 찾으려면 어떻게 해야 할까요? 특별한 마법을 쓰지 않아도 서버로 접근하는 경로와 머무르는 시간 등을 설정하는 방법을 살펴보겠습니다.

비즈니스는 ‘애자일(Agile)한 방식으로 점차 빠른 구현과 검증을 요구하는 형태로 변화하고 있다. 이에 따라 ‘애플리케이션(Application)’도 빠른 대응을 위한 유연한 구조를 원하고 있고, 데이터를 관리하는 인터페이스도 유연한 구조를 원하고 있다. 이번 글에서는 OLAP-Stars schema를 GraphQL을 통해서 구현하는 방법에 관해 다룰 계획이다. 기업의 의사결정을 돕는 데이터를 제공하며, 유연한 Application을 구축하는 방안을 생각해보고자 한다.

하나의 웹 사이트에서 왜 이렇게 다른 버전의 HTTP가 사용되고 있는 걸까요? 각 버전에는 무슨 차이가 있는 걸까요? 왜 HTTP의 버전은 1, 2, 3으로 딱 나누어 떨어지지 않을까요? 그래서 오늘은 HTTP의 각 버전이 등장하게 된 배경과 버전 별 특징을 정리해보고자 합니다. 이번 글을 통해 HTTP의 각 버전에 대해 자세하게 알고 싶은 분 들게 도움이 되기를 바랍니다.

리눅스에서 ‘etc’ 디렉터리는 정반대입니다. 디렉터리 이름과 달리, 이 속에는 시스템 설정 관련 파일이 있습니다. 시스템 부팅 전반에 걸쳐 영향을 주는 파일이 대부분이죠. [여기보기] 글 중, ‘파일과 디렉터리에는 정확한 소유권과 적당한 권한을 부여하라’ 글을 보셨을까요? ‘etc’ 디렉터리와 파일을 보호하는 기초적인 방법은 역시 소유권과 권한 설정입니다. 그래서 ‘chown’과 ‘chmod’ 명령어만으로 문제를 대부분 해소할 수 있습니다.

리눅스에서는 기본적으로 ‘find’, ‘chown’, ‘chmod’만 잘 써도 위협 요소 대부분 방어할 수 있습니다. 파일과 디렉터리마다 정확한 소유권과 적당한 권한이 부여된 것만으로도 허가받지 않은 사용자가 의도한 악의적인 활동은 기본적으로 차단할 수 있기 때문입니다. 그래서 어떤 조처를 하느냐보다 무엇을 왜 했는지 이해하고 명확한 기준을 세우는 것이 중요합니다. 이유와 기준만 확실하다면, 나머지 설정은 그에 따라가기만 하면 되니까요. 이번에는 조금 특별한 소유권 관계와 권한이 어떤 영향을 주는지 살펴보겠습니다.

GitHub(깃허브)는 개발자와 떼려야 뗄 수 없는 관계에 있는 서비스로, 개발자가 아닌 사람들조차 GitHub를 어렴풋이 들어본 적이 있을 정도로 유명합니다. 이 글은 ‘GitHub에 대해 듣기는 했지만, 무엇인지 정확히 모르는 사람들’과 ‘주변에서 많이 사용해서 일단 쓰고는 있는데, GitHub가 어떤 사이트인지 잘 모르는 사람들’을 위해 작성되었습니다. GitHub의 탄생부터 지금까지의 역사를 간단하게 살펴보고, 어떤 기능이 있는지 알아보겠습니다.

알라미 Android 팀에서도 최신 UI 빌드 트렌드를 따라가기 위해, 더 나아가 Compose의 이점을 활용하기 위해 기존 UI 빌드 방식을 Jetpack Compose로 전환하고 있습니다. 이에 대한 첫걸음으로 다음 ‘설정’의 ‘정보' 화면을 Jetpack Compose로 전환했습니다. 오늘은 Jetpack Compose를 적용해서 어떤 이점이 있었는지 공유해보고자 합니다.

핑퐁팀은 2022년 상반기에 루다와 유저를 만나게 하는 수단으로 더 이상 페이스북 메신저를 사용하지 않고 자체 메신저 앱을 개발하기로 결정했습니다. 빠르게 MVP 형식의 메신저 앱을 완성하여 배포한 후 지속적인 업데이트를 통해 앱의 완성도를 올리자는 계획을 세웠고, 이를 위해 앱 배포 과정을 최대한 자동화하였습니다. 이번 글에서는 루다와 함께 사용하는 메신저 ‘너티’의 빌드와 배포를 자동화하는 과정을 설명해 보겠습니다.

처음에는 그냥 기능 구현을 하면 되지만 프로젝트의 크기가 커지다 보면 ‘제대로 정리해두지 않으면 정말 안 될 것 같은 순간’들을 맞이하게 됩니다. 그냥 만들면 쉬운 요구사항도 기존 코드에 확장하는 것이 쉽지 않고, 점점 디버깅도 힘들어지는 걸 느낍니다. 이러한 문제에 부딪힌 많은 프론트엔드 개발자가 기존 구조에서 조금씩 더 나은 아키텍처와 프레임워크 형태, 그리고 라이브러리리를 제안했습니다. 덕분에 짧은 시간 안에 새로운 아키텍처들과 방법들이 꾸준히 탄생했습니다.

요즘 프론트엔드 영역에서 타입스크립트를 쓰는 것은 선택이 아니라 필수로 자리 잡고 있습니다. 타입스크립트라는 이름에서부터 느낄 수 있듯이 타입을 작성하는 데에 시간을 많이 쏟고, 사용할 때는 타입을 집합의 관점에서 바라보고 사용하게 됩니다. 하지만 우리가 상식적으로 알고 있는 집합의 관점으로만 바라보기에는 받아들이기 어려운 상황이 발생합니다. 왜 그런 일이 생기는 걸까요?