Reimaginer

좋은 소프트웨어 개발자는 좋은 질문을 하는 사람이다

Voyager Woo — Sun, 19 Feb 2023 23:16:54 +0900

소프트웨어 개발은 항상 새로운 것을 배우고 문제를 해결하기 위해 끊임없이 노력하는 분야입니다. 이러한 작업에서 적절한 질문을 하고 이를 해결하는 것은 매우 중요합니다. 그래서 나는 "좋은 소프트웨어 개발자는 좋은 질문을 하는 사람이다"라는 주장에 동의합니다.

우선, 좋은 질문을 하는 것은 자신이 직면한 문제나 과제를 이해하고, 문제의 본질을 파악하는 데 매우 중요합니다. 좋은 소프트웨어 개발자는 문제를 분석하고 해결책을 찾기 위해 깊이 있는 질문을 할 수 있어야 합니다. 그들은 단순한 예/아니오 질문이 아니라, 왜 그렇게 생각하느냐는 것을 물어봄으로써 문제의 본질을 파악하려고 노력합니다. 이를 통해 좋은 개발자는 복잡한 문제를 해결할 수 있습니다.

또한, 좋은 질문을 하는 것은 다른 사람들의 경험과 지식을 존중하며 그들의 의견을 이해하려는 태도에서 비롯됩니다. 협업은 소프트웨어 개발에서 중요한 역할을 합니다. 여러 사람이 함께 일하게 되면, 각자의 경험과 지식을 공유하여 문제를 해결할 수 있습니다. 따라서, 소프트웨어 개발자는 다른 사람들의 생각과 의견을 듣고, 그것들을 존중하며 그들과의 대화를 통해 문제를 해결해야 합니다. 좋은 질문을 하면 다른 사람들의 생각을 이해하고, 그들의 의견을 수용하여 팀워크를 향상시킬 수 있습니다.

마지막으로, 좋은 질문을 하는 것은 지속적인 학습과 성장에 도움이 됩니다. 소프트웨어 개발은 계속해서 변화하고 진화하고 있습니다. 따라서, 개발자는 새로운 기술과 개념을 배우고 이를 적용할 수 있어야 합니다. 그러나 모든 것을 완벽하게 이해하거나 모든 문제에 대한 답을 알고 있지는 않습니다. 그렇기 때문에 소프트웨어 개발자는 질문을 통해 새로운 것을 배우고, 문제를 해결하기 위해 끊임없이 질문해야 합니다. 좋은 질문은 개발자가 어떤 것을 잘하고, 어떤 것을 더 배울 수 있는지에 대한 힌트를 제공합니다. 이를 통해 개발자는 항상 학습하고 발전할 수 있습니다.

고민하는 개발자

그러나, 모든 질문이 좋은 질문은 아닙니다. 어떤 질문은 너무 일반적이거나 너무 구체적이어서 본질적인 부분을 놓치거나, 다른 사람의 시간과 노력을 낭비할 수 있습니다. 따라서, 개발자는 좋은 질문을 하는 방법을 배워야 합니다. 질문을 할 때는 문제의 본질에 초점을 맞추고, 불필요한 정보를 배제하여 명확하게 질문을 구성해야 합니다.

또한, 개발자는 무엇을 질문하는지에 따라 질문을 받는 사람의 반응이 달라질 수 있다는 것을 염두에 두어야 합니다. 질문을 받는 사람은 개발자가 질문하는 이유와 방식에 대해 이해하지 못한다면, 답변을 제공하는 것이 어려울 수 있습니다. 따라서, 질문을 할 때는 예의와 존중을 기반으로 상황에 맞는 질문을 해야 합니다.

요약하자면, 좋은 소프트웨어 개발자는 좋은 질문을 하는 사람입니다. 좋은 질문은 문제 해결의 핵심이 되며, 자신과 다른 사람들의 지식과 경험을 공유하며 성장하는 데 큰 도움을 줍니다. 개발자는 좋은 질문을 구성하는 방법을 배우고, 예의와 존중을 지키면서 문제를 이해하고 해결하는 방법을 연마해야 합니다.

2022-10-26 앱푸시 관련 기능은 중요하다.

Voyager Woo — Sun, 13 Nov 2022 11:25:36 +0900

푸시 발송을 FCM 레거시 API로 발송하고 있어서, 최신 SDK를 이용해서 푸시가 발송되도록 코드를 수정했다. 페이로드 형태가 약간 변했는데, 호환될것 같은 형태로 코드를 수정했다. 당시 가지고 있던 아이폰으로 발송 테스트는 잘 했다. 그러나 배포 다음날 대량 푸시발송을 했을 때, 안드로이드폰의 지표가 이상한것을 확인했다. 확인해보니 푸시는 발송되었지만, 푸시 랜딩과 푸시를 수신했다고 하는 로그를 저장하는 기능이 동작하지 않았다. 안드로이드 개발자의 도움을 받아 원인은 파악했다. 원인은 페이로드 형태가 이전과 호환되지 않는 것이었고 호환되도록 수정해서 바로 배포했다.

이 오류로 안드로이드로 발송된 푸시가 정상동작하지 않았고, 고객은 특정 메시지의 푸시를 눌렀지만 앱만 켜지고 아무것도 안하는 경험을 했다. 우리가 의도한 대로 고객이 기능을 사용할 수 없었고, 우리는 그렇게 고객의 시간을 허비하게 했다.

실수는 결국 테스트였다. 페이로드의 변화가 분명히 있었음에도 특정 플랫폼에서만 테스트했다. 지표에 대한 확인도 없었다. 지금 수정하는 코드의 중요도에 대해서 제대로 인지하지 못했다.

이번 실수를 통해서 푸시의 기능의 중요성을 실감했다. 앱 서비스에서 푸시는 고객을 넛지하는 매우 중요한 수단이다. 그리고 정상적인 넛지를 통해서 고객은 제품을 인식하고, 제품을 더 사용하게 된다. 성장에 매우 중요한 레버인 것이다.

푸시 기능을 수정할 일은 앞으로 많이 없겠지만, 앞으로 푸시에 대한 기능 수정에 대해서 다음의 프로토콜로 테스트를 진행하려고 한다.

플랫폼별로 특정 스킴으로 랜딩이 잘 되는가?
플랫폼별로 수신 및 클릭 이벤트가 잘 기록되는가?

또 하나 제대로 배웠다.

2022 하반기 마이크로서비스 패턴 스터디 후기

Voyager Woo — Fri, 11 Nov 2022 22:49:25 +0900

스터디 소개

2022년 6월 30일부터 2022년 11월 3일까지 마이크로서비스 패턴 스터디를 진행했습니다. 진행하기 전에 신청 공고를 페이스북, 링크드인, 커리어리에 올려 두었고, 간단한 폼으로 신청을 받았어요. 어떤 일을 하시는지 여쭤보았고 왜 공부하고 싶으신지 여쭤봤습니다. 그리고 적극적으로 답해주신분들을 제 주관적으로 판단해서 스터디 멤버를 구성했습니다. 중간에 나가신 분도 계셨지만 그래도 열분정도 끝가지 스터디에 참여해주셨어요.

다양한 회사에서 오셨고 다양한 경험을 가지고 계셨어요. 운이 좋게도 각 패턴에 대해서 고민을 하셨던 경험이 있는 분들이 있어서 이야기가 재미있게 오갔습니다. 연차는 비교적 다양하진 않았어요. 2-4년차 분들이 대부분이셨어요. 그래서 더 열정적이었던 것 같아요.

13개의 장을 4달에 나눠서 진행했어요. 구글 밋에서 매주 목요일, 한 챕터당 한사람이 정리해서 공유하는 방식으로 진행했습니다. 진행중에도 질문을 하기도 하고 자신의 경험을 나누기도 하는 그런 방식으로 진행했어요. 한시간 반만 하고 싶었는데, 이야기가 재밌어서 2시간정도 한것 같습니다. 마지막 스터디는 오프라인으로 진행했는데, 역시 저는 오프라인이 훨씬 좋더라고요.

책에 대한 간단한 리뷰

이 책은 패턴을 설명하고 그 구현 코드를 설명하는 방식으로 서술되어 있어요. 만약 이 패턴이 나온 맥락과 상황을 전혀 모른다면 이 책의 효용이 매우 작을거라고 생각해요. 그래서 스터디를 진행하면서 패턴의 맥락과 상황에 대해서 제가 아는 내에서 최대한 이야기 해보려고 노력했어요. 다행히 잘 들어주시고 질문도 해주셔서 이야기가 지식이 전달되는 느낌을 받았습니다. 저도 다른 분들의 경험에서 인사이트를 얻을 수 있었고요.

이 책을 읽으면서, MSA가 당연하게 이야기되는 지금 상황에서 경험이 부족하다면, 이 책을 잘못 이해할 가능성이 조금 있다고 생각했어요. 왜냐하면 이 책에서는 분산시스템을 다루는게 어렵다고 말은 하지만 그게 얼마나 어렵고 비용이 큰 일인지는 자세히 설명하지 않기 때문이에요.

새로 프로젝트를 한다고 해볼게요. 요새 MSA가 좋다고 하니까 처음부터 MSA로 잘 만들고 싶은 마음이 있을거에요. 요구사항에 대해서 작은 단위로 기능을 쪼개고 그것을 서비스로 어렵지 않게 만들수 있을겁니다. 그리고 각 서비스에 대해서 API 요청으로 단순하게 기능을 연결해서 더 큰 기능 구현하는 것도 그리 어렵진 않겠죠. 그러나 사용자들이 그 기능을 사용하게 되고, 요구사항이 변화면서 코드도 변하게 되는 과정에서 기능의 일관성을 유지하는 것은 매우 어려운 일이죠. 각 API의 실패에 대응해야하고, 그로 인해서 발생하는 데이터의 정합 오류를 계속 맞춰줘야하니까요. 그래서 이번엔 이걸 해결하기 위해서 사가 패턴을 도입했다고 해보죠. 그 일관성을 위해서 이벤트 스트리밍 시스템을 구축하고, 각 보상 트랜잭션을 구현을 했습니다. 그런데 그렇게 이벤트로 격리된 시스템을 추적하는 것이 또 너무 어려워졌습니다. 그걸 해결하기 위해서 큰 비용을 주고 솔루션을 사용해야할 수도 있겠죠. (생각만해도 끔직하네요.) 사실 그 새 프로젝트는 그냥 하나의 서버에서 구현해도 되었을 텐데 말이죠. 그렇게 되면 데이터베이스의 트랜잭션을 이용해서 기능의 일관성을 비교적 쉽게 구현할 수도 있고요. 아마 그 팀은 그 기술 선택으로 개발 속도가 느려지고 운영 비용이 커지면서 제품의 성장을 지원하기가 매우 어려워졌을거에요. 트랜드 때문에 적정기술을 선택하지 못한것이죠.

좀 극단적이 이야기였습니다만, 결국 적정 기술을 판단하는 능력을 갖기 위해서 그 패턴이 왜 나왔는지, 어떤 상황에서 나왔는지 알아야합니다. (사실 이건 이 책에도 적혀있는 내용이에요.) 그 기술을 선택하는데 발생하는 비용이 상쇄될만한 가치를 주는지 판단할 수 있어야겠죠. 정리하면, 패턴의 상황과 맥락을 이해하기 위해서 노력해야합니다.

여담이지만, 제 개인적인 통계에 의하면 대부분의 개발자들이 지금 만들고 있는 제품은 영원히 마이크로서비스 패턴들을 도입해야할 만큼 복잡해지지 않을 가능성이 높은 것 같아요. (왜냐하면 대부분 망하니까…)

개인적으로 요즘 이런 책들이 재미있는 포인트는 바로 그 패턴이 나온 상황과 맥락에 대한 이해를 통해서, 복잡함이라는 문제를 어떤 원리로 해결해나갔는지 체험할 수 있는점입니다. 패턴이라는 해결책들을 찬찬히 살펴보면 결국 어떤 정수(essence)가 흐릿하게 보입니다. 자주 나오는 기출문제들을 계속 보다 보면, 이 시험을 관통하는 중요한 개념을 이끌어낼수 있는 느낌일까요. 저도 아직 흐릿하게 보여서 흐릿하게 말하고 있네요.

결론

"적정 기술을 판단할 수 있는 능력을 갖기 위해서, 패턴의 상황과 맥락을 이해하자!"

아무튼 오랫만에 회사 밖에서 진행했던 스터디는 유익했습니다. 마이크로 서비스에 대해서 그리고 패턴이라는 문제 해결 방법에 대해서 정리할 수 있던 시간이었습니다. 그리고 좋은 인연을 만들 수 있었고요. 다음 스터디도 기대가 됩니다.

실용적 함수형 프로그래밍을 적용하기 위한 준비 - 읽을 책

Voyager Woo — Mon, 7 Nov 2022 11:43:08 +0900

공부하려는 의도

우리가 작성한 대부분의 코드들은 테스트가 어렵고 구조를 파악하기 어렵다. 주요 기능에 대해서 테스트하기 위해서 테스트가 실행되는 시간과 상황을 명시해야지 테스트가 정상적으로 수행된다. 이것은 해당 코드가 시간과 상황에 따라 다르게 동작하는 코드이기 때문이다. 이런 코드나 기능을 부수효과(side effect)가 있다고 하고, 그렇게 부수효과가 있는 기능을 액션이라고 칭한다.

반대로 단순히 부수효과 없이 동일한 인풋이라면 동일한 아웃풋이 나오는 기능을 계산(함수)이라고 칭한다. 계산은 당연하게도 시간과 상황을 명시할 필요없이 인풋과 예상되는 아웃풋만 있다면 쉽게 테스트 가능하다.

기존 코드에서 액션과 계산, 데이터를 구분해서 코드를 구분하고, 주요 로직을 계산함수로 추출하면 주요 로직을 쉽고 빠르게 테스트할 수 있다. 그러나 어떤 코드는 함수로 추출하는 것이 오버헤드만 키울 수도 있다.

실용적인 범위 내에서 함수형 방식을 도입하여, 현재 코드에 대한 신뢰도와 유지보수성을 높이는 방법에 있을까 알아보고자 한다!

읽을 책

쏙쏙 들어오는 함수형 코딩: 실용적 함수형 기본서
클린 아키텍처 (함수형 프로그래밍 파트): 그냥 뭔 얘기 넣었을까 궁금해서
도메인 주도 설계 구현: 도메인 서비스에 대한 개념 확실히 잡기
Domain Modeling Made Functional: 도메인 모델을 함수형으로 만드는 방법 알아보기

쏟아지는 일 완벽하게 해내는 법 Getting Things Done(GTD) 독후감

Voyager Woo — Thu, 24 Feb 2022 01:58:23 +0900

쏟아지는 일 완벽하게 해내는 법

뉴욕타임스 베스트셀러 Getting Things Done의 2016년 최신 업그레이드판. 초판이 출간되자마자 이 책에서 소개한 일 정리법은 ‘GTD 방식’이라 불리며 전 세계 수많은 직장인들에게 큰 반향을 일으켰

www.aladin.co.kr

책 읽기가 너무 힘들었다. 같은 말을 반복하는 느낌이 강했다. 그 와중에 인상깊은 문장들이 있어서 꾸역꾸역 읽어나갔다. 완독한 것에 대해 스스로에게 매우 칭찬하고 싶다.

나는 지금 쏟아지는 일 속에 살고 있다. 그리고 그 일들에 휩쓸려 살아가고 있다. 심지어 오늘도. 회사일, 개인적인 일들이 맥락없이 쏟아지고 계속 집중을 스위칭하며 살아가고 있다. 이 책은 그 상황에서 나에게 많은 액션아이템을 제안했다. 올해 상반기에는 이 제안들을 연습하고 체화할 예정이다.

첫째, 모든것을 수집한다.

머리속에 아무것도 남기지 않는 습관을 길러야 한다.

그렇다. 진짜 머리속에 아무것도 남겨서는 안된다. 미완의 일들이 머리 속을 끊임없이 돌아다니고 내 평화를 방해한다. 그 망령같은 것들을 글로서 박제해야한다. 그냥 박제해서는 안되고 행동으로 구체화해서 박제해야한다. 정말 사소한 일이더라도 나를 방해할 수 없도록 수집할 것이다.

둘째, 매일 수집한 것을 검토한다.

그냥 무한정한 콜렉터가 되어선 안된다. 살아있는 목록을 만들어야 한다. 계속 완료되고 추가되고, 불필요하다면 사라지도록 관리해야한다. 책에서 구체적인 방식을 설명하지만 나는 아직 그 방식을 온전히 이해하진 못했다. 우선 나의 방식대로 목록을 관리하면서 개선을 하다보면 저자의 방식을 온전히 이해할 수 있기를 바란다.

셋째, 미루지 않고 처리한다.

방해는 없다. 인풋이 관리되지 않는 것 뿐이다.

내가 GTD를 하는 목적은 처리량의 증가이다. 많은 일을 해낼 수 있는 역량을 가지는 것이 목표이다. 머리속에 컨텍스트가 많아지면 자연스레 일을 미루게 된다. 그리고 그 미룸 때문에 스트레스를 받는다. 지금도 미루고 다른 걸 하고 싶다는 충동이 간간히 드는데, 미루지 않고 빨리 해낸다. 그게 결국 일을 더 많이 하게 할거라는 강한 믿음으로 말이다.

우선은 이렇게 세개의 액션아이템으로 이번 상반기를 보내보려고 한다. 여기에 적진 않았지만 프로젝트 관리도 할 예정이다. 우선은 꾸준히 연습하면서 나만의 방식을 찾아나가는 것으로! 상반기 회고가 기대된다.

하반기에 또 만나자!

깨달음과 액션아이템 - '분산'과의 전쟁

Voyager Woo — Sat, 8 Jan 2022 16:02:40 +0900

끊임없이 나에 대해서 관찰했다. 과연 내가 언제 기분 좋은 상태를 유지하는지, 언제 일을 잘하는지, 언제 우울해지는지 등등. 그리고 더 나은 내가 되려면 뭘 해야할지 고민했다. 최근에 그 고민에 잠정적인 결론을 얻어서 적어두려고 한다.

나를 분산시키는 모든것과 싸운다. 내가 몰입하는 시간을 최대한 늘린다.

결국 나란 인간은 외부 자극에 끊임없이 분산된다. A를 하다가도 B를 보면 그게 더 하고 싶다. 관리하지 않으면 끊임없이 외부 자극에 휘둘리고 분산된다. 그리고 그 분산은 효능감을 떨어뜨리고 나를 우울한 상태로 만든다. 이 분산에 적극적으로 대응하지 않으면 나는 좋지 않은 상태를 유지하게 된다. 심지어 휴가나 여행을 갔을 때도 그렇다. 이것 저것 다 하고 싶어서 조급한 마음에 이것 저것을 따라가기 시작하면 결국 남는게 없고 쉬었다는 느낌도 없다.

반대로, 의도적으로 온전히 집중하고 몰입하면 꽤나 기분좋은 효능감과 그에 따른 높아지는 자존감을 경험할 수 있다. ‘딥워크’라는 종교가 상실된 시대에 몰입이 신앙을 대체할만한 종교적인 경험이라고 했는데 나는 진심으로 동의한다. 일할때도 놀때도 그 상황에 몰입하는 경험을 떠올려보면 분산의 우울함 속에서도 희망이 느껴진다.

지금도 내가 하고 싶은 것을이 크게 여러 꼭지가 있다. 우선 그 꼭지들을 매우 힘들게 제거하고 있다. 올해 상반기에 집중해야할 꼭지를 하나만 정하고 나머지는 다 내 머리속에서 지울 것이다. 그리고 그 큰 꼭지를 기준으로 목표를 재구조화할 것이다.

이 깨달음 이후의 내가 매우 기대된다. 화이팅.

실수 노트 2021-07-28 돈과 관련된 기능은 중요하다

Voyager Woo — Thu, 29 Jul 2021 03:45:55 +0900

돈(금원)과 관련된 기능은 중요하다. 문제가 발생했을 때, 금전적 손실을 일으킬 수 있다. 만약 작은 회사라면 금전적 손실이 회사 전체의 리스크가 될 수 있다. 돈과 관련된 기능을 다룸에 있어서 다른 여타 기능들 보다 더 면밀하게 살필 필요가 있다. 돈과 관련된 기능을 어떻게 다뤄야할 지 동료들과 회고한 내용을 좀 적어두려고 한다.

1. 이상 상황을 곧바로 탐지할 수 있는 장치가 있어야한다.

문제는 언제든 발생할 수 있다. 문제를 빨리 감지하는 것이 중요하다. 간단하게 비즈니스 메트릭을 구축하고 임계치가 벗어났을 때 알람을 주게 한다던지, 특정 에러상황에서 에러 알림이 오게 한다던지, 이상 탐지 장치를 꼭 구축해야한다.

2. 이상 상황의 문제를 빠르게 식별하고 차단 및 해결할 수 있는 장치가 있어야한다.

문제가 발생했을 때, 빠르게 해결할 수 있어야한다. 시간이 지체되면 그 시간동안 돈이 사라질 수 있다. 예를 들어, 돈과 관련된 기능을 곧바로 닫을 수 있는 장치(피쳐 토글, feature toggle)를 만들어 둘 수도 있을 것이다. 그리고 문제의 원인을 빠르게 파악(디버깅)하기 위해서 적절한(다른 기능과 비교해 좀 더 자세한) 수준의 로깅과 관련 데이터를 저장하는 것이 필요하다고 생각한다.

3. 이상 상황을 빠르게 동료(리더)들에게 전파해야한다.

돈과 관련된 문제는 그 자체로 중요하여 동료와 리더가 알아야할 뿐더러, 엔지니어링 적인 대응뿐 아니라 사업적이 대응 등 다른 대응이 필요할 수 있다. 시간이 새벽이건 주말이건 전화, 문자등으로 어떻게든 전파할 필요가 있다.

또한 이 문제가 내가 보는 것보다 동료가 해결하는 것이 더 빠를 것 같다고 판단이 된다면 지체없이 동료에게 연락할 필요가 있다. 오래 붙잡고 있는게 절대 능사가 아니다.

4. 돈과 관련된 기능의 문제는 좀더 예민하게 받아드릴 필요가 있다.

돈과 연관된 기능의 오류나 비정상적 상태가 감지되었을 때, 다른 기능들 보다 좀 더 예민하게 받아들이고 분석할 필요가 있다. 대부분의 문제는 그때 좀 더 예민했더라면 더 빠르게 해결가능했다. 사실 어떤 오류가 돈과 관련된 기능과 연관되어있는지는 그 부분을 개발한 개발자가 아니라면 알기 어렵다. 그래도 기본적인 태도를 이렇게 가지는 것이 문제를 빨리 해결하는데 도움이 될 것이다.

5. 테스트를 잘 해야한다.

돈돠 관련된 기능은 중요도가 높기 때문에 더 꼼꼼히 테스트하고 동료와 리뷰할 필요가 있다.

그러나, 문제가 발생했다고 리뷰와 테스트에 대한 프로세스를 강제하는 것은 고민해볼 필요가 있다. 문제의 해결을 너무 보수적으로 생각하면 개발 생산성이나 속도가 느려질 수 있기 때문이다. 그래서 개인적으로는 더 빨리 식별하고 해결하는 것에 더 집중하는 것이 좋은 판단이라고 생각한다.

정리

돈과 관련된 기능은 중요하여 잘 모니터링하고 빠르게 해결하며, 선제적으로 문제를 예방할 수 있도록 해야한다. 그런데 잘 생각해보면 '돈'을 다른 중요한 것들로 대체하여도 말이 된다. 예를 들어, '개인정보'로 바꿔도 말이 된다. 이 맥락에서 중요하다고 하는 것은 실수 했을 때 리스크가 얼마나 큰지로 볼 수 있을 것 같다. 책임이 커지면서 리스크가 큰 기능을 잘 다루는 것도 꼭 필요해지는 시점이 된 것 같다.

MySql(MariaDB) Character Set과 Collation에 대한 이해

Voyager Woo — Tue, 13 Jul 2021 04:11:21 +0900

의도나 생각 없이 mysql collation을 general_ci을 쓰거나 unicode_ci를 쓰곤 했다. 이번에 unicode_ci로 통일하게 되었는데, collation 때문에 의도치 않은 상황을 겪었다. 그래서 collation에 대해서 살짝 파보았다.

Character Set

Character Set은 문자를 어떻게 표현할 지 정의한 집합이다. 세상에 존재하는 많은 문자들을 디지털로 표현하기 위해서 정의했다고 볼 수 있다. 이 시대에 우리가 주로하는 utf-8이 바로 Character Set 이다. utf-8은 세상의 대부분의 문자와 특수기호, 심지어 이모지를 1~4바이트로 표현할 수 있게 정의해두었다.

mysql에서는 utf8을 3바이트로 표현하는 선택을 했다. (세상의 모든 언어가 21bit로 저장할 수 있기 때문이라나..) 그래서 최근에 나온 이모지( 등등)는 4바이트인데 이걸 제대로 저장하지 못한다. 그래서 MySql은 2010년에 utf8mb4라는 4바이트까지 저장가능한 Character Set을 만들었다. 그래서 이모지를 자주 다는 댓글이나 채팅 서비스를 MySql을 이용해서 구현할때는 utf8mb4로 Character Set을 설정해야한다.

다른 Charater Set도 있을 텐데, 쓸일이 없어서 파보지 않았다.

Collation

collation은 text 자료형에서 문자열들을 비교 정렬하는 방식을 나타낸다. 어떤게 더 먼저나와야할 지, 어떤게 같은 건지 정의했다. 내가 알아야하는 것으로 unicode, general 방식이 있고, 그 뒤에 붙어서 대소문자를 구분하는 것을 의미하는 ci(case insensitive)가 있다.

Character Set과 Collation을 합쳐서 보통 utf8mb4_unicode_ci 이렇게 쓸 수 있다. 문자열 집합과 정렬기준을 설정할 수 있다.

골때리는 것은 이 Collation에 따라서 MySql이 임의로 특정 문자열을 같은 것으로 취급하는 것이다. 특히 unicode는 사람이 같다고 판단하는 것을 같은 것으로 취급한다. 아래의 예시에서 그것을 확인해볼 수 있다.

-- １(FULLWIDTH DIGIT ONE, %EF%BC%91) vs 1 (DIGIT ONE, %31)
select '１' = '1' collate utf8mb4_unicode_ci; 
select '１' = '1' collate utf8mb4_general_ci;

-- SPACE (%20) vs IDEOGRAPHIC SPACE(%E3%80%80)
select ' ' = '　' collate utf8mb4_unicode_ci;
select ' ' = '　' collate utf8mb4_general_ci;

첫번째 unicode collation을 사용하는 sql을 실행해보면 결과가 1(true)로 같다고 나온다. 전각(Full Width) 문자와 반각(Half Width) 문자를 같게 다루는 것이다.

만약 (사람이 봤을 때) 생긴건 같아도 다르게 취급하고 싶다면, utf8mb4_bin을 사용하면 된다.

정리

상황에 맞는 도구를 선택하고, 문제 상황에 대응할 수 있도록 Character Set과 Collation에 대해서 살짝 파보았다. 오늘은 여기까지!

참고 링크

Charset과 Collation에 대한 개념

출처: https://blog.lael.be/post/917 기술이 매우 빠르게 발전한다. 배워도 배워도 계속 배워야 한다. 최근에 라엘이가 앞으로 100년동안은 나타나지 않을 것이라고 예상했던, 4 Byte UTF-8 문자열을 보고

sshkim.tistory.com

MySQL UTF8MB4 Charset의 Collation 선택 (대소문자, 전각/반각, emoji 문자 구분)

MySQL에서 collation으로 인해 흔히 겪게 되는 문제는 알파벳 대소문자 구분 ...

blog.naver.com

전각 문자와 반각 문자 - 위키백과, 우리 모두의 백과사전

전각 문자와 반각 문자를 표시하는 한국어 명령 프롬프트 (cmd.exe). 전각 문자(全角文字)와 반각 문자(半角文字)는 주로 한중일의 인쇄 문화에서 사용하는 용어로, 문자의 폭이 일반적인 영문자의

ko.wikipedia.org

커피챗(coffeechat.kr) 파트너 이용 후기

Voyager Woo — Mon, 12 Jul 2021 02:01:42 +0900

2023-02-12 업데이트

이제 저는 커피챗 플랫폼을 이용하지 않고, 무료 커피챗 신청을 받으려고 합니다. 고민있으신 분들은 편하게 신청해주세요.

익명으로 커리어 관련한 가벼운 상담을 할 수 있는 커피챗이라는 서비스를 알게 되었다. 현재 베타 서비스 중으로, 자신의 회사와 직무, 경력을 인증한 파트너에게 커피챗을 요청하고, zoom을 통해서 20~25분 동안 가볍게 이야기할 수 있는 서비스이다. 커피챗 한번에 가격은 14,900원이고, 파트너는 10000원을 받게 된다.

지금까지 나에게 4번의 요청이 왔고, 2번의 노쇼와 2번의 실제 대화가 있었다. 그 후기를 적어보았다.

2번의 노쇼

내가 가능한 시간대를 저녁대로 설정했다. 파트너로 등록하고 커리어 상담이 왔다. 카카오톡으로 일정에 대해서 리마인드 해주고, 30분 전에 접속 가능한 zoom 링크를 공유해준다. 5분 정도의 지각은 허용하는 것으로 보인다.

정시에 들어가서 기다렸지만, 아쉽게도 상대가 오지 않았다. 그렇게 두번 정도 노쇼를 경험했다. 노쇼를 하게 되면 파트너는 건당 5000원을 받는다.

2번의 대화

현재 재직중인 회사에서 하는 인턴쉽에 대한 궁금증을 가진 커피챗 신청이 두번 왔다. 인턴쉽 관련한 공개가능한 정보(회사 블로그)를 미리 확인해 두었다. 다행히도 두번 다 노쇼없이 정시에 만나서 시간을 꽉 채워서 이야기를 나눴다.

줌으로 접속하면 기본적으로 카메라는 꺼져있다. 나는 소개나 아이스브레이킹 없이 간단하게 상황과 궁금한 점을 물어보고 그에 대해서 이야기했다. 자연스럽게 답변을 하면서 내 상황에 대해서 이야기하였다. 인턴쉽에 관련된 답변들과 이직이나 구직을 대하는 내 태도와 방법을 솔직하게 말했다.

첫번째 커피챗에서는 25분이 지나면 연결이 강제 종료되는 것을 모르고, 신나게 이야기하다가 중간에 끊어졌다. 두번째 커피챗은 25분 타임아웃을 알고 딱 25분 될때 대화를 마무리 했다.

후기

기분 좋은 내 후기!

두번의 대화를 통해서 다양한 상황에서 구직 혹은 이직을 하는 사람들의 이야기를 들을 수 있었다. 질문에 대해서 잘 준비한 덕분에 25분이라는 짧은 시간동안 충분히 유의미한 대화를 할 수 있었다.

파트너로서 커피챗을 진행하는 흐름도 걸리는 것 없이 수월하게 진행 되었다. (다만 아직은 앱이 아닌 웹서비스라 로그인을 매번 하는 수고는 있다.)

카톡으로 커피챗 신청 받음
웹사이트에 로그인 해서 시간을 정함
당일 카톡으로 리마인더
30분전 리마인더 및 줌 링크 공유
정시 혹은 몇분 전에 줌 접속
커피챗 시작
커피 챗 종료

이 플랫폼을 통해서 개발자 커리어 관련된 고민을 더 듣고, 내가 어떤식으로 도움이 될지 좀 더 구체화 하길 기대해본다.

같은 한글이 아니라고? 유니코드 완성형과 조합형의 차이!

Voyager Woo — Sun, 16 May 2021 19:29:24 +0900

뭐라고???

기존에 s3에 있는 한글 이름을 가진 엑셀 파일을 변경하고 싶어서 맥에서 같은 이름의 엑셀 파일을 만들어서 다시 업로드했다. 그런데, 덮어써지지 않았다. 엥? 그래서 이래저래 삽질을 하다보니 유니코드에서 한글의 조합형(NFD)과 완성형(NFC)이 있다는 것을 알게 되었고, 맥은 조합형을 사용한 다는 것을 알게 되었다. 그래서 엑셀 파일을 구글 드라이브를 통해서 만들고 다시 s3에 업로드 했더니 잘 되었다.

말그대로 한글 조합형(NFD)는 한글을 초성중성종성을 분리하여 유니코드로 표현한 것이다.
예를 들어, '템' 이라고하는 글자가 있다면 'ㅌ', 'ㅔ', 'ㅁ'이라고 분리해서 유니코드로 표현한다.

템 NFD

완성형(NFC)는 완성된 하나의 글자를 유니코드로 표현한 것이다.
예를 들어, '템'이라고 하는 글자가 있다면, '템' 이렇게 하나의 글자 자체를 유니코드로 표현한다.

템 NFC

특이한 점은 같은 자모음이더라도 NFC, NFD에 따라서 유니코드가 다른 것이다.

윈도우에서 'ㅌㅔㅁㅍㅡㄹㄹㅣㅅ' 이런 형태의 파일명을 간혹 본 사람이 있을 텐데, 조합형으로 작성된 파일명이 윈도우에서는 완성형 형태로 표현되어서 발생하는 이슈이다.

참고 링크

Raymond Chen이 한글날에 밝히는 윈도우의 한글 자모 분리 현상

우리에게는 "레이몬드 첸의 윈도우 개발 282 스토리"라는 책의 저자로 알려진 Raymond Chen이 이번에는 ...

blog.naver.com

한글과 유니코드

한글과 유니코드. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

Reimaginer

좋은 소프트웨어 개발자는 좋은 질문을 하는 사람이다

2022-10-26 앱푸시 관련 기능은 중요하다.

2022 하반기 마이크로서비스 패턴 스터디 후기

스터디 소개

책에 대한 간단한 리뷰

결론

관련 링크

실용적 함수형 프로그래밍을 적용하기 위한 준비 - 읽을 책

공부하려는 의도

읽을 책

쏟아지는 일 완벽하게 해내는 법 Getting Things Done(GTD) 독후감

첫째, 모든것을 수집한다.

둘째, 매일 수집한 것을 검토한다.

셋째, 미루지 않고 처리한다.

깨달음과 액션아이템 - '분산'과의 전쟁

실수 노트 2021-07-28 돈과 관련된 기능은 중요하다

1. 이상 상황을 곧바로 탐지할 수 있는 장치가 있어야한다.

2. 이상 상황의 문제를 빠르게 식별하고 차단 및 해결할 수 있는 장치가 있어야한다.

3. 이상 상황을 빠르게 동료(리더)들에게 전파해야한다.

4. 돈과 관련된 기능의 문제는 좀더 예민하게 받아드릴 필요가 있다.

5. 테스트를 잘 해야한다.

정리

MySql(MariaDB) Character Set과 Collation에 대한 이해

Character Set

Collation

정리

참고 링크

커피챗(coffeechat.kr) 파트너 이용 후기

2번의 노쇼

2번의 대화

후기

관련 링크

같은 한글이 아니라고? 유니코드 완성형과 조합형의 차이!

참고 링크