PlanB의 백엔드 엔지니어링

주석(comment)은 설명문이다. 문학 책에 실려 있는 소설에서, 어려운 단어가 나오면 페이지의 맨 밑에서 뜻을 풀어 알려주는 것처럼 말이다. 남이 짠 코드를 본 적이 있거나, 내 코드를 남이 본 경험이 있다면 주석이 왜 중요한지 알 것이다. 코드의 이해를 돕기 때문이다. 주석으로 나쁜 코드를 회피하지 말라고 하지만, 아무리 가독성에 신경쓴다고 하더라도 코드의 복잡도가 늘어나면 주석 없이는 의도를 파악하기 힘들기 마련이다.

대부분의 프로그래밍 언어들은 일반적으로 한 줄짜리 주석에 slash(/)를, 여러 줄짜리 주석에 slash와 asterisk(*)를 섞어 사용한다. Java의 예를 보자.

그리고 아래는 Python의 예다.

한 줄짜리 주석에는 내용의 맨 앞에 sharp(#) 기호를 사용하고, 여러 줄짜리 주석에는 내용에 세 개의 double quote(""")를 감싸 표현한다. 대부분의 경우 #을 사용하는 전자의 표현식을 사용한다. 참고로 쉘 스크립트와 Ruby에서 주석을 #으로 표현한다.

후자의 주석 표현에서 사용하는 세 개의 double quote로 감싸진 문자열은, 사실 파이썬에서 문자열 리터럴 표현식이기도 하다.(파이썬에는 4가지의 문자열 리터럴 표현식이 있다 : ', ", ''', """) 따라서 값으로써 관리하기에 더 유연하기 때문에, 파이썬에서는 이를 함수나 클래스 정의의 맨 위에 사용하여 docstring(문서화 문자열)이라는 이름의 주석으로 사용하도록 권고한다. 실제로 #을 사용한 주석은 런타임으로 넘어가며 무시되지만, """를 사용한 주석은 런타임에서도 그대로 유지된다. 결론은, 여러 줄에 걸쳐 주석 처리를 하는 것을 포함한 일반적인 경우에는 #을 사용하는 것이 좋다는 것이다.

이번엔 버전 관리 시스템과, 이러한 버전 관리 시스템을 사용하는 프로젝트를 지원하는 웹호스팅 서비스를 결정해보도록 하자. 각각 Git, SVN / GitHub, BitBucket같은 것을 예로 들 수 있다. 소스코드 형상관리 시스템이나 소스코드 관리 시스템 같은 명칭으로도 종종 불리는데, 나는 그냥 버전 관리 시스템이라고 부르는 게 더 편한 것 같다.

버전 관리 시스템의 도입 이유

아무튼 이러한 버전 관리 시스템을 도입하려는 이유는 다음과 같다.

• 백엔드 어플리케이션을 지금 당장은 혼자 개발하겠지만, 미래에 새로운 백엔드 엔지니어가 우리 팀에 들어와서 협업하게 될 수도 있다. 시스템의 도움을 받아 협업을 원활히 하는 것이 첫 번째 이유다. 소스 코드를 USB나 메일로 주고받는 건 엄청난 낭비니 말이다.
• 변경을 쉽게 되돌릴 수 있다. 에디터 툴들이 일반적으로 지원하는 Ctrl+Z 커맨드와는 차원이 다른 수준의 기록 관리를 지원한다. 소스코드를 과거의 특정 시점으로 되돌리거나, 특정 시점의 변경 사항을 취소하거나, 두 버전의 소스 코드를 비교하는 등의 일이 가능하다.

잘 모르겠다면 생활코딩 git 강의의 '버전관리란?' 챕터 영상를 살펴보자.

버전 관리 웹호스팅 서비스의 도입 이유

• 협업하고 있는 코드를 저장할 서버가 필요하기 때문이다. 이게 없으면 작업을 서로 공유하기 어려우며 사실 이 이유 하나만으로도 도입 동기가 충분하다. 코드를 USB나 메일로 주고받을 수도 있겠지만, 인생을 그렇게 낭비하지 말자. 버전 관리 서버는 직접 운영할 수도 있으나 에어비앤비, 슬랙, 페이팔같은 큰 조직도 GitHub을 쓰는 마당에 특별한 이유가 없다면 이미 잘 만들어져 있는 서비스를 쓰도록 하자.
• 버전 관리 시스템을 지원하는 웹호스팅 서비스의 hook 기능을 통해, push나 이슈 추가, pull request같은 이벤트에 반응하여 자동으로 무언가(테스트 실행, 배포 등)가 실행되게 만들 수 있다. 예를 들면, master 브랜치로 push가 이루어졌을 때 자동으로 테스트를 돌리고, 문제가 없다면 배포하는 식이다.
• 이러한 서비스들은 'pull request'라는 기능을 지원한다. 작업물의 병합을 요청하는 것이다. 여기서 리뷰를 진행하거나, 커뮤니케이션할 수 있다. 개발 프로세스 정립의 자유도가 높아진다.

의사결정 - 버전 관리 시스템

사실 요즘은 게임 업계가 아닌 이상 무조건 git을 쓰고있는 것 같지만, 이것도 의사결정에 포함시켜 보자.

배경과 요구사항

• 대부분의 개발자가 이미 익숙해져 있는 도구일 수록 좋다.
• 브랜치 개념이 있어야 한다. 배포용 코드/작업용 코드 등으로 나누어 프로젝트를 원활히 진행하기 위해 꼭 필요하다.
• 분산형 모델을 사용하는 것을 우선적으로 선택하겠다. 중앙집중식/분산형 버전 관리 시스템의 차이를 모르겠다면 Git SCM의 문서 버전 관리란?을 읽어보자.

선택지

• git
• svn
• mercurial

의사결정

나라면 git을 선택할 것 같다. 그 이유는,

• SVN은 클라이언트-서버 모델을 사용한다. 이 때문에 저장소의 사본을 로컬에서 관리하는 git에 비해 매우 느리며(변경 로그 하나 보는 것도 인터넷을 경유해야 하므로) commit이 원격에 즉시 반영되기 때문에 부담이 크다. 게다가 SVN은 변화를 저장하는 방식으로 버전(변경 이력)을 관리하는데, 이것도 git과 비교했을 때 속도 문제를 일으킨다. git은 버전을 스냅샷으로 관리하기 때문이다.
• 게다가 SVN에는 시스템적으로 브랜치 개념이 없어서, 작업마다 폴더를 만드는 식으로 우회하곤 한다. 스냅샷 기능이 없기 때문.
• Mercurial과 Git은 분산 버전 관리 시스템이라는 점에서 꽤 유사하지만, 대부분의 개발자는 Git에 더 익숙하다. 우리 조직에 누군가가 들어왔을 때 불필요한 러닝커브가 생기지 않았으면 하는 바람이고, Git과 비교했을 때 Mercurial이 큰 메리트가 있는 것도 아니라는 판단이다.

준비

Git은 MacOS를 비롯한 대부분의 리눅스 환경에서 기본으로 제공한다. Windows를 사용하는 경우에만 Git for Windows를 설치하면 된다.

의사결정 - Git 웹호스팅 서비스

Git이 참조할 원격 저장소를 관리해줄 장소가 필요하다.

배경과 요구사항

• 이것도 대부분의 개발자가 이미 익숙해져 있는 도구일 수록 좋다.
• private 저장소를 무료로 만들 수 있게 해주는 서비스를 우선적으로 검토할 것이다. 나중에 조직이 커지면 돈을 쓰는 게 맞겠지만, 지금은 과금에 대한 부담이 적을수록 좋을 것이니 말이다.
• 자체적으로 가지고 있는 이슈 트래커(작업 관리 도구)가 있으면 좋다.

선택지

• GitHub
• GitLab
• BitBucket

의사결정

GitHub를 선택하겠다. 그 이유는,

• BitBucket은 서버가 느리다. 이게 딱히 문제가 안 될 줄 알았는데 생각보다 굉장히 답답하며 자체적으로 제공하는 기능도 GitHub만큼 풍부하지 않다.
• GitLab은 써본 사람이 얼마 없다. 이것도 딱히 문제가 안 될 줄 알았는데 예전에 GitLab 한 번 썼다가 어떤 기능이 어디에 있는 줄 몰라서 답답해 죽는줄 알았다. Mercurial을 쓰지 않았던 이유와 동일하게, 큰 메리트가 없으면서 굳이 익숙하지 않은 걸 썼다가 괜히 생산성만 조지는 수가 있다.
• GitHub에 내장되어 있는 이슈 트래커(GitHub Issues)가 Projects 기능이나 ZenHub 플러그인과 함께 쓰면 생각보다 쓸만 하다. 조직이 웬만큼 커지기 전에는 이슈 트래커로 따로 돈 들어갈 일이 없다. 이슈 각각에 due를 설정하는 게 없는 것 빼고 꽤 만족스럽다.
• GitHub은 free로 쓰던 돈을 내고 쓰던 거의 모든 면에 있어서 가장 풍부한 서비스라고 생각한다. 별의 별 기능이 다 있는데 그게 다 꼭 한 번씩은 필요한 기능들이었으며 기능 자체도 매우 잘 만들어져 있었다. 특정 브랜치를 향한 pull request에 대해 n개 이상의 리뷰를 받아야 merge할 수 있게 만드는 것이나, Organization에서 팀을 만들어 사용자를 포함시키고, 팀 단위로 저장소 각각에 read/write/admin 권한을 부여하고, 서브 팀을 만들어 더 세부적인 위계를 나누는 등, 팀 관리 면에서도 매우 뛰어났던 것 같다.
• 서비스 개발을 진행하는, 특히 백엔드 저장소를 public으로 두면 다른 의미로 많은 관심을 끌 수 있으므로 private로 두는 것이 좋다. 이 때문에 한가지 걸렸던 점은, GitHub에서 free 계정은 visibility를 public으로만 설정 가능하다는 것이었다. GitLab과 BitBucket이 무료 계정에게도 private 저장소를 제공하는 것과 대비된다. 이를 위해선 개인이 한 달에 7달러씩 지불하는 developer plan에 가입하거나, 팀 단위로 organization을 만들어서 유료 플랜을 구입해야만 했는데, 최근에 GitHub가 무료 플랜에게도 private 저장소를 만들 수 있도록 과금 정책을 변경하며 이러한 고민이 당장은 사라졌다. 물론 나중에 조직이 커져서 organization 단위로 프로젝트를 진행하게 되면 돈을 써야겠지만, 이건 다른 서비스들에게도 똑같이 적용되는 이야기다. 따라서 돈 때문에 GitHub를 포기할 이유가 없다. 필자는 독자 여러분의 코드 참조를 위해 public으로 두겠다.

준비

GitHub에 계정이 없다면 만들고, 원격 저장소 하나를 만들어 두자. 원래는 팀 단위로 organization을 만들어서 저장소를 만드는 것이 일반적이지만, 같이 프로젝트를 하는 친구들은 사실 가상인물이므로 개인 계정에서 진행하자. GitHub Help의 Create a repo를 참고하면 될 것 같다. 위에서도 말했듯 필자는 독자 여러분의 코드 참조를 위해 저장소를 public으로 만들텐데, 실제로 프로젝트를 하는 중이라면 private로 만드는 것이 맞다.

의사결정 - Git GUI

참고로 이건 조직 내가 아니라 개인적으로 결정해야 할 일이다. CLI를 쓰겠다면 존중하겠지만 나는 그 많은 git 명령어를 자유자재로 외울 자신이 없기에 GUI를 사용하겠다. git 명령어가 익숙치 않은 독자가 git을 조금 더 쉽게 시작할 수 있게 하기 위한 목적도 있다.

배경과 요구사항

• GUI 단에서 Git이 가지고 있는 대부분의 기능을 모두 사용할 수 있어야 한다.
• UX가 후지지 않아야 한다.
• GUI 툴 쓰다가 답답해서 콘솔 여는 경우가 없어야 한다.

선택지

• GitHub Desktop
• SourceTree
• GitKraken

의사결정

조직 단위의 결정이 아니기에 매우 개인적인 관점에서 GitKraken를 선택하겠다. 그 이유는,

• GitHub Desktop은 가볍고 깔끔하지만 Git의 모든 기능을 지원하지 않는다. 예전에 신규 기능을 개발하다가 버그 핫픽스 작업이 갑작스레 생겨서 git stash 명령을 찾아보려 했는데, GitHub Desktop은 이걸 지원하지 않아서 CLI의 도움을 받았던 적이 있다.
• 일할 땐 웬만하면 SourceTree를 쓰고, 나름 만족스럽지만 이번에 GitKraken을 찾아보니 UI도 예쁘고 좋아 보였다. 맨날 쓰던 것만 쓰면 꼰대가 되지 않을까 싶어서 이번에 GitKraken을 새로 써보려고 한다. GUI 툴은 쉽게 바꿀 수 있으니 써 보다가 아니다 싶으면 SourceTree로 바꾸려는 생각이다.

준비

다운로드를 받아 설치해 두자. 그리고 처음 실행하면 'Sign in with GitHub' 버튼을 통해 본인의 GitHub 계정을 연동할 수 있다. 물론 내가 GitKraken을 쓰기로 결정했다고 해서 꼭 이걸 써야 되는 건 아니다. 말했듯이 조직 단위의 결정이 아니기 때문이다.

그리고 Git GUI를 쓰던 bash를 쓰던 접근하기 편한 장소에 위에서 만들어 뒀던 레포를 clone해 두자. 나도 내 개인 계정에 Sampleapp-for-blog라는 이름의 저장소를 만들고, GitKraken을 통해 clone받았다.

지금까지

• 버전 관리 시스템으로 Git을 사용하기 시작했다.
• Git 웹호스팅 서비스로 GitHub를 사용하기 시작했다.

이번에는 "Hello World"라는 문자열을 콘솔에 출력하는 방법과, 파이썬에서 세미콜론의 용도에 대해서 알아보고자 한다.

Hello World

파이썬에는 글로벌 네임스페이스에서 빌트인 함수들이 여럿 지원된다. List 자료형의 요소를 정렬한 결과를 반환하는 함수도 있고, 요소를 뒤집은(reversed) 결과를 반환하는 함수, 숫자의 절대값을 반환하는 함수, 그리고 파이썬 3.7에서는 디버깅을 위해 break point를 걸어주는 함수도 생겨났다. 콘솔 출력을 위해선 빌트인 함수들 중 print를 사용하며, 파이썬의 빌트인 함수들은 공식 문서에서 확인할 수 있다. 최근부터 한국어 문서화가 잘 진행되고 있어서 편하다.

print 함수의 시그니처는 print(*objects, sep='', end='\n', file=sys.stdout, flush=False)인데, 'Hello World'를 출력하기 위해서는 기본값이 정의되어 있는 sep, end 등의 인자는 아직 신경쓸 필요 없고, *objects 부분만 이해하고 있으면 된다. 파이썬에서는 가변 인자(variable argument)를 위해 * 기호를 쓰므로, 여러 값을 한 번에 출력할 수 있다는 것을 의미한다.

위 두 개의 print문의 결과는 동일하게 'Hello World', 그리고 개행이다. print 함수는 인자로 전달된 objects를 하나씩 출력할 때, sep에 지정되어 있는 문자열이 사이사이에 들어가기 때문에 2번 라인의 결과도 'Hello World'가 된다. sep을 바꾸면 어떻게 될까?

'Hello'와 'World' 사이에 sep인 ', '가 포함되어, 결과는 'Hello, World'가 된다. 참고로, 파이썬은 위처럼 인자를 '선택'하여 값을 전달할 수 있다. 키워드 인자라고 부른다.

파이썬에서의 세미콜론

일부 가이드에서는 파이썬에서 세미콜론은 optional(선택적)이라고 이야기하나, 잘못된 설명이다. '세미콜론이 optional하다'라는 설명은 '써도 되고, 안 써도 된다'라는 이야기이므로 JavaScript에 어울린다.

세미콜론을 붙이던, 붙이지 않던 상관 없다(일부 버전에서는 그렇지 않을 수도 있다). 파이썬에서 세미콜론은 단지 여러 statement를 한 줄에 이어서 사용할 때만 쓸 수 있다.