이 글은 Ruby로 다양한 정렬 알고리즘을 구현해 보는 시리즈의 세 번째 편입니다. 1편에서는 버블 정렬을, 2편에서는 선택 정렬을 다루었으니 아직 읽지 않으셨다면 함께 참고하시길 권합니다. 병합 정렬이란? 이 시리즈의 앞선 글에서 말씀드렸듯이, 데이터를 정렬하는 방법을 이해하는 것은 모든 소프트웨어 엔지니어에게 필수적인 역량입니다. 다행히 Ruby처럼 고수준 언어 대부분은 이미 효율적인 정렬 메서드를 내장하고 있습니다. 예를 들어 배열에 .sort를 호출하면 내부적으로는 퀵 정렬(quicksort)이 동작합니다. 이번 글에

이 시리즈의 이전 글에서는 Go의 net/http 패키지와 이를 활용해 프로덕션 수준의 웹 애플리케이션을 구축하는 방법을 폭넓게 다루었습니다. 당시에는 주로 라우팅 측면과 http.ServeMux 타입의 다양한 기능과 특성에 초점을 맞췄습니다. 이번 글에서는 기본 라우터를 사용해 미들웨어 함수를 구현하는 방법을 통해 ServeMux에 대한 논의를 마무리하고, Go로 웹 서비스를 개발할 때 반드시 유용하게 쓰일 다른 표준 라이브러리 패키지들을 소개합니다. Go에서의 미들웨어(Middleware) 많은 수 혹은 모든 HTTP 요청

소프트웨어를 최종 사용자에게 배포하기 전에 우리는 애플리케이션에 버그가 없고 비즈니스 요구 사항을 충족하는지 확인하기 위해 다양한 종류의 테스트를 수행합니다. 하지만 아무리 많은 테스트를 거쳐도 실제 사용자가 애플리케이션을 사용하기 전까지는 소프트웨어가 안정적이라고 확신할 수 없습니다. 사용자들이 애플리케이션을 사용하기 시작하면 다음과 같은 이유로 예상과 다르게 동작할 수 있습니다. 사용자 행동은 예측하기 어렵습니다. 사용자는 서로 다른 지역에 분산되어 있습니다. 대규모 사용자가 동시에 애플리케이션을 사용할 수 있습니다. 대

소프트웨어 개발은 어려운 일이지만, 개발 이후의 유지보수는 그보다 훨씬 더 어렵습니다. 유지보수에는 소프트웨어 패치와 서버 관리가 포함되는데, 이 글에서는 특히 서버 관리와 운영에 초점을 맞춰 살펴보겠습니다. 전통적으로 서버는 온프레미스(on-premises) 방식으로, 물리적인 하드웨어를 직접 구매하고 관리해야 했습니다. 하지만 클라우드 컴퓨팅의 등장으로 더 이상 물리적 서버를 소유할 필요가 없어졌습니다. 2006년 아마존이 AWS를 시작하며 EC2 서비스를 선보였을 때, 현대 클라우드 컴퓨팅 시대가 열렸습니다. 이러한 서비스 덕

캐싱(caching)을 일반적으로 설명하면, 어떤 코드의 실행 결과를 저장해 두었다가 나중에 빠르게 꺼내 쓰는 것을 의미합니다. 경우에 따라서는 계산된 값을 미리 저장해 두어 다시 계산할 필요가 없도록 하기도 합니다. 하지만 단순히 데이터를 메모리에 보관만 해도, 하드 디스크에서 읽거나 네트워크 요청을 수행하지 않아도 되므로 이 역시 캐싱의 한 형태입니다. 후자의 형태는 ActiveRecord에서 특히 중요합니다. 데이터베이스가 별도의 서버에서 구동되는 경우가 많기 때문입니다. 이런 환경에서는 모든 요청마다 네트워크 트래픽 오버헤

때로는 예상치 못한 상황과 통제할 수 없는 외부 요인들이 터무니없이 비정통적인 요구사항을 만들어냅니다. 최근 저는 데이터베이스 ID에 전혀 의존하지 않고 ActiveRecord를 사용해야 하는 경험을 했습니다. 혹시 같은 일을 고려하고 계신다면, 솔직히 말씀드리면 다른 방법을 찾아보시길 강력히 권합니다! 하지만 어쩔 수 없는 사정이라면, 이 글이 도움이 될 것입니다. 이야기를 계속 이어가 보겠습니다. 결정은 이미 내려진 상태였습니다. 구조는 같지만 데이터는 서로 다른 여러 개의 작은 데이터베이스를 하나로 통합해야 했습니다. 제가

Ruby의 코드 로더 - Zeitwerk 이해하기 Zeitwerk를 사용하면 클래스와 모듈이 코드베이스 어디에서든 사용 가능하다는 확신을 갖고 개발에 집중할 수 있습니다. 복잡한 require 호출 없이도 깔끔하고 효율적인 코드 로딩 환경을 구축할 수 있죠. 코드 로더란 무엇인가? 코드 로더(Code Loader)는 개발자가 여러 파일과 폴더에 클래스와 모듈을 정의하고, 명시적으로 require하지 않고도 코드베이스 전체에서 사용할 수 있게 해주는 도구입니다. Rails가 코드 로더를 활용하는 대표적인 예입니다. Rails에서는 컨

Ruby에서 로그 다루기: Logger부터 Lograge까지 로깅은 애플리케이션이 반드시 처리해야 하는 핵심 작업 중 하나입니다. 로그는 다음과 같은 경우에 활용됩니다. 애플리케이션 내부에서 무슨 일이 일어나는지 확인할 때 애플리케이션을 모니터링할 때 특정 데이터에 대한 지표(metric)를 수집할 때 새로운 프로그래밍 언어를 배울 때 로그를 남기기 위해 가장 먼저 선택하게 되는 것은 보통 해당 언어의 네이티브 메커니즘입니다. 사용법이 쉽고, 문서화가 잘 되어 있으며, 커뮤니티 전반에 널리 알려져 있기 때문입니다. 로그

모든 소프트웨어 애플리케이션은 시간이 지나면서 변화합니다. 소프트웨어에 가해진 변경은 예상치 못한 연쇄적인 문제를 일으킬 수 있습니다. 하지만 변하지 않는 소프트웨어를 만들 수는 없기 때문에 변화는 피할 수 없습니다. 소프트웨어가 성장함에 따라 요구사항도 계속 바뀌기 마련입니다. 우리가 할 수 있는 것은 변화에 유연하게 대응할 수 있도록 소프트웨어를 설계하는 것입니다. 처음에는 시간과 노력이 들지만, 장기적으로 보면 큰 비용을 절약해 줍니다. 강하게 결합된(tightly coupled) 소프트웨어는 취약하며, 변경이 어떤 결과를 가

솔직히 고백하자면, 저는 정규식 작업이 그다지 좋지 않습니다. 실무에서 자주 사용하긴 하지만, /^foo.*$/ 수준을 넘어서는 복잡한 표현식을 마주치면 매번 멈춰서 곰곰이 생각해야 합니다. \A(?=\w{6,10}\z)(?=[^a-z]*[a-z])(?=(?:[^A-Z]*[A-Z]){3}) 같은 표현식을 한눈에 해독할 수 있는 사람도 분명 있겠지만, 저는 몇 분 동안 구글링을 해야 하고 기분까지 가라앉습니다. 익숙한 Ruby 코드를 읽는 것과는 상당히 다른 경험입니다. 참고로 위 예제는 정규식 lookahead(전방탐색)를 다룬

올해 초 우리는 전용 서버 호스팅 환경에서 AWS로 인프라를 이전했는데, 지금 와서 돌아보면 정말 잘한 선택이었다는 생각이 듭니다. 자동화를 폭넓게 구축해 두었기 때문에 서버를 직접 만지작거리는 데 쓰는 시간이 크게 줄었죠. :) 이 글에서는 에러 알림(error notification) 처리량에 변화가 생길 때 우리 인프라에서 어떤 일이 일어나는지 소개합니다. 스케일링 방식 우리의 처리 파이프라인은 Sidekiq에 크게 의존하고 있으며, Sidekiq은 그동안 놀랄 만큼 안정적으로 동작해 왔습니다. 파이프라인 작업의 대부분은

최근 honeybadger 루비 젬(Ruby Gem) 버전 3.2를 출시했습니다. 이번 릴리스에는 에러 리포트에 컨텍스트를 더 쉽게 추가할 수 있는 새로운 기능이 포함되어 있습니다. 핵심 요약 honeybadger 젬은 이제 모든 예외 클래스에서 #to_honeybadger_context 메서드를 정의할 수 있습니다. 해당 예외의 인스턴스가 발생해 Honeybadger에 보고되면, 이 메서드가 반환하는 컨텍스트가 에러 리포트에 자동으로 포함됩니다. class MyError < StandardError attr_reade

지난 6개월 동안 저는 Rust로 NES 에뮬레이터를 만들어 왔습니다. 예상하시겠지만, 이 과정에서 Rust에 대해 많은 것을 배웠고, NES 내부 구조에 대해서는 더 많이 배웠습니다. 그런데 흥미롭게도 이 경험은 제가 Ruby를 바라보는 방식까지 바꿔 놓았습니다. 특히 nil을 반환하는 메서드를 볼 때면 어딘가 불안해졌습니다. 확실한 원칙이 없으면 무엇이든 속아 넘어가기 마련 Ruby에서 nil은 정확히 무엇을 의미할까요? 사실상 거의 모든 것이 가능합니다. 메서드가 nil을 반환할 때 그 의미는 다음 중 하나일 수 있습니다.

최근 저는 신뢰성이 떨어져 사용하기 정말 답답한 테스트 스위트를 다룬 적이 있습니다. 테스트 대상 애플리케이션은 API 전용 Rails 애플리케이션이었고, 테스트는 JavaScript로 작성되었습니다. 사용된 프레임워크는 Chakram으로, JSON REST 엔드포인트에 대한 엔드 투 엔드(end-to-end) 테스트를 수행하도록 설계된 API 테스팅 프레임워크입니다. 이 테스트 스위트의 핵심 문제는 결정적(deterministic)이지 않다는 것이었습니다. 함수나 프로그램이 결정적이라는 것은 동일한 입력을 주면 항상 동일한 출

지난주 honeybadger 루비 젬의 버전 4.0.0이 정식 출시되었습니다. 이번 릴리스에는 오랫동안 기다려 온 기능이 포함되어 있어, 에러 리포트가 Honeybadger로 전송되기 전에 훨씬 더 손쉽게 커스터마이징할 수 있습니다. 아울러 꼭 필요했던 내부 리팩토링이 진행되었고, 일부 기능의 제거 및 지원 중단(deprecation)도 함께 이루어졌습니다. 하지만 걱정하지 않으셔도 됩니다. 대부분의 API는 그대로 유지되었기 때문에, 대다수 사용자에게 업그레이드 과정은 비교적 간편하게 진행될 것입니다. before_notify

AWS Lambda의 Ruby 공식 지원 소식이 발표되자마자 너무 반가워서 바로 사용해 보았습니다. Honeybadger에서는 한동안 Lambda를 활용해 왔고, 저 역시 오랫동안 서버리스 함수를 Ruby로 작성할 수 있기를 기대해 왔습니다. 새로운 Ruby 런타임을 몇 시간 가까이 사용해 본 결과, 앞으로 Node, Go, Python에 들이는 시간이 눈에 띄게 줄어들 것이라 확신하게 되었습니다. :) 간단한 예제 살펴보기 AWS의 공식 발표 블로그 포스트만으로도 Ruby on Lambda를 빠르게 시작할 수 있지만, 이 글에

루비(Ruby)는 객체지향 언어이기 때문에 우리는 흔히 세상을 객체들의 집합으로 모델링하곤 합니다. 예컨대 두 개의 정수 x와 y를 묶어 Point라고 부르고, Line은 그런 Point 두 개로 이루어져 있다고 정의하는 식입니다. 이 접근 방식은 분명 유용하지만, 한 가지 큰 문제를 안고 있습니다. 바로 데이터에 대한 하나의 해석을 다른 모든 해석보다 우선시한다는 점입니다. x와 y는 언제나 Point일 것이라고 가정하며, 이들이 Cell이나 Vector로 동작해야 할 일은 애초에 없을 거라 전제하는 것이죠. 그렇다면 정말 C

얼마 전 HB 팀이 잡담을 나누던 중, 데브옵스 전문가인 Ben이 특정 시스템에 UUID 대신 ULID를 사용했더라면 좋았을 텐데라고 언급한 적이 있습니다. 늘 그렇듯 베테랑 엔지니어다운 반응으로 저는 애매한 말만 중얼거린 뒤, 몰래 Google에 검색해 ULID가 도대체 무엇인지 알아보러 갔습니다. 두 시간 후, 저는 멍한 눈으로 돌아왔고, 고유 식별자의 세계가 상상했던 것보다 훨씬 넓고 흥미롭다는 사실을 깨달았습니다. ULID를 본격적으로 다루기 전에, 기본으로 돌아가 UUID가 무엇인지 먼저 살펴보겠습니다. 일반적인(순차) I

비싼 인터넷 요금을 버리고 이웃집의 보안이 허술한 Wi-Fi를 몰래 쓰고 싶었던 적 있으신가요? 그런데 유일하게 발목을 잡은 것이 바로 Honeybadger의 단일 인증 방식이었다면? 좋은 소식이 있습니다. 2단계 인증(Two-Factor Authentication, 2FA) 출시 농담은 여기까지 하고, 진지하게 말씀드리자면 저희는 보안을 매우 중요하게 생각합니다. 사용자와 데이터를 더욱 안전하게 지킬 수 있는 중요한 도구를 제공하게 되어 기쁩니다. 그냥 2FA 활성화 방법만 설명할 수도 있지만, 그게 어디 재미있겠습니까? 가

프로덕션 환경에서 오류가 발생했는데, 아무리 시도해도 개발이나 스테이징 환경에서는 재현할 수 없는 경험이 있으신가요? 이런 경우 다음 단계로 보통 프로덕션에 디버그 로그를 추가해 더 많은 데이터를 수집하게 됩니다. 하지만 로그와 요청을 연관 지을 좋은 방법이 없다면, 특히 장애 대응 중이라면 상당히 답답한 상황이 됩니다. 이를 돕기 위해 새로운 기능을 추가했습니다. 바로 브레드크럼(Breadcrumbs)입니다. 브레드크럼이란? 브레드크럼은 로그 이벤트와 매우 유사하지만, 오류와 함께 저장되고 보고된다는 점이 다릅니다. 로그처럼 메