Jongbin Oh

I write something to think

3 minute read

Behind the Letters

패스워드 누구한테 물어보면 되나요?

팀이 같이 쓰는 패스워드 관리는 힘들다. 빌드 머신 비밀번호부터 시작해서 aws 접속에 사용하는 private 키까지. 구두로 전달하거나 포스트잇에 적어 놓는다. 구두로 전달하다 보니 간단한 조합을 선호하게 된다.

1password처럼 팀 패스워드를 한 곳에 몰아넣어서 관리하고 싶다. 1password teams가 있지만, PD를 설득해야 하는 입장에선 비용이 들어 고려하지 않았다. 그러던 중에 pass 프로그램을 발견했다. windows 빼고 모든 플랫폼을 지원한다. windows가 뭐 그렇지. 패스워드 관리는 오랫동안 유지보수된 프로그램을 사용하고 싶다. 이걸로 골치 아픈 건 싫기 때문에 보수적으로 접근하고 싶다. pass 프로그램은 단순하고 오래돼서 마음에 들었는데, 다른 걸 찾아봐야 하나?

현재 팀은 Git for Windows SDK가 필수 프로그램이다. 여기서 pacman 패키지 매니저로 pass 프로그램을 설치할 수 있을까? 빙고! 된다. windows에서도 사용할 수 있다.

사용해보니 간단하고 편하다. 하지만 팀에서 사용하기엔 불편하다. 팀에서 사용하는 건 고려하지 않은 것 같다. pass 프로그램은 패스워드를 암호화하고 복호화할 때, gpg를 사용한다. 그래서 다른 팀원도 해당 패스워드를 볼 수 있게 하려면 공개키를 받아서 같이 암호화를 해야 한다. 팀원 각자의 공개키를 쉽게 공유할 방법이 있어야 한다. public key server가 있어서 로컬에 공개키를 다운로드 받을 수 있긴 하지만 잘도 하겠다 싶다. 우리는 게임 아티스트, 게임 디자이너도 있거든요.

그래서 사이드 프로젝트를 시작했다. 아이디어는 간단하다. .team_pubs 디렉터리를 만들고 여기에 패스워드를 공유할 팀원 공개키들을 모두 모아 놓는다. 팀원을 추가 또는 삭제할 때, .team_pubs 디렉터리에 있는 공개키들로 다시 재암호화한다. pass 프로그램에 간단한 bash 스크립트 몇 개를 추가했을 뿐이다.

그럼 패스워드 저장소는 어디에 저장하나? git으로 버전 컨트롤하면 된다. 이게 또 매력적이다. 패스워드 저장소가 공유 폴더라면? 이거 지워지면 어쩌나? git으로 버전 컨트롤할 수 있어서 이런 걱정이 싹 사라진다.

테스트가 까다롭다. pass는 HOME 디렉터리를 사용한다. 어떻게 하면 고통 없이 테스트를 할 수 있을까? docker가 딱이다. 빠르고 환경을 격리할 수 있다. 유저들끼리 공개키를 주고받고 패스워드를 추가하고 삭제하는 걸 쉽게 확인할 수 있었다.

nil

docker for mac을 딱 설치하고 시작하려는데… 그래 노트북(MacBook Air, Late 2010) 그동안 마이 고생했다 아이가. 바꿀 때가 되긴 됐네. 우선 vagrant로 설치한 linux 위에 docker를 깔아서 진행했다.

nil

git 커밋 메시지에 이모지(emoji)를 썼다. 구분이 확 되니 좋으네. atom 커밋 메시지에 사용하는 이모지를 참고했다. atom 커밋 메시지에 이모지 정리가 너무 잘 되어 있어서 거기에 몇 개만 더해서 본격적으로 사용해도 괜찮겠단 생각을 했다.

개발 일기를 꾸준히 썼다. 쓰길 잘했단 생각이 든다. 별거 아니라고 생각할 수 있지만, 이게 프로젝트를 계속 할 수 있는 원동력이 된다. 나중에 볼 수 있는 기록을 남기는 건 주목적이 아니다. 난 원동력이 더 중요했다. 남겨지는 기록은 덤이었다. - #clojure 로 짠 트위터 봇 tbot-800을 출동시키고

tbot-800 작업할 때는 에버노트에 작업 일지를 썼다. 에버노트는 내게 중간 저장소다. 정리해서 발행하면 지우는 중간 저장소. 그래서인지 작업 일지를 에버노트에 적으면 정리해서 어디엔가 발행해야겠단 생각이 든다. 이번에는 emacs org mode로 작업 일지를 썼다. org mode로 적으면 느낌이 다르다. 최종 결과물로 보관하는 게 많아서 정리해 블로그로 발행해야겠단 생각이 안 든다. 대신 TIL(Today I Learned)이 많아서 다른 방식으로 ddiary 블로그에 글을 많이 올렸다.

마무리까지 24시간이 걸렸다. 테스트 환경 만들고 테스트 스크립트 만드는데 10시간 정도를 사용했다. 절반 정도를 써 배보다 배꼽이 커 보이지만 테스트 자동화를 안 했다면 직접 테스트한다고 시간을 더 썼지 싶다. 지금보다 결함도 많았을 테고. 게다가 테스트 지식을 쌓고 싶은 터라 시간이 아깝지 않았다.

이 프로그램을 지금 참여하고 있는 프로젝트에서 사용할지는 모르겠다. 사용 안 해도 별로 상관없다. 팀 패스워드 관리가 힘들어서 문제가 생길 때, 제시할 수 있는 대안을 갖추는 것으로 충분하다. 이번 프로젝트에서 사용 안 하면 다음 프로젝트에서 사용해도 괜찮은 거고. 업무 시간이 아니라 개인 시간을 따로 내서 사이드 프로젝트로 진행한 이유다.

링크

You May Also Enjoy

pass, expect 프로그램과 함께한 #jekyll 블로그 deploy 스크립트

2 minute read

static 블로깅 툴인 jekyll은 직접 빌드를 해야 한다. 빌드 결과물인 html, css 파일을 웹호스팅 서버로 배포한다. 이걸 수동으로 하고 있었다. script/build 스크립트로 빌드하고 filezilla로 업로드하고 있다. 언젠가는 aws로 옮기고 push hook...