보성

인터넷 세상을 만들어 가는 사람들은 애매한 결정을 어떻게 할까?

언제 어디서나 중요한 결정을 해야할 때가 다가온다.

그런데 그 순간이 인터넷 세상을 만들어가는 중요한 순간이면 어떻게 해야할까?

퓨니코드를 알고 있다면 한글로된 도메인이 xn--으로 시작한다는 것을 알고 있을 것이다.

근데 왜 하필이면 xn--일까?

누군가는 xn에 의미가 있다고 생각할 수 있겠지만, 이는 사실 랜덤으로 정해진 것이다(!!)

하지만 이걸 아무 논의 없이 랜덤으로 정하지는 않았을 것이다.

블로그에 그 이야기를 자세하게 적었다

그때 누군가가 주식을 조금 더 샀더라면 지금 보고 있는 xn-- 은 없었을지도 모른다.

직접 구글 로그인 같은 서비스를 만든 이야기 - OAuth 2.0, OpenID Connect

학내 개발팀에서 개발자로 있으면서 여러가지 서비스를 제공해야하는 환경에 놓였어요. 이때, 각 서비스가 굳이 각각의 인증 시스템을 가지고 있을 필요가 없죠. 왜냐하면 서비스를 사용하는 대상은 학부생으로 정해져있지만, 만일 각 서비스가 각각의 인증 시스템을 가지고 있다면 유저가 각 서비스를 처음 사용할 때마다 같은 정보를 입력하는 번거로운 회원가입을 과정을 거쳐야하죠. 사실 회원가입은 문제가 없을 수도 있는데, 정보가 바뀌게 된다면 (주로 휴대폰 번호) 모든 서비스에서 휴대폰 번호를 수정해야하죠. 이때 하나를 놓치기라도 하면 중요한 정보를 받지 못하는 문제가 일어날 수도 있고요.

또한 통합된 인증 서비스를 제공하면 제가 소속된 학내 개발팀이 만드는 서비스 말고도 외부에서 제작하는 서비스가 이 인증 서비스를 가져가서 편하게 연동을 할 수도 있을거에요. 보안을 신경써서 한번 제대로 만들면 다시 인증 시스템을 구현하다가 잘못하여 보안에 취약한 코드를 만들 수 있는 가능성도 막을 수 있어요.

통합 인증 서비스를 만들면서 가장 많이 신경 썼던 것은, 이것을 사용해서 연동하는 개발자가 어떻게 하면 편하게 쓸 수 있을지, 어떻게 하면 보안에 대한 이슈를 최대한 줄일 수 있을지였어요. 이 두가지를 간단하게 만족시킬 수 있는 방법은 이미 표준화 되어있는 기술을 사용하는 것이었어요. 그 기술이 바로 OAuth와 OpenID Connect에요.

보통 OAuth 2.0은 많이 들어봤을 것인데, OpenID Connect는 생소할 수도 있을 것 같아요. OAuth 2.0은 내가 개발하는 서비스에서 다른 서비스(ex: 구글)의 리소스를 가져와서 사용할 수 있는 인가(Authorization)를 지원하는 기술이고, OpenID Connect는 OAuth 2.0을 기반으로하여 유저 정보를 전해주는 인증(Authentication)을 지원하는 기술이에요.

OpenID Connect는 처음 들어보는 표준이었기 때문에 이것을 구현하기 위해 여러 문서(스펙, RFC)를 보면서 오랜 시간 동안 공부를 했어요. 아래 글은 RFC와 스펙 문서를 읽으면서 작동 방식에 대해 정리한 글입니다!

그리고 그 내용을 바탕으로 코드로 옮겼습니다! 사전 지식 글에서도 나오듯이 인증 서비스를 구현하기 위해서 나오는 참여자가 개발하는 서버(클라이언트), 인증 서버, 유저가 사용하는 브라우저(유저 에이전트)로 여러개가 있어서 각자 지금 인증 상태에서는 어떤 작업을 해야하는지를 염두에 두어야 하기에 복잡했던 것 같아요.

새로운 것을 배우고 그것을 그 의도대로 구현해보는 재밌는 경험이었습니다 :)

Flutter를 1년 정도 사용하면서 얻은 노하우

플러터가 뭔데?

하나의 코드로 여러가지 플랫폼에서 사용할 수 있는 앱을 만드는 프레임워크요~

나름 플러터 헤비 유저로서 플러터로 개발할 때 유용하게 쓸 수 있는 지식들을 끄적여봤어요.

Flutter SDK 설치처럼 가장 기본부터 Dependency Injection이라는 복잡한 사용 방법까지 넓게 담아봤습니다.

Flutter를 사용하고 계신 메이커 분들, 개발자 분들이라면 get이라는 라이브러리를 들어보셨을텐데, get은 pub.dev에서 like 순으로 정렬한 페이지를 봤을 가장 많은 like를 차지하고 있는 라이브러리에요

이렇게 많은 사람들에게 사랑 받고 있는 라이브러리이지만 개인적으로는 이 라이브러리가 주는 한계에 너무 많이 부딪혔어요. 라이브러리 설명에도 있듯이 get하나만으로 state management, dependency injection, routing등이 다 되고 그것이 context 없이 가능하다고 되어있죠.

근데 Flutter에서 context는 가장 중요한 대원칙 중 하나라고 볼 수 있는데 이걸 무시하고 있으니 아무래도 제약이 있을 수 밖에 없었어요.

그래서 이 모든 것을 정리하는 느낌으로 Flutter의 매력에 빠진 이유와 Flutter에서 멋진 개발 환경을 설정하는 내용을 글로 써보았습니다!

모바일 앱 개발을 좋아하는 분들은 재미나게 읽어볼 수 있을 것 같아요 :) 만약 Flutter를 안 쓰신다면 Flutter의 매력에 빠져보시는 것은 어떠할지.. 흠흠

최근에 만들게 된 Soak이라는 프로젝트도 학교 선배의 꼬심에 당해 일주일 동안 Flutter로 만들어낸 앱이에요! 만약에 Flutter가 아니였다면 제 기간에 만들지 못했을 겁니다,, 쏙과 관련된 메이커로그도 나중에 시간 나면 써보도록 하겠습니다 😊

GitHub 메일에 숨겨진 UX

GitHub에서는 이메일로 알림을 받을 수 있고, 나는 이 기능을 굉장히 애용한다. OS에 내장 되어있는 메일 클라이언트를 사용하고 있는데, GitHub에서 알림이 생성 되면 즉각적으로 메일이 수신 되어서 빠르게 PR의 Review Request에 응답하거나 관심을 가지고 있는 이슈의 업데이트 사항을 빠르게 팔로업 하는 것이 가능하다.

메일은 굉장히 형식을 갖춘 수단이다. 문화적으로나 기술적으로나 메일은 자유롭게 꾸미지 못한다. 물론 HTML과 CSS를 활용한다면 (심지어는 JavaScript도 된다) 강조하고 싶은 부분을 자유롭게 강조할 수 있지만 GitHub에서는 그러한 방식을 채택하지 않았다. 최대한 텍스트 위주로만 알림을 보내고 있다.

이외에도 총 5가지의 숨은 UX를 발견하였다.

• 과도한 스타일링을 적용하지 않아서 가독성을 높였다.

• 메일의 답장으로 응답이 가능하다.

• 이전 알림과 연결 되어있는 알림은 답장으로 오기 때문에 메일 클라이언트에서 한번에 묶여 보인다.

• 참조(cc) 부분도 활용하여 알림의 상태를 나타낸다.

• 링크를 적절하게 활용하여서 메일 클라이언트에서 바로 원하는 항목에 도달할 수 있게 하였다.

많은 메일 클라이언트들이 있지만 기본적으로 제공하는 기능은 비슷하기 때문에 어느 환경에서든지 GitHub mail notification이 제공하는 UX를 경험할 수 있다.

더 자세한 내용은 최근에 만들게 된 블로그에 담았다.
블로그에서 재미난 이야기를 많이 풀고자 하니.. 많관부..!