June Heo

순수 프론트엔드 신규 기능 개발 후기

"...하지만 실제로 가이드라인이 표시되기 시작했을 때, 사전에 크게 고민안하고 넘겨버렸거나 미처 생각하지 못한 부분들이 실질적인 문제로 나타나기 시작했는데 문제들은 다시 복잡하게 얽히면서 더 큰 문제를 만들어냈는데, 사전 계산 페이즈에서 상하좌우 정렬 가이드라인은 O(N) 시간 내에 가이드라인을 모두 구해서 Interval Tree에 집어넣을 수 있었지만 등간격 가이드라인은 하나의 객체를 기준으로 또 다시 다른 객체들과의 거리를 측정해서 계산해야 했기 때문에 N제곱 시간이 소요되었습니다. 이는 객체 숫자가 늘어날 수록..."

레디스 중독형 아키텍처에 대한 이야기

"...그래서 나는 레디스를 더럽히고 있던 코드들을 싹 지우고, 하나의 사용자 요청이 기존 데이터 규모와 상관없이 상수시간에 완료될 수 있도록 메소드를 수정했고, 바뀐 시스템에 대한 성능 테스트를 했고, 초당 15,000개의 요청을 처리하는 레디스틱(Redis-tic)한 시스템으로 길들일 수 있었다. 끝을 모르고 치솟는 TPS 그래프를 보면서 이 성능 테스트 결과는 내 장례식장에 걸어두어도 괜찮겠다는 생각을 잠시 했다...."

운영중인 서비스의 텍스트 에디터 엔진 교체하기

"...이러한 경험이 쌓이기 시작하자 저희는 고갈된 베스핀 간헐천과 같은 상태가 되어버린 Quill에 계속 의지하다가는 텍스트 에디터가 서비스 개선의 발목을 잡을 수 있겠다는 판단을 하게 되었고 더 늦기 전에 에디터를 교체하는 것이 가능할지, 대안은 있을지에 대해 검토하기 위해 정찰을 보내게 되었습니다. 대안이 될만한 텍스트 에디터를 찾는 과정에서 가장 먼저 고려했던 것은 역시나 캔버스 기반의 텍스트 에디터를 인하우스 방식으로 직접 구현하는 방식이었습니다. 하지만 리치 텍스트를 지원하는 에디터를 바닥에서부터 만드는 것은 철근 콘크리트로 궤도 엘리베이터를 만들자는 소리만큼이나 막막한 일이었습니다..."

KubeCon + CloudNativeCon North America 2019 참가 후기

"...그래서 이렇게 위상이 바뀐 쿠버네티스와 클라우드 네이티브 생태계는 이제 어떻게 사람들에게 이걸 쓰게 할까? 라는 고민을 넘어서서 어떻게 하면 이 지배적인 생태계를 더 좋은 방향으로, 실수하거나 망치지 않고, 더 품위있게 발전할 수 있을까를 고민하기 시작했고 그 나름의 결론이 다양한 세션으로 표현되었습니다. 에를 들어서 몇 년 전에는 쿠버네티스 위에서 DB를 돌리는 것이 엄청나게 도전적인 일이었는데..."

2019 Global Exchange Program 후기 - 개발 문화의 상대성에 관하여

"...잘 안 풀리던 프로젝트에 새롭게 투입된 관리자는 보통 팀원들의 자율성을 보장하기보다는 강한 권한으로 강제성을 주는 선택을 하는 경우가 많습니다. 그래야 깨진 유리창을 방치할 수 없다고 주장하는 사람들에게 멀쩡한 유리창을 깨서라도 일을 진행시키라고 강제할 수 있으니까요. 그러한 강제성을 위해서는 시간과 공간적인 거리감이 방해가 됩니다. 업무의 분배와 완료는 팀원들에 의해서 이루어지는 것이 아니라 관리자에 의해서 이루어져야 하기 때문에 팀원들은 식량을 배급받듯이 정해진 장소와 정해진 시간에 업무를 분배받아야 합니다..."

K8S 클러스터 프로비저닝 시스템의 멀티 리전 기능 개발 후기

"...정적인 정의를 동적으로 생성하기 위해서는 리플렉션(Reflection)이 필요했고, 큰 기대를 하지 않고 찾아봤는데 Go 언어에도 리플렉션이 존재한다는 사실을 알게 되어서 살짝 희망을 가졌지만 매우 강하게 타입을 체크하고 제네릭(Generic)을 지원하지 않는 Go 언어의 특성 때문에 리플렉션을 통해 생성된 엔드포인트에서 내가 원하는 메서드를 실행해서 요청을 전달하는 일은 불가능해 보였습니다. 사실 제가 익숙하게 사용했던 스프링 프레임워크에서는 이렇게 요청을 동적으로 해석해서 라우팅하는 것이 전혀 어려운 일이 아니었기 때문에..."

레디스를 이용해 수평 확장 가능한 마이크로 서비스 아키텍처 구성하기

"...제가 주로 고민했던 확장성은 주로 서버가 수평적으로 확장되는, 그러니까 스케일 아웃 되는 상황이었습니다. 최근 클라우드와 컨테이너 환경등의 발전으로 인하여 더더욱 중요해진 부분이기도 했고, 이 프로젝트는 딥러닝 분석 모듈을 돌린다는 특성 상 서버를 수직적으로 확장하는 것은 한계가 비교적 뚜렷한 편이었습니다. 물론 수평적인 확장성을 위한 아키텍처는 전혀 새로운 것이 아니었고 이미 많은 오픈소스 소프트웨어들이 이 환경에서 생길 수 있는 잠재적인 문제점을 해결하기 위해 개발되어 있었습니다. 하지만 당장의 현실적인 문제들을 생각 안 할 수 없었습니다..."

API 인증키 발급 시스템 개발 후기

"...그리고 실제로 해당 클래스는 기존에 생성된 UUID와 중복되지 않는 값을 생성해줌을 보장해주지는 않습니다. 다만 중복될 확률이 지극히 낮을 뿐입니다. 해당 확률을 계산해보면, 임의의 2개의 랜덤 UUID를 생성했을 때 두 UUID가 같을 확률은 2의 122제곱 분의 1에 해당합니다. 만약 기존에 생성된 UUID가 1억개라면 2의 122제곱 분의 1억이 되겠죠. 2의 122제곱 분의 1 확률은 확실히 낮을 것 같은데, 2의 122제곱 분의 1억은 살짝 일어날 수도 있는 확률같이 보일 수도 있습니다. 하지만 2의 122제곱은 5316911983139663491615228241121378304 인데 일반적인 상식으로는 읽기도 어려운 숫자입니다..."

클라우드 네이티브 프로그래밍 기술 세미나 발표 자료

"...스케일 아웃 가능한 애플리케이션을 만들 때 또 중요하게 고민해봐야 할 점이 ‘상태를 가지고 있는’ 애플리케이션과 ‘상태를 가지지 않는’ 애플리케이션의 구분입니다. 만약 스케일 아웃되는 프로세스나 서버가 독자적인 상태를 가지고 있다면, 즉 저장하고 있는 데이터가 있다면 서버가 확장될 때 각각의 상태를 서로 공유해야 하는 어려움이 생겨나게 됩니다. 때문에 최근의 개발 트랜드에서는 가급적이면 애플리케이션 서버는 어떠한 상태도 가지지 않는 Stateless Application으로 구성하고, 상태 정보들은 모두 별도의 저장소 (Persistence)에 몰아버리는 흐름이 있습니다..."

엔터프라이즈 앱을 만들기 위한 안드로이드 공통 라이브러리 제작기

"...로그 하나를 찍는 것 조차도 ‘Log 클래스 쓰세요’라고 단순하게 말하고 넘어갈 수 있는 상황이 아니었습니다. 최소한 그저 파일 하나 저장했을 뿐인데 상황에 따라 느려지거나 튕겨나가는 일은 없도록, 조금 더 나아가서는 안드로이드 개발에 경험이 있거나 없거나 자신이 알고 있는 것들을 이용해서 충분히 원하는 화면과 로직을 만들어 낼 수 있도록, 그러니까 개발자들이 쓸데없는 것에 신경쓰지 않고 충분히 자신의 역량을 발휘할 수 있도록 준비해주는 작업이 필요했던 것입니다..."