팀 프로젝트를 진행하며 다음과 같은 요구사항이 발생했습니다. 1. 특정 워크스페이스 구성원인지 식별할 수 있어야 한다 2. 내부 구성원이라면 해당 사용자를 식별할 수 있는 정보를 확보해야 한다 이를 구현할 방법에 대해 탐색한 결과를 간단히 기록해봅니다 OAuth Flow OAuth Flow 를 이해하는 데에 시간이 많이 필요했습니다. 레벨2에서 인증, 인가를 학습하며 RFC 문서를 통해 인증 서버와 자원 서버를 구분하여 사용한다는 개념은 미리 습득해두었지만, 이를 하나의 사용자 관점에서만 접근했었기 때문에 미싱 링크가 존재했습니다. 사용자와 두 개의 서비스가 존재할 때, 서비스 A는 사용자에 대한 인증을 서비스 B에 의존하는 상황이라면 상호작용하는 대상이 셋이 되고, 이 경우에 대한 이해가 추가적으로 필..
2010년, 제즈 험블과 데이비드 팔리의 Continuous Delivery가 출판되었습니다. 그리고 같은 해에 Git Flow가 빈센트 드리슨에 의해 제안되었습니다. 2022년 1월 GOTO Conference 채널에 업로드 된 영상에서 데이비드 팔리는 Git Flow가 CI/CD 에는 어울리지 않는다고 이야기합니다. 해당 영상의 내용을 요약하며 왜 그러한지 이해한 내용을 기록해봅니다. David Farley 가 이야기하는 CI 어.. CI 그렇게 하는 거 아닌데.. 추측(guessing)이 아닌 확인(checking)을 해야 한다 Dave는 여러 개발자들이 함께 일하고 있는 시스템의 상태에 대해 공유된, 정확한 관점을 유지하고 배포하는 것을 CI 라고 이야기합니다. 이러한 정의에 입각해서 Dave는 ..
Git Flow 전략에 대해 알아본 내용을 정리합니다. 각각의 브랜치들이 왜 필요한지, 생애주기는 어떻게 되는지, 다른 브랜치들과 어떻게 상호작용하는지 알아보겠습니다. https://nvie.com/posts/a-successful-git-branching-model/ main 브랜치 생애주기 서비스의 탄생, 종료와 생애주기를 같이하는 브랜치입니다. 계속해서 유지되는 브랜치입니다. 필요성 최종적으로 고객에게 전달되는 내용이 관리되는 브랜치입니다. 즉, 운영 환경에 현재 배포되어 있는 내용입니다. 특징 시멘틱 버저닝 전략을 활용하여 버전 태깅을 합니다. 다른 브랜치와의 상호작용 develop : 서비스의 탄생 시점에 한 번 파생 개발된 기능을 병합하는데 사용될 develop 브랜치를 main 브랜치 탄생 ..
팀 프로젝트를 진행하며 재밌는 경험을 해서 기록해봅니다 😃 모든 종류의 Slack Event는 하나의 URL로 전달된다 Since your application will have only one Events Request URL, you'll need to do any additional dispatch or routing server-side after receiving event data. Slack Evnt API 문서 Slack App을 워크스페이스에 설치하고 권한을 부여하면, 특정 상황이 발생할 때마다 이를 이벤트로 감지하여 Slack App에 설정된 URL로 이 정보를 보내줍니다. 가령 채널에 메시지가 전송되었다거나, 편집 혹은 삭제되었다거나, 심지어 이모지가 달린 것까지. 사용자에 관련해서는..
추상적인 개념에 대한 학습 경험 레벨 2 동안엔 정답이 없는 문제에 접근하고, 나만의 답을 형성하기 위해 끊임없이 고민해야만 했다. 정답이 아니라 why를 던져주는 우테코 교육방식의 절정이었다. 미션을 수행하는 과정에서 계속해서 고민하고 크루들과 대화하며 나만의 객체지향, 나만의 아키텍처에 대한 기준을 정립했다는 점에서 큰 성과가 있었다. 나만의 이해, 나만의 기준이 얼마나 수준 높은지 보다는 존재 여부가 훨씬 중요하다고 생각한다. 작은 느낌표라도 일단 손에 쥐어지게 되면, 이를 개선하는 것은 수월하기 때문이다. 크루들과 대화하며 생각을 공유하고 나만의 답을 찾아갔던 과정이 정말 행복했다. 아마 우테코를 회상하게 될 때, 함께 고민하며 대화했던 순간들, 함께 했던 사람들, 그들과 함께 했던 행복했던 감정..
