카테고리 보관물: Tools & Tips

Gmail의 Sub-addressing 기능과 활용

거의 모든 인터넷 서비스들이 연락처로 email 주소를 기입하라고 요구한다. 때로는 가입하는 서비스에 따라 서로 다른 이메일을 생성하고 가입하기도 하는데, 이러다 보면 어느새 수 많은 이메일 계정들을 새로 만들어야 하고 관리가 불가능한 지경에 이르게 될 수도 있다. 이 포스팅에서는 별도의 설정 없이 Gmail 주소를 여러개로 확장하여 수신 메일을 라벨링하고, 필터링할 수 있는 서브어드레싱(Sub-addressing)에 대해 정리해본다.

Mechanism: 플러스(+)와 점(.)의 처리 방식

Gmail을 비롯한 많은 서비스 들이 RFC 5233 를 지원한다. Gmail 서버의 경우 수신 주소의 로컬 파트에서 특정 문자를 처리할 때 다음과 같은 규칙을 따른다.

  • The Plus (+) Operatorusername+keyword@gmail.com 형식으로 사용하며, 서버는 + 이후의 문자열을 무시하고 원본 주소인 username@gmail.com으로 라우팅한다.
  • The Dot (.) Neutrality: 로컬 파트 내의 마침표는 무시된다. 즉, user.name@와 username@은 논리적으로 동일한 엔드포인트를 가리킨다.

활용하기

인프라 모니터링 분류

시스템 모니터링 용도로 서비스 별 주소를 분리하면 필터링을 편하게 할 수 있다. 매번 용도에 따라 새로운 email 주소를 만드는 것이 아니라, plus operator를 사용해서 해당 주소로 들어오는 것들은 별도로 필터링을 수행하는 것이다. 예를 들어 GitHub에서 오는 noti 이메일을 별도로 관리해서 자동으로 라벨을 붙이고 싶다면 다음과 같이 +가붙은 새로운 이메일 주소(계정+github@gmail.com)을 GitHub에 등록하고 Gmail엣 filtering에서 label을 선택해주면 자동으로 라벨을 붙이도록 할 수 있다.

개발 단계의 멀티 계정 테스트

OAuth 가입 로직이나 이메일 인증 워크플로우를 테스트할 때 매번 새로운 계정을 생성하는 것보다는 user+test01user+test02와 같은 가상 주소를 사용하면 하나의 메일함 내에서 상태별 테스트 데이터를 격리하여 검증할 수도 있다.

유의 사항

RFC5233을 지원하지 않는 오래된 시스템이나 엄격한 정규표현식 검증을 수행하는 서비스의 경우 “+” 기호 자체가 유효하지 않은 문자라 판단하고 거부할 수도 있다는 점은 알아두자.

그리고 회사에서는 “이름.성@회사도메인” 형식으로 이메일을 생성규칙을 적용하는 경우가 많아서 dot neutrality 기능은 상황에 따라 비활성화 시켜두는 곳도 있다.

Emacs: Buffer is read-only

원격 서버에 접속해서 개발을 마치고 커밋을 정리하려고 git rebase -i <base_commit>를 하는데 “Buffer is ready-only”가 뜨면서 rebase를 수행할 수 없는 문제가 생겼다.

로컬에서 사용하는 Emacs에서는 이런 문제를 겪은 적이 없었는데 원격 서버에서는 git-rebase-todo 버퍼를 읽기 전용으로 읽어 버리는 문제가 생기는 것이다. 이 문제를 해결하는 방법은 두가지 정도가 있다.

방법1: Read-only 강제 전환

특별한 문제가 있어서라기 보다는 모종의 이유로 special mode가 활성화 되어서 read-only가 걸린 상태가 되는 것일 뿐이므로 C-x C-q로 쓰기모드로 강제 전환해서 수정을 해도 별 문제가 없다. 다만, 이후로도 git rebase -i 명령어를 수행할 때 마다 강제 전환을 해줘야 한다는 사소한 문제가 있을 뿐.

방법2: git-rebase-mode-hook 설정

매번 버퍼를 강제 변환하는 과정을 귀찮으니 아예 git rebase mode일 때 read-only를 강제로 푸는 방법도 있다. init file의 뒷쪽에 다음을 추가해 준다.

...

;; git rebase를 수행할 때 read-only 걸리는 문제 수정
(add-hook 'git-rebase-mode-hook
  (lambda ()
    (read-only-mode -1)))

Rust와 Python unit test의 공존

예전 글에서 vscode의 test explorer에 Rust의 unittest가 보이도록 설정하는 방법을 다룬 적이 있었는데, 여기에 Python test case (여기서는 pytest)도 함께 표시되도록 하려면 .vscode/settings.json을 편집해 주어야 한다.

해당 프로젝트의 경우 가상환경을 source root에 두지 않고 서브 디렉토리인 service/.venv 안에 넣어 두었기 때문에 python.defaultInterpreterPath 값을 이곳으로 직접 설정해 주고 pytest 사용을 위한 설정도 해 두었다.

{
    // Rust unit test
    "rust-analyzer.testExplorer": true,

    // Python virtual environment용 인터프리터 설정
    "python.defaultInterpreterPath": "${workspaceFolder}/service/.venv/bin/python", 
    
    // pytest 사용
    "python.testing.pytestEnabled": true,
    "python.testing.unittestEnabled": false,

    // Python unit test가 있는 디렉토리 경로
    "python.testing.pytestArgs": [
        "service/test"
    ],
    "python-envs.defaultEnvManager": "ms-python.python:venv"
}

그리고 나서 vscode GUI에서도 다시 한번 venv를 설정해 준다. 그냥 프로그램을 재 실행 했으면 이 부분은 건너 뛰어도 되었을 것 같긴 한데, 오류가 계속 뜨길래 수동으로 설정해 주었다.

이렇게 하고 나면 test explorer에 두 언어의 test case들이 모두 표시되는 평화로운 공존상태가 된다.