Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

기술 뉴스 #128 : 19-06-15

웹개발 관련

  • 주니어 개발자가 반응형 레이아웃 리팩토링한 썰.txt : 360 파노라마 뷰어를 반응형 웹사이트로 개편한 과정을 설명한 글이다. 기존에 제대로 관리되지 않던 페이지의 분기점을 정해서 모바일과 구분한 반응형으로 만들었지만 태블릿 형태의 디바이스를 고려하지 않아서 모든 디바이스를 지원할 수 있도록 하면서 분기점을 최소화해서 반응형 레이아웃을 설계했다고 한다.(한국어)
  • Get Started with Flutter : 앱 프레임워크인 Flutter의 사용방법을 설명하는 글로 첫 글에서는 Flutter 환경 설정에 관해서 설명하고 있고 Layouts in Flutter에서는 Flutter의 핵심 개념인 위젯을 조합해서 화면을 구성하는 방법을 설명한다.(한국어)
  • WCAG 2.1 새로운 성공 기준 : 웹 콘텐츠 접근성 가이드라인인 WCAG 2.1 권고안이 6월 5일 공개되었는데 여기서 새로 추가된 성공 기준을 번역하고 그 의미를 추가 설명하고 있다. 웹 접근성을 지키려고 한다면 2019년에 새로 염두에 두어야 할 부분을 이해할 수 있다.(한국어)

그 밖의 프로그래밍 관련

  • SwiftUI : Apple에 WWDC에서 애플 플랫폼의 UI를 선언적으로 만들 수 있는 SwiftUI를 발표했다. SwiftUI를 이용하면 이전보다 훨씬 편하고 빠르게 UI를 구성할 수 있어서 많은 개발자들이 기대하고 있고 Xcode11에는 SwiftUI로 UI를 만들 수 있는 새 디자인 도구가 포함되었다.(영어)
  • Docker Best Practices : 뱅크샐러드를 운영하는 레이니스트에서 Kubernetes, AWS ECS로 서버를 운영하면서 그동안 Docker에서 염두에 두어야 할 팁을 정리한 글이다. WORKDIR 사용의 장점, CMD 명령어에서 exec 형식으로 사용했을 때의 좋은 점, 패키지의 의존성 관리와 불필요한 파일을 넣지 않기 위한 .dockerignore 파일의 사용 등을 추천하고 있다.(한국어)
  • Building Sentry: Symbolicator : iOS나 Android 같은 환경에서는 빌드할 때 코드가 최적화되기 때문에 예외가 발생해도 Sentry에서 스택트레이스를 제대로 분석하기 어려운 부분을 해결하기 위해서 Sentry가 노력한 과정이 나와 있다. 디버그 정보로 이용하는 디버그 파일을 이용하는데 이 파일은 너무 크므로 필요한 내용만 서브 셋으로 만들어서 이를 Sentry가 이용할 수 있도록 Symbol Server를 제공하고 이를 Symbolicator라는 서비스로 발전시켜서 Sentry가 스택트레이스를 제대로 분석해서 보여줄 수 있게 했다.(영어)
  • (번역) 리플렉션의 규칙들 : Go 언어를 만든 Rob Pike가 쓴 The Laws of Reflection의 번역 글로 Go 언어에서 Type과 Interface가 어떻게 구성되어 있는지 설명하고 리플렉션의 세 가지 규칙 "리플렉션은 인터페이스값에서 출발하여 리플렉션 객체로 갑니다", "리플렉션은 리플렉션 객체에서 출발하여 인터페이스값으로 갑니다", "리플렉션 객체를 수정하려면, 값이 설정 가능해야 합니다"를 설명해서 리플렉션의 이해를 돕는 글이다.(한국어)
  • Spring Boot에서 Repository로 DynamoDB 조작하기 (1) - 설정부터 실행까지 : MongoDB에서 DynamoDB로 갈아타면서 공부한 DynamoDB의 사용방법을 설명한 글이다. 쿼리 메서드로 이용하기 위해 spring-data-dynamodb를 사용하기까지 AWS CLI, CURL, AmazonDynamoDB 클래스, DynamoDBMapper 클래스 순서로 DynamoDB에서 항목을 조회, 추가, 삭제하는 방법을 자세히 설명하고 있어서 꼭 Java를 이용하지 않더라도 DynamoDB의 사용방법을 이해할 수 있다.(한국어)

볼만한 링크

  • Password expiration is dead, long live your passwords : Microsoft가 Windows 10에서 일정 기간마다 비밀번호를 바꾸도록 하는 정책을 없애기로 했다고 한다. Microsoft에 따르면 2FA, 패스워드 추측 공격, 비정상 로그인 시도 감지 등 보호 장치가 있으면 주기적으로 비밀번호를 바꾸게 할 필요가 없고 비밀번호가 유출되었다는 증거가 있으면 즉시 변경을 해야 하므로 주기적으로 바꾸도록 할 필요가 없다고 한다. 그리고 위의 보안 보호장치가 없으면 주기적으로 비밀번호를 바꾸더라도 어차피 의미가 없다고 한다. 국내에도 빨리 보편화하였으면 하는 정책이다.(영어)
  • 20 Patterns to Watch for in Your Engineering Team : 기업용 Git 저장소를 운영하는 GitPrime에서 "효과적인 매니저는 효과적인 디버거"라는 생각으로 엔지니어링 팀의 성과를 측정하고 문제를 파악해서 개발 프로세스를 개선할 수 있는 패턴을 정리해서 50페이지짜리 PDF로 공개했다. 이메일을 입력하면 다운로드 받을 수 있고 아직 읽어보지는 않았지만, 사일로팀이나 PR 전략, 버스 팩터 문제 등 흥미로운 주제가 많다.(영어)
  • Abstract를 이용한 Sketch 파일 버전 관리 : 마이리얼트립에서 협업하면서 관리가 어려운 Skectch 파일을 Abstract라는 도구로 버전 관리한 내용이 나와 있다. 내가 디자이너는 아니지만, 디자이너들이 디자인 파일로 협업하면서 최신 파일을 찾기도 어렵고 각자 다른 버전을 가진 때도 있고 해서 Abstract를 도입해서 Git으로 코드를 관리하듯이 각자 협업을 할 수 있었다고 한다. 도입 이후 히스토리 확인도 편해졌고 달라진 부분을 비교하기도 쉬워졌다고 한다.(한국어)
  • 메리 미커 인터넷 트렌드 2019 요약 : 메리 미커 인터넷 트렌드 2019의 내용을 요약한 글이다. 크게 보면 스마트폰 출고 대수가 처음 감소세로 접어들었지만 커머스와 광고는 여전히 성장 중이고 잘나가는 서비스와 분야들이 잘 정리되어 있다. 그리고 SNS를 너무 오래 사용하는 것을 사람들이 걱정하기 시작했기 때문에 사용 시간의 증가는 더는 기대하기 어렵다고 한다.(한국어)
  • Sign In with Apple : Apple이 WWDC에서 애플 계정으로 타 서비스에 로그인할 수 있는 "Sign In with Apple"를 공개했다. 이때 서드파티 서비스에 사용자 이메일은 애플이 임시로 만든 비공개 이메일 주소만 전달한다.(영어)

IT 업계 뉴스

프로젝트

  • entropic : 중앙화된 npm 저장소와는 다른 접근을 하는 분산화된 페더레이트 저장소, JSConf.eu의 발표 참고.
  • MDX Deck : MDX 기반으로 발표자료를 만들 수 있는 npm 도구.
  • Formik : React.js로 Form을 쉽게 만들게 해주는 라이브러리.
  • λ Serverless Benchmark : AWS Lambda, Google Cloud Functions, Azure Functions, IBM Cloud Functionsl, Cloudflare Workers 등 다양한 서버리스 플랫폼의 평균 응답시간과 콜드스타트 시간을 벤치마킹한 사이트.
  • Firefox Monitor : 개인 정보가 유출된 사이트를 기준으로 이메일을 입력하면 어떤 사이트에서 어떤 정보가 유출되었는지 알려준다.

버전 업데이트

2019/06/16 02:43 2019/06/16 02:43

Git 계정 여러 개 동시 사용하기

코드 저장소로 GitHub을 주로 사용해 왔는데 요즘은 회사에서도 GitHub을 쓰는 경우가 많아져서 계정 관리가 신경 쓰이는 편이다. 물론 사내에 이상한(?) 코드 저장소가 있는 것보다는 GitHub을 쓰는 걸 훨씬 선호하지만, GitHub Enterprise를 쓰면 상관없지만 GitHub.com을 쓰면 개인 계정과 회사 계정을 섞어서 써야 한다.

예전에는 GitHub Enterprise를 사용했었는데 커밋할 때 결국은 회사 이메일과 개인 이메일을 구분해서 하기가 어려워서 엔터프라이즈에도 개인 이메일을 등록해서 사용했다. 이때는 서비스 자체가 완전히 분리되어 있어서 큰 상관이 없었는데 지난 회사에서 GitHub.com의 같은 계정으로 회사 일까지 하다 보니까 꽤 불편함이 느껴졌다.

GitHub 컨트리뷰션 그래프

일단 컨트리뷰션 그래프에서 개인 사이드 프로젝트나 오픈소스 활동이 회사 코드 작업과 섞이는 게 별로였다. 이건 컨트리뷰션을 꽉 채우고 싶다거나 그런 것보다 나로서 둘은 완전히 타입이라서 이 둘이 섞여 있는 게 불편하게 느껴졌다. 나중에 시간이 지나서 "이때는 개인 코딩은 못 했구나", "이때는 정말 열심히 했구나" 혹은 "이때는 회사 일을 열심히 했구나" 같은 걸 돌아보고 싶은데 그런 게 되지 않는다. GitHub에서 이런 필터링이 지원된다면 해결될 일이긴 하지만... 어차피 회사 저장소는 Private라서 시간 지나면 컨트리뷰션 그래프에 표시만 되지 내용을 볼 수 있는 게 아니기도 하고...

가장 불편한 것은 "알림"이 섞이는 것이었다. 오픈소스 쪽에 워치를 걸어두어서 받는 알림이 많다 보니 의외로 회사 GitHub 알림을 놓치기도 하고 회사 일을 할 때랑 개인 코딩을 할 때랑 시간대가 완전히 다른데 주말에 코딩하다가 불필요한 회사 GitHub 알림을 보게 되거나 하는 건 내가 원하는 게 아니었다. 그냥 딱 분리되어서 내가 의식적으로 두 영역을 왔다 갔다 하기를 바랐다.

GitHub 계정 분리하기

그래서 이번에는 GitHub 계정을 분리해서 사용하기로 했다. 주변에서 마찬가지로 불편하다는 얘기도 들었지만, 같이 썼을 때의 불편함은 느껴봤으니 이번엔 따로 써보자는 생각이었다.

회사 이메일로 GitHub 계정을 새로 만들기는 쉽고 요즘 브라우저에서는 프로필 기능 등으로 GitHub의 계정을 따로 사용하는 건 어렵지 않지만, 메일이 중복 등록은 당연히 안되므로 Git 커밋을 할 때 계정에 맞게 잘 해주어야 한다. 회사 업무에 개인 이메일을 쓰거나 반대로 하면 커밋이 다른 계정에 연결되게 된다.

그래서 중요한 부분은 저장소에 맞게 (실수 없이) 원하는 이메일 주소로 커밋할 수 있어야 하고, git clone이나 git push를 할 때 올바른 SSH 키를 사용할 수 있어야 한다.

SSH 키 분리

회사 계정에서 사용할 SSH 키를 생성한다. 기존에 쓰던 SSH 키는 개인 계정에 등록되어 있으므로 회사 계정용 SSH 키를 따로 만들어야 한다.(중복 등록을 할 수 없다.)

SSH 키는 ~/.ssh/config 파일에서 호스트별로 관리할 수 있다.

# work account
Host work-github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/github-outsider-work

위 설정은 호스트가 work-github.com로 되어 있으면 실제 호스트는 github.com를 사용하고 SSH 키 파일도 ~/.ssh/github-outsider-work를 사용하라는 의미이다.

즉, mocha같은 경우 클론할 때 git@github.com:mochajs/mocha.git 주소를 사용하는데 git@work-github.com:mochajs/mocha.git를 사용해야 한다. 여기서 github.comwork-github.com으로 변경했다. 이는 클론하거나 리모트 저장소를 등록할 때 수동으로 변경해줘야 하지만 원격 저장소는 처음 세팅할 때만 신경 쓰면 이후로는 주소를 매번 입력하는 것은 아니라서 나한테는 받아들일 만한 불편함이다.(정 귀찮아지면 간단한 크롬 익스텐션을 만들어서 써도 될 것 같다.)

이메일 주소 분리

커밋할 때 사용하는 이메일 주소는 ~/.gitconfig 파일에 전역으로 설정해 놓고 사용하는 것이 보통이다. 저장소별 로컬 config마다 설정하면 되긴 하지만 작업을 해보면 자연스럽게 Git 저장소를 클론하고 작업을 하므로 매번 실수하기 마련이다.

encyphered님인 pre-commit 얘기를 해주셔서 처음에는 pre-commit 훅을 이용하려고 했다. Git의 템플릿 기능을 사용해서 미리 pre-commit 훅을 넣어두면 새 저장소를 초기화할 때마다 훅이 기본 설정되므로 잘못된 저장소에 잘못된 이메일로 커밋하는 것을 차단할 수 있다. 대신 컴퓨터에 개인 프로젝트와 회사 프로젝트가 섞여 있으므로 사용할 때 신경을 좀 써야 한다.

그러다가 Obliviscence님이 Includes 설정에 대해서 알려주셔서 좀 찾아보니 이 기능이 내가 딱 원하던 기능이었다.

.gitconfig에 설정하는 includeincludeIf 섹션을 원하는 설정 파일을 추가로 불러오게 할 수 있다.

예를 들어 다음과 같이 ~/.gitconfig 전역 설정 파일을 만들어 보자.

[user]
  email = outsideris@gmail.com
  name = Outsider
  signingkey = 131EA9B1
[includeIf "gitdir:~/my-company-project/"]
  path = .gitconfig-work

여기서는 includeIf 섹션을 사용했는데 이 설정은 Git 디렉터리가 ~/my-company-project/ 디렉터리 아래 있다면 ~/.gitconfig-work 파일을 추가로 불러오도록 한 것이다.

~/.gitconfig-work 파일은 다음과 같다.

[user]
  email = outsider@my-company.com
  name = Outsider
[github]
  user = outsider-biz

테스트해본 결과 원래의 ~/.gitconfig 설정에 ~/.gitconfig-work를 추가로 사용하기 때문에 aliasmerge처럼 공통으로 사용하는 설정은 추가로 적어줄 필요 없고 덮어쓸 설정만 지정하면 된다.

나 같은 경우 개인 프로젝트와 회사 프로젝트가 상위 폴더부터 분리해서 사용하는 편이고 이를 섞는 일은 없으므로 includeIf가 딱 내가 원하던 설정이다. 2주 정도 사용해 보고 있는데 별도로 신경 쓰지 않아도 되면서 편하게 잘 쓰고 있다. 별일 없으면 앞으로도 업무용 GitHub을 분리해서 사용할 계정이고 회사를 이직하더라고(이직한 지 얼마 되지도 않아놓고!!) 같은 업무용 계정을 쓰면 회사별로 얼마나 커밋 양이 달라지는지도 한눈에 볼 수 있을 것 같다.

2019/06/08 16:33 2019/06/08 16:33