tag: 개발 이야기

Hacktoberfest 2018 후기

2018년 11월 14일

지난달 Hacktoberfest 2018이 열린다고 트위터에서 알게 되었다. 이번이 5회차라고 하니 여러 해 있던 행사인데 어떻게 한번도 몰랐나 싶었다. 그동안 몇 달 코드를 작성할 일이 전혀 없어서 나는 정말 개발자인가 😢 싶을 정도였는데 오랜만에 코드를 작성해서 즐거웠다.

PR을 보내며 느낀 점, 더 배우고 싶은 부분을 적어야겠다 생각했었다. 그런데 월 중순부터 여행을 다녀온 이후로 정신이 없어 까맣게 잊고 있었는데 오늘 참여 기념품이 덜컥 도착했다. 더 잊기 전에 짧게라도 작성하려고 한다.

I just got a package from #Hacktoberfest! 😊😊😊

참여 방법은 간단했다. 10월에 GitHub을 통해서 5건의 Pull Request를 보낸다. 물론 몇 가지 품질 표준으로 제시한 내용(빈칸 고치기 같은 것을 스크립트로 돌리지 않는다, 다른 사람의 코드로 PR을 보내지 않는다거나 하는 등)에 맞춰야 했다.

보낸 Pull Requests

원래 hacktoberfest에서 PR을 확인할 수 있었는데 끝나서 그런지 더는 해당 페이지를 제공하지 않는 것 같다. 분명 접근할 수 있을 텐데 주소를 찾지 못하겠다. 대신에 Hacktoberfest Checker에서 보낸 PR을 확인할 수 있다.

geokrety/geokrety-website

"label:hacktoberfest"로 검색하던 중에 찾은 리포지터리다. php로 만든 geocaching 웹사이트인데 php도 할 줄 알고 geocaching도 좋아하는 주제라서 더 살펴보게 되었다. 코드가 엄청 깔끔하진 않지만, 이슈 내용으로는 내가 쉽게 도울 수 있는 부분이라서 코드를 보냈다.

코드 내에서 영어가 아닌 폴란드어를 자주 사용하고 있다는 점이 흥미로웠다. 예를 들면 search.php가 아니라 szukaj.php라는 파일명을 쓰거나 변수명이 name 대신 nazwa를 사용한다. 테이블 이름도 테이블 필드명도 부분마다 그랬다. (그래도 영어와는 다르긴 하지만) 알파벳을 사용하는 국가에서는 큰 어려움 없이 프로그래밍에 사용할 수 있다는 장점이 있었다. 여기서 구글 번역기의 힘이 크게 도움 되었다.

만약 반대 관점에서 한글을 로마자로 작성한 경우라면 어떨까? 가끔 용어 적절성 등의 이유로 한국어를 영어로 옮기지 못하는 경우를 종종 마주하기도 했다. 그렇다고 한글을 직접 사용하지 못하고 로마자 표기법대로 변환해서 사용하게 된다. 한국어를 전혀 모르는 사람이 이런 코드에 기여한다고 상상해보면 전혀 알 수 없는 단어를 번역기에 넣기 전에 일단 로마자-한글 변환을 해야 한다는 점부터 알아야 하는데 그렇게 쉽지는 않다. 이런 생각을 하니 폴란드어가 조금은 부러워졌다.

만약 이런 한글-로마자 변환을 써야 하는 경우라면 CONTRIBUTING.md 같은 곳에 어떻게 변환하고 찾아야 하는지 정리해주면 좋겠다. 별도로 glossary 페이지를 작성하는 것도 공수가 들긴 하겠지만 도움이 될 것 같다.

docker-compose가 들어있긴 했지만, 생각처럼 한 번에 돌지는 않았고 내 환경에 맞춰서 수정해야 했다. 그래도 어디를 보고 수정해야 하는지도 INSTALL.md에 문서화되어 있어서 다행이었다.

프론트 컨트롤러 패턴을 사용하고 있지 않은 php 웹사이트라서 보안도 그렇고 고쳐야 할 부분이 많이 보였다. 일단은 이슈 중심으로 PR을 보냈고 시간대 차이 덕분에 빠르게 피드백을 받을 수 있었다.

totuworld/time-recorder-viewer

어디 기여할 곳 없는가 기웃거리고 있었는데 totu님이 리포지터리 주소를 던져주셨다.

작업시간 기록 도구인 time recorder의 웹 뷰어인데 typescript로 작성하셔서 보는 재미가 있었다. typescript를 프로젝트에서 사용해본 적이 없었는데 express.js에 asp.net mvc처럼 쓰고 있어서 신기했다. react도 그렇고 너무 화려하다! 얼른 부트스트랩 프로젝트로 뜯어서 공개해주셨으면 좋겠다. 😇

어디에 기여해야 하는가 생각하며 코드를 보다가 쓰지 않는 파일이 있길래 파일을 제거하는 PR을 보냈다. 품질 표준 기준에 미치지 않는 것 같아 좀 찔린다. 하하하...

gatsbyjs/gatsby

Gatsby는 React 기반의 사이트 생성기다. 얼마 전에 이 블로그도 Gatsby로 옮겨와서 익숙한 이름이기도 했고, 커뮤니티 분위기라든지 너무 좋은 프로젝트라 뭐라도 기여하고 싶었었다. 문서화도 정말 잘 되어 있어서 환경도 쉽게 구성해 시작할 수 있었다.

단일 리포지터리를 쓰는 프로젝트는 처음 봐서 이걸 여기에 이렇게 보내는 게 맞나 싶었다. 이슈는 온갖 다양한 주제로 가득했고 PR도 어떻게 담당하는 사람을 찾아가는지 대단하다 싶었다. 그래도 모든 창구가 단일화되어 운영되는 것이 오히려 전체적인 흐름을 파악하기도 쉽고 다른 의존적 코드를 참조하거나 찾는 일도 쉬웠다. 처음 리포지터리를 받아서 테스트를 돌리는데 리포지터리 내에 있는 모든 패키지가 교통정리 되면서 모든 테스트가 한꺼번에 진행되는 모습이 인상적이었다. 구조적인 장점 때문인지 몰라도 그동안 봤던 어느 프로젝트보다 많은 CI가 달려 있었다. 코드를 작성하면서 단일 리포지터리의 좋은 점에 언급된 장점 대부분을 몸소 느낄 수 있었다.

Gatsby의 단일 리포지터리는 lerna를 사용해서 운영되고 있다. lerna를 처음 봤을 때는 왜 이런 수고를 하지 싶었는데 실제로 운영되는 모습을 보고 나니 역시 나는 하나도 모르는구나, 탄식했다. 조만간 사용해보고 싶다.

이 블로그에 아직 한국어 포스트만 많은데 영어 포스트도 할 생각으로 영어 포스트와 한국어 포스트의 RSS 피드를 따로 생성하고 있었다. RSS 리더기는 대부분 웹사이트를 등록하면 rss 주소를 찾아내는 auto discovery 기능을 제공한다. 이 과정에서 <link>title을 읽어 해당 피드의 이름으로 사용하는데 gatsby의 gatsby-plugin-feed는 이 필드를 설정하는 부분이 없었다. 그래서 이 부분을 추가해서 코드를 보냈다.

Gatsby에서 gatsby-config.js플러그인을 설정하고 용도에 따라 플러그인 내에 gatsby-*.js를 읽어가는 부분이 흥미로워서 관심 있게 살펴봤다. 플러그인도 그렇고 확장성을 염두에 두고 메시지 기반처럼 작성된 부분이 많았다.

그리고 jest를 테스트에 사용하고 있는데 스냅샷 테스팅이 두루두루 적용되어 있었다. 처음 __snapshots__ 디렉토리를 보고 의아했는데 찾아보고서는 반하지 않을 수 없었다.

참고로 Gatsby는 기여를 하면 Gatsby Store에서 사용할 수 있는 $10 쿠폰을 준다! Hacktoberfest가 시작되기 전에 문서에 있던 잘못된 링크를 고친 적이 있었는데 이때 받은 쿠폰으로 재빠르게 스티커랑 티셔츠를 샀다.

I regret everything

내 웹사이트 니꺼보다 빠름 💜

짧게는 행동으로, 길게는 영향으로

오픈소스 소프트웨어 커뮤니티는 우리 이전의 사람들 덕분에 지금 자리에 있을 수 있습니다. 당신의 참여는 10월(Hacktoberfest) 이후에도 많은 사람과 기술에 지속적인 영향을 줍니다. 이 과정은 경쟁이 아닌 여행입니다.

Hacktoberfest의 가치

몇 안 되는 사소한 코드긴 했지만 hacktoberfest를 기회로 오픈소스에 참여해볼 수 있어서 좋았다. 항상 사용자 입장에 있던 탓인지 언제든 이슈를 열고 PR을 보낼 수 있는 시대가 되었어도 참여는 늘 멀게만 느껴졌다. 겨우 몇 개의 PR을 작성했을 뿐이지만 앞으로는 무슨 코드든 마음 편하게 작성해서 보낼 수 있을 것 같다.

그리고 오픈소스를 프로젝트를 운영하는 방식, 라이브러리와 패키지, 마음 편히 코드를 보낼 수 있도록 돕는 도구가 얼마나 중요한지 또 상기했다. 좋은 방법과 도구는 부지런히 익숙해지도록 써보고 언제든 꺼낼 수 있도록 깊이 있게 배워야겠다.

마지막으로 작은 코드나 문서의 오타를 수정하는 정도지만 오픈소스 세상은 충분히 커서 내 조그마한 기여도 정말 많이 필요로 하는 것 같다. "경쟁이 아닌 여행"이란 부분을 상기한다. 앞으로도 얼마나 많이 기여할 수 있을지 모르겠지만 틈틈이 참여할 수 있으면 좋겠다.

단일 리포지터리의 좋은 점

여러 리포지터리를 운영하는 방법 대신에 단일 리포지터리를 운영할 때 좋은 점, 번역

2018년 11월 6일

지난 달에 있던 Hacktoberfest에 참여하면서 Gatsby에 기여를 하게 되었습니다. 단일 리포지터리로 된 프로젝트는 처음 경험해서 코드가 반영되고 갱신되는 과정이 흥미로웠습니다. 단일 리포지터리를 사용하면 다중 리포지터리에 비해 어떤 장점이 있는지 여러 글을 읽어보게 되었는데 그 중 하나를 번역하게 되었습니다.

이 글은 Dan LuuAdvantages of monorepos 번역입니다.


단일 리포지터리(monorepo)의 좋은 점

다음 같은 대화를 자주 합니다.

누군가: 페이스북/구글에서 거대한 단일 리포지터리를 사용한다는 얘기 들었어? 뭐임 대체!

: 그래, 엄청 편하겠다. 그럴 것 같지 않아?

누군가: 엥 내가 들어본 얘기 중에 가장 황당한 얘기다. 페이스북이나 구글은 단일 리포지터리에 모든 코드를 넣는 게 얼마나 끔찍한 아이디어인지 모르는 건가?

: 내 생각에는 페이스북, 구글에서 일하는 엔지니어도 작은 크기 리포지터리가 익숙할 거야. (Junio Hamano도 구글에서 일하지 않나?) 그리고 여전히 단일 거대 리포지터리를 선호하는데 거기에는 이런 [이유]가 있어.

누군가: 흠, 그래, 꽤 괜찮은 것 같네. 내 생각엔 여전히 이상하긴 하지만 왜 이런 리포지터리를 원하는지도 이해할 수 있을 것 같다.

"[이유]"는 생각보다 꽤 깁니다. 그러니 같은 대화를 계속 반복하는 것보다 글로 작성해서 이유를 설명하려고 합니다.

단순화된 편성

다중 리포지터리를 사용한다면 일반적으로 프로젝트 당 리포지터리가 있거나 연관된 프로젝트를 기준으로 리포지터리가 있을 겁니다. 하지만 "프로젝트"가 무엇인가에 대한 정의는 어떤 팀 또는 회사에 있는가에 따라 달라질 겁니다. 이런 이유로 리포지터리를 합치거나 분리하게 되는데 이런 작업은 순수하게 부가적인 비용이 됩니다. 어떤 경우에 프로젝트를 분리하게 되는지 예를 들면 프로젝트가 너무 큰 경우, 또는 버전 관리 도구의 이력이 너무 많아 최적화가 필요한 경우에 프로젝트를 분리하게 됩니다.

단일 리포지터리를 사용하면 버전 관리 도구가 특정 방식으로 구조를 구성하도록 하는 것이 아니라 논리적으로 가장 일관적인 방법으로 프로젝트를 편성하고 묶을 수 있습니다. 또한 단일 리포지터리를 사용하면 의존성을 관리하는 부하를 줄일 수 있습니다.

편성 단순화의 부수 효과는 프로젝트 간 탐색을 더 쉽게 할 수 있다는 점입니다. 단일 리포지터리를 사용하면 기본적으로 파일 시스템에서 파일을 탐색한다고 말하는 것과 동일하게 모든 프로젝트를 탐색할 수 있습니다. 다중 리포지터리로 구성하면 대부분 두 계층으로 분리된 탐색이 필요합니다. 먼저 프로젝트 안을 탐색할 때는 파일 시스템에서 말하는 탐색이 필요하고, 메타 계층으로서 프로젝트 사이를 찾는 탐색도 필요합니다.

단일 리포지터리를 사용하면 나타나는 이 부수 효과에는 또 부수 효과가 있는데 아주 쉽게 개발 환경을 꾸리고 빌드, 테스트까지 구동할 수 있다는 점입니다. 다른 프로젝트를 탐색하기 위해서 cd를 사용할 수 있고 cd; make로도 당연히 가능하게 됩니다. 이런 구조가 동작하지 않는 것은 당연히 이상하게 보일 정도로 제대로 동작합니다. 동작하기 위해 필요한 어떤 툴링 작업이든 문제없이 완료됩니다.1 물론 기술적으로 다중 리포지터리를 사용하더라도 동일한 작업을 할 수 있지만 자연스럽지는 않습니다. 즉, 생각처럼 동작하지 않을 때가 종종 있다는 의미입니다.

단순화된 의존성

아마 이 사실은 말할 필요도 없겠지만 다중 리포지터리를 사용하면 서로 어떤 버전에 의존하고 있는지 정의하는 방법이 필요할 것입니다. 듣기에는 복잡하지 않은 문제라고 느낄지 몰라도 실무에서는 대부분의 해결책이 성가신 데다 많은 부하가 따릅니다.

단일 리포지터리를 사용하면 모든 프로젝트를 위한 단일 버전을 쉽게 만들 수 있습니다. 여러 프로젝트에 걸쳐서 원자적인 커밋(atomic cross-project commit)이 가능하기 때문에 리포지터리는 언제나 일관적인 상태를 유지할 수 있습니다. 즉, #X 커밋에 모든 프로젝트 빌드가 동작해야 합니다. 빌드 시스템에서는 여전히 의존성을 지정할 필요가 있지만 Makefile이나 bazel BUILD 파일을 사용할 때는 다른 것과 같이 버전 관리 내에서 확인할 수 있습니다. 그리고 단 하나의 버전 번호를 갖게 되는 것으로 Makefile이나 BUILD 파일, 또는 어떤 빌드 방법을 사용하더라도 특정 버전 번호를 지정할 필요가 없게 됩니다.

툴링(Tooling)

탐색과 의존성을 단순하게 하면 도구를 만드는 일도 훨씬 쉬워집니다. 도구를 만들며 각 리포지터리의 관계를 이해하도록 하는 방법 대신에 모든 파일이 리포지터리 내에 들어 있기 때문에 이런 도구는 (리포지터리 내에 의존성을 정의한 몇 파일을 포함해서) 그저 파일을 읽는 일만 하면 됩니다.

이 부분은 사소한 것처럼 느껴질 수 있겠지만 Christopher Van Arsdale의 예에서 빌드가 얼마나 단순하게 가능한지 볼 수 있습니다.

구글 내부의 빌드 시스템은 대형 모듈러 블록 코드를 사용해서 빌드를 환상적으로 쉽게 수행합니다. 크롤러가 필요해요? 여기에 몇 줄 추가합니다. RSS 파서가 필요해요? 몇 줄을 더 추가합니다. 대형 분산, 장애 허용 데이터 저장소? 물론 몇 줄을 더 추가합니다. 이렇게 만들어진 코드 블록과 서비스는 여러 프로젝트에서 공유되며 쉽게 통합할 수 있습니다. … 이처럼 레고(LEGO)처럼 조립 가능한 개발 프로세스는 오픈소스 세계에서 자주 일어나지 않습니다. … 이런 다양한 상태의 결과로 (추측하건대) 오픈소스에 복잡한 장벽이 생겨나고 지난 몇 년간 큰 변화가 없었습니다. 이런 이유에서 구글과 같이 쉽게 관리하는 경우와 그러지 못한 여러 오픈소스 프로젝트의 차이를 만들게 되었습니다.

Arsdale이 편하다고 말한 이 시스템은 오픈소스가 되기 전에 전 구글 엔지니어가 페이스북, 트위터에서도 동일한 혜택을 누리기 위해서 bazel의 자체 버전을 작성했습니다.

이론적으로는 단순히 단일 리포지터리 없이도 모든 의존성을 해결하고 빌드를 수행하는 빌드 시스템을 만들어 낼 수 있습니다. 하지만 더 큰 노력이 필요한 데다 이런 노력에도 불구하고 문제없이 돌아가는 시스템을 본 적이 없습니다. Maven과 sbt는 그런 점에서 꽤 잘 만들어지긴 했지만, 버전 의존성 문제를 추적하고 고치는데 많은 시간을 들이는 것 또한 일반적으로 많이 겪게 됩니다. rbenv나 virtualenv와 같은 시스템은 문제를 우회하려는 노력이지만 개발 환경을 급증하게 하는 결과를 만들었습니다. 단일 리포지터리에서 HEAD는 항상 일관적이고 유효한 버전을 가리키고 있으며 다중 리포지터리의 버전을 추적하는 노력을 완전히 제거하게 됩니다2.

단일 리포지터리를 운영하면서 빌드 시스템에만 이득이 있는 것이 아닙니다. 더 예를 들자면 프로젝트 경계를 넘어서 정적 분석을 수행하는 일에도 추가적인 노력이 필요하지 않습니다. 프로젝트 간의 통합 테스트나 코드 검색과 같이 많은 부분에서도 훨씬 단순해집니다.

프로젝트 간 변경

많은 리포지터리를 갖고 있다면 프로젝트 간 변경은 고통스럽습니다. 일반적으로 각각의 리포지터리를 걸쳐 정합성을 맞추기 위해 어마어마한 양의 수작업이 따르거나 또는 핵과 같은 스크립트를 작성해서 돌려야 합니다. 스크립트가 동작하더라도 프로젝트 간 버전 의존성을 올바르게 고치기 위한 부하도 발생합니다. 10개의 내부 프로젝트에 걸쳐 사용하고 있는 API를 리팩토링한다면 아마 하루종일 시간 쓰기 좋은 분량일 것입니다. 수천 개의 내부 프로젝트에서 사용하고 있는 API를 리팩토링하는 경우라면 꿈도 희망도 없습니다.

단일 리포지터리라면 API와 모든 호출자의 리팩토링은 커밋 하나로 해결할 수 있습니다. 항상 이런 사소한 작업이 있는 것은 아니지만 수많은 작은 리포지터리를 수정하는 방법보다 훨씬 쉽습니다.

대부분은 CVS, RCS, ClearCase와 같은 버전 관리 도구를 사용하는 일이 불합리하다고 생각하고 있습니다. 이런 버전 관리 도구는 여러 파일에 걸친 원자적 커밋을 할 수 없습니다. 그래서 커밋의 타임 스탬프와 커밋 메시지, 또는 "진짜" 원자적으로 커밋된 파일이 어떤 것인지 확인할 수 있는 메타 정보를 확인해야 합니다. SVN, hg, git 등과 같은 도구는 여러 파일 변경도 하나의 커밋에 넣을 수 있기 때문에 이 문제를 해결할 수 있습니다. 단일 리포지터리는 동일한 문제를 여러 프로젝트에 걸쳐 해결할 수 있습니다.

이 접근 방법의 유용성은 단순히 대규모의 API 리펙토링에만 국한되지 않습니다. David Turner는 트위터에서 여러 리포지터리를 단일 리포지터리로 옮기는 작업을 했습니다. 이 작업은 작은 일이지만 여러 프로젝트에 걸친 변경과 이 변경을 배포하는 과정에서 어떤 부하가 발생하는지 이야기합니다.

[프로젝트 A]를 갱신해야 합니다. 하지만 이 작업을 위해서는 내 동료가 이 프로젝트의 의존성인 [프로젝트 B]에서 고친 코드가 필요합니다. 이 동료는 [프로젝트 C]에서 변경된 내용이 필요합니다. 만약 A를 고쳐서 배포하려 한다고 해도 C의 배포를 기다려야 하고 B 배포도 기다려야 하는 상황입니다. 하지만 모든 것이 하나의 리포지터리에 있다면 내 동료가 코드를 변경해서 커밋 하자마자 내 코드 변경도 즉시 가능합니다.

물론 git 버전에 의해 모든 것이 연결되어 있다면 다중 리포지터리에서도 가능할 겁니다. 하지만 내 동료는 두 개의 커밋이 필요할지도 모릅니다. 이런 작업에는 버전을 하나 집어서 "안정화" (더 움직이지 않도록) 하고 싶은 욕망이 항상 생깁니다. 하나의 프로젝트라면 문제가 없겠지만 상호의존적인 복잡한 프로젝트에서는 이조차도 그다지 쉽지 않은 방법입니다.

[다른 방향에서 본다면] 의존하는 부분 이 강제로 갱신돼야 하는 상황인데 이 또한 단일 리포지터리의 장점이라고 할 수 있습니다.

이 접근 방법은 단순히 프로젝트 간 변경을 쉽게 수행할 수 있는 것만 아니라 변경을 추적하는 일도 쉽게 만듭니다. git bisect을 여러 리포지터리에서 수행한다면 분명 다른 도구를 이용해서 메타 정보를 읽는 방법을 배워야 할 것이고 대부분 프로젝트에서는 그냥 간단하게 이런 작업을 하지 않아버리고 맙니다. 만약 이런 일을 한다고 해도 하나의 도구만 써도 충분한 작업을 여러 도구에 걸쳐서 하게 될 겁니다.

Mercurial과 git은 멋집니다! 실화입니다

CVS 또는 SVN에서 git 또는 hg로 변경한 경우에 가장 일반적으로 들을 수 있는 이야기는 엄청나게 생산성이 좋아졌다는 얘기입니다. 이 점은 사실입니다. 하지만 대부분 이런 응답의 관점은 git과 hg가 더 발달한 여러 측면(예를 들면 더 나은 코드 머지를 지원한다던가)이 그 이유였지 작은 리포지터리가 더 낫기 때문인 것은 아니었습니다.

사실 트위터는 git을, 페이스북은 Mercurial을 대형 단일 리포지터리를 지원하기 위해 고쳐서 사용하고 있습니다.

단점

물론 단일 리포지터리에도 단점이 있습니다. 여기서는 단점을 적지 않을 생각인데 이미 충분히 많은 논의가 있었기 때문입니다. 단일 리포지터리는 다중 리포지터리에 비해 엄격하게 우월한 지위를 갖는 것은 아닙니다. 그렇다고 엄격하게 나쁜 것도 아닙니다. 제 관점에서는 누구든 꼭 단일 리포지터리로 옮겨야 한다고 얘기하지 않습니다. 단지 단일 리포지터리를 쓰는 일이 완전히 부당하지 않다는 얘기를 하고 싶었습니다. 구글, 페이스북, 트위터, 디지털오션과 엣시(Etsy)에서 수백, 수천, 수만 개의 작은 리포지터리를 운영하는 대신 단일 리포지터리 사용을 선호하는 점에는 분명 좋은 이유가 있어서 그럴 겁니다.

다른 논의

광범위한 토론에 함께 한 Kamal Marhubi, David Turner와 Leah Hanson에게 감사 말씀 전합니다. 이 토론에서 적어도 절반 이상의 아이디어가 나왔습니다. 또한 이 글에서 오타와 실수를 찾아 준 Leah Hanson, Mindy Preston, Chris Ball, Daniel Espeset, Joe Wilder, Nicolas Grilly, Giovanni Gherdovich, Paul Hammant, Simon Thulbourn에게 감사드립니다.


  1. 이 부분은 제가 일했던 하드웨어 회사에서도 맞는 말입니다. 저는 이 회사에서 NFS에서 동작하는 RCS를 버저닝하는 단일 리포지터리를 만들어서 사용했습니다. 물론 사람들이 중앙 리포지터리에서 파일을 수정할 수 있게 할 수 없으니 억지로 이 작업을 가능하게 누군가가 여러 스크립트를 작성했습니다. 이런 시스템을 추천하진 않습니다만 엄청나게 단일 리포지터리처럼 해킹해서 쓰더라도 단일 리포지터리의 장점을 누릴 수 있습니다.
  2. 적어도 최신 의존성을 관리하는 메커니즘이 있어야 할 것입니다. 물론 이런 작업은 구글에서 문제가 없는데 구글은 코드를 작성해도 많은 수의 직원이 그 코드에 의존하기 때문에 모든 외부 의존성을 단일 리포지터리에 넣어도 전체 직원 규모에서 보면 오히려 비용이 절감되기 때문입니다. 제가 보기에 작은 회사에서 이런 접근 방법에 이득을 얻기에는 너무 비용이 많이 든다고 생각합니다.

React에서 Redux 전에 배워야 할 8가지

React에 Redux (또는 MobX)를 사용하기 전에 알아야 할 사실들, 번역

2018년 11월 4일

이 글은 Robin Wieruch8 things to learn in React before using Redux 번역입니다.


React에서 Redux 전에 배워야 할 8가지

상태 관리(State management)는 어렵습니다. React같은 뷰 라이브러리는 지역 컴포넌트 상태를 관리하는 일이 가능합니다. 하지만 이 상태는 특정 시점에서 확장해야 하는 일이 생깁니다. 리액트는 단순히 뷰 계층 라이브러리 입니다. 언젠가는 Redux와 같이 더 수준 높은 상태 관리 솔루션으로 넘어가는 결정을 하게 될 겁니다. 하지만 이 글에서는 Redux 열차에 올라타기 전에 React에서 알아야 하는 부분에 대해서 지적하고 싶습니다.

사람들은 간혹 React와 Redux를 함께 배웁니다. 하지만 거기에 문제점이 있습니다.

  • 지역 상태 (this.state)만 사용하는 경우에 왜 상태 관리에 확장 문제가 발생하는지 겪어보지 못합니다
    • 그래서 왜 Redux 같은 상태 관리 라이브러리가 필요한지 이해하지 못합니다
    • 그래서 너무 많은 보일러플레이트에 대해 불평합니다
  • React에서 지역 상태를 관리하는 방법을 배우지 못합니다
    • 그래서 모든 상태를 Redux에서 제공하는 상태 컨테이너에 담아두고 관리하려고 합니다
    • 그래서 지역 상태 관리를 전혀 사용하지 않게 됩니다

이런 문제점으로 인해서 React를 먼저 배우고 나중에 필요하다고 느낄 때 Redux를 배우도록 조언합니다. 확장 문제는 대형 애플리케이션에서만 나타납니다. 가끔 Redux를 사용하고 있으면서도 상태 관리 라이브러리가 필요하지 않은 경우가 있습니다. 책 The Road to learn React에서는 Redux와 같은 외부 의존성 없이 있는 그대로의 React로 애플리케이션을 만드는 방법을 설명합니다.

하지만 당신은 지금 Redux 열차에 올라타기로 결정했습니다. 그래서 이 글에서는 Redux를 쓰기 전에 React에서 알아야 할 내용을 살펴봅니다.

  • React에서의 지역 상태는 자연스럽다
  • React 함수형 지역 상태
  • React의 상태와 프로퍼티
  • React 상태 옮기기
  • React의 고차 컴포넌트
  • React의 Context API
  • React의 상태 컴포넌트
  • 컨테이너와 프레젠터 패턴
  • MobX 아니면 Redux?

React에서의 지역 상태는 자연스럽다

이미 언급했지만 가장 중요한 조언은 React를 먼저 학습하라는 점입니다. 컴포넌트에 지역 상태 즉, this.setState()this.state를 사용해서 생명을 불어 넣는 일을 피할 수는 없습니다. 이 방식에 익숙해져야 합니다.

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { counter: 0 };
  }

  render() {
    return (
      <div>
        Counter: {this.state.counter}

        <button
          type="button"
          onClick={() => this.setState({ counter: this.state.counter + 1 })}>
          Click!
        </button>
      </div>
    );
  }
}

React 컴포넌트는 초기 상태를 생성자(constructor)에서 정의하고 있습니다. 그런 후에 this.setState() 메소드를 사용해서 갱신할 수 있습니다. 상태 객체의 갱신은 얕은 병합(shallow merge)으로 수행됩니다. 그러므로 지역 상태 객체를 부분적으로 갱신하고도 상태 객체의 다른 프로퍼티는 손대지 않고 그대로 유지할 수 있습니다. 상태가 갱신된 후에는 컴포넌트가 다시 렌더링을 수행합니다. 앞에서 예로 든 코드에서는 this.state.counter의 갱신된 값을 보여줄 것입니다. 이 예제에서는 React의 단방향 데이터 흐름을 사용해 하나의 닫힌 루프(loop)를 작성했습니다.

React 함수형 지역 상태

this.setState() 메소드는 지역 상태를 비동기적으로 갱신합니다. 그러므로 언제 상태가 갱신되는지에 대해 의존해서는 안됩니다. 상태 갱신은 결과적으로 나타납니다. 대부분의 경우에는 이런 방식이 별 문제 없습니다.

하지만 컴포넌트의 다음 상태를 위해 연산을 하는데 현재 지역 상태에 의존한다고 가정해봅시다. 앞서 작성했던 예제에서는 다음처럼 작성했습니다.

this.setState({ counter: this.state.counter + 1 });

지역 상태(this.state.counter)는 연산에서 바로 그 시점의 상태로 사용했습니다. 그러므로 this.setState()를 사용해서 상태를 갱신하긴 했지만 지역 상태는 비동기 실행이 수행되기 전에 신선하지 않은 상태값을 사용해 연산하게 됩니다. 이런 점은 처음 보고 나서는 바로 파악하기 어렵습니다. 천 마디 말 보다 다음 코드를 보는게 더 빠를 것 같습니다.

this.setState({ counter: this.state.counter + 1 }); // this.state: { counter: 0 }
this.setState({ counter: this.state.counter + 1 }); // this.state: { counter: 0 }
this.setState({ counter: this.state.counter + 1 }); // this.state: { counter: 0 }

// 예상한 상태: { counter: 3 }
// 실제 갱신된 상태: { counter: 1 }

이 코드에서 확인할 수 있는 것처럼 지역 상태를 갱신할 때 현재 상태에 의존해서는 안됩니다. 이런 접근 방식은 버그를 만듭니다. 그래서 이런 상황에서는 다음과 같은 방식으로 지역 상태를 갱신합니다.

this.setState()에는 객체 대신 함수도 사용할 수 있습니다. 함수는 비동기적으로 this.setState()가 실행될 때, 함수 시그니처에 지역 상태를 전달합니다. 그래서 이 함수는 콜백 함수로 정확한 시점에 올바른 상태를 갖고 실행되기 때문에 문제 없이 사용할 수 있게 됩니다.

this.setState(previousState => ({ counter: previousState.counter + 1 }));

이 방법으로 this.setState()를 여전히 이용하면서도 객체 대신 함수를 사용해서 이전 상태를 활용할 수 있습니다.

추가적으로 프로퍼티(props)에 의존적인 갱신이 필요한 경우에도 이 접근 방식을 따라야 합니다. 비동기적 실행이 수행되기 이전에 부모 컴포넌트에서 받은 프로퍼티가 변경되어서 값이 이전 정보가 되는 경우가 있기 때문입니다. 그래서 this.setState()의 두 번째 인자로 프로퍼티가 전달됩니다.

this.setState((prevState, props) => ...);

이제 올바른 상태와 프로퍼티를 사용해서 상태를 갱신할 수 있게 됩니다.

this.setState((prevState, props) => ({ counter: prevState.counter + props.addition }));

객체 대신에 함수를 사용하면서 얻을 수 있는 또 다른 장점은 바로 상태를 갱신하는 방법을 격리된 상태에서 테스트 해볼 수 있다는 점입니다. 단순히 this.setState(fn)을 사용하는 함수를 추출한 다음에 독립적으로 둔 다음에 테스트가 가능하도록 작성할 수 있습니다. 이 함수는 입력으로 간단히 출력을 확인할 수 있는 순수 함수여야 합니다.

React의 상태와 프로퍼티

상태는 컴포넌트 안에서 관리됩니다. 이 상태는 다른 컴포넌트에 프로퍼티로 내려줄 수 있습니다. 이 컴포넌트는 프로퍼티를 사용하거나 더 깊히 자식 컴포넌트로 전달할 수 있습니다. 덧붙여 자식 컴포넌트는 부모 컴포넌트로부터 콜백 함수를 전달 받을 수 있습니다. 이렇게 전달 받은 함수를 사용하면 부모 컴포넌트의 지역 상태를 변경하는 일도 가능합니다. 기본적으로 프로퍼티는 컴포넌트 트리를 타고 내려갑니다. 상태는 하나의 컴포넌트에서 관리합니다. 하위 컴포넌트에서는 프로퍼티로 전달한 함수를 사용해서 상태를 관리하는 컴포넌트까지 거슬러 올라와 상태를 변경할 수 있습니다. 갱신된 상태는 프로퍼티로 다시 하위 컴포넌트로 전달됩니다.

컴포넌트는 전체적인 상태를 관리할 수 있으며 자식 컴포넌트에게 프로퍼티를 전달할 수 있습니다. 프로퍼티에 함수를 전달하는 방법으로 자식 컴폰넌트가 부모 컴포넌트의 상태를 변경할 수 있게 합니다.

하지만 자식 컴포넌트는 전달된 함수의 출처가 어디인지, 프로퍼티로 받은 함수가 어떤 동작을 하는지 알지 못합니다. 이 함수는 부모 컴포넌트의 상태를 변경할 수도 있지만 다른 일을 할 가능성도 있습니다. 자식 컴포넌트는 단순히 실행하는 역할을 합니다. 프로퍼티도 동일합니다. 컴포넌트는 받은 프로퍼티가 프로퍼티인지, 상태인지, 또는 부모 컴포넌트에서 파생된 프로퍼티인지 알 방법이 없습니다. 자식 컴포넌트는 그저 사용할 뿐입니다.

프로퍼티와 상태의 개념을 이해하는 일은 중요합니다. 컴포넌트 트리에서 사용하는 모든 속성은 프로퍼티와 상태로 (그리고 프로퍼티와 상태에서 파생된 속성으로) 나눌 수 있습니다. 무엇이든 상호작용이 필요한 경우에는 상태에 보관되어야 합니다. 그 외 나머지는 모두 프로퍼티 형식으로 전달합니다.

수준 높은 상태 관리 라이브러리를 사용하기 전에 컴포넌트 트리를 따라 프로퍼티를 보내본 적이 있어야 합니다. 가장 끝에 있는 자식 컴포넌트에서 특정 값을 사용하려고 중간 컴포넌트에서는 전혀 쓰지 않는, 수많은 프로퍼티를 전달하는 코드를 작성하면서 "분명 이보다 더 나은 방법이 있을 거야" 생각해본 적이 었어야 합니다.

React 상태 옮기기

이미 지역 상태 계층(local state layer)을 옮겼나요? 이 방식은 일반 React에서 지역 상태 관리를 확장하는데 가장 중요한 전략입니다. 상태 계층은 올릴 수도, 내릴 수도 있습니다.

다른 컴포넌트에서의 접근을 줄이기 위해 지역 상태 계층을 하위로 내릴 수 있습니다. 컴포넌트 A가 자식 컴포넌트로 B와 C를 갖고 있다고 상상해봅시다. B와 C는 A의 자식 컴포넌트로 동등합니다. 컴포넌트 A는 유일하게 지역 상태를 관리하며 자식 컴포넌트에 프로퍼티를 전달합니다. 덧붙여 B와 C에서 A의 상태를 변경할 수 있는 함수도 전달합니다.

          +----------------+
          |                |
          |       A        |
          |                |
          |    Stateful    |
          |                |
          +--------+-------+
                   |
         +---------+-----------+
         |                     |
         |                     |
+--------+-------+    +--------+-------+
|                |    |                |
|                |    |                |
|       B        |    |        C       |
|                |    |                |
|                |    |                |
+----------------+    +----------------+

이제 컴포넌트 A의 지역 상태 절반은 컴포넌트 C에서 프로퍼티를 통해 쓰고 있으며 컴포넌트 B에서는 전혀 사용하고 있지 않습니다. 게다가 C는 A 컴포넌트에서 C에서만 사용하는 상태만 제어할 수 있는 함수를 프로퍼티로 전달했습니다. 여기서 볼 수 있는 것처럼 컴포넌트 A는 컴포넌트 C를 대신해서 상태를 관리하고 있습니다. 대부분의 경우에는 한 컴포넌트가 자식 컴포넌트의 모든 상태를 관리하는 일에 큰 문제가 없습니다. 하지만 컴포넌트 A와 컴포넌트 C 사이에 다른 컴포넌트가 추가된다고 생각해봅시다. 컴포넌트 A에서 컴포넌트 C에 전달해야 하는 프로퍼티를 컴포넌트 트리에 따라 전달합니다. 컴포넌트 A는 여전히 컴포넌트 C의 상태를 관리하고 있습니다.

          +----------------+
          |                |
          |       A        |
          |                |
          |                |
          |    Stateful    |
          +--------+-------+
                   |
         +---------+-----------+
         |                     |
         |                     |
+--------+-------+    +--------+-------+
|                |    |                |
|                |    |        +       |
|       B        |    |        |Props  |
|                |    |        v       |
|                |    |                |
+----------------+    +--------+-------+
                               |
                      +--------+-------+
                      |                |
                      |        +       |
                      |        |Props  |
                      |        v       |
                      |                |
                      +--------+-------+
                               |
                      +--------+-------+
                      |                |
                      |                |
                      |        C       |
                      |                |
                      |                |
                      +----------------+

이런 경우가 React의 상태를 아래로 내려야 하는 완벽한 경우입니다. 컴포넌트 A는 컴포넌트 C의 상태를 관리하고 있지만 이 상태 일부는 컴포넌트 C가 스스로 관리해도 문제가 없습니다. 즉, 각각의 상태에 대해 각 컴포넌트가 자율적으로 움직일 수 있습니다. 지역 상태 관리를 컴포넌트 C로 옮기면 더이상 컴포넌트 트리를 따라 프로퍼티를 전달하지 않아도 됩니다.

          +----------------+
          |                |
          |       A        |
          |                |
          |                |
          |    Stateful    |
          +--------+-------+
                   |
         +---------+-----------+
         |                     |
         |                     |
+--------+-------+    +--------+-------+
|                |    |                |
|                |    |                |
|       B        |    |                |
|                |    |                |
|                |    |                |
+----------------+    +--------+-------+
                               |
                      +--------+-------+
                      |                |
                      |                |
                      |                |
                      |                |
                      |                |
                      +--------+-------+
                               |
                      +--------+-------+
                      |                |
                      |                |
                      |        C       |
                      |                |
                      |     Stateful   |
                      +----------------+

컴포넌트 A의 상태도 덩달아 깔끔해졌습니다. 이 컴포넌트는 필요에 따라 자신의 상태와 가장 가까운 자식 컴포넌트의 상태만 관리하게 됩니다.

React에서 상태 옮기기는 다른 방향, 즉 상태 위로 옮기기도 가능합니다. 부모 컴포넌트인 컴포넌트 A와 자식 컴포넌트인 컴포넌트 B, C로 다시 돌아와서 살펴봅니다. A, B, C 사이에 얼마나 많은 컴포넌트가 있는지 상관 없습니다. 하지만 이번에는 컴포넌트 C가 이미 자신의 상태를 관리하고 있습니다.

          +----------------+
          |                |
          |       A        |
          |                |
          |                |
          |    Stateful    |
          +--------+-------+
                   |
         +---------+-----------+
         |                     |
         |                     |
+--------+-------+    +--------+-------+
|                |    |                |
|                |    |                |
|       B        |    |                |
|                |    |                |
|                |    |                |
+----------------+    +--------+-------+
                               |
                      +--------+-------+
                      |                |
                      |                |
                      |        C       |
                      |                |
                      |    Stateful    |
                      +----------------+

만약 컴포넌트 B가 C에서 관리하는 상태가 필요하다면 어떻게 해야 할까요? 이 상황에서는 공유할 수 없습니다. 상태는 프로퍼티 형태로 아래로만 넘겨줄 수 있기 때문인데요. 이런 이유에서 상태 계층을 위로 이동시킬 필요가 있습니다. 컴포넌트 C의 상태를 컴포넌트 B와 C가 공통으로 갖는 부모 컴포넌트의 위치로 올릴 수 있습니다. (여기서는 A가 해당되겠군요.) 만약 C가 관리하는 상태를 B에서 필요로 한다면 C는 상태 없는 컴포넌트가 됩니다. 상태는 A에서 관리되며 B와 C에 공유됩니다.

          +----------------+
          |                |
          |       A        |
          |                |
          |                |
          |    Stateful    |
          +--------+-------+
                   |
         +---------+-----------+
         |                     |
         |                     |
+--------+-------+    +--------+-------+
|                |    |                |
|                |    |        +       |
|       B        |    |        |Props  |
|                |    |        v       |
|                |    |                |
+----------------+    +--------+-------+
                               |
                      +--------+-------+
                      |                |
                      |                |
                      |        C       |
                      |                |
                      |                |
                      +----------------+

상태를 위로, 또는 아래로 옮기는 전략에서 단순 React를 사용할 때는 어떻게 상태 관리를 확장하는지 배울 수 있습니다. 더 많은 컴포넌트가 특정 상태에 관심을 가져야 하는 경우에은 상태에 접근해야 하는 컴포넌트 간의 공통 부모 컴포넌트까지 거슬러 올라가 상태를 둬야 합니다. 덧붙여 지역 상태 관리에서 충분히 관리할 수 있다면 컴포넌트는 필요한 만큼 상태를 관리하고 있기 때문입니다. 만약 컴포넌트 자체나 자식 컴포넌트에서 사용하지 않는 상태가 있다면 그 상태는 상태가 필요한 컴포넌트의 위치로 이동해야 합니다.

React의 상태 들어 올리기는 공식 문서에서 더 자세히 살펴볼 수 있습니다.

React의 고차 컴포넌트

고차 컴포넌트 (Higher order components, HOCs)는 React의 고급 패턴입니다. 이 패턴은 추상적인 기능이 필요할 때 사용할 수 있으며 여러 컴포넌트에서 선택적으로 기능이 필요할 때 활용할 수 있습니다. 고차 컴포넌트는 컴포넌트를 받아서 선택적 설정을 입력으로 받아 강화된 버전의 컴포넌트를 반환합니다. 이 기능은 JavaScript의 고차 함수 원칙인 함수를 반환하는 함수처럼 구현되었습니다.

만약 고차 컴포넌트가 익숙하지 않다면 React의 고차 컴포넌트 안내를 읽어보길 추천합니다. 이 글은 React의 고차 컴포넌트를 React의 조건부 렌더링의 용례와 함께 설명합니다.

고차 컴포넌트는 뒤에서 더 중요해지는데 Redux와 같은 라이브러리를 사용하게 되면 마주하게 되기 때문입니다. Redux 같은 라이브러리는 React의 뷰 계층(view layer)와 라이브러리의 상태 관리 계층과 "연결"하게 되며 이 과정에서 고차 컴포넌트를 사용해 처리하게 됩니다. (고차 컴포넌트로 이뤄지는 연결은 react-redux를 사용합니다.)

MobX와 같은 다른 상태 관리 라이브러리도 동일한 방식으로 적용합니다. 고차 컴포넌트는 라이브러리에서 제공하는 상태 관리 계층과 React의 뷰 계층을 붙이는데 사용합니다.

React의 Context API

React의 context API는 드물게 사용됩니다. 이 API를 사용하라 충고하지 않는 편인데 이 API는 안정적이지 않고 애플리케이션의 묵시적 복잡도(implicit complexity)를 높이기 때문입니다. 하지만 어떤 기능을 하는지 들어보면 왜 이런 기능이 있는지 충분히 이해할 수 있을 겁니다.

왜 이 기능을 알아야 할까요? React의 context는 컴포넌트 트리에서 속성을 묵시적으로 전달할 때 사용됩니다. 부모 컴포넌트에서 속성을 context로 선언하면 컴포넌트 트리 아래에 있는 자식 컴포넌트에서 활용할 수 있습니다. 명시적으로 각각의 컴포넌트 계층에 일일이 전달할 필요 없이 단순히 부모-자식 관계라면 부모 컴포넌트가 생성한 context를 자식 컴포넌트가 집어 사용할 수 있습니다. 모든 컴포넌트 트리에 걸쳐 언제든 꺼내서 쓸 수 있는, 보이지 않는 컨테이너가 존재합니다. 이 컨테이너 덕분에 컴포넌트에서 필요하지 않는 프로퍼티는 접근할 일이 없어지기 때문에 React에서 "프로퍼티 내려꽂기(props drilling)"라고 하는 일을 피할 수 있게 됩니다. 다시 원래 주제로 돌아와서 왜 이런 API를 알아야 할까요?

Redux나 MobX와 같은 세련된 상태 관리 라이브러리를 사용하다보면 어떤 시점에서 상태 관리 계층을 React 뷰 계층에 붙여야 하는 상황이 생깁니다. React의 고차 컴포넌트를 언급한 이유가 여기에 있습니다. 이 붙이는 과정을 통해 상태에 접근하고 수정할 수 있게 됩니다. 상태 자체는 일종의 상태 컨테이너 안에서 관리됩니다.

하지만 어떻게 모든 컴포넌트에서 이 상태 컨테이너에 접근할 수 있도록 붙일 수 있을까요? 이런 상황에서 React의 context를 사용할 수 있습니다. 최상위 컴포넌트 즉, React의 루트 컴포넌트(root component)에서 상태 컨테이너를 context로 지정합니다. 그래서 컴포넌트 트리에 있는 모든 컴포넌트에 명시적으로 전달하지 않으면서도 모두 접근할 수 있게 됩니다. 이 모든 과정은 React의 프로바이더 패턴으로 적용할 수 있습니다.

물론 이런 방식을 사용한다는 게 Redux 같은 라이브러리를 사용할 때마다 React의 context를 직접 제어해야 할 필요가 있다는 의미는 아닙니다. 이런 라이브러리는 이미 모든 컴포넌트에서 상태 컨테이너에 접근 가능하도록 모든 기능이 함께 제공되고 있습니다. 하지만 이 기능이 보이지 않는 곳에서 어떤 방식으로 동작하고 있는지 이해하게 된다면 여러 컴포넌트에서 상태를 제어하면서 도대체 이 상태 컨테이너는 어디서 오는 것일까 걱정할 필요도 없어지게 됩니다.

React의 상태 컴포넌트

React는 두 종류의 컴포넌트 선언이 존재합니다. ES6 클래스 컴포넌트와 함수형 상태 없는 컴포넌트(functional stateless component)입니다. 함수형 상태 없는 컴포넌트는 props를 인자로 받고 JSX를 반환하는 단순한 함수입니다. 이 함수는 어떤 상태도 갖지 않으며 React의 생애주기(lifecycle) 메소드에도 접근하지 않습니다. 이 컴포넌트는 이름 붙여진 그대로 상태가 없습니다.

function Counter({ counter }) {
  return (
    <div>
      {counter}
    </div>
  );
}

반면, ES6 클래스 컴포넌트는 지역 상태와 생애주기 메소드를 사용할 수 있습니다. 이 컴포넌트는 this.statethis.setState() 메소드에 접근 가능합니다. ES6 클래스 컴포넌트는 상태 컴포넌트로 사용할 수 있다는 의미입니다. 물론 이 컴포넌트가 꼭 지역 상태를 사용해야 한다는 뜻은 아니며 상태 없는 컴포넌트로도 작성할 수 있습니다. 일반적으로 상태가 없는 ES6 클래스 컴포넌트라면 생애주기 메소드를 사용하기 위해 클래스 형태로 작성한 경우입니다.

class FocusedInputField extends React.Component {
  constructor(props) {
    super(props);
  }

  componentDidMount() {
    this.input.focus();
  }

  render() {
    return (
      <input
        type="text"
        value={this.props.value}
        ref={node => this.input = node}
        onChange={event => this.props.onChange(event.target.value)}
      />
    );
  }
}

결론적으로 ES6 클래스 컴포넌트만 상태를 가질 수도 가지지 않을 수도 있습니다. 함수형 상태 없는 컴포넌트는 항상 상태가 없습니다.

덧붙여 고차 컴포넌트도 React 컴포넌트에 상태를 덧붙일 수 있습니다. 상태를 관리하기 위해 직접 고차 컴포넌트를 만들거나 recompose와 같은 라이브러리에서 제공하는 withState 고차 컴포넌트를 사용하는 것도 가능합니다.

import { withState } from `recompose`;

const enhance = withState('counter', 'setCounter', 0);

const Counter = enhance(({ counter, setCounter }) =>
  <div>
    Count: {counter}
    <button onClick={() => setCounter(n => n + 1)}>Increment</button>
    <button onClick={() => setCounter(n => n - 1)}>Decrement</button>
  </div>
);

고차 컴포넌트를 사용하면 어떤 컴포넌트에든 지역 상태를 추가할 수 있습니다.

컨테이너와 프레젠터 패턴

컨테이너와 프레젠터 패턴은 Dan Abramov의 블로그 포스트 이후 유명해졌습니다. 이 패턴에 익숙하지 않다면 지금이 살펴 볼 차례입니다. 컴포넌트를 컨테이너와 프레젠터로 구분합니다. 컨테이너 컴포넌트는 어떻게 동작하는가를, 프레젠터 컴포넌트는 어떻게 보이는가를 정의합니다. 컨테이너 컴포넌트는 ES6 클래스 컴포넌트로 구현되어 지역 상태를 관리합니다. 프레젠터 컴포넌트는 함수형 상태 없는 컴포넌트로 작성하여 프로퍼티로 받은 내용을 표현하고 부모 컴포넌트로부터 받은 함수 몇 가지를 실행하는 역할을 합니다.

Redux로 뛰어들기 전에 이 패턴 뒤에 있는 원칙을 이해할 필요가 있습니다. 상태 관리 라이브러리는 컴포넌트를 상태와 "연결"해줍니다. 상태 관리 계층과 연결된 컴포넌트를 **연결된 컴포넌트(connected component)**라는 용어로 부르기도 합니다. 이 컴포넌트는 어떻게 보이는가는 신경쓰지 않지만 어떻게 동작하는가에 집중하게 됩니다. 이런 컴포넌트가 바로 컨테이너 컴포넌트의 역할을 합니다.

MobX 아니면 Redux?

모든 상태 관리 라이브러리를 통틀어 Redux가 가장 유명하고 MobX는 살펴 볼 가치 있는 대안입니다. 두 라이브러리는 다른 철학과 프로그래밍 패러다임을 따라가고 있습니다.

둘 라이브러리 중 하나로 고르기 전에 이 글에서 설명한 내용에 대해 이해하고 있어야 합니다. 기본 React의 상태 관리를 확장하기 위해 다른 개념을 적용할 정도로 지역 상태 관리에 익숙해야 합니다. 미래에 규모가 커질 애플리케이션을 염두해서 상태 관리도 확장해야 한다는 점을 기억합시다. 상태 관리 위치를 변경하거나 React의 프로바이더 패턴을 활용해 context를 사용하는 것으로 이미 어느 정도 문제를 해결할 수 있어야 합니다.

Redux나 MobX를 사용하기로 결정했다면 Redux 또는 MobX: 혼란을 해결하려는 시도에서 더 심층적으로 다루고 있으니 읽어보기 바랍니다. 두 라이브러리를 비교하고 어떻게 적용할지 설명하고 있습니다. 아니면 React + Redux 학습 팁으로 바로 Redux를 시작할 수 있습니다.

이 글이 상태 관리 라이브러리를 사용하기 전에 어떤 역할을 하는지 이해하는데 도움이 되었으면 좋겠습니다. Redux와 MobX에 대해 더 궁금하다면 전자책/코스인 Taming the State in React를 확인해보세요.


2018-11-24: Rinae님의 피드백으로 프로퍼티 구멍내기를 프로퍼티 내려꽂기로 수정했습니다. 피드백 감사드립니다.

블로그 업데이트

wordpress에서 gatsby로 옮긴 과정 정리

2018년 10월 11일

wordpress를 사용해서 운영하고 있던 블로그를 gatsby 기반으로 전환했다. 전환하는 과정에서 고려한 부분과 생각한 점을 정리하려고 한다.

전환 이전의 상황

그동안 wordpress를 직접 호스팅해서 사용하고 있었는데 매월 digitalocean에 비용을 내고 있는게 조금 아까웠다. 예전에는 블로그 외에도 이것 저것 올렸던 사이트가 있어서 크게 고민이 없었지만 이제는 다 정리되고 블로그만 남아 있었다. 게다가 거의 방치되다시피 하다보니 보안 문제도 계속 신경이 쓰일 수 밖에 없었다. wordpress를 실무에서 더이상 사용하고 있지 않아서 무슨 문제가 생기더라도 예전만큼 빠르게 알고서 대응할 수 없을 거란 생각도 들었다.

이런 이유에서 정적 사이트 생성기로 전환할 생각은 오래 전부터 했었다. 비용도 거의 무료인 데다 보안에도 크게 걱정할 필요가 없었다. 하지만 실천으로 옮기기 쉽지 않았다. 전적으로 마음에 드는 도구도 찾기 힘들었다. 블로그에 촛점을 맞춘 도구가 대부분이라 유연함이 상대적으로 부족했다. 또한 데이터 마이그레이션에 대한 두려움이 있었다. 모든 자료를 문제 없이 옮기더라도 문제가 있는지 없는지 검증할 필요가 있었다. 자동으로 추출하는 도구를 사용하더라도 분명 손이 가는 부분이 있을 것 같았다.

그리고 wordpress는 최고다. 그저 클릭 몇 번으로 새로운 기능을 쉽게 설치할 수 있고 테마도 손쉽게 바꿀 수 있는 데다 웹엔드에 앱도 제공한다. wordpress에서 벗어나고 싶어도 게으름이 내 발목을 꼭 잡고 놓아주질 않았다! 그래서 매번 "바꿀까?" 생각이 들 때마다 얼마 후에 "굳이 그래야 할까?"로 자연스럽게 의식의 변화가 생겼다.

I regret everything
모든 걸 후회합니다ㅏㅏ

쉬고 있는 동안 글은 안쓰는데 비용 나가는 것이 눈에 보이니 지금이라도 서둘러 옮겨야겠구나 하고 도구부터 찾았다.

도구 찾기

맨 처음엔 nextjs를 사용하려고 했었는데 생각보다 구현이 단순해서 직접 만져야 하는 부분이 많았다. 특히 파일 구조가 아닌 내가 원하는 url 구조를 넣으려니 생각보다 시간이 걸렸다. 한 3일 정도 만졌는데 뭔가 알 수 없는 404 오류가 계속 콘솔에 찍혀서 시간을 허비하고 있었다. 그러던 중 gatsby가 생각나서 튜토리얼만 봐야지 했는데 직접 만들려고 했던 기능들이 이미 다 훨씬 멋지게 제공되고 있었다.

특히 graphql로 쉽게 filesystem도 불러오고 사용할 수 있도록 구현되어 있고 url 구조도 내가 원하는 대로 생성할 수 있다는 점에 바로 마음을 돌렸다.

개발 과정

데이터 추출하기

Gatsby는 마크다운으로 작성되기만 하면 활용에 큰 문제가 없도록 구현되어 있어서 특히 편리했다. 그래서 hugo용이더라도 상관이 없어서 wordpress-to-hugo-exporter 플러그인을 사용해 추출했다.

데이터를 추출하기 전에 haruair.com에서 어떤 주소였는지 frontmatter에 history로 저장하도록 플러그인을 수정했다. 그리고 기존에 사용하던 headline도 저장했다.

글 몇 개를 제외하고 변환되긴 했는데 마크다운이 아닌 html로 저장된 문서도 몇 발견할 수 있었다. 지금도 다 확인하지 못해서 소셜 embed가 깨지는 페이지가 좀 있다. 변환이 안된 글도 있는데 플러그인에서 yaml 변환 과정에 문제가 있으면 깨진다. 누락되지 않는 페이지가 있는지 뒤늦게 확인했고 몇 개 안되어 손으로 변환했다.

영어와 한국어를 분리하고 싶어서 lang도 추가했다.

구현 사항과 사용한 플러그인

  • URL 처리: createPage()에서 path만 값만 넣으면 손쉽게 커스텀 경로를 사용할 수 있었다. frontmatter에 추가한 langtype, slug를 조합해서 사용하도록 했다. 또한 절대 경로도 사용할 수 있도록 url도 추가했다.
  • RSS 피드: gatsby-plugin-feed을 사용하면 쉽게 만들 수 있다. 다만 정적 사이트라서 xml 확장자를 써야만 하는 점이 아쉽다. /feed.xml/ko/feed.xml을 분리해서 생성하도록 config에 추가했다. 각각 어느 피드인지 title도 넣었다.
  • sitemap: 구글 웹마스터 도구에 제출하기 위해서 gatsby-plugin-sitemap을 추가했다.
  • PWA용 기능: gatsby-plugin-offlinegatsby-plugin-manifest를 추가했다. PWA는 잘 몰라도 속도가 빨라진 것은 바로 체감할 수 있었다.
  • 문법 강조: prismjs를 설치했다. 항상 hightlightjs를 사용해와서 조금 어색하긴 하지만 마음에 든다.
  • 소셜 공유: react-helmet으로 og meta와 twitter meta를 추가했다. 플러그인이 있을 것 같은데 일단 helmet으로 해결했다. 테스트 해보니 큰 문제 없었다.
  • 404 페이지 링크 문제: 내 코드에 문제인가 한참 씨름했는데 gatsby의 버그였고 현재는 고쳐졌다.
  • 배포: 도메인은 cloudflare에 있었고 github pages에 배포하려고 생각했는데 netlify가 정말 멋지게 서비스를 만들어둬서 netlify를 사용하게 되었다.
  • Google Analytics 설정: gatsby-plugin-google-analytics로 간편히 설정했다.

redirect과 canonical

앞서 자료를 추출하며 추가한 history로 redirect.json을 생성했다. 이 파일로 haruair.com에서 yoast SEO의 canonical 란에 새 주소를 저장했다.

<?php
if (php_sapi_name() !== 'cli') exit;
require_once(__DIR__ .'/wp-load.php');

$filename = './redirect.json';
$key = '_yoast_wpseo_canonical';

$data = json_decode(file_get_contents($filename));

foreach($data as $r) {
  $u = explode('/', $r->from);
  $id = array_pop($u);
  if (!is_numeric($id)) continue;

  $canonical = get_post_meta($id, $key);
  if ($canonical !== null) continue;

  update_post_meta($id, $key, $r->to);
  echo "SET {$id} {$r->to}". PHP_EOL;
}

사용하고 있는 amp 플러그인에서는 yoast의 canonical을 불러오고 있지 않아서 다음처럼 추가했다.

<?php
function haruair_amp_canonical($data, $post) {
  $data['canonical_url'] = get_post_meta($post->ID, '_yoast_wpseo_canonical', true);
  return $data;
}

add_filter('amp_post_template_data', 'haruair_amp_canonical', 100, 2);

여기까지 하고 Google Webmasters에 sitemap을 제출했다.

amp 페이지는 캐싱 되는 주기가 길어서 빨리 반영이 되지 않는 데다 사용하고 있던 cloudflare의 캐시를 매번 지워줘야 해서 확인이 어려웠다.

게다가 canonical을 추가하니 기존 사이트가 검색에서 사라졌는데 새 페이지가 아직 구글에 크롤링 되지 않아 아예 검색 결과에 나오지 않는 문제가 있었다. 그래서 모든 페이지에서 301 Moved Permanently로 새 주소에 이동하도록 코드를 추가했다.

<?php
function haruair_redirect_canonical() {
  if (!is_single()) return;
  $canonical = get_post_meta(get_the_ID(), '_yoast_wpseo_canonical', true);
  if ($canonical) {
    wp_redirect($canonical, 301);
    exit;
  }
}

add_action('template_redirect', 'haruair_redirect_canonical');

이제 색인이 어느 정도 정리되면 haruair.com 도메인도 netlify에서 제공하는 _redirect로 변경할 예정이다.

edykim.com

그동안 haruair.com을 오래 사용했는데 하나로 다 통합하기로 결정했다. 새 도메인에서 다시 시작하는 기분으로 깔끔하게 정리했다. 예전에는 블로그 구조에서 벗어나기 어려워서 노트처럼 사용하려는 취지와 조금 멀어졌는데 여기서는 좀 더 차분하게 내 자료를 쌓아갈 수 있으면 좋겠다.

처음 사용해본 Gatsby도 마음에 들었다. 주변에서도 많이 언급해서 궁금했었는데 이 정도로 만족스러울 줄은 몰랐다. Gatsby를 사용하면서 source와 transformer, plugin의 구분으로 확장의 성격을 명확하게 분리하는 점과, GraphQL로 마치 데이터를 가져와 페이지를 생성하면서도 그 과정 어느 순간이든 사용자가 개입할 수 있도록 열린 구조가 너무 좋았다. 작업 하면서 사소하지만 작은 코드를 기여하기도 했는데 기여 방법도 어떤 과정으로 참여할 수 있는지 잘 정리되어 있어서 손쉽게 제출할 수 있었다. 아직 코드가 지저분한데 정리도 하면서 gatsby도 좀 더 깊이 살펴보는 기회로 삼고 싶다.

HUZZAH!!!
어예! 공부다 공부 ✌

아직도 개인 신상이 정리가 되질 않아서 제출한 서류 결과만 기다리고 있는 상황이라 조금 답답했었다. 그래도 오랜만에 코드 만지면서 예전 생각도 들고, 얼른 다시 코드 짜는 삶으로 돌아가고 싶어졌다. 연말까지는 큰 일 없이 이렇게 지내게 될 것 같은데 조금 더 멀리 보고 부지런히 준비해야겠다.

C++ 연산자 오버로딩 가이드라인

2018년 8월 2일

이 가이드라인은 California Institute of Technology의 강의 자료인 C++ Operator Overloading Guidelines를 번역한 글로 C++에서 연산자를 오버로딩 할 때 유의해야 하는 부분을 잘 설명하고 있다.


C++ 연산자 오버로딩 가이드라인

사용자 정의 클래스를 사용할 때 연산자에 특별한 의미를 부여할 수 있다는 점은 C++의 멋진 기능 중 하나입니다. 이 기능을 연산자 오버로딩(operator overloading) 이라고 합니다. C++의 연산자 오버로딩은 클래스에 특별 멤버 함수를 다음과 같은 명명 규칙에 따라서 작성해 구현할 수 있습니다. + 연산자를 클래스에 오버로드 하는 것으로 예를 들면 operator+라는 이름의 멤버 함수를 클래스에 작성해서 제공할 수 있습니다.

다음은 사용자 정의 클래스에 일반적으로 오버로드하는 연산자 목록입니다.

  • = (할당 연산자, assignment operator)
  • + - * (이진 산술 연산자, binary arithmetic operators)
  • += -= *= (복합 할당 연산자, compound assignment operators)
  • == != (비교 연산자, comparison operators)

이 연산자를 구현하는데 있어 몇 가지 지침이 있습니다. 이 지침을 따르는 것은 매우 중요하며 각 지침은 꼭 버릇으로 만들기 바랍니다.

할당 연산자 =

할당 연산자는 다음과 같은 시그니처(signature)를 사용합니다.

class MyClass {
  public:
  ...
  MyClass & operator=(const MyClass &rhs);
  ...
}

MyClass a, b;
...
b = a;   // b.operator=(a); 와 동일함

= 연산자가 우측에 할당한 내용을 상수 참조로 받는 점을 확인할 수 있습니다. 이렇게 하는 이유는 명확한데 할당 연산자 왼쪽에 있는 내용을 바꾸고 싶은 것이지 할당 오른쪽은 변경을 원하지 않기 때문입니다.

또한 할당 연산자도 참조로 반환하는 점을 확인할 수 있습니다. 이 방식으로 **연산자 연결(operator chaining)**이 가능합니다. 원시 형식(primitive types)이 다음처럼 동작하는 것을 봤을 겁니다.

int a, b, c, d, e;

a = b = c = d = e = 42;

컴파일러는 이 코드를 다음처럼 해석합니다.

a = (b = (c = (d = (e = 42))));

다시 말하면 할당은 **우측 연관(right-associative)**입니다. 마지막 할당 연산이 먼저 평가되며 연쇄적인 할당에 따라 좌측으로 퍼져가게 됩니다. 특히,

  • e = 42는 42를 e에 할당하고 그 결과로 e를 반환합니다.
  • e의 값이 d에 할당되며 그 결과로 d를 반환합니다.
  • d의 값이 c에 할당되며 그 결과로 c를 반환합니다.
  • 기타 등등…

이제 연산자 연결을 지원하기 위해서 할당 연산자는 반드시 어떤 값을 반환해야 합니다. 반환되어야 하는 값은 할당의 좌측 을 참조합니다.

반환 참조에는 상수로 선언되지 않았음 을 확인할 수 있습니다. 이 점은 좀 혼란스러울 수 있는데 다음과 같은 기괴한 코드를 작성할 수 있기 때문입니다.

MyClass a, b, c;
...
(a = b) = c;  // 이건 뭐죠??

이건 코드를 처음 봤다면 아마 이런 상황을 방지하기 위해 operator=를 상수 참조로 반환하고 싶을지도 모릅니다. 하지만 이런 구문(statements)은 원시 형식과 함께 동작할겁니다. 그리고 더 나쁜 점은 어떤 도구는 이런 동작 방식에 의존하고 있다는 점입니다. 그러므로 operator=상수가 아닌 참조로 반환하는 것이 중요합니다. 경험적으로 “상수에 괜찮다면 사용자 정의 자료 형식에도 괜찮다”고 말할 수 있습니다.

그래서 가상의 MyClass 할당 연산자를 다음처럼 작성할 수 있습니다.

// 우측 할당에서 상수 참조를 받습니다.
// 좌측에 상수가 아닌 참조를 반환합니다.
MyClass& MyClass::operator=(const MyClass &rhs) {
    ...  // 할당 연산을 수행합니다!

    return *this;  // 자기 자신을 참조를 반환합니다.
}

기억하세요. this는 이 객체에 대한 포인터며 멤버 함수로 호출되는 대상입니다. a = ba.operator=(b)처럼 취급되는 방식을 보면 반환 객체 자체가 호출되는 함수라는 점이 더 와닿을 것입니다. 객체 a는 좌측에 해당합니다.

하지만 멤버 함수는 객체에 대한 포인터를 반환하는 것이 아니라 객체에 대한 참조를 반환해야 합니다. 그래서 *this를 반환했는데 이 코드는 무엇을 가리키고 있는지를 반환했지 포인터 자체를 반환한 것이 아닙니다. (C++에서는 인스턴스는 참조로 전환되고 또 그 역으로도 성립하는데 거의 자동으로 처리됩니다. 그래서 *this는 인스턴스지만 C++는 암시적으로 인스턴스에 대한 참조로 변환합니다.)

이제 할당 연산자에 가장 중요한 점이 하나 더 있습니다. 자기 할당(self-assignment)를 꼭 확인해야 합니다!

클래스가 자체적으로 메모리 할당을 하는 경우라면 특히 중요합니다. 할당 연산자가 일련의 연산을 수행할 때 일반적으로 다음처럼 동작합니다.

MyClass& MyClass::operator=(const MyClass &rhs) {
    // 1. MyClass가 내부적으로 갖고 있는 모든 메모리를 할당 해제합니다.
    // 2. rhs의 내용을 보관하기 위해 메모리에 할당합니다.
    // 3. rhs로부터 값을 인스턴스에 복사합니다.
    // 4. *this을 반환합니다.
}

이제 이렇게 작성하면 다음과 같은 일이 일어납니다.

MyClass mc;
...
mc = mc;     // 짜잔!

이 코드를 보면 프로그램에 대혼란을 불러온다는걸 볼 수 있을겁니다. mc는 좌측에도 있고 또한 우측에도 있기 때문에 가장 먼저 일어나는 일은 mc가 내부적으로 들고 있는 모든 메모리를 해제합니다. 하지만 여기서 값이 복사될 위치이기도 합니다. 우측도 mc가 있기 때문이죠! 이제 나머지 할당 연산자 내부를 완전히 다 엉망으로 만들고 맙니다.

이런 문제를 손쉽게 피하려면 자기 할당을 확인합니다. “두 인스턴스는 같나요?”라는 질문에 답하는 방법은 많지만 우리 용도를 생각해보면 객체 주소가 동일한지 확인하는 정도면 지금 용도에 맞습니다. 만약 주소가 동일하면 할당을 하지 않습니다. 주소가 다르면 할당을 수행합니다.

이제 올바르고 안전한 버전의 MyClass 할당 연산자를 생각하면 다음과 같습니다.

MyClass& MyClass::operator=(const MyClass &rhs) {
    // 자기 할당을 확인합니다.
    if (this == &rhs)      // 동일 객체?
        return *this;        // 맞네요. 그럼 할당을 건너뛰고 *this를 반환합니다.

    ... // 할당 해제, 새 공간을 할당하고 값을 복사합니다...

    return *this;
}

또는 간단하게 다음처럼 할 수 있습니다.

MyClass& MyClass::operator=(const MyClass &rhs) {

    // `rhs`가 `this`와 다를 때만 할당을 합니다.
    if (this != &rhs) {
        ... // 할당 해제, 새 공간을 할당하고 값을 복사합니다...
    }

    return *this;
}

위 비교에서 this는 호출되는 객체 포인터고 &rhs는 인자로 전달된 객체를 가리키는 포인터라는 점을 기억한다면 위 코드와 같은 검사로 자기 할당의 위험성을 회피할 수 있다는 점을 확인할 수 있을겁니다.

결론을 정리하면 할당 연산자를 위한 가이드라인은 다음과 같습니다.

  1. 인자는 상수 참조로 받습니다. (할당 우측)
  2. 좌측에 참조를 반환해서 안전하고 적절한 연산자 연결을 지원합니다. (*this를 반환하는 방법으로)
  3. 포인터를 비교해서 자기 할당을 확인합니다. (this&rhs)

복합 할당 연산자 += -= *=

산술 연산자에 대해 특별히 언급할 부분이 있는데 뒤에서 자세히 다루겠습니다. 이 연산자는 비구조(destructive) 연산자라는 점이 중요합니다. 바로 할당의 좌측 값이 갱신되거나 대체되기 때문입니다. 다음 예시를 확인합니다.

MyClass a, b;
...
a += b;    // a.operator+=(b) 와 동일함

이 경우에는 += 연산에 의해 값이 수정되었습니다.

어떻게 이 값이 변경 되었는가는 그렇게 중요하지 않습니다. 명백하게 MyClass가 이 연산자의 의미가 어떤 것인지 나타내고 있기 때문입니다.

이런 연산자의 멤버 함수 시그니처는 다음과 같아야 합니다.

MyClass & MyClass::operator+=(const MyClass &rhs) {
    ...
}

rhs가 상수 참조인 이유는 이미 앞에서 다뤘습니다. 그리고 이런 연산자의 구현 또한 직관적입니다.

하지만 연산자가 MyClass 참조를 반환하는 것을 볼 수 있으며 상수가 아닌 형태로 반환하고 있습니다. 이 말은 다음과 같은 코드도 가능하다는 의미입니다.

MyClass mc;
...
(mc += 5) += 3;

누가 이런 코드를 작성하는지 저에게 물어보지 않기 바랍니다. 하지만 다른 일반적인 할당 연산자와 같이 이런 원시 데이터 형식에서는 허용되야 하는 방식입니다. 사용자 정의 데이터 형식도 원시 데이터 형식에서 이런 연산자와 함께 동작하는 방식과 맥락이 맞는 동작을 제공해야 모든 코드가 기대한 대로 동작할 것입니다.

이런 작업은 매우 직관적입니다. 단지 복합 할당 연산자 구현을 작성하고 *this를 마지막으로 반환하도록 작성합니다. 다른 일반적인 할당 연산자처럼 말이죠. 그러면 다음과 같은 코드를 작성하게 될 것입니다.

MyClass & MyClass::operator+=(const MyClass &rhs) {
    ...   // 복합 할당 작업을 처리합니다.

    return *this;
}

마지막으로 일반적으로 복합 할당 연산자더라도 자기 할당 문제에 유의해야 합니다. 운좋게도 C++ 트랙 연구실에서 이 걱정을 할 필요는 없겠지만 클래스를 직접 작성하고 사용할 때마다 이 문제에 대해 항상 생각하고 있어야 합니다.

이진 산술 연산자 + - *

이진 산술 연산자는 연산의 양쪽을 모두 수정하지 않으며 두 인자로 만든 새로운 값을 반환한다는 점에서 흥미롭습니다. 아마 이 작업은 조금 추가적인 작업을 필요로 해서 짜증날 수 있겠지만 여기에 비밀이 있습니다.

복합 할당 연산자를 활용해서 이진 산술 연산자를 정의하세요.

방금 제가 당신이 숙제에 쓸 수많은 시간을 절약해줬습니다.

이미 += 연산자를 구현했고 이제 + 연산자를 구현하려고 합니다. 함수 시그니처는 다음과 같습니다.

// 인스턴스의 값을 다른 곳에 추가하고 결과와 함께 새 인스턴스를 반환합니다.
const MyClass MyClass::operator+(const MyClass &other) const {
    MyClass result = *this;     // 자신의 사본을 만듭니다. `MyClass result(*this);`와 같습니다.
    result += other;            // 다른 곳에서 사본에 더하기 위해 +=를 사용합니다.
    return result;              // 모두 끝났습니다!
}

간단하네요!

사실 명시적으로 모든 과정을 다 설명했지만 원한다면 이 모든 코드를 다음처럼 한 줄 구문으로 작성할 수 있습니다.

// 인스턴스의 값을 다른 곳에 추가하고 결과와 함께 새 인스턴스를 반환합니다.
const MyClass MyClass::operator+(const MyClass &other) const {
    return MyClass(*this) += other;
}

이 코드는 *this의 사본으로 이름 없는 MyClass 인스턴스를 생성합니다. 그리고 += 연산자는 이 임시 값에서 호출하고 반환합니다.

마지막 구문이 아직 이해가 되지 않는다면 앞서 단계를 풀어서 설명한 코드를 사용하기 바랍니다. 하지만 정확히 무슨 과정이 이뤄지는지 이해된다면 짧은 코드를 사용하세요.

+ 연산자가 상수 인스턴스를 반환한 것이지 상수 참조를 반환하지 않았다는 점 을 알 수 있을 겁니다. 상수 참조를 반환하지 않는 것으로 다음과 같은 이상한 구문을 작성하는 일을 막습니다.

MyClass a, b, c;
...
(a + b) = c;   // 엥...?

이 구문은 기본적으로 아무 일이 일어나지 않습니다. 하지만 + 연산자가 상수가 아닌 값을 반환하는 경우에는 컴파일이 됩니다! 반환 값을 상수 인스턴스로 한다면 이런 광기는 더이상 컴파일 되지 않을 것입니다.

이진 산술 연산자를 위한 지침을 정리하면 다음과 같습니다.

  1. 복합 할당 연산자를 처음부터 구현합니다. 그리고 이진 산순 연산자를 복합 할당 연산자를 사용해서 이진 산술 연살자를 정의합니다.
  2. 허용되지 말아야 할 쓸모 없고 혼란스러운 할당 연산을 방지하기 위해서 상수 인스턴스를 반환합니다.

비교 연산자 ==, !=

비교 연산자는 매우 간단합니다. 다음 함수 시그니처를 사용해서 ==를 먼저 정의합니다.

bool MyClass::operator==(const MyClass &other) const {
    ...  // 값을 비교하고 bool 형식으로 결과를 반환합니다.
}

구현 내부는 매우 명확하고 직관적입니다. bool 반환 값도 아주 분명합니다.

여기서 중요한 점은 != 연산자도 == 연산자를 사용해서 간편하게 정의할 수 있습니다. 다음과 같이 작성하세요.

bool MyClass::operator!=(const MyClass &other) const {
    return !(*this == other);
}

== 연산자를 구현하려고 고생해서 만든 코드를 그대로 재사용하는 방법입니다. 또한 ==!= 구현이 서로를 구현하고 있기 때문에 이 연산자 사이에서 불일치 문제가 발견될 가능성이 매우 낮습니다.


Updated Oct 23, 2007

Copyright (c) 2005-2007, California Institute of Technology.


더 읽을 거리

프로그램과 프로그래밍에 대해

2018년 7월 25일

Bjarne Stroustrup 책을 읽고 있는데 단순하면서도 마음에 남는 말이 참 많다.

Our code must be maintainable … A successful program “lives” for a long time (often for decades) and will be changed again and again. … Only a failed program will never be modified.

코드는 꼭 유지보수가 가능해야 합니다. … 성공적인 프로그램은 오랜 시간을, 종종 수십 년을 “살며” 계속 변경됩니다. … 실패한 프로그램은 절대 수정되는 일이 없습니다.

To be maintainable, a program must be simple relative to its requirements, and the code must directly represent the ideas expressed.

유지보수가 가능하려면 프로그램은 프로그램의 요구사항에 비해 단순해야 하며 코드는 아이디어의 표현을 직접 드러내야 합니다.

A program is a precise representation of our understanding of a topic.

프로그램은 우리가 주제를 어떻게 이해하는지를 알려주는 정확한 표현(representation)입니다.

Think about the problem itself, rather than your incomplete solution.

자신의 불완전한 해결책보다 문제 자체에 대해 생각하세요.

Programming is part practical, part theoretical. If you are just practical, you will produce non-scalable, unmaintainable hacks. If you are just theoretical, you will produce unusable (or unaffordable) toys.

프로그래밍은 실용적인 부분과 이론적인 부분이 있습니다. 만약 당신이 실용적이기만 한다면 당신은 확장하기 어렵고 유지보수 하기 어려운 코드 덩어리를 만들 겁니다. 반대로 이론적이기만 하면 사용 불가능한 (또는 감당하기에 너무 비싼) 장난감을 만들게 됩니다.


이 챕터 끝에 길을 잃은 기분이 들 때 이 책을 꺼내서 이 챕터를 다시 읽으라는 말에 울컥했다. 요즘 앞으로 어떤 개발을 해야 할지, 어떤 시장에서, 환경에서, 어떤 언어로 할지 고민이 많다. 다시 처음부터 시작하는 기분에 더 갈피가 잡히지 않는 것 같다.

웹 외의 환경은 해본 적이 없기도 하고 학교 가면 하게 될 것 같아서 cpp를 한동안 볼 것 같다. 영어도, 수학도 준비해야 하고. 적어보니 바빠야 하는데 막상 하나 제대로 하지 못하는 것 같고. 이렇게 고민에 고민을 더한다.

내 기분 속여서 하려고 노력하기보다 어떻게든 꾸역꾸역 해야 할 때가 온 것 같다. 빨리 방향도 생각도 다듬어졌으면 좋겠다!