이번엔 버전 관리 시스템과, 이러한 버전 관리 시스템을 사용하는 프로젝트를 지원하는 웹호스팅 서비스를 결정해보도록 하자. 각각 Git, SVN / GitHub, BitBucket같은 것을 예로 들 수 있다. 소스코드 형상관리 시스템이나 소스코드 관리 시스템 같은 명칭으로도 종종 불리는데, 나는 그냥 버전 관리 시스템이라고 부르는 게 더 편한 것 같다.
아무튼 이러한 버전 관리 시스템을 도입하려는 이유는 다음과 같다.
잘 모르겠다면 생활코딩 git 강의의 '버전관리란?' 챕터 영상를 살펴보자.
사실 요즘은 게임 업계가 아닌 이상 무조건 git을 쓰고있는 것 같지만, 이것도 의사결정에 포함시켜 보자.
git을 선택하겠다. 그 이유는,
SVN
은 클라이언트-서버 모델을 사용한다. 이 때문에 저장소의 사본을 로컬에서 관리하는 git에 비해 매우 느리며(변경 로그 하나 보는 것도 인터넷을 경유해야 하므로) commit이 원격에 즉시 반영되기 때문에 부담이 크다. 게다가 SVN은 변화를 저장하는 방식으로 버전(변경 이력)을 관리하는데, 이것도 git과 비교했을 때 속도 문제를 일으킨다. git은 버전을 스냅샷으로 관리하기 때문이다.Mercurial
과 Git
은 분산 버전 관리 시스템이라는 점에서 꽤 유사하지만, 대부분의 개발자는 Git에 더 익숙하다. 우리 조직에 누군가가 들어왔을 때 불필요한 러닝커브가 생기지 않았으면 하는 바람이고, Git과 비교했을 때 Mercurial이 큰 메리트가 있는 것도 아니라는 판단이다.Git은 MacOS를 비롯한 대부분의 리눅스 환경에서 기본으로 제공한다. Windows를 사용하는 경우에만 Git for Windows를 설치하면 된다.
Git이 참조할 원격 저장소를 관리해줄 장소가 필요하다.
GitHub를 선택하겠다. 그 이유는,
BitBucket
은 서버가 느리다. 이게 딱히 문제가 안 될 줄 알았는데 생각보다 굉장히 답답하며 자체적으로 제공하는 기능도 GitHub만큼 풍부하지 않다.GitLab
은 써본 사람이 얼마 없다. 이것도 딱히 문제가 안 될 줄 알았는데 예전에 GitLab 한 번 썼다가 어떤 기능이 어디에 있는 줄 몰라서 답답해 죽는줄 알았다. Mercurial을 쓰지 않았던 이유와 동일하게, 큰 메리트가 없으면서 굳이 익숙하지 않은 걸 썼다가 괜히 생산성만 조지는 수가 있다.GitHub에 계정이 없다면 만들고, 원격 저장소 하나를 만들어 두자. 원래는 팀 단위로 organization을 만들어서 저장소를 만드는 것이 일반적이지만, 같이 프로젝트를 하는 친구들은 사실 가상인물이므로 개인 계정에서 진행하자. GitHub Help의 Create a repo를 참고하면 될 것 같다. 위에서도 말했듯 필자는 독자 여러분의 코드 참조를 위해 저장소를 public으로 만들텐데, 실제로 프로젝트를 하는 중이라면 private로 만드는 것이 맞다.
이건 조직 내가 아니라 개인적으로 결정해야 할 일이지만, 이미 CLI로 고통받고 있거나, CLI 때문에 git을 어려워하는 독자가 있을 수도 있기에 포함시켰다. CLI를 쓰겠다면 존중하겠지만 나는 그 많은 git 명령어를 자유자재로 외울 자신이 없기에 GUI를 사용하겠다. git 명령어가 익숙치 않은 독자가 git을 조금 더 쉽게 시작할 수 있게 하기 위한 목적도 있다.
조직 단위의 결정이 아니기에 매우 개인적인 관점에서 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받았다.
li 하위 code 태그에 폰트가 깨지는 문제가 있어서 마음이 아픕니다. 고쳐줘요 벨로퍼트님 ㅎㅎ 이번에는 사용자 인증 방식을 결정하자. SNS나 우리가 만드려는 서비스처럼 계정 개념이 들어가고, 리소스가 특정 사용자에게 귀속되는 서비스라면 인증이 꼭 필요하다. 도입 이유 사용자 인증 방식 HTTP는 연결 지향 프로토콜인 TCP 기반임에도...
이번엔 API 설계 원칙과 직렬화 포맷을 결정한다. 대부분의 경우 이 두가지는 '당연히 REST랑 JSON 아님?' 하며 관례적으로 결정하고 넘어가곤 하지만, 빼먹지 말고 이것도 의사결정 과정을 끼워 두자. 사실 이 앞에 프로토콜을 결정하는 챕터를 넣어두려 했는데, 거기까진 너무 TMI인 것 같아서 나중으로 미뤘다. 프로토콜은 일단 현재로선 일반적으로 사용...
이번엔 백엔드 포지션에서 어떤 방식으로 개발을 진행할지를 결정하자. 개발 프로세스 정립에 대해 두 가지의 의사결정을 진행할 것이다. 도입 이유 개발 프로세스 정립 개발 프로세스는 어떻게 이슈를 관리하고, 어떤 방식으로 작업을 진행하고, 완료된 작업은 어떤 과정을 거쳐서 실제 제품에 반영시킬지와 같은 것들을 규칙화시킨 것이다. 소프트웨어 공학...
이번엔 버전 관리 시스템과, 이러한 버전 관리 시스템을 사용하는 프로젝트를 지원하는 웹호스팅 서비스를 결정해보도록 하자. 각각 Git, SVN / GitHub, BitBucket같은 것을 예로 들 수 있다. 소스코드 형상관리 시스템이나 소스코드 관리 시스템 같은 명칭으로도 종종 불리는데, 나는 그냥 버전 관리 시스템이라고 부르는 게 더 편한 것 같다. ...
필자는 고등학교 1학년 말에 처음으로 백엔드 포지션에서 프로젝트를 진행했다. 여기저기서 자주 우려먹는 교내 공식 기숙사 관리 시스템인데(파업 상태일 수도 있다), 같은 동아리였던 선배와 함께 Vert.x라는 서버 프레임워크가 지원하는 Vert.x-Web 툴킷으로 Java 8 런타임에서 돌아가는 웹 어플리케이션 서버를 개발했었다. 지금 생각해보면 참 많은 문...