불타는 키보드

[육아휴직자 감잡기 D+5]삽질하는 신입,, 아니 클로드 바로잡기

moonionn — Thu, 19 Mar 2026 12:39:56 +0900

(질끈)

내용 미리 요약: 아직은 개발자 몇 년 더 할 수 있을 거 같은데...

저번 프론트 작업에 이어 백엔드 작업을 시켜보았다.

당연히 휘리릭 뚝딱 만들어준다.

하지만 문제가 있었다.

본인이 다 짜놓고 테스트가 실패한단다

그렇담 디버깅도 네 몫이다

...? 얘 뭔가 삽질 하는 거 같은데...?

하지만 믿고 기다려준다.

슬슬 대차게 삽질하기 시작하는 거 같다

실무였으면 토큰 아까워서 바로 껐을 거 같은데

어디까지 가나 계속 돌려보겠다

뭐해?

RestAssured에서 NullPointerException 발생하는 현상이었다.

왜 삽질이라 하냐면 보통 이런 문제는 버전충돌 문제일 가능성이 농후하다.

내가 Spring Boot 메이저 4로 실험해보고 있었는데

메이저 4가 가장 최신버전이니 RestAssured랑 호환이 안 되는 부분이 있을 수도 있다.

검색해보니 진짜 그 문제였다.

AI에게 없는 게 하나 있다면 그것은 실무진 촉이 아닐까...

아니 모르면 검색을 해보라고~

자꾸 RestAssured 메서드만 고쳐써보고 있지 말고!

그럴 수 있다^^

아니 그럴 수 없다.

기계에게 관용은 없다.

그 찰나 클로드가 드디어 버전 충돌 문제를 의심하기 시작했다.

RestAssured 버전을 다운그레이드 해본다.

근데 그게 쉽게 되겠니

버전명시가 점점 더러워지길래 그냥 꺼버렸다

(계속 시켜볼걸...!!! 지금 생각하니 조금 아쉽네...)

아

그냥 무턱대고 디버깅해서 고치라고 하면 꽤나 헤매는구나

그렇다면 방식을 바꿔야겠다

내 코드가 아닌 dependency 문제인 게 명확하니

심플한 기본 테스트코드를 별도로 만들어서 디버깅하게 한다

실제 API 테스트코드에서 디버깅시키니 부수적인 요소들에 distracted되어 AI가 헤매는 거 같달까

이번엔 예상대로 훨씬 빨리 문제를 찾아냈다.

이제 선택의 순간이다.

이 아이는 RestAssuredMockMvc를 쓰는 방안을 제시한다.

하지만 인수테스트인데 Mock을 쓰라고...? 나는 달갑지가 않다.

너도 알고 나도 아는 쉬운 방법이 있다

바로 Spring Boot 3을 쓰는 것 ! ㅎ

한큐에 촤르륵 완벽하게 만들어주는 걸 생각했는데 나의 기대가 컸나보다.

실망이야 클로드...

[육아휴직자 감잡기 D+4]프론트는 할 줄 모르지만

moonionn — Wed, 11 Mar 2026 13:36:31 +0900

이제는 AI가 코드를 다 짜준다고 하니 간단한 어플리케이션을 만들어보도록 해야겠다.

안그래도 만들어보고 싶은 게 있었다.

목적은 '남편에게 아기 밥 차리게 만들기'를 가능케 만들도록 하는 것.

전에 "냉장고 맨윗칸에 있는 토마토 꺼내서 먹여" 했다가

못 찾겠다고 씩씩대는 걸 보고는 기가 찬 적이 있다. (냉장고 문 열면 바로 앞에 있었음)

~~아니 밖에서 돈은 어떻게 벌어오는걸까?~~

무튼

이제 복직하면 아기 저녁밥은 남편이 차려야 할텐데 매우 걱정이 크다.

있는 반찬 꺼내 먹이는 건 물론이고,

요리도 해줘야 할텐데 아무것도 할 줄 모른다.

그래서 냉장고 인벤토리 관리 및 레시피 가이드가 있는 서비스를 만들어보겠다.

화면 만들기

참고로 난 프론트엔드에는 꽤 많이 취약하다.

코드만 봐도 짜증난다.

디자이너로 살면서 그 직업에 학을 떼어서 그런가

몇 픽셀, 몇 픽셀... 반응형 이런 거 쳐다보기도 싫다.

하지만 요즘은 AI가 다 해준다지?

아차차 기술 스택 먼저 정해야 되지참.

당연히 Vite + React지

이런 기술 스택은 아직 일년 전과 같구만? 다행이군.

이제 틀이 잡혔으니 일을 시켜보자.

냅다 화면 짜달라고 하면 당연히 곤란하다.

일단 이 아이디어가 내 머릿속에만 있기 때문에 이 친구에게 공유를 해줘야 하고,

기능 명세부터 정리해야 어떤 화면을 구성할지 흐름이 잡히기 때문이다.

기능명세 일부

몇 번의 티키타카를 하며 기능명세서를 작성했다.

이제 대충 홈화면에 무슨 버튼들이 필요한지 그려지기 시작한다.

이제 제미나이에게 목업 이미지를 만들어달라 요청하자.

AI 냄새가 진하게 나는 이미지가 완성됐다!

하지만 그런들 어떠하리 디자인 퀄리티는 별 상관 없다.

이야 대단한데... 라떼는 이정도 뽑아내려면 돈 내야 했는데...!

여기서 조금만 가다듬어주고 바로 만들어달라 해봐야겠다.

혼자 뭘 뚝딱뚝딱 하더니 몇초만에 완성됐다.

이야! 이게 요즘 세상의 코딩? 어디 한번 코드를 볼까?

약간의 밤티스러운 부분들이 있지만 초안이라 감안되는 수준이다.

생각보다 드래프트 코드를 잘 구성해서 당황스럽다.

다른 페이지도 만들어보자.

아 적응 안 되네;

다들 나 빼고 이렇게 꿀 빨면서 개발하고 있던거?

저 이제 오후 3시에 퇴근해도 되나요

코드도 알아서 리팩토링 하는군

사실 프론트는 내가 잘 아는 영역이 아니라서 감탄만 하다 끝난 거 같은데

본격적으로 API를 만들게 시키면 문제점이 드러나지 않을까하는 기대감(?)이 있다.

과연...

아무도 관심 없을 워킹맘 이야기

moonionn — Thu, 5 Mar 2026 02:51:34 +0900

아기가 어린이집에 갔다.

홀가분한가? 아니, 안쓰럽다.

걷지도 못하는 게 아침마다 사회생활을 하러 간다.

이제 내 아이는 가족이 아닌 타인의 손에 자란다.

<나는 솔로> 30기에는 공사현장에서 일하는 '영자'라는 당찬 여성이 나온다.

그녀는 아기를 낳으면 당연히 기관에 보내고 자신의 생활을 유지할 거라 말한다.

남편과 나는 그 순간 서로를 바라보며 실소했다.

당연히 앞날을 모르겠지.

무자녀였던 나도, 아니 아기가 10개월이 될 때까지의 나조차도 그렇게 생각했지.

관심도 없었지 사실.

그래서 제목이 그렇다.

"아무도 관심 없을 워킹맘 이야기"

아기를 낳고 키우는 건 정말 기이한 경험이다.

태어나 처음 느껴보는 생경한 감정들이 매일 파도처럼 밀려온다.

30년간 굳건했던 나의 가치관과 신념이 어처구니없이 무너진다.

"저를 낳고 전업주부가 된 엄마를 보며, 저는 절대 결혼하지 않겠다고 다심했습니다."

고등학교 1학년 때 했던 나의 자기소개다.

'일 관두지 말걸'하며 툴툴대는 엄마에게 질려버린 탓이었을 터.

무엇보다 남자랑 똑같이 교육받아놓고 전업주부가 되는 건 억울한 일이라 여겼다.

아! 나 또한 그랬듯, 이 '엄마'라는 존재를 우리는 얼마나 쉽게 폄하해왔던가.

입주 육아도우미와 가정부의 대략적인 월급은 각각 500만 원 선이다.

엄마의 노동이 실로 어마어마하다는 걸, 왜 직접 당해보고서야 깨닫게 되는 걸까.

멋진 프로젝트를 성공시켜 사회에서 이름을 날리는 게 정말 중요한 일이었나?

어쩌면 나는 그저 남의 인정을 받아야만 성공한 것이라 믿어왔던 건 아닐까.

이젠 나도 잘 모르겠다.

많은 엄마들은 그럼에도 불구하고, 각자의 사정으로 워킹맘이 된다.

나 역시 아이가 세상 무엇보다 소중하지만, 이런저런 연유로 다시 워킹맘이 될 예정이다.

그런데 신기하게도, 워킹맘이 되고 나서야 일에 대한 태도가 더 단단해졌다.

미혼일 땐 "맘에 안 들면 관두지 뭐"라는 생각이 일상다반사였다.

"회사는 왜 다니니?" 라고 누가 묻는다면

"코딩이 재밌는데요, 코딩한다고 돈도 줘요"라고 답할 정도로 재미를 좇아 일을 했다.

하지만 알다시피 일은 반드시 재미없어지는 순간이 온다.

나는 운명의 장난처럼 딱 그 시기에 엄마가 되었다.

이제 누가 "회사는 왜 다니니?" 라고 묻는다면

아이러니하게도 "아기가 있어서요" 라고 대답하게 된다.

그리고 이 목적은, 투지를 그 무엇보다 강하고 지속적으로 만들어준다.

2021년, 어떤 회사에 입사해야 할지 고뇌하던 사회초년생 시절이었다.

한 시니어가 내게 해준 말이 기억에 남는다.

고민이 많았나보구나.
그런데 있지, 어떤 회사에 다니느냐는 인생 전체에서 사실 그렇게 중요하지 않아.
인생의 갈림길은 누구랑 결혼을 하느냐, 아이를 낳느냐, 어떻게 키우느냐, 그런거더라.
그러니 지금 너의 선택에 무게를 두고 스트레스받을 필요 없다.

아마도 나는 중요한 인생의 갈림길에 놓여 있다.

어떻게든 해낼 거라는 걸 안다.

어떻게든 아이도 자랄 거라는 것도 안다.

이렇게 생각할 수 있는 이유조차, 부모님이 나를 안정적으로 키워주셨기 때문임을 이제야 깨닫는다.

부모가 된다는 건, 정말이지 경이로운 일이다.

[육아휴직자 감잡기 D+3]개발자 괜히 했나

moonionn — Sun, 1 Mar 2026 02:02:28 +0900

D+3가 늦은 이유: 독감

내가 아니라, 남편이 독감에 걸렸다.
(저번엔 혼자 코로나 걸리더니…?)

아기에게 옮기면 안 되니 남편은 셀프 격리에 들어갔다.
그렇게 나는 일주일간 독박육아와 독박살림을 맡게 되었다.

그래서였을까.
남편이 가정에 복귀하자마자 이번엔 내가 원인 모를 두통과 근육통에 시달렸다.

(그렇다고 편히 쉬진 못했다^^... 난 엄마..니까...ㅎ)

아기 있는 집은 한 명이 아프면 모두가 올스톱 된다더니 정말 그랬다.

한계 봉착

몇 주간 OpenClaw가 핫하다.

기술 진행 속도가 너무 빠르다.

돌쟁이 아기를 키우며 이 모든 걸 따라잡는 건 불가능에 가깝다.
“개발자 워킹맘”은 과연 가능한 것일까?

멀티에이전트도 마찬가지다.
요즘은 AI가 알아서 일하게끔 만드는 흐름이 대세인 듯하다.

하지만 휴직자인 나는 그만한 토큰 비용을 감당할 재력도 없고
로컬 LLM을 돌릴 빵빵한 컴퓨터도 없다.

그리고 실무에서 이렇게 헤비하게 AI를 사용할까?

우리 회사 기준으로 생각해 보면... 아니라고 본다.

아, 이 방향은 아닌 것 같다.

AI 트렌드를 쫓아가는 데 에너지를 다 쓰는 건
지금의 나에게는 효율이 너무 떨어진다.

본질과 기본기를 다시 다지자.

현재 상황에서 할 수 있는 최선은 그렇다.

[육아휴직자 감잡기 D+2]AI 맛보기

moonionn — Fri, 6 Feb 2026 03:28:15 +0900

1년 사이에 강산이 변해버렸다.

라떼는 챗지피티랑 코파일럿이 전부였는데...

Cursor? Antigravity? 갑자기 난데 없는 IDE들이 눈에 띈다.

백문이 불여일견. 우선 Cursor를 깔아본다.

화면이 익숙한듯 낯설어요

좋은 모델을 쓰려면 돈을 내란다.

무료로 몇마디 좀 주고받았더니 또 돈을 내라고 한다.

이젠 코딩하려면 돈 내야 하는 세상인가?

오픈소스 마인드는 다 어디가고 전부 타락해버렸군.

하지만 어림도 없지

Antigravity로 갈아탄다.

아무래도 Cursor에 비하면 사용량 리밋이 꽤 자애롭다.

아, 그 사이에 Claude 결제도 그냥 질렀다.

여전히 적응 안된다. 코딩하려면 돈을 내야 한다고?

세상이 미쳐 돌아가는구만!

아무래도 기본적인 기능부터 고찰해봐야겠다.

회원가입 기능부터 만들어보자.

짠

뚝딱 만들었다.

사실 AI 에이전트 기능을 탐색해보는 과정들이 있었는데

하나하나 기록해두지 못했다..;

새로운 장난감 갖고 노느라 너무 빠져 있었나보다.

구현 과정

일단 제미나이에게 기능명세서부터 작성해달라 했다.

기능명세서를 먼저 작성해볼까?

우선 기본 인증기능부터.
회원을 생성하려면 이메일, 전화번호, 비밀번호가 필요해.
탈퇴, 토큰 갱신 등 기본적인 어플리케이션 인증기능들은 다 필요하고.
특히 전화번호는 인증절차를 거쳐야 할 거 같아.
엔드포인트는 "/auth"로 시작하는 게 좋겠어.

그 외 추가적으로 필요한 기능이 있다면 알아서 작성해줘.

적당히 "너 알아서 해줘" 라는 늬앙스로 부탁했다.

이것이 바이브코딩?

제미나이가 뽑아준 기능명세서 엑셀시트이다.

뭔가 맘에 안 드는 부분들이 있다.

이번엔 우리의 오랜친구 챗지피티에게 크로스체크를 부탁한다.

위 기능명세서 첨삭해줘.
소셜로그인 기능은 지금 굳이 필요 없으니 지워줘.

미약하게나마 개선된 것 같다.

불필요한 기능이 제거되었고

API경로가 조금 더 보편적이고 RESTful해졌다.

(요즘 세상에도 이게 미덕인지는 잘 모르겠으나)

이제 클로드에게 명세서대로 코딩을 부탁한다.

그냥 명세서를 던져준다.

그런데!

그냥 맡겨놨더니 구현을 개발새발로 한다...!

그러니까 코드는 잘 짜는데...

불필요한 if문들과 위계는 죽 쒀먹은 코드를 내놓는다.

아!

아직은 결국 인간이 개입해야 하는군. (당연한 얘기)

바이브코딩은 비개발자들이, 혹은 급한 데모 만들때나 쓰고

개발자들은 프롬프트 엔지니어링을 해야 하는군. (어디서 들어본 얘기)

그런데 어차피 코드 개발새발 써놔도

이젠 AI가 대신 다 읽어주고 파악해주는데

예전처럼 품질을 신경쓸 필요가 있나?

라는... 남들은 이미 다 해봤을 고민을 이제 해보기 시작한다.

[육아휴직자 감잡기 D+1]변해버린 세상

moonionn — Wed, 4 Feb 2026 20:33:07 +0900

아기를 낳은 지 어언 1년.

여유가 생겼냐고 묻는다면, 딱히 그렇지는 않다.
오히려 복직을 앞두고 본업에 대한 압박이 슬슬 몰려오기 시작했다.

그래서 정말 오랜만에 링크드인에 들어가 보았다.
앤트로픽, 클로드, 커서, 에이전트 어쩌고저쩌고… ‍
피드는 온통 모르는 단어들로 가득했다. ‍

아아…
1년 사이에 도대체 무슨 일이 있었던 거지?

남편에게 물었다.

‍ : 요즘은 AI가 다 코딩해 주는 거야?
‍♂️: 자기 회사 복귀해서 손으로 코드 치고 있으면, 옆사람들 동공지진 날걸
‍ : ………?

이 업계가 원래 이런 곳이었을까.(원래 좀 그렇긴 했지만)

아니면 내가 휴직한 타이밍이 유독 안 좋았던 걸까.(이것도 좀 그런 것 같고)

불안하다.
절망적이다.
걱정된다.
자신감은 눈에 띄게 하락 중이다.

그래도! 이대로 주저앉을 수는 없다.

콩알만 한 아들을 위해서라도,

잠을 줄여서라도(이미 하루에 5시간 밖에 못 자지만)

다시 적응해야한다!

엄마는…

아마도 무엇이든 할 수 있다.
아자아자.

다음화: AI 에이전트 에디터 체험기

1년 3개월만에 쓰는 글

moonionn — Thu, 13 Nov 2025 02:38:38 +0900

부제 : 엄마가 된 직장인

마지막으로 글을 써본 게 작년 여름이다. 사실 그때도 나에겐 큰 변화가 일어나고 있었다. 임신 4개월 차였다. 그 이후로 여러 초안들을 작성했지만 완성시키지 못했다. 그렇게 겨울에 출산했고, 이제 아기는 어느덧 9개월 차가 되었다.

아기는 100일만 넘으면 밤에 쭉 잔다고 누가 그러던가. 우리 아기는 아직도 밤 9시에 겨우 잠들고, 새벽에 한두번씩 깬다. '100일의 기적'은 SNS가 만들어낸 허상이었다. 이유식 만들고 먹이는 것도 이렇게 힘든 일이었다니, 왜 아무도 알려주지 않았을까. 밤 9시에 겨우 재우고 나면 씻고, 밀린 집안일을 하고, 이유식을 만든다. 남편의 아침 메뉴까지 챙긴다. 중간중간 깨는 아기를 달래다 보면 어느새 새벽 3~4시. 아기가 아침 8시에 깨니, 수면 시간은 하루 4~5시간 남짓이다.

그렇게 살다 보니 코딩도, 개발도, 세상사도 모두 뒷전이 되었다. 물론 걱정됐다. 출산 후 IT업계는 빠르게 변했다. 출산휴가 전엔 낯설기만 했던 '바이브코딩'과 'MCP' 같은 개념이 이제는 뉴노멀이 되어 있었다. 이런 걱정들은 마음 한켠 작은 상자에 넣어두었지만, 언젠가 마주해야 할 현실임을 안다.

블로그도 마찬가지다. 이제 사람들은 모르는 게 생겨도 구글링을 하지 않는다. 스택오버플로우를 아직도 쓰는지 모르겠다(현직에 있다면 알려주길 바란다). 그래서 처음엔 '이제 블로그 시대는 끝난 게 아닐까' 생각했다. 그런데 좀 더 생각해보니, 결국 블로그는 '나'를 표현할 수 있는 몇 안 되는 공간이라고 결론내렸다. 아기 키우며 고군분투하는 개발자의 이야기는 AI가 경험하지 못하는 범위이지 않을까.
~~(링크드인은 너무 부끄럽다)~~

1년 안에 정말 많은 일들이 있었다. 결혼, 임신, 출산, 육아, 신혼집마련 등등... 지금은 12월에 있을 이사 준비로 바쁘다. 이 이야기를 하는 이유는, 이사만 잘 끝나면 다시 사회로 복귀할 연습을 해야 하기 때문이다. 오랜만에 블로그에 들어온 것도 그 때문이다. 인생과업(?)이 어느정도 끝나가니 원래 하던 일들이 생각나기 시작한다. 글을 쓰고 있는 지금도 새벽 2시이지만 이렇게나마 짬을 내서 글을 다시 써본다.

(스프링을 모르는 자의) 넥스트스텝 ATDD, 클린 코드 with Spring 교육 후기

moonionn — Mon, 19 Aug 2024 17:07:36 +0900

https://edu.nextstep.camp/c/R89PYi5H/

ATDD, 클린 코드 with Spring

edu.nextstep.camp

올 상반기 넥스트스텝에서 주관하는 ATDD 클린코드 교육을 들었습니다. 그리고 교육이 끝난지 반 년이 지난 지금, 이제서야 후기를 작성해보려 합니다. (상반기에 개인적으로 너무 바빴다고 핑계를...)

참고로 스프링은커녕, 자바도 잘 모르는 상태로 교육에 참여했기 때문에 "스프링을 해본 적이 없어 고민"인 분들에게 이 후기가 조금이나마 도움이 될 수 있길 바라봅니다. 결론부터 말하자면, 고민하지 말고 신청하세요!

교육에 참여하게 된 이유

신입으로 입사한 첫 회사에서 2년을 쭉 다니다 보니, 슬슬 바깥세상이 궁금해지기 시작했습니다. 컨퍼런스에 참석해 연사의 이야기들을 듣는 것보다, 직접 부딪혀 무언가를 만들 수 있는 경험이 필요했습니다. 때마침 개발자 교육 플랫폼인 넥스트스텝에서 "ATDD, 클린코드 with Spring"이라는 강의가 오픈했고, 스프링 경험이 전무했지만 이래저래 따지면 할 수 있는 게 없을 것 같아 무작정 교육에 참여하였습니다.

ATDD란 무엇인가

누군가 "ATDD"를 언급하자, 어떤 사람이 "ATDD는 TDD의 오타인가요?"라고 되물은 걸 본 적이 있습니다. 이렇듯 ATDD는 TDD에 비해 개발자들에겐 낯선 존재입니다. 그렇다면 ATDD는 도대체 뭘까요? 쉬운 설명을 위해 예시 상황을 가져와 보았습니다.

여기 개발자, 기획자, QA엔지니어, 디자이너로 구성된 팀이 있다고 가정해 보겠습니다.

그리고 그들에게는, 한 달 내에 새로운 기능을 개발하고 배포까지 해야 하는 미션이 주어졌습니다.

빠듯한 스케줄을 두고 이 팀은 분주해지기 시작합니다. 커뮤니케이션은 점점 산만해지고, 누군가는 업무 공유를 받지 못할 수도 있습니다. 떨어지는 업무 효율성만큼 결과물의 퀄리티도 낮아질 건 불 보듯 뻔합니다.

이 상황은 이 팀원들이 능력이 없어서 발생한 게 아닙니다. 아직 협력 시스템이 갖춰지지 않거나 총괄 매니저가 없는 팀이라면 어디서든 일어날 수 있는 상황입니다. 그렇다고 시스템 탓만 하며 이를 방치할 수는 없는 노릇입니다.

상황을 심각하게 받아들이고 있던 개발자가 어느 날, "우리 이러지 말고 ATDD를 도입해 봅시다."라는 제안을 하며 유저 시나리오라는 걸 작성해 옵니다. 이 유저 시나리오에 모두가 수긍한다면, 이것은 이제 해당 기능의 "인수 조건(Acceptance Criteria)"이 됩니다.

ATDD의 기본, 인수조건

인수 조건은 Given, When, Then 세 가지로 크게 나눌 수 있습니다.

Given

ex: 로그인한 회원이 배송상품을 구매한 뒤

시나리오를 진행하기 위한 최초 전제 조건입니다.

When

ex: 내 배송현황을 조회하면

시나리오가 테스트하고자 하는 바를 드러내는 메인 액션입니다.

Then

ex: 구매한 상품의 배송상태를 조회할 수 있다.

시나리오의 예상결과입니다. 즉, 테스트의 예측 결괏값입니다.

인수 조건에 따라 작성된 테스트를 인수 테스트라 명칭 하며, 기능 개발 전 인수 테스트를 먼저 작성하는 걸 ATDD(Acceptance Test Driven Development)라 칭합니다.

백엔드 API 개발 중 작성된 인수 테스트는 아마 아래와 비슷한 모양새를 지닐 겁니다.

const VALID_USER = {
  email: "test@test.com",
  password: "test1234"
};

const DELIVERY_PRODUCT = {
  id : 1,
  price: 100000
};

// Given : 로그인한 회원이 배송상품을 구매한 뒤
// When  : 내 배송현황을 조회하면
// Then  : 구매한 상품의 배송상태를 조회할 수 있다.
test('배송현황 조회 성공', () => {
  const app = startTestServer();
  
  // Given
  const token = app.post('auth/token', VALID_USER);
  app.post(`purchase/${DELIVERY_PRODUCT.id}`, { Authorization: token.accessToken });
  
  // When
  const result = app.get('my/deliveries', { Authorization: token.accessToken });
  
  // Then
  expect(result).contains(DELIVERY_PRODUCT);
})

인수 테스트를 작성함으로써 얻을 수 있는 이점은 아래와 같습니다.

기능 명세에 대한 합의점이 명확해진다. (앞선 예시와 같은 상황)
API 호출 흐름이 명확해져 개발자들끼리의 의사소통이 원활해진다.
빠르게 개발할 수 있다.

1번에 대한 예시는 이미 서술했으므로 2번부터 순차적으로 그 이유를 예시와 같이 설명해 보겠습니다.

API 호출 흐름이 명확해져 개발자들끼리의 의사소통이 원활해진다

위 예시의 백엔드 테스트코드는 문서의 역할도 할 수 있습니다. 일반적인 경우 스웨거 같은 오픈 API가 제공되곤 합니다. 그러나 시나리오가 복잡한 기능이라면 API 호출 흐름도 복잡해집니다. 이 경우 인수테스트가 있다면, 상황에 따른 API 호출순서가 가시화된다는 장점이 있습니다.

빠르게 개발할 수 있다.

- 병합에 대한 명확한 기준점 제공

팀, 혹은 팀원에 따라 PR에 대한 승인 기준이 제각각인 경우는 흔합니다. 프로토타입을 개발 중인 팀이라면 더더욱 그럴 겁니다. 이럴 때 ATDD는 PR이 통과되어도 되는지에 대한 기준점을 제공해 줍니다. PR에 포함된 인수테스트가 통과한다면, 그 PR은 병합되어도 되는 것이죠. 기술적으로 아쉬운 부분은 추후 보완할 기회가 제공될 때 수정하도록 합니다.

- 테스트 케이스를 먼저 공유하면 엉뚱한 길로 빠지지 않는다

이건 TDD 개념이 보편적으로 주장하는 사안이기도 합니다. 실무에 적용했을 때 가장 효용성을 느낀 게 바로 이 부분인데, 코드를 짜기 전 테스트 코드를 합의하는 시간을 가지면 업무 방향성을 빠르게 잡는 데 도움이 되더랍니다.

왜냐하면 기능 명세에 대한 합의가 이루어졌다 하더라도 이를 구현하는 방향은 가지각색이기 때문입니다. API 엔드포인트 디자인은 물론, 어느 레포지토리에 이 기능을 작성할지 등등... 그렇기 때문에 인수 테스트 껍데기를 먼저 첨삭받는다면 엉뚱한 길로 샐 일을 막을 수 있습니다.

describe('인증/인가 API', () => {
  // Given: 액세스 토큰으로 로그인 한 뒤
  // When: 내 정보 페이지로 접속하면
  // Then: 내 정보를 조회할 수 있다
  test('로그인 성공' async () => {
    // Given
    const login = api.post(`/login`)
                     .query({ email: 'test@test.co.kr', password: '1234' });
	// When
    const mypage = api.get(`/me`)
                      .query({ accessToken: login.accessToken })
    // Then           
    expect(mypage.body.email).toBe('test@test.co.kr');
  });
});

예를 들어 어떤 동료가 위와 같은 테스트 파일을 먼저 작성했다고 가정해 봅시다.

어떤 리뷰를 해주고 싶은가요? 저라면 아래와 같은 부분에 대해 코멘트할 것 같습니다.

POST /login이라는 엔드포인트는 /auth라는 대분류 엔드포인트 하위로 두었으면 좋겠고
로그인할 때 이메일과 패스워드 정보를 쿼리스트링으로 보내는 것도 고쳤으면 싶고
내 정보 조회할 때 액세스 토큰을 헤더가 아니라 쿼리스트링에 담는 것도 고쳤으면 싶네요.

이 테스트 케이스를 작성하고 첨삭받는 데까지 걸리는 시간은 매우 짧습니다. 하지만 잘못 디자인된 API를 수정하는 데에는 엄청난 비용이 듭니다. 테스트 케이스를 미리 합의한다면 이런 불필요한 추가작업에 리소스를 낭비하지 않아도 됩니다.

회사 프로젝트에 도입해 보기

마침 복잡한 기능의 데모 프로덕트 개발을 진행하고 있던 터라 배운 바를 바로 적용해 보았습니다.

혹시 몰라 중요부분들 블러 처리 ㅎㅎ

위 코드는 유닛테스트입니다. 이렇게 코어 모듈 개발만 담당하는 경우에도 Given/When/Then 템플릿을 활용해 함수의 사용법과 기능을 명시하면 테스트 설명이 좀 더 명확해집니다. 특히 해당 프로젝트가 비교적 복잡하고 낯선 도메인에 해당되었기 때문에 이런 방식은 개발자들 간 도메인 지식 간극을 줄이는 데 큰 도움이 되었습니다.

개인적인 후기

자바/스프링을 못하는 사람도 할 수 있는가?

- YES, but...

남들보다 두 배 가량 애를 써야 비슷한 코드 흉내라도 낼 수 있습니다. 이 말인즉슨 회사 7시 퇴근해도 새벽 2시까지는 코딩해야 한다는 뜻

얼마나 힘든가?

- 자바/스프링을 할 줄 안다면 주말 포함 매일 1~2시간 정도만 투자하면 될 거 같은데,

만약 그게 아니라면...

다음에도 넥스트스텝 교육과정에 참여할 의향이 있는가?

- YES

Row vs Column oriented Databases

moonionn — Mon, 4 Dec 2023 00:29:15 +0900

혹시 통계 데이터 조회를 위해 구글 빅쿼리 혹은 아마존 레드시프트를 사용한다는 말, 들어보셨을까요? 흔히 사용되는 MySQL, PostreSQL 등 외에도 이런 별도의 데이터 저장소들을 사용하는 경우는 많이 보았을 겁니다. 막연하게 "그냥 MySQL과는 다른 어떤 통계용 DB? 데이터 웨어하우스? 인가보다?" 라고 생각하고 넘어갈 수 있지만, 오늘은 이 데이터 저장소들이 어떻게 차이가 나는지 적어보고자 합니다.

데이터베이스 시스템은 데이터를 어떻게 저장하느냐에 따라 크게 두 가지로 나뉩니다. 하나는 행(row)을 중심으로 저장하는 row oriented (한국말로는 행 기반, 혹은 행 지향), 다른 하나는 열(column)을 중심으로 저장하는 column oriented (한국말로는 열 기반, 혹은 열 지향) 방식입니다. 말로만 설명하면 이해하기 어려울 듯 싶으니 예시 테이블을 하나 준비해 보았습니다.

이해를 돕기 위한 payment 테이블 (primary key 외 인덱스 없음)

id	payer	amount	state	created_at	updated_at
1	James	100	Completed	2022-12-03	2022-12-03
2	John	200	Cancelled	2022-12-03	2022-12-04
3	Parker	300	Completed	2022-12-04	2022-12-04
4	Anne	400	Cancelled	2022-12-05	2022-12-06
5	Adam	500	Completed	2022-12-09	2022-12-09
6	Mary	600	Requested	2022-12-09	2022-12-09

위 테이블과 같은 데이터를 저장해야 한다고 할 때, Row vs Column 데이터베이스는 어떤 차이를 보일까요?

두 시스템을 비교하기에 앞서 디스크 읽기의 최소 단위인 블락(block)에 대해 잠깐 설명하고자 합니다. 우리는 데이터베이스, 즉 디스크에서 데이터를 읽어오는 작업을 I/O(Input/Ouput) 라고도 표현하죠. 이 때 한 번의 I/O로 읽어오는 최소 데이터 단위를 블락(block)이라고 합니다. 즉 최대한 적은 I/O로 원하는 데이터를 얻는 것이 효율적인 디비 사용의 핵심이라고 할 수 있습니다. 이 row/column oriented 데이터베이스의 차이점 또한 이 블락 단위 안에 데이터가 어떻게 저장되는지에 따라 생긴다는 점을 일러두고 싶습니다.

* MySQL의 경우 디폴트 블락 사이즈는 16KB

Row-oriented database

Row-oriented의 경우 행 단위로 하나의 블락이 구성됩니다.

예시의 payment 테이블인 경우 간단하게 아래 두 개의 블럭으로 구성된다고 가정해 보겠습니다. 블럭 안에 여러 행들이 포함되어 있으니, 내가 원하는 건 단 하나의 행 데이터라 하더라도 해당 블락 안에 포함된 그 외 행들도 읽어오게 되어 있습니다.

블럭 1

1	James	100	Completed	2022-12-03	2022-12-03
2	John	200	Cancelled	2022-12-03	2022-12-04
3	Parker	300	Completed	2022-12-04	2022-12-04

블럭2

4	Anne	400	Cancelled	2022-12-05	2022-12-06
5	Adam	500	Completed	2022-12-09	2022-12-09
6	Mary	600	Requested	2022-12-09	2022-12-09

만약 여기서 아래와 같은 쿼리를 날린다면 내부적으로 어떤 일이 일어날까요?

SELECT payer FROM payment WHERE state = 'Requested';

첫 번째 읽어온 블럭의 경우 state가 Requested인 행이 없으니 다음 블럭을 또 읽어와야 합니다. 두 번째 읽어온 블럭에 Requested라는 값이 있는 행(id=6)을 발견하게 되는데 해당 행에 payer 컬럼에 대한 값도 포함되어 있으므로 Mary라는 결과물을 얻을 수 있습니다.

예시의 경우 두 개의 블럭만 있었지만 만일 실세계에서 사용되는 데이터베이스였다면 엄청나게 많은 블락을 읽어와야 하고, 이 말인 즉슨 엄청나게 많은 I/O 작업을 필요로 한다는 뜻이기도 합니다.

해당 쿼리를 row-oriented 데이터베이스인 MySQL에서 explain 해봐도 풀스캔을 시행하는 걸 확인할 수 있습니다.

그렇다면 아래 쿼리는 어떨까요?

SELECT * FROM payment WHERE id=6;

조건절에 쓰인 id 컬럼은 primary key이기 때문에 엉뚱한 블락을 가지고 올 필요도 없이 바로 아래 행에 접근할 수 있습니다. (primary key, index에 대한 글이 아니니 추가 설명은 스킵하도록 합니다.)

Mary

600

Requested

2022-12-09

중요한 점은, row-oriented의 경우 이미 이 행이 가지고 있는 컬럼값들이 동시에 조회되기 때문에 SELECT * 에 대한 부담이 비교적 덜 하다는 점입니다. 이 부분은 후술할 column-oriented를 보면 얼마나 극명하게 차이가 나는지 아실 수 있습니다.

이제 Aggregation 성격의 쿼리를 실행해 보겠습니다.

SELECT sum(amount) FROM payment;

첫 번째 블럭을 읽어옵니다. 블럭에 포함된 행들의 amount 컬럼 값들을 합칩니다.

1	James	100	Completed	2022-12-03	2022-12-03
2	John	200	Cancelled	2022-12-03	2022-12-04
3	Parker	300	Completed	2022-12-04	2022-12-04

이제 두 번째 블럭을 읽어서 동일한 작업을 진행합니다. 예상 가능하다시피 테이블의 규모가 크면 클 수록 I/O는 늘어납니다.

4	Anne	400	Cancelled	2022-12-05	2022-12-06
5	Adam	500	Completed	2022-12-09	2022-12-09
6	Mary	600	Requested	2022-12-09	2022-12-09

이 경우도 마찬가지로 풀 테이블 스캔을 시행해야 함을 알 수 있습니다. 다시 설명하자면, 현재 나의 관심 밖에 있는 payer, state, created_at, updated_at 컬럼 데이터들 또한 모두 메모리에 올라가게 됨을 의미합니다.

위 사례들에서 보았듯 통계성 데이터 조회에 row-oriented는 적합하지 않습니다. 물론 인덱스를 별도로 추가하면 또 달라지겠지만, 인덱스는 어디까지나 보충장치일 뿐 이는 근본적으로 사용 목적에 부합한 툴이 아님을 알 수 있습니다. 그리고 아무리 인덱스나 쿼리 튜닝으로 호흡기를 달아놔도 column-oriented와 비교했을 때 그 한계가 명확히 드러나는 시점이 올 수도 있습니다.

Column-oriented database

그렇다면 column-oriented는 뭐가 다를까요? 아까 테이블을 다시 봅시다.

id	payer	amount	state	created_at	updated_at
1	James	100	Completed	2022-12-03	2022-12-03
2	John	200	Cancelled	2022-12-03	2022-12-04
3	Parker	300	Completed	2022-12-04	2022-12-04
4	Anne	400	Cancelled	2022-12-05	2022-12-06
5	Adam	500	Completed	2022-12-09	2022-12-09
6	Mary	600	Requested	2022-12-09	2022-12-09

column-oriented의 경우 블락 단위는 대략 아래와 같습니다.

동일한 컬럼의 값 군집이 하나의 블락을 이루며, 각 데이터들에는 어떤 행에 매칭되는 데이터인지 유추할 수 있는 유니크 키(여기선 primary key, 즉 id)가 포함되어 있습니다.

(아래 다이어그램은 단순화되었지만 하나의 컬럼 != 하나의 블락 입니다. 엄연히 블락도 리밋 사이즈가 있기 때문에 하나의 컬럼에 대해 여러 블락이 생성됩니다!)

James:1

John:2

Parker:3

Anne:4

Adam:5

Mary:6

100:1

200:2

300:3

400:4

500:5

600:6

Completed:1

Cancelled:2

Completed:3

Cancelled:4

Completed:5

Requested:6

2022-12-03:1

2022-12-03:2

2022-12-04:3

2022-12-05:4

2022-12-09:5

2022-12-09:6

2022-12-03:1

2022-12-04:2

2022-12-04:3

2022-12-06:4

2022-12-09:5

2022-12-09:6

이제 여기에 아까 row-oriented에 사용했던 쿼리를 순차적으로 사용해 비교해보겠습니다.

SELECT payer FROM payment WHERE state = 'Requested';

WHERE 절에 쓰인 것은 state 컬럼입니다. 따라서 우리는 state 컬럼에 대한 블락을 조회하면 됩니다. 그리고 그 중 Requested 값을 지닌 데이터는 id 6을 가리키고 있습니다.

Completed:1

Cancelled:2

Completed:3

Cancelled:4

Completed:5

Requested:6

그럼 이제 payer 컬럼에 대한 블락을 조회해 해당 id를 지닌 데이터를 조회하면 원하는 값을 얻을 수 있습니다.

James:1

John:2

Parker:3

Anne:4

Adam:5

Mary:6

힌트 없이 모든 데이터를 스캔해야 했던 row-oriented와 비교해보면 효율적으로 보일 수 있습니다만, 이는 단순히 payer라는 단 하나의 컬럼만을 조회하기 때문입니다. 만일 payer 뿐 아니라 state, amount 등 여러 컬럼을 조회하려 한다면 과연 그 때도 효율적이라고 할 수 있을까요?

이제 모든 컬럼 값을 조회하는 쿼리를 비교해봅시다.

SELECT * FROM payment WHERE id=6;

각 데이터마다 id값을 지니고 있기에 찾는게 어려운 건 아닐테지만, 문제는 모든 컬럼을 가지고 와야 하기 때문에 모든 컬럼에 대한 블락을 읽어와야 합니다.

James:1

John:2

Parker:3

Anne:4

Adam:5

Mary:6

100:1

200:2

300:3

400:4

500:5

600:6

Completed:1

Cancelled:2

Completed:3

Cancelled:4

Completed:5

Requested:6

2022-12-03:1

2022-12-03:2

2022-12-04:3

2022-12-05:4

2022-12-09:5

2022-12-09:6

2022-12-03:1

2022-12-04:2

2022-12-04:3

2022-12-06:4

2022-12-09:5

2022-12-09:6

단 한 번의 I/O만 필요로 했던 row-oriented와 비교해보면 column-oriented에서는 상당량의 I/O 작업이 필요하다는 걸 알 수 있습니다. column-oriented를 사용한다면 SELECT * 와 같은 액션은 되도록 피하는 게 좋겠습니다.

이제 column-oriented가 빛을 발할 수 있는 aggregation성 쿼리입니다.

SELECT sum(amount) FROM payment;

이미 예상했겠지만 amount라는 하나의 컬럼만 읽어오면 되기 때문에 불필요한 그 외 블락들을 읽어올 필요가 없게 됩니다. 앞선 row-oriented와 비교해보면 상당히 효율적임을 알 수 있습니다.

100:1

200:2

300:3

400:4

500:5

600:6

결론

row-oriented database

- 여러 컬럼을 조회하는 쿼리인 경우 효율적이다

- 불필요한 컬럼과 같은 무의미한 데이터들까지 조회해올 수 있다

- 위 이유로 인해 데이터 집합/연산 시 매우 비효율적이다

- 데이터 저장 시 맨 마지막 블락 공간에 행을 추가해주기만 하면 되기에 쓰기가 빠르다

- 대표적인 예: MySQL, Oracle, PostreSQL

column-based database

- 특정 컬럼을 조회하는 쿼리인 경우 효율적이다

- 반대로 다수의 컬럼을 조회하는 경우 비효율적이다

- row-oriented와 반대의 이유로 데이터 집합/연산 시 효율적이다

- 데이터 저장 시 각 컬럼들에 해당하는 구조물마다 삽입 처리를 해줘야 해서 쓰기가 느리다

- 대표적인 예: Redshift, BigQuery, Cassandra, PostreSQL (postre는 오픈소스답게 두 옵션을 다 지원하는 듯)

[이모지와 유니코드]" " 얘랑 " " 얘가 같은 문자로 보이나요?

moonionn — Wed, 1 Nov 2023 23:59:38 +0900

(공부하기 싫어서 잼는 글 써보기)

며칠 전 친구와 대화 도중, 맥(Mac)환경에서 하얀피부의 사람신체 이모지를 보내면 윈도우 환경을 쓰는 친구에게는 사람신체 + 웬 사각형 블락이 표기된다는 사실을 알게 되었습니다.

관련해서 또 재밌는 사실 하나 알려드리자면.. 사람 여러명 붙어있는 이모지에다 백스페이스를 사용해 지우려 하면 사람이 하나씩 없어진다는 사실을 아시나요?

오늘은 이와 관련해서 유니코드에 대한 이야기를 조금 해볼까 합니다.

유니코드란?

우리가 컴퓨터로 보는 이모지 글자 형태는 유니코드(Unicode)로 구현됩니다. 유니코드는 현존하는 대부분의 문자를 표현할 수 있죠. 이모지도 여기 포함됩니다. 그렇다면 유니코드는 어떻게 이 세상에 존재하는 그 많은 글자들을 표현할 수 있는걸까요?

컴퓨터는 0과 1로만 동작한다는 이야기는 이 분야 전문가가 아니더라도 한 번쯤은 들어봤을법할 정도로 유명합니다. 여기서 0,1이 들어가는 자리의 단위를 비트(bit)라고 부르죠. 그리고 유니코드는 32비트를 활용할 수 있습니다. 그럼 한 비트 당 두 종류의 표현법(0,1)을 쓸 수 있는 거니까, 유니코드는 2의 32제곱, 즉 4,294,967,296개의 문자를 구현할 여유가 있습니다. (참고로 사실 정말 42억대의 글자를 표현할 수 있는 건 아닙니다만 이 이야기는 여기서 서술하지 않도록 하겠습니다.)

유니코드 표현식

유니코드는 코드 포인트(code point)라는 이름의 각자 고유한 코드를 가지고 있습니다. 이는 U+ (혹은 \u) 뒤에 16진수 넘버링 규칙을 준수하며, 범위는 U+0000 부터 U+10FFFF 까지입니다.

U+270B  > '✋'
U+0041  > 'A'
U+0023  > '#'

JAVA

String str="\u270B"
str ==> "✋"

String str="\u0041"
str ==> "A"

String str="\u0023"
str ==> "#"

Javascript

str='\u{270B}'
'✋'

str='\u{0041}'
'A'

str='\u{0023}'
'#'

유니코드 조합

재밌는 사실은, 어떤 문자(character)들은 여러 코드 포인트들의 조합으로 구성되었다는 점입니다. ‍ 여기 농부 아저씨 이모지를 예시로 들어보겠습니다. 이 농부를 표현하기 위해 필요한 유니코드 코드 포인트는 총 몇개일까요?

Javascript

farmer='\u{1F468}\u{1F3FB}\u{200D}\u{1F33E}'
' ‍ '

답은 총 네 개 입니다. 코드 포인트를 하나하나 살펴보면 아래와 같습니다. 성인 남성 + 밝은 피부 톤 + 빈 공백 + 수확물 이모지의 조합으로 구성되었다는 것이 파악됩니다. 하나하나 살펴보면 밝은 피부의 성인 남성이 수확물을 들고 있는 걸 표현했구나... 라는걸 가늠할 수 있습니다만, 중간에 껴있는 +U200D 이건 뭘까요?

+U200D 코드는 흔히 Zero Width Joiner, 줄여서 ZWJ라 불립니다. (즈윋ㅈ..? 라고 발음하는듯...?) 이는 화면에 실제로 표현되는 문자는 아니며, 어떤 문자 뒤에 ZWJ가 붙으면 또 다른 문자와 조합해 새로운 문자를 표현한다고 볼 수 있습니다. 그래서 농부 = 사람 + 수확물 이기 때문에 ZWJ가 붙은 것이죠. 또 재밌는 사실을 말씀드리자면 국기 이모지도 사실 ZWJ를 사용한 여러 이모지의 조합입니다. 네모박스 K와 네모박스 R을 조합하면 태극기가 나온다는 사실 알고 계셨나요?

이 외에도 ZWJ는 다른 언어에도 활용되곤 합니다. 아랍어, 말레이시아어 등 여러 국가들의 언어를 표현할 때도 필요한 요즘 시대 필수 유니코드라고 할 수 있죠.

여기서 재밌는 사실은 저 농부 이모지( ‍ )를 보면 피부색 조합에는 ZWJ가 사용되지 않음을 확인할 수 있습니다. 이는 피부색 조합의 경우 Fitzpatrick Skin Modifier 라는 유니코드가 붙으면 자동으로 피부색 결합이 되기 때문입니다. FitzPatrick Skin Modifier 유니코드 코드 포인트 범위는 +U1F3FB 부터 +U1F3FF 로 구성되어 있습니다.

그렇다고 아무 이모지나 스킨 모디파이어와 조합할 순 없겠죠? (ex: + white skin tone ????) 스킨 모디파이어와 조합할 수 있는 이모지인지를 판별할 수 있는 기능을, 자바스크립트는 내장 지원한다는 사실을 아시나요?

> /\p{Emoji_Modifier_Base}/u.test(' ')
true

> /\p{Emoji_Modifier_Base}/u.test(' ')
false

자바스크립트 같은 경우 위처럼 Emoji_Modifier_Base 라는 regexp를 별도 선언 없이 사용하면 스킨톤 변경이 가능한 이모지인지 아닌지를 판별해줍니다. 정말 편리한 기능이지 않습니까!!

실생활 적용

특정 텍스트를 20바이트까지만 잘라서 가공해줘~ 라는 요청이 들어왔다고 칩시다. 해당 문자는 이모지를 포함한 UTF-8 인코딩 텍스트라 가정합시다. (유니코드와 UTF-8에 대해서는 나중에 2탄 쓸 일 있으면 그때 서술하겠습니다 . UTF-8에 대해 잘 모르신다면 지금은 그냥 그렇다 치고 이해 바랍니다.)

예시 텍스트는 아래와 같습니다.

const text = '놓칠 수 없는 가족 세일! ‍ ‍ ‍  오늘부터 10일간 진행됩니다';

만약 이런 이모지 특성을 고려하지 않고 텍스트를 트림(trim)해버린다면 무슨 일이 발생할까요?

function trimTextToBytes(text) {
  const MAX_BYTES = 50;

  let trimmedText = text;
  while (Buffer.byteLength(trimmedText, 'utf8') > MAX_BYTES) {
    trimmedText = trimmedText.slice(0, -1);
  }
  return trimmedText;
}

const text = '놓칠 수 없는 가족 세일! ‍ ‍ ‍  오늘부터 10일간 진행됩니다';
const trimmedText = trimTextToBytes(text);

결과는 위와 같습니다. 이모지 결합을 고려하지 않아 아들래미가 빠진 이모지가 표현되게 됩니다. 아들램을 제거함으로써 50 바이트 리밋을 충족하기는 하나, 기존 텍스트와는 좀 다른 형상이 표현되게 되는 것이죠. 앞서 말한 내용들을 고려해 코드를 수정하면 이런 상황을 피할 수 있습니다.

function trimTextToBytes(text) {
  const MAX_BYTES = 50;
  const EMOJI_REGEXP = /([\uD800-\uDBFF][\uDC00-\uDFFF])/;
  const EMOJI_ZERO_WIDTH_JOINER = '\u200D';

  let trimmedText = '';
  let detectedEmoji = '';
  const splitTextByEmoji = text.split(EMOJI_REGEXP);

  splitTextByEmoji.forEach((text) => {
    if (
      Buffer.byteLength(trimmedText + text + detectedEmoji, 'utf8') < MAX_BYTES
    ) {
      const isPlainText =
        !EMOJI_REGEXP.test(text) && text !== EMOJI_ZERO_WIDTH_JOINER;

      if (isPlainText) {
        if (detectedEmoji) {
          trimmedText += detectedEmoji;
          detectedEmoji = '';
        }
        trimmedText += text;
      } else {
        detectedEmoji += text;
      }
    }
  });
  return trimmedText;
}

const text = '놓칠 수 없는 가족 세일! ‍ ‍ ‍  오늘부터 10일간 진행됩니다';
const trimmedText = trimTextToBytes(text);
console.log(trimmedText);