독자가 재귀라는 개념과 루비를 안다는 것을 가정합니다.

꼬리 호출 최적화란?

꼬리 호출 최적화(TCO: tail call optimization)는 꼬리 재귀(tail-recursive) 프로시져를 최적화하는 방법입니다. 재귀적인 프로시져의 콜 스택 사이즈를 하나로 줄여주어서 재귀를 사용할 때 스택 오버플로가 발생하는 것을 막아 줍니다.

이 글에서는 루비에서 메서드를 호출했을 때, 루비가 어떤 식으로 이를 처리하는지를 살펴보도록 하겠습니다. 루비 언어를 어느 정도 사용할 줄 안다고 가정합니다.

두 개의 글로 나누어서 구성했는데 첫 번째 글에서는 일반적인 루비 프로그램에서 알아야 될 내용을 다루는데, 구체적으로는 조상 목록, 클래스 상속, 모듈 include 및 prepend 등입니다.

두 번째 글에서는 더 드물게 사용되는 기능을 살펴보는데 싱글턴 메서드, 싱글턴 클래스, 클래스 메서드 등을 다룹니다.

이 글에서는 루비에서 메서드를 호출했을 때, 루비가 어떤 식으로 이를 처리하는지를 살펴보도록 하겠습니다. 루비 언어를 어느 정도 사용할 줄 안다고 가정합니다.

두 개의 글로 나누어서 구성했는데 첫 번째 글에서는 일반적인 루비 프로그램에서 알아야 될 내용을 다루는데, 구체적으로는 조상 목록, 클래스 상속, 모듈 include 및 prepend 등입니다.

두 번째 글에서는 더 드물게 사용되는 기능을 살펴보는데 싱글턴 메서드, 싱글턴 클래스, 클래스 메서드 등을 다룹니다.

블로그에 어떤 글을 써야할지에 대해 좋은 조언을 들은 적이 있습니다. 내가 1년 전에 읽을 수 있었으면 좋았을 글을 쓰라는 것이었죠. 이 글은 그런 글입니다. 초심자가 타입 시스템을 잘못 이해하는 경우가 많은데 그 중 몇 가지를 설명하고자 합니다.

이 글은 2016년 11월 16일 서울 엘릭서 밋업에서 한 발표의 내용을 정리한 것입니다.

초심자에게 가르칠 언어를 선택할 때 바로 엘릭서를 떠올리실 분은 없을 것입니다. 파이썬, 루비, 자바스크립트, C/C++, 자바 등이 더 일반적이죠. 하지만 저는 엘릭서 특유의 장점 덕분에 엘릭서도 첫 언어로 진지하게 고려해볼 만하다고 생각합니다.

이 글은 2016년 11월 16일 서울 엘릭서 밋업에서 한 발표의 내용을 정리한 것입니다.

초심자에게 가르칠 언어를 선택할 때 바로 엘릭서를 떠올리실 분은 없을 것입니다. 파이썬, 루비, 자바스크립트, C/C++, 자바 등이 더 일반적이죠. 하지만 저는 엘릭서 특유의 장점 덕분에 엘릭서도 첫 언어로 진지하게 고려해볼 만하다고 생각합니다.

한줄 요약

얼랭 스탠다드 라이브러리의 crypto 모듈에 있는 :crypto.exor/2 함수를 사용하면 됩니다.

삽질의 기록

코세라에서 제공하는 Cryptography 수업에 있는 간단한 퀴즈를 풀려고 하다가 모든 것이 시작되었습니다. 평문(pt)과 One-Time Pad로 암호화된 암호문(ct)이 주어졌으니 간단하게 ct와 pt를 XOR하기만 하면 One-Time Pad 키를 알아낼 수 있습니다.

그런데 엘릭서로는 아직 비트 연산자 작업을 안 해봐서 이 참에 엘릭서로 해보기로 했습니다.

역주

이 글은 programming is terrible이라는 블로그에 tef가 작성한 Write code that is easy to delete, not easy to extend.라는 글의 전문을 저자의 허락을 받고 번역한 글입니다.

대상 독자로는 아직 프로그래밍을 배우고 있는 학생과 2년차 이하의 초급 개발자를 생각했습니다.

공감하는 부분이 많아서 번역했지만, 짧은 글이 아님에도 불구하고 글 길이에 비하면 정말 많은 개념을 다루고 있기 때문에 조금 난해할 수도 있습니다. 더 자세히 알고 싶으면 클린 코드(로버트 C. 마틴)나 루비로 배우는 객체지향 디자인(샌디 메츠) 같은 책에서 비슷한 내용을 더 길게 풀어서 설명하고 있으니 참조하면 좋을 것 같습니다.

저자가 중간중간에 다른 프로그래머의 말이나 글을 인용하는데, 보통 새로운 주제로 넘어갈 때 인용을 하니 참고해주세요.

드디어 Ruby Rogues 팟캐스트의 모든 에피소드를 완주했습니다. 에피소드마다 1시간 정도 분량인데 현재 시점에서 총 283개의 에피소드가 있습니다. 올해 초에 구독을 시작했으니 매일 한 시간은 Ruby Rogues를 듣고 있었던 셈이네요. 이젠 호스트인 Chuck Maxwood나 자주 등장한 패널들의 목소리나 웃음소리가 머리 속에서 자동으로 재생이 되는 수준입니다.

무엇보다도 이 팟캐스트를 만들고, 벌써 5년도 넘게 이어나가고 있는 Chuck, 패널들, 게스트들, 그리고 스태프에게 감사의 말씀 드립니다. 정말 이 팟캐스트가 제게 얼마나 도움이 되었는지, 그리고 제가 얼마나 고맙게 느끼는지는 말로 표현하기 힘들 정도입니다.

초보 루비 온 레일즈 개발자가 개발을 하다 보면 쓸데없이 크고 엉망진창인 모델을 만들기 마련입니다. 흔히 하는 실수죠. 저도 마찬가지였습니다. 경험 있는 개발자가 곁에 있어서 그런 실수를 하는 것을 막아줬으면 다행이었겠지만 안타깝게도 제 주변엔 없었습니다. 결국 스스로 그 상황을 해결할 방법을 찾아야 했죠.

해결책을 찾는 과정에서 수많은 블로그 글을 읽으면서 이 문제를 저만 겪고 있는 것이 아니란 사실을 알게 되었습니다. 레일즈 개발자 사이에서는 상당히 흔한 문제로 레일즈가 액티브 레코드 패턴을 사용하는 방식 때문에 발생하는 것이었죠. 검색을 하다보니 레일즈 앱 구조의 역사 비슷한 것도 보이더군요. 컨트롤러가 복잡하던 시대, 모델이 복잡하던 시대, 그리고 요즘은 루비 오브젝트를 사용하는 시대구요. 완전히 다른 해법도 있었습니다. 예를 들어 Ruby Object Mapper나 Hanami 프레임워크는 그냥 액티브 레코드 패턴을 버리고 데이터 매퍼 패턴을 사용해버렸습니다.

같은 실수를 여러 사람이 반복한다면 그건 개발자 개개인의 잘못때문에 발생한 문제가 아닙니다. 레일즈 자체에 사람들이 그런 실수를 반복하도록 오도하는 디자인 문제가 있다는 것이 더욱 타당한 해석이죠. 물론 디자인 문제는 충분히 있을 수 있습니다. 애초에 영원히 완벽한 시스템은 존재할 수가 없으니까요. 그리고 레일즈는 잘못된 부분보다는 잘 된 부분이 훨씬 많은 프레임워크입니다.