윤민상 블로그

심리학자가 알려주는 모든 기획자와 프리젠터가 알아야할 사람에 대한 100가지 사실 독서모임 후기

안양사람 — Mon, 2 Mar 2026 17:24:50 +0900

서론

잠깐 모임이 중지되었던 독서토론 모임이 다시 열렸다. 원래는 개발과 커뮤니케이션 관련 주제였는데, 이번에는 서비스(제품)라는 확장된 주제였다. 회사에서 개발자들과 소통만 하는게 아니라, 다른 직군의 동료들과도 소통 하기 때문에 오히려 좋다고 생각했다. 한가지 아쉬운(?)점은 나는 이제 제품 개발자가 아니라 플랫폼 개발자다. 뭐 이것도 좋게 생각하면 독서토론을 하면서 제품에 대한 감을 잃지 않을 수 있다.

본론

이번 모임은 사람이 너무 많았다.. 그래서 좀 부담되었다. 확실히 나는 친하지 않은 많은 사람들 앞에서 얘기하는게 부담된다. 자리도 빈자리 없이 꽉꽉 채워 앉아야했다.

아이스브레이킹

이번에도 역시나 아이스브레이킹이 있었다. 이번에는 6명?정도로 조를 나누고 왼손으로 30초씩 돌아가면서 한명의 얼굴을 그렸다. 모든 조원들의 얼굴을 30초동안 자세히 보면서 그림을 그리면서 자연스럽게 긴장이 풀리는 그런 원리라고 한다. 덕분에 내 초상화도 얻을 수 있었다. IT 대기업일수록 아이스브레이킹을 진심으로 한다고 느꼈다. 사람이 많고 팀 이동도 많다보니 자연스럽게 그런 것 같다. 나는 작은 스타트업에 다니다보니 이런 아이스브레이킹을 하는 일 없이 자연스럽게 팀에 적응하는 경험이 많다. 조직마다 다른 선택을 해야하는건 맞지만 한번쯤은 나도 기회가 오면 이런걸 시도해봐야겠다는 생각이 들었다.

자기소개

사람이 너무 많다 보니 회사이름을 말하는 것도 조금 부담이 되었다. 회사 이름을 말해서 영업을 했어야했는데 약간 아쉽다.

"통신 도메인의 스타트업에 다니는 프론트엔드 개발자다. 원래는 제품팀에 있었는데 최근에 개발자들의 생산성을 올려주는 플랫폼 팀으로 이동했다. 커뮤니케이션 역량을 올리기 위해 지원했고 모임장이 경력 많은 프론트엔드 개발자라서 신청했다." 정도로 얘기했다.

예전에 스피치 학원에 다닐때 자신감있게 청중들 눈을 보면서 대화해야된다고 했는데 못했다.. 컴퓨터만 보면서 했다. 원형의 테이블이라 시선처리가 어려운 것도 있었고 그냥 부담되어서 그런것도 있었다.

이 책에서 꼭 공유하고 싶은 한 줄

아무도 얘기를 안하길래 내가 용기내서 먼저 얘기를 했다. 확실히 처음에 누군가가 뚫어줘야 다른 사람도 편하게 대화할 수 있다. 나는 먼저 나서는 편은 아니지만 누군가 해야된다면 먼저 나서는 편이다.

나는 다음 두가지 문장을 얘기했다. 독후감에 적었기 때문에 간단히만 설명을 덧붙이겠다.

1. 사람들은 당신이 말한 내용은 잊어버릴지 몰라도 어떤 기분이 들게 했는지는 절대 잊지 않는다.

내가 잘못했던 경험들이 생각나서 너무 두렵다. 앞으로는 더 잘 해야지..

2. 사람들은 자기가 실제 처리할 수 있는 것보다 더 많은 선택권과 정보를 원한다.

(제품 관련해서)고객들은 자신들이 원하는게 뭔지 모른다. 원래는 연애, 삶까지 조금 더 확장해서 생각했지만 처음보는 사람들에게 이런 얘기를 하기에는 조금 부끄러웠다. 아마 이런 얘기는 훨씬 가까운 사이에 소수의 사람들과 할 수 있을 것 같다. 아닌가.. 다시 생각해보니 이런것도 부끄러움없이 얘기할 수 있게 바뀌어야하나 싶기도 하다. 내향적이여도 본인의 솔직히 이야기는 할 수 있다. 그리고 솔직함은 내 장점이기도 하다. 나는 커뮤니케이션이라는 단점을 그동안 많이 개선해왔고 이제는 장점으로 가져가려고 한다. 그리고 솔직함이라는 장점을 커뮤니케이션과 연결시켜서 더욱 시너지를 낼 수 있을 것 같다. 어렵지만.. 다음 모임에는 이런 기회가 있으면 시도해봐야겠다.

슬렉 예시

모임장님이 슬렉의 특정 케이스의 ui ux에 대한 예시를 들었다. 다이렉트 메세지에서 x를 누르면 left panel에서 사라지는데 특정 메세지를 입력하고 보내지 않은 경우는 x버튼이 노출되지 않고 입력중 버튼이 노출된다. 그래서 dm을 지우기가 너무 불편하다고 했다.

사실.. 나는 해당 케이스에는 슬렉처럼 하는게 맞다고 생각했다. 근데 왜 거기서 불편함을 느꼈는지는 알 수 있었다. 나는 dm을 자주 사용하지 않고 모임장님은 dm을 자주 사용한다. 거기서 사용성의 차이가 나타났다. 뭐 물론 입력중과 x버튼을 둘다 노출시켜주면 해결되는 문제긴 하다. 근데 그건 또 다른 문제를 야기한다. 정답이 뭐라고 정의할수는 없다.

그래서 ux가 어렵다. 사람들마다 좋고 나쁜 사용성이 다르다. 모든 사람의 니즈를 충족시킬수는 없다.

모임장님은 여기서 3가지 원칙을 얘기했다.

- 내가 틀릴수있다.

- 완벽한 이유가 있어야한다.

- 최대한 빨리 원복할 수 있는 방법을 만들어라.

원복에 대한 얘기를 할 때는 카나리배포를 얘기했는데 AB테스트는 왜 얘기를 안했을까? 라는 생각이 들었다. 버그가 문제되는 경우라면 카나리배포를 하는게 맞는데 ui ux 관련된 거라면 AB 테스트 비율을 조정하는거로도 충분하지 않나? 뭐 어쨋든 두가지는 how to 에 대한 영역일뿐이다. 그렇게 얘기한다면 피쳐플래그 등의 개념까지 확장할 수 있다.

공리주의

조금 더 나아간다면 나는 공리주의에 대한 생각도 든다. 어차피 모든 유저가 원하는 최선의 UI UX를 보여줄 수는 없다. 그래서 AB테스트로 전환율을 확인하고 높은 전환율을 보이는 기능을 선택한다. 물론 이해관계에 대한 문제가 있을 때는 소수의 편의를 선택하기도 한다.

요즘엔 UI를 유저가 원하는대로 직접 커스텀할 수 있게 만들어줘야한다는 얘기도 나오는 것 같다. 내 생각엔 대다수의 일반 유저들은 그렇게 복잡한 설정을 원하지 않는다.(B2B는 조금 얘기가 다르다.) 결국 UI 커스텀도 많아야 2,3가지 레이아웃정도고 결국 누군가는 만족하지 못하는 UI UX를 선택해서 찍고 가야한다. 소수를 존중하지 않겠다는 얘기는 아니지만 여전히 공리주의는 유의미한 것 같다.

90%의 유저들은 10%만큼 편해졌고 10%의 유저들은 30%만큼 불편해졌다고 가정하자. 그리고 90%의 유저들은 전환율이 7%올랐고 10% 유저들은 전환율이 30%떨어졌다. 이러면 전체 유저로 봤을 때는 이득일 수 있다. 이후에 10% 유저들을 챙기기 위한 개선 작업을 할 수도 있지만 세상에는 양자택일로 선택할 수 밖에 없는 순간들이 있다.

AI는 통계고 평균이다. 잘하지 않는다.

모임장님이 지라같은 서비스를 개발한걸 보여줬다. 꽤 페이지가 많았는데 얼마나 걸렸게? 라고 물어봤다. 프롬프트를 가다듬는데는 하루정도 걸렸지만 실제 그 이후 개발은 2시간?정도 걸렸다고 했다. 사실 아주 놀랍지는 않다. 단순히 기능 개발한건 아무 의미 없다. 그게 유지보수 가능한 아키텍쳐인지, 사용자에게 wow할 포인트, 취향을 저격할 부분이 있는지 이런것들이 더 중요하다. AI는 이미 너무나도 발전했다. 사내에서도 비개발자들이 꽤 멋진 개발 결과를 보일때가 있다. 그리고 모임장님도 얘기했다. 평균정도를 하는거지 잘하지는 않는다고. 매우 공감한다. 몇시간만에 개발했는지도 중요하지만 그걸로 어떤 가치를 줄 수 있는가, 수익을 낼 수 있는가가 뒷받침되지 않는다면 무의미하다.

기능은 넣는것보다 빼는게 어렵다.

책에서 "상실의 두려움이 획득의 기대보다 크다." 라는 얘기가 나온다. 거기서 한 멤버(?)분이 기능은 넣는것보다 빼는게 어렵다는 얘기를 했다. 지금 회사에서 엄청 크게 느낀 부분이다. 넣는건 어렵지 않은데 빼는건 정말 어렵다.. 여러 이해관계자들을 설득해야하고 고객들의 불편함까지 감수해야한다. 빠르게 AB테스트로 검증하고 배포하고 이후에 불필요해진다면 빠르게 다시 제거하는게 이상적인 그림인줄알았다. 그런데 배포까지는 쉬운데 제거가 어렵다. 이걸 잘 하려면 어떻게 해야할까? 반대로 너무 고민하면 속도가 느려진다. 결국엔 결정의 문제다. 현재 팀의 상황에 맞는 온도감으로 속도와 안정성을 결정해야한다.

소모임

시간이 부족해서 소모임할시간이 조금 부족했다. 커뮤니케이션 관련 이슈에 대해 발표를 해야했다.

우리조에서는 회의가 길다, 업무 기대가 다르다 등의 얘기가 나왔다. 이슈 정의가 한줄이면 하나로 명확히해야되는데 여러가지를 포괄하려다 보니 이슈 정의가 명확하게 되지 않았다고 느꼈다. 뭔가 더 잘 해보고 싶은데 처음 보는 사람들이기도 하고 나도 뾰족하게 하나를 확정하기가 어려워서 조금 어려움이 있었다.

그에 비해 내일 할일, 다음달에 할일은 꽤 쉽게 정할 수 있었다. 왜냐면 나는 이 정답을 알고 있었으니까 ㅎㅎ

체크리스트를 만들고 이걸 템플릿화하면 된다. 이전 독서토론에서 체크리스트에 대한 얘기를 하기도 했고, 사내에서도 이런 체크리스트 기반의 템플릿을 자주 사용해서 쉽게 떠올릴 수 있었다.

결정이 이루어지지 않은 상황에서 발표를 해야됐는데 어쩌다보니 다른 멤버가 처음에 발표를 하다가 자연스럽게 나에게 넘겨줬다.. 다행히 내가 제시한 템플릿, 체크리스트 관련 내용이라서 그럭저럭 나쁘지 않게 발표를 했다. 좀 즉흥적으로 해서 기록된 내용도 없고 시간이 지나서 잘 기억이 안나지만 기억나는 정도로만 적어보겠다.

"회의가 길어지는 경우는 명확합니다. 딴 얘기로 흘러가는 경우, 사전 준비를 안해온 경우 등등. 시작전에 읽을 체크리스트, 종료후에 회고할 체크리스트 정도만 있어도 같은 실수를 반복하지 않습니다. 그리고 이걸 템플릿화하면 모든 회의를 효율적으로 할 수 있습니다.

한 달 후에 이 템플릿이 어떤 점이 좋았고 어떤 문제가 있었는지 회고하는 피드백 루프를 돌리면 점점 좋은 회의를 할 수 있게 됩니다."

모임장님의 조언

모임장님은 우리들의 발표를 듣고 다 잘 말해서 크게 할말이 없다고 했다. 특히 내가 얘가한 체크리스트와 템플릿 관련해서도 좋은 방법이라고 얘기했다. 그리고 회의 목적을 똑바로 정하면 좋다고 했다.

목적 없는 회의가 필요할때가 있지 않을까? 라고 생각을 했는데 조금 더 생각해보니 아닌 것 같다. 모호한 회의라고 하더라도 목적은 있어야한다. 밑에서도 얘기하지만 결정하지 않아도 좋다. 하지만 목적만큼은 명확해야한다.

1. 설명하는건지, 결정하는건지 명확히 해라.

나를 되돌아봤는데 이걸 제대로 못한 경험이 있다. 설명하면 설명만하고, 결정해야하면 결정을 해야했다. 그리고 둘 다 필요하다면 설명후에 결정해야한다고 말하면 된다. 객관적인 사실과, 나의 주관적 의견을 얘기한 이후에 팀원들과 공동의 결정을 해야하는 경우도 있다. 이런 경우는 어떻게 해야할까? 나라면 섹션별로 명확히 끊어서 얘기할 것 같다. 책에서 현재 프레젠테이션의 진행도를 알려주면 좋다고 했는데 회의도 똑같다. 그리고 모임에서 얘기하진 않았지만 내 의견을 명확히 하는 것도 도움이 될 것 같다. 이것도 좋고 저것도 좋아요는 결정을 힘들게 한다. 특히 회의 주최자가 해당 안건에 대해 가장 잘 알기 때문에 주최자가 망설이면 다른 동료들은 더 결정하기 힘들다.(사실 예전에 관련된 내용을 피드백받은 경험이 있다.)

2. 오래걸리는 건지.

책에서도 나오는데 정해진 시간내에 끝내는게 가장 좋다. 여기서부터는 모임장님의 얘기가 기억이 안나서 내 생각이다. 긴 회의는 기본적으로 좋지 않다. 다만, 아무리 잘 진행되어도 길어질 수 밖에 없는 회의들이 있기 마련이다. 이럴땐 잠깐의 휴식이 도움이 될 수 있다.

오늘의 멤버

오늘의 멤버라는걸 뽑았는데 공동 1등에 뽑혔다. 그리고 가위바위보에 이겨서 모임장님에게 책도 한권 받았다. 그냥 한마디씩 했는데 오늘의 멤버에 뽑힌걸 보니 나쁘지 않았나? 라는 생각도 든다. 아직 커뮤니케이션이 아쉬운 부분이 많은데 그래도 이제는 어느정도는 올라왔나 싶은 생각이 들기도 한다. 다음에도 오늘의 멤버에 뽑힐 수 있게 열심히 해봐야겠다!

심리학자가 알려주는 모든 기획자와 프리젠터가 알아야할 사람에 대한 100가지 사실 독후감

안양사람 — Sun, 1 Mar 2026 12:32:12 +0900

이전에 읽은 새로운질서라는 책과는 전혀 다른 스타일의 책이였다. 책의 난이도도 낮고 항목이 하나하나 나뉘어져 있어서 읽기에는 수월했다. 내가 최근에 책을 읽으면서 느낀 한가지가 있다. 나는 책의 저자가 의도한 주제대로만 읽지 않는다. 발표가 주제여도 AI가 주제여도 결국 다른 무언가 꽂히는게 있다면 그 부분에 대해 깊이 파고든다. 책의 전체 흐름을 파악하고 따라가는 것도 중요하지만 이렇게 읽고 생각해보는 것도 나쁘지 않은 방식같다. 이전에 읽은 책만큼 인상깊지는 않았지만 나에게는 읽어서 도움이 되는 정도의 책이였던 것 같다.

너무 다양한 섹션들이 있어서 요약하기가 조금 애매한데 내가 이 책에서 중점적으로 본건 사람에 대한 이해다. 멘탈 모델, 무의식적인 결정, 방어적인 태도 이런 것들은 결국 사람에 대한 이해가 밑바탕이 되어야한다. 저자가 심리학 박사이다보니 자연스럽게 이런게 강조되었을지도 모르겠다.

사람들은 자기 생각에 확신이 없을수록 더 방어적인 태도를 취한다.

회사 생활을 하면서 크게 느꼈다. 심지어 내가 방어적인 태도를 취하는 것도 느꼈다.
확실히 발표에서는 100명중 1명의 의견만 바꿔도 성공이라고 생각해도 좋을 것 같다.
회사는 발표와 조금 다르다. 처음에 방어적인 태도를 취하더라도, 조금씩 천천히 설득할 수 있다. 또한 언젠가 설득력을 얻을 수 있는 상황이 반드시 온다. 처음에 상대방이 방어적인 태도를 취하더라도 작은 씨앗을 뿌렸다고 생각하면 좋다.

사람들은 정신(멘탈) 모델을 갖고 있다.

대학생 때 친구에게 "모두 각자의 사정이 있다." 라는 얘기를 한적이 있다. 그 각자의 사정으로 인해 개개인의 멘탈 모델이 생성되었다. 친한 친구들은 서로의 멘탈 모델을 알고 있다. 당연히 발표자도 참여자의 멘탈 모델을 조금이나마 들여다볼필요가 있다. 근데 과연 나는 그렇게 발표를 해왔을까? 개발자를 대상으로, 회사 직원을 대상으로 하는 경우는 어느정도 타겟층이 명확했기 때문에 큰 문제가 없었다. 근데 조금 더 그들의 멘탈 모델을 이해하려고 시도했다면 더 좋은 결과가 있지는 않았을까? 라는 생각이 든다. 그 예시로 최근 스터디의 모임장님이 생각난다. 정말 뛰어난 실력과 강의 경험이 있지만 세부적인 설문을 돌리고 그 내용을 기반으로 스터디를 구성했다.

사람들은 기억할 때마다 기억을 재구성한다.

기억보단 기록을...

즉흥적 & 인지적 창의성

이 책 덕분에 내가 무슨 창의성을 가진 사람인지 알게 되었다. 그냥 일을 열심히 하다보니 새벽에도 창의적인 생각이 나는게 아니라, 즉흥적 인지적 창의성을 가진 사람이라 갑자기 아이디어가 떠오르는 거다.

도파민은 쾌락을 경험하게 해 주는 게 아니라 실제로 원하고 소망하며, 찾아내고 검색하게 하는 물질임을 발견했다.

나는 도파민이 별로 없는 사람이라고 생각했었는데 최근에는 꼭 그렇지만은 않다고 느꼈다.
꼭 지나치게 자극적인 것만이 도파민이 아니다. 회사에서 문제를 해결하는 것에서도 도파민이 나오고, 요리하는데도 도파민이 나온다.
그리고 안정적인 상태가 되기 위해서는 초반에 어느정도의 도파민이 어쩔 수 없이 필요하다는 것도 최근에 느꼈다.

일 또는 개인 생활 중에 재미있는 이야기를 적어놓거나 녹음해 둬라.

이건 진짜 필요하다고 느꼈다. 꼭 재밌는 이야기가 아니여도 좋다. 갑자기 이런 얘기를 해야하는 상황이 들이닥칠 때가 있다. 원래 말 잘하고 외향적인 사람이라면 크게 걱정이 없겠지만 갑자기 나에게로 이목이 쏠리면 좀 부담스러워서 말하기 어려울 때가 있다.

너무 많이 기대하지 마라

일이 잘못될 수 있는 상황을 예측해서 문제를 최소화할 계획을 세우고 대비하라.

주변에서 주도적으로 처음부터 끝까지 끌고나가는게 좋아보인다는 말을 종종 듣는다. 그리고 나는 그럴때마다 항상 비슷한 얘기를 한다. "내가 안하면 아무도 안한다." 이렇게만 들으면 그 조직에 문제가 있다고 생각할 수 있지만 전혀 그런 뜻이 아니다. 각자 주어진 많은 업무들이 있고 각자의 관심사도 다르다. 특정 이슈를 발견하고 해결할 수도 있는 내가 모른척 넘어간다면 다른 누구도 하지 않을거다. 이런 부분에서는 기대가 0이다. 어느 조직이던지 크게 다르지 않다고 생각한다. 그렇다고 해서 내가 기대하는게 없는건 아니다. 기대하는 부분과 기대하지 말아야하는 부분을 분리해서 생각할뿐이다.

항상 최악을 생각해야한다. 나는 언제부터인가 잘되는 상황을 가정하고 상황에 임하지 않는다. 대학교 때 한 머리좋은 동기가 있었다. 대학교 학점을 신경써서 따는 친구는 아니였는데 특정 전공 과목은 재밌다고 열심히 했다. 내가 그 친구 상황이였다면 A+이 안나오면 실망했을거다. 근데 그 친구는 B만 나와도 좋다고 했다. 왜냐고 물어보니 기대가 낮으면 나쁠게 없다는거였다. 잘나오면 좋고 기대만큼 나오면 그냥 그런거고. 나는 그 당시 그 마인드를 이해하지 못했다.

학점, 발표, 인생 크게 다를건 없다고 생각한다. 항상 잘못될 수 있는 상황은 존재하고 그 문제를 최소화할 계획이 있어야한다. 나는 발표하다 당황한적이 꽤 많다. 내 마인드는 바꼈는데 왜 발표에서는 그렇게 하지 않았을까? 아니 정확히는 잘못될 수 있는 상황을 고려했다. 다만 어느정도의 시간을 쓸거냐에서 그만큼의 시간을 쏟지 않은 것 뿐이다. 시간은 한정되어 있기 때문에 그 당시의 내 선택이 무조건 잘못되었다고 할 수는 없다. 하지만 아쉬움이 남는걸보니 더 시간을 쏟았으면 좋았겠다는 생각이 든다. 과연 미래의 내가 지금 내가 한 말을 기억하고 지킬까? 그건 알 수 없다. 그래도 다행인건 지금 기록을 하고 있다는 것이다.

사람들은 당신이 말한 내용은 잊어버릴지 몰라도 어떤 기분이 들게 했는지는 절대 잊지 않는다.

진짜 무서운 말이다... 나는 이미 누군가에게 부정적인 기분을 들게한 사람이다. 물론 그러지 않으려고 노력한다. 하지만 과거는 바꿀 수 없다. 같이 오랫동안 지내온 사람들은 내 변화된 모습을 봤다. 하지만 여전히 나를 부정적으로 생각할지도 모른다. 또 누군가는 내 변화된 모습을 보지 못한채 여전히 부정적으로 평가할지도 모른다.

사람들은 데이터보다 일화에 더 크게 반응한다.

데이터 기반으로 대화하는건 꽤 유의미하게 설득할 수 있는 수단이라고 생각했는데..
결국 둘다 중요한데 스토리텔링이 더 중요하다는 뜻인 것 같다. 데이터를 기반으로하는 일화를 소개하면 금상첨화겠지.
그리고 책에서는 데이터에 대한 예시를 몇퍼센트의 고객들 이런식으로 들었는데 매출이 150% 늘었다는 식으로 얘기하면 아마 임팩트가 있었을거다. 뭐가 더 중요하다는 크게 의미없고 그냥 둘다 잘 사용해야겠다.

사람들은 대부분의 결정을 무의식적으로한다.

참 웃기는 얘기다. 경력이 많아질수록 가치관은 확고해지고 무의식은 강해진다. 그리고 이성적인척하지만 내면에는 이전의 경험들로 인한 무의식이 박혀있다. 사실 이게 잘못된 건 아니다. 경험이란건 현재 시점에서 이성적으로 판단하더라도 무엇이 더 좋다고 쉽게 판단할 수 없다. 블로그 글로도 쓴 주제인데 결국 겸손해야 이런 현실적인 문제들을 해결할 수 있다.

나는 상대방의 무의식을 공감하는 대화를 한적이 있는가? 생각해보게 된다. 어렴풋이 한 적은 있는 것 같다. 그리고 나도 이전 경험으로 인해 해당 방식을 고민하고 있다고 얘기한 적이 있다. 앞으로는 조금 더 이런 부분들에 대해 공감하면서 대화, 발표를 하려고 한다.

사람들은 자기가 실제 처리할 수 있는 것보다 더 많은 선택권과 정보를 원한다.

제품을 만들면서 정말 크게 느끼는 부분이다. b2b, b2c 크게 다르지 않다. 고객들은 자기가 뭘 원하는지 모른다. 제품이 아니라 일, 연애, 삶 모두 마찬가지다. 본인이 진정으로 원하는게 뭔지 아는 사람은 얼마나 될까?
데이터, AB테스트, 직관 등으로 해결하는게 정답일까?
어쩌면 삶도 AB테스트의 연속일지 모르겠다.

github 링크

쿼리파람을 typesafe하게 다루는 방법(feat. SKILL)

안양사람 — Sun, 22 Feb 2026 17:13:54 +0900

배경

예전부터 그랬지만 쿼리파람이 상태로 다뤄져야한다는 글들이 점점 많이 보이는 것 같다.(예전에도 관련한 글을 작성한적이 있다.) 최근에는 LLM의 SKILL도 많이 사용하게 되면서 정형화된 패턴을 문서로 작성하는게 필요해졌다. 이런 상황에서 내가 사용하는 패턴을 글로 작성하면 좋을 것 같다는 생각이 들었다.

기존 문제점

인 메모리 상태는 유저의 악의적인 상태 변경을 제어할 수 있다. 그런데 URI는 절대로 제어할 수 없다. 여기서 딜레마가 생긴다. 해결 방법은 네가지다.

1. 터트리기

경우에 따라서는 assert를 걸어서 타입을 확실하게 정의하고 그렇지 않다면 터트리는 것도 방법이다. 단, 나는 대부분의 경우에 이 방법을 지양한다. 유저의 실수로 인해 화면이 터지는건 좋은 방법이 아니라고 생각한다. 에러바운더리를 잡고 reset 버튼을 유도하는 것도 마찬가지다.

2. 잘못된 상태가 들어왔을 때 잘못된 쿼리파람 고치기

deprecated된 쿼리파람인 경우는 이 방법을 사용하는 것도 좋아보인다. pushstate가 아니라 replace를 사용해야한다는 것을 주의하자. 하지만 그냥 잘못된 쿼리파람을 고쳐주는건 좋은 방법인지 모르겠다. 가끔 잘못된 URI 공유로 인해 잘못된 쿼리파람을 가지고 들어오는 경우도 있는데 쿼리파람을 고쳐버리면 정확한 로그를 찍을 수 없다.(정확히 말하면 찍을수는 있지만 전 상태가 유실될 가능성이 너무 높다. 이걸 세부적으로 컨트롤하는 것도 굉장히 불편한 일이고) 너무 많이 이상한 쿼리파람이 찍힌다면 광고페이지에서 잘못된 URI를 넘겨준다던가 이런걸 유추할 수 있다.

3. 라우터단에서 쿼리파람을 typesafe하게 관리하기

tanstack router는 typesafe하게 쿼리파람을 관리한다. 내부적으로는 zod같은걸 이용하는 것 같다. 사실 next나 react-router를 사용해도 한번 래핑하면 typesafe하게 관리할 수 있다. 다만 이건 마이그레이션 비용이 좀 있다.

https://tanstack.com/router/v1/docs/guide/search-params#zod

import { zodValidator } from '@tanstack/zod-adapter'
import { z } from 'zod'

const productSearchSchema = z.object({
  page: z.number().default(1),
  filter: z.string().default(''),
  sort: z.enum(['newest', 'oldest', 'price']).default('newest'),
})

export const Route = createFileRoute('/shop/products/')({
  validateSearch: zodValidator(productSearchSchema),
})

4. 잘못된 쿼리파람 상태를 default 값으로 대체하기

나는 이 방법을 가장 선호한다. undefined인 경우는 그냥 ||이나 ?? 문법으로 default 값을 넣어주면 된다. 그런데 잘못된 값이 들어왔다면 특정 enum에 속하는지 확인하고 속하지 않는 경우만 default 값을 넣어주는 코드가 필요하다. 어렵지 않지만 모든 쿼리파람 관련 코드에 이런 코드를 넣는다면 너무 코드량이 많아진다. 이건 보일러플레이트에 가깝다. 추상화시킬 수 있다.

enum 유틸함수

그 전에.. enum에 대한 유용한 유틸함수부터 살펴보자.

enumIncludes

Array 인스턴스에는 includes라는 메서드가 존재한다. enum에도 이게 있으면 유용하지 않을까? 나는 다음과 같은 유틸함수를 자주 사용한다. 딱히 어려운 코드는 아니다. 그냥 제네릭과 is 용법을 이용해 typesafe하게 boolean을 return해주는 함수다.

/**
 * 주어진 enum 객체에 특정 값이 포함되어 있는지 확인합니다.
 * 타입 가드로 사용되어 item의 타입을 TEnumValue로 좁혀줍니다.
 *
 * @param enumVariable - 검사할 enum 객체
 * @param item - enum 값에 포함되어 있는지 확인할 값
 * @returns item이 enum 값 중 하나인지 여부 (타입 가드)
 *
 * @example
 * enum Color { Red = 'red', Blue = 'blue' }
 * const value = 'red';
 * if (enumIncludes(Color, value)) {
 *   // 이 블록 안에서 value는 Color 타입으로 취급됨
 * }
 */
export function enumIncludes<T extends string, TEnumValue extends string>(
  enumVariable: { [key in T]: TEnumValue },
  item: unknown
): item is TEnumValue {
  return Object.values(enumVariable).includes(item);
}

getValidEnumValue

위에서 만든 enumIncludes를 활용한 함수다. 유효한 enum이 아닐 때 placeholder를 return해준다.

/**
 * 주어진 값이 enum에 포함된 유효한 값인지 확인하고,
 * 유효한 경우 해당 값을 반환하고, 그렇지 않은 경우 기본값을 반환합니다.
 *
 * @param enumVariable - 검사할 enum 객체
 * @param item - 검증할 값
 * @param placeholder - item이 유효하지 않을 경우 반환할 기본값
 * @returns 유효한 enum 값 또는 기본값
 *
 * @example
 * const order = getValidEnumValue(ORDERS_MAP, searchParams.get(SEARCH_PARAMS_ORDER));
 * // order: OrderType | undefined
 * const order = getValidEnumValue(ORDERS_MAP, searchParams.get(SEARCH_PARAMS_ORDER), 'asc');
 * // order: OrderType
 */
export function getValidEnumValue<T extends string, TEnumValue extends string, P = undefined>(
  enumVariable: { [key in T]: TEnumValue },
  item: unknown,
  placeholder: P = undefined as P,
): TEnumValue | P {
  return enumIncludes(enumVariable, item) ? item : placeholder;
}

쿼리파람 다루는 방법 패턴화하기

이제 위에서 만든 유틸함수들을 이용해서 패턴화할 수 있다. 어떤 router를 사용하느냐에 따라 조금씩 다르지만 대부분의 라이브러리들은 사용법이 크게 다르지 않아서 react-router를 기준으로 적어보겠다. (애초에 웹에서 URLSearchParams라는 API를 제공하고 그걸 래핑한게 라이브러리들이기 때문에 사용법이 특별하게 다르지 않은게 당연하다.)

쿼리파람을 다루는 다양한 케이스가 있는데 tab을 다루는 경우로 생각해봤다.

나는 개인적으로 enum을 사용하지 않아서 as const 용법을 사용했는데 이건 각자 팀 컨벤션, 개인 취향에 맞게 사용해도 좋을 것 같다.

handleTabChange는 본인이 다루는 코드베이스에서 typesafe한 tab을 다룬다면 굳이 신경쓸필요없는 부분이다.

const TabValue = {
  all: 'all',
  foo: 'foo',
} as const;
type TabValue = (typeof TabValue)[keyof typeof TabValue];

const DEFAULT_TAB: TabValue = 'all';
const SEARCH_PARAMS_TAB = 'tab';

// 컴포넌트 내부
const [searchParams, setSearchParams] = useSearchParams();
const currentTab = getValidEnumValue(TabValue, searchParams.get(SEARCH_PARAMS_TAB), DEFAULT_TAB);

// value가 TabValue면 더 좋지만 Tab 컴포넌트의 onChange는 onChange value에 제네릭을 지원하지 않는 경우가 많다.
// 또한 잘못된 value가 들어오더라도 currentTab에서 fallback 처리를 하기 때문에 큰 문제는 없습니다.
const handleTabChange = (value: string) => {
    setSearchParams({ [SEARCH_PARAMS_TAB]: value });
};

SKILL로 만들기

사실 꼭 스킬이 아니여도 괜찮다. 나는 claude를 주로 사용하는데 CLAUDE.md에 넣어도 된다. 그런데 코드베이스가 커지면 자연스럽게 넣을 프롬프트가 길어진다. 그리고 이는 claude 팀에서도 권장하지 않는다. SKILL 적중율이 claude.md보다 낮다는 문제가 있지만.. 일단은 SKILL로 만들어보자.

tab은 하나의 예시일 뿐이라서 조금 더 일반적인 주석으로 변경했다. 그리고 지금은 쿼리파람을 상태로 관리하는 패턴만 가이드했는데 어떤 경우에 쿼리파람을 상태로 사용해야하는지는 적지 않았다. 지금 SKILL과는 성격이 다르다고 생각해서 의도적으로 적지 않은 것이다. 만약 AI가 쿼리파람을 적절한 경우에 사용하지 못한다고 생각한다면 상태관리에 대한 SKILL을 만들고 그 내부에서 지금 만든 SKILL을 호출하는 걸 만들 수도 있다.

`SKILL.md`

---
name: query-params
description: URL Search Params로 상태를 관리하는 패턴 가이드
---

# URL Search Params 패턴

URL search params로 상태를 관리할 때 사용하는 패턴입니다.
`getValidEnumValue` 유틸 함수를 활용하여 잘못된 값에 대한 fallback 처리를 합니다.

## Import

```ts
import { getValidEnumValue } from '@/shared/utils/enum';
import { useSearchParams } from 'react-router';
```

## 기본 패턴

### 1. Enum 객체 및 타입 정의

```ts
const TabValue = {
  all: 'all',
  foo: 'foo',
} as const;
type TabValue = (typeof TabValue)[keyof typeof TabValue];

const DEFAULT_TAB: TabValue = 'all';
const SEARCH_PARAMS_TAB = 'tab';
```

### 2. 컴포넌트에서 사용

```tsx
const [searchParams, setSearchParams] = useSearchParams();
const currentTab = getValidEnumValue(TabValue, searchParams.get(SEARCH_PARAMS_TAB), DEFAULT_TAB);

// 기본적으로 value 타입을 맞춰서 사용
const handleTabChange = (value: TabValue) => {
  setSearchParams({ [SEARCH_PARAMS_TAB]: value });
};

// 외부 컴포넌트가 제네릭을 지원하지 않아 string만 받는 경우에만 string 사용
// 읽을 때 getValidEnumValue로 검증하므로 잘못된 값이 들어와도 fallback 처리됨
const handleTabChange = (value: string) => {
  setSearchParams({ [SEARCH_PARAMS_TAB]: value });
};
```

## 핵심 포인트

- `getValidEnumValue`는 유효하지 않은 값이 들어오면 기본값(placeholder)을 반환
- URL에서 읽은 값이 enum에 없는 경우 자동으로 fallback 처리됨
- onChange 핸들러의 value 타입은 기본적으로 enum 타입을 사용하고, 외부 컴포넌트가 제네릭을 지원하지 않는 경우에만 `string`을 허용

후기

사실 SKILL을 만드는것자체는 크게 어렵지 않다. 이미 내 방법론에 대한 것들이 정형화 되어있고 문서화되어있다면 그냥 적당히 다듬으면 된다. 진짜 문제는 팀에서 사용하는 정형화된 패턴이 없는 것이다. 어떤 팀에서는 빡빡하게 컨벤션을 가져가고, 어떤 팀에서는 높은 자율성을 기반으로 코드를 작성한다. 정답은 없지만 이런 AI 시대에는 어느정도 컨벤션을 만들고 이걸 AI에게 넘겨줄 컨텍스트를 만들고 이 컨텍스트를 유지보수하는게 필요할지도 모르겠다.

2025년 회고

안양사람 — Sun, 28 Dec 2025 23:55:12 +0900

배경

취업하기 전에 매년 회고를 블로그에 올리기로 마음먹었다. 근데 단 한 번밖에 올리지 못했다. 그 당시의 생각이 휘발되었다는 게 아깝다.

이력서와 포트폴리오에 작업에 대한 결과물은 있지만 내 생각은 남아있지 않다. 지금부터라도 꾸준히 올려보려고 한다.

회사

첫 이직

3년 6개월을 다닌 회사를 그만두고 새로운 회사로 이직했다.

지금은 확실히 안다. 나는 좋은 환경에서 좋은 사람들과 일했다. 가끔은 그 시절이 그립기도 하다. 하지만 이미 시간이 많이 흘렀고 그때 그 시절이 돌아오지는 않는다. 어쩔 수 없이 좋게 헤어진 연인이 그 시절을 그리워하면서 다시 만나도 그 시절의 감정은 느낄 수 없다고 하는데 그것과 크게 다르지 않다. 세상도, 사람도, 관계도 멈춰있지 않고 계속 흘러갈 뿐이다.

"완벽한 회사는 없다." 라는 얘기를 많이 듣곤 했다. 그리고 지금은 그때보다 더 확실히 안다. 그런 건 세상에 존재하지 않는다. 그저 나에게 맞는 회사가 있을 뿐이다. 개인도 회사에 아쉬운 부분이 있을 거고 회사도 개인에게 아쉬운 부분이 있을 거다. 올해는 꽤 다양한 회사의 사람들과 대화할 기회가 있었는데 모두 각자의 고민을 가지고 있었다. 그리고 그 모든 고민을 해결해 줄 수 있는 회사는 없다고 느꼈다.

나는 지금의 회사에 만족한다. 나에게 맞는 회사다. 맞지 않는 부분은 서로 맞춰나가면 된다.

중니어

조직에 따라서 다르겠지만 지금 정도의 조직 규모에서 나는 주니어로 취급받지는 않는 것 같다. 그렇다고 지금 내 역량이 시니어라고 보기는 어렵다. 그래서 그냥 내 마음대로 지금의 나는 중니어라고 정의를 했다. 이제 나는 곧 5년차 개발자다. 연차가 올라감에 따라 부담감도 같이 올라가는데 사실 아직까지는 부담감이 없다. 이전에 비해 많이 성장했고 지금도 성장하고 있다. 지금의 나보다 조금 더 연차가 많은 사람들과도 대화를 많이 해봤는데 아주 특별한 인사이트는 얻을 수 없었다. 정확히는 모두 내가 했었던, 하고 있는 고민들을 하고 있다. 결국 사람 사는게 다 똑같고 개발자도, 회사도 크게 다르지 않다는 걸 느꼈다. 물론 그렇다고 내가 그들의 능력을 가지고 있다는 것은 아니다. 또한 가만히 흘러갈 생각도 없다. 열심히 물장구칠 예정이다. 그 구체적인 방법은 따로 시간을 내서 고민할 예정이다.

조직

이직을 하면서 좋은 조직이 되기 위해서는 어떤 게 필요한지? 나는 조직에서 어떤 역할을 해야 하는지 이런 고민들을 하게 되었다. 확실히 좋은 조직을 만드는 것은 쉬운 게 아니다. 그리고 그 좋은 조직은 단순히 뛰어난 사람 몇 명으로 만들어지는 것도 아니다. 옛날이나 지금이나 생각이 변하지 않은 한 가지는 물은 위에서 아래로 흐른다는 것이다. 나는 아직 위에 있는 사람은 아니지만 선순환이 되도록 다양한 시도를 하는 사람이다. 그리고 그 과정속에서 때로는 좋은 선택을 하기도 하고, 실수를 하기도 한다. 그 여러 과정들을 통해 조금씩 조직이 단단해지거나 무너진다고 생각한다. 나는 조금씩 조직이 단단해지는데 기여하고 싶다.

나라는 사람

주도적인 사람

회사와 이별하고 사람과 이별하고 새로운 회사를 만나면서 나라는 사람이 어떤 사람인지 조금 더 잘 알게 되었다. 나는 (회사에서) 불편함을 잘 느끼는 사람이다. 그리고 이걸 참기보다는 주도적으로 해결하는데 쾌락을 느끼는 사람이다. 때로는 이게 오버엔지니어링으로 이어지기도 하고, 좋은 평가로 이루어지기도 한다. 오버엔지니어링의 기준도 사람마다, 처한 상황마다 다르다. 극단에 있다면 누구나 쉽게 판단할 수 있지만 애매한 경계의 영역에 있는 부분은 판단이 어렵다. 그리고 이런 경우는 논리적인 커뮤니케이션이 중요하다. 잘 설득하고 잘 설득되어야 한다.

이전 회사에 비해 지금 회사는 주도적으로 해결할 수 있는 문제들이 많다. 커뮤니케이션의 범위도 더 넓어졌다. 자연스럽게 커뮤니케이션 역량의 부족함이 느껴지고 이를 발전시키기 위한 다양한 노력, 회고 등이 수반되었다.

최근 이력서의 소개란에 다음과 같은 문장을 추가했다. 앞으로는 이걸 내 장점으로 키워 나갈 예정이다.

불편함을 감지하는데 장점이 있고, 제품과 플랫폼 영역에서 이를 주도적으로 해결합니다.

미움받을 용기

나는 미움받을 용기가 있는 사람이다. 할 말은 한다. 그로 인해 여러 가지 불이익을 받게 되더라도 필요하다고 생각하면 그냥 한다. 운이 좋게도 대부분 이게 긍정적으로 받아들여져 왔다. 소프트커뮤니케이션을 통해 동료들의 심기를 최대한 불편하지 않게 하면서 이 용기를 잃지 않는게 지금의 내가 원하는 작은 바람이다.

질문하는 사람

나는 모르는 게 있으면 그냥 물어보는 사람이다. 아무리 AI가 잘 알려준다고 해도, 옆에 있는 동료만큼 잘 알려주지는 못한다. 너무 많은 질문은 동료를 피로하게 만들기 때문에 주의해야 하는 부분이기도 하다. 그래도 나는 혼자서 1시간을 쓰기보다는 2명이 5분을 사용해 문제를 해결하는 게 더 효율적이라고 생각하는 사람이다. 그래서 질문받는 것도 좋아하고 토론도 좋아한다.

고민이 많은 사람

이직하고 나서 더 고민이 많아졌다. 고민으로 인해 잠을 못 이루는 날들이 많다. 새벽 3시 4시에 갑자기 좋은 생각이 나면 슬렉에 글을 올리거나, 메모장을 켜서 메모해 두기도 한다. 전 회사에서는 어느 정도 일과 사생활 분리가 되었는데, 지금은 두 개가 합쳐져 버렸다. 이게 좋은 건지 나쁜 건지 아직은 모르겠다. 아마 내년 이맘때쯤에는 그 결과가 나올 것이다.

역할의 확장

이전 회사에서는 스쿼드에서 제품 개발에 적극적으로 참여하면서 프론트 개발자의 역할을 했고, 프론트엔드 공통 영역(플랫폼)에 적극적으로 많이 기여 했다.

지금 회사에서는 기획이라는 영역에 다리 하나는 들어간 것 같다. UI UX, 데이터 분석에도 발 한쪽 정도는 들어갔다.

어드민 시스템 기획, 개발 자동화를 위한 기획, 독립적인 MVP 제품 기획 · 디자인 · 개발(서버, AI, 프론트) · 데이터 분석, 유저 데이터 분석을 기반으로 가장 진입률이 높은 페이지의 UI UX 개선 등등이 기억난다. 이 과정에서 다양한 직군의 동료들과 커뮤니케이션이 필요했고 전반적인 업무 프로세스나 동료들이 어려움을 느끼는 부분도 알게 되었다.

기획은 PM보다는 TPM이 하는 일에 가까웠고, 백엔드, UI UX, AI라는 영역을 조금씩 붙들고 있었기 때문에 이게 가능했던 것 같다.

AI 시대에는 혼자서 다 할 줄 알아야 한다는 얘기도 하는데 한 걸음 정도는 가까이 간 것 같다.

플랫폼 영역은 원래 다리 하나 정도 들어가 있었다면 지금은 몸 절반 정도는 들어갔다.

위에서 나는 불편함을 느끼는 사람이라는 얘기를 했는데 그게 플랫폼 업무를 하는 데 도움이 되었다.

꽤 많은 마이그레이션을 진행했고, 큰 그림이 조금씩 완성되어 가는 것도 느껴진다.

공부

OS

맨날 미루던 OS를 드디어 시작했다. 25년에 완벽히 마무리하는 게 목표였는데 완벽히 마무리하지는 못했다. 책과 강의를 기반으로 공부하다가 나중에는 그냥 책만 보면서 공부했다. 정확히는 책에서 모르는 내용을 AI에게 물어보고 모의 면접도 진행했다. 아직 모든 부분이 완벽하지는 않지만 더 이상 OS가 내 약점은 아니다.

OS 공부를 늦게 시작했는데 늦게 시작한 게 오히려 좋았던 것 같다. 취업하기 전 억지로 책을 봤을 땐 외우는 느낌이 들었는데 지금은 외운다기보다는 전체 흐름을 이해하면서 공부하는 느낌이다. 심지어 예전에는 지루하기만 했던 OS 공부가 지금은 재밌게 느껴질 때도 있다.

함수형 DDD

과거 유튜브 강의로 들었던 강의가 있다. 그 강사님이 라이브 강의를 한다는 소식을 들어서 신청하게 되었다. 진짜 배운 게 많다.

너무 low level이나 high level을 공부하다 보면 학습 방향성에 대한 고민이 들기 마련인데 OS와 함수형 DDD를 같이 공부하다 보니 그런 고민이 사라져서 좋았다.

https://github.com/yoonminsang/TIL/tree/main/%08%EC%B1%85/%EB%8F%84%EB%A9%94%EC%9D%BC%EC%A3%BC%EB%8F%84%EC%84%A4%EA%B3%84%EB%A5%BC%EC%9C%84%ED%95%9C%ED%95%A8%EC%88%98%ED%98%95%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

TIL/ 책/도메일주도설계를위한함수형프로그래밍 at main · yoonminsang/TIL

Today I Learned. Contribute to yoonminsang/TIL development by creating an account on GitHub.

github.com

https://www.youtube.com/@NeuronDevAI

뉴런데브

AI시대의 개발자를 위한 학습 채널입니다. 뉴런데브 강의 개발자를 대상으로 하는 인공지능 기반의 개발을 다룹니다. 인공지능에 대한 다양한 지식과 개발응용을 학습합니다. 코드스피츠 강의

www.youtube.com

headless tree 라이브러리 배포

나는 headless tree를 만든 적이 있다. 그리고 이걸 조금만 고도화한다면 오픈소스로 만들 수 있을 것 같다는 생각이 들었다. 그렇게 그 생각이 잊혀지던 와중에 우연히 링크드인에서 누군가 tree 컴포넌트를 만들어서 배포한 것을 봤다. 그 순간 마음이 조급해졌다. tanstack 같은 곳에서 곧 만들 것 같았고, 그전에 한 번 시도해보고 싶었다. 그래서 예전에 만들었던 방법을 떠올리면서, 이전보다 더 좋은 방법으로 headless tree를 완성했다.

몇십만 개의 데이터를 다루다 보니 가상화 이외에도 최적화가 필요한 것을 알 수 있었고 전부 해결해서 몇십만개의 tree를 다룰 때도 부드럽게 인터렉션하는 트리를 만들었다. 가볍게만 설명하면 "대용량 객체의 상태 분리 최적화"와 noramlize를 사용했다.

인터페이스도 마음에 들고 성능도 마음에 든다.(테스트코드는 조금 개선이 필요하다.)

내년에는 조금 더 발전시키고 다른 나만의 오픈소스 라이브러리를 만들면 좋을 것 같다.

https://github.com/yoonminsang/headless-tree

GitHub - yoonminsang/headless-tree: react-headless-tree

react-headless-tree. Contribute to yoonminsang/headless-tree development by creating an account on GitHub.

github.com

TIL

올해는 유난히 더 많이 TIL을 올렸다.

그 이유는 깊이파고들기 글과 TIL 커뮤니티(아래에서 설명) 덕분이다.

아래 링크에서 내가 학습한 내용들을 확인할 수 있다.

https://github.com/yoonminsang/TIL

GitHub - yoonminsang/TIL: Today I Learned

Today I Learned. Contribute to yoonminsang/TIL development by creating an account on GitHub.

github.com

https://frontend-fundamentals.com/today-i-learned/profile/yoonminsang

Today I Learned

frontend-fundamentals.com

블로그

지금 이 글을 제외하고 올해 12개의 글을 썼다. 아주 많지도 적지도 않은 적당한 개수인 것 같다. 지금 가장 기억나는 건 겸손함에 대한 글이다. 내년에는 지금보다 더 겸손하고, 쪽팔린 걸 두려워하지 말고 적극적으로 행동해야겠다.

https://ms3864.tistory.com/481

겸손함에서 뻗어나가는 생각들...

옛날부터 겸손해야한다. 겸손해야한다. 여기저기서 10번도 넘게 들었던 말이다. 나는 겸손해야하는 이유가 남에게 미움받지 않기 위해서라고 생각했었는데 지금은 생각이 좀 다르다. 정말 겸손

ms3864.tistory.com

기타 활동들

독서

맨날 책 읽어야지 읽어야지 생각만 하다가 드디어 독서를 시작했다. 독서할 시간에 전공책을 읽는 게 더 좋지 않을까 라는 생각도 조금 했었는데 책을 몇 권 읽어보니 그 생각은 잘못되었다는 걸 알 수 있었다. 전공책 하나를 덜 보더라도 독서를 하는게 훨씬 나에게 도움이 되었다.

성과를내고싶으면실행하라

회사에서 추천하는 책이라서 읽었는데 진짜 내용이 너무 좋았다. 책을 읽다 보니 자연스럽게 내 지난 아쉬웠던 경험들이 머릿속을 스쳤다. 그리고 이 책을 그때 읽었다면 결과가 달라졌을까? 라는 생각이 들었다. 현실의 벽이 얼마나 큰지 알고 있기 때문에 단순히 책 하나로 바뀔 거라고 생각하지는 않는다. 그래도 5% 정도는 긍정적인 영향을 줄 수 있지 않을까? 라는 생각이 들었고 조직 관점에서 팀 관점에서 나는 어떤 역할을 해야 하는지 그런 고민들로 자연스럽게 확장하게 되었다.

https://github.com/yoonminsang/TIL/tree/main/%08%EC%B1%85/%EC%84%B1%EA%B3%BC%EB%A5%BC%EB%82%B4%EA%B3%A0%EC%8B%B6%EC%9C%BC%EB%A9%B4%EC%8B%A4%ED%96%89%ED%95%98%EB%9D%BC

TIL/ 책/성과를내고싶으면실행하라 at main · yoonminsang/TIL

Today I Learned. Contribute to yoonminsang/TIL development by creating an account on GitHub.

github.com

새로운질서

AI와 미래에 대해 철학, 역사, 정치 등 다양한 관점에서 바라본 책이다. 헨리 키신저라는 사람의 가치관이 나와 약간 비슷하다고 느껴져서 더 흥미로웠던 책이다. 번역이 조금 어렵게 되어있어서 원서가 더 읽기 쉽다는 평가가 있는데 원문이든 번역본이든 읽었을 때 후회하지 않는다고 확신한다.

https://ms3864.tistory.com/483

새로운 질서 독후감

마음의 이상주의는 이성의 현실주의와 양립할 수 있으며 전자가 후자를 고귀하게 만든다는 것을 그는 평생에 걸쳐 증명하려고 애썼다. 위 한 문장만으로 이 책을 읽을 가치가 있다고 느꼈다. 나

ms3864.tistory.com

수영

수영을 시작한 이유는 두 가지다.

1. 허리 강화

허리가 점점 안 좋아지는 게 느껴졌다. 수영이 허리에 좋다는 건 너무나도 많이 알려진 사실이라서 시도해 보기로 했다.

2. 평생 맥주병으로 살고 싶지는 않다.

앞으로 바다, 빠지, 수영장 갈 일이 많은데(솔직히 많은진 모르겠다) 평생을 수영 못하는 건 너무 슬프다는 생각이 들었다. 잘하진 않아도 최소한 물에 뜰 정도는 배우고 싶었다.

PT

내가 PT를 하게 될지 몰랐다. 올해는 운동을 열심히 하지도 않았고 큰 욕심도 없었다.

우연히 처음 하는 기구를 하다가 PT 선생님이 나를 도와줬고 OT를 받게 되었다. OT 이후 PT 영업은 필수적이란 걸 알고 있었지만 나는 이미 버텼던 경험이 있다. 그런데 OT 경험이 생각보다 좋았고(시간도 원래 50분인데 거의 3시간 진행) 허리 강화, 스트레칭 등으로 어필을 하셔서 넘어갔다. 50회나 끊기는 했지만.. 가격도 꽤 합리적이었다.

아직 몇 번밖에 안 했는데 지금까지는 좋다. 그동안 스트레칭은 크게 신경 안 썼는데 이제는 스트레칭도 신경 쓰면서 하게 되었고, 등 중앙부와 허리 아치 등을 강화하고 있다. 아마 혼자서는 평생 해도 고치기 힘들었을 것 같다.

외부활동

그동안은 특별한 외부활동을 하지 않았는데 올해는 작지만 몇개의 외부활동을 했다.

테크밋업

특정 회사에서 열린 테크밋업을 다녀왔다. 개인적으로는 조금 아쉬웠지만.. 다양한 개발자들과 얘기해 본 건 좋은 경험이였다. 테크밋업을 열려면 여러 가지 준비할게 많을텐데 이 기회에 회사에도 감사하다는 말씀을 드립니다.

TIL 커뮤니티 모임

특정 회사에서 TIL 커뮤니티를 만들고 있는데 베타테스터로 참여하자는 지인의 연락을 받았다. 그렇게 참여하게 되었고 한 번 회식도 했다. 확실히 내 세상 밖의 개발자들과 얘기를 해보니 좋았다.

독서토론

이직하기 전에도 커뮤니케이션 역량을 늘리기 위해 많은 노력을 해왔다. 그리고 이직하고 나서는 이전보다 더 큰 역량이 필요함을 느끼게 되었고 개발자 + 커뮤니케이션 관련 주제의 독서토론을 신청하게 되었다. 너무 좋은 경험이였는데 한 번 만에 종료되어서 아쉽다. 이후에 다시 열릴 수도 있다는데 그 기회를 일단 잡아보고 안된다면 다른 독서토론이라도 신청하고 싶다.

https://ms3864.tistory.com/484

새로운 질서 독서토론 후기

서론지인이 직무 관련 독서토론을 하는 것을 보고 나도 관심이 가서 추천해달라고 했었다. 그렇게 추천을 받고 오랜 시간이 지난 후에야 독서토론에 참여하게 되었다. 이번에는 새로운 질서라

ms3864.tistory.com

투자시작

미루고 미루던 투자를 시작했다. 사실 이직으로 인해 IRP 계좌가 필요해졌고 자연스럽게 돈을 굴려야만 하는 상황이 왔다.
나는 IRP 연금저축 ISA에서 S&P 500을 메인으로 하고, 미국주식 · 국내주식은 조심스럽게 적은 금액으로 투자를 해보고 있다.
초보 투자자의 시선에서 기억나는 건 다음과 같다.
- 피그마 30% 급락을 보면서 무조건 버티는 게 좋은 게 아니란 걸 느꼈다. 적절한 손절이 필요하다. 또한 우량주가 아니라면 투자하기 더 조심스러워졌다.
- "좀 떨어지면 어때, 다시 오를 텐데"라고 생각했는데 여러 종목이 크게 떨어지자 원래 생각과는 다르게 팔아버렸다. 오를 걸 알고 있었지만 그 당시 스트레스를 감당하기 힘들었다. 근데 지금은 좀 괜찮아졌다. 좀 떨어져도 그러려니 한다. 1년 정도는 이 경험을 통해 나라는 사람을 조금 더 알아보려고 한다.
- 기술주만 투자하면 너무 리스키하다는 걸 느꼈다. 트럼프 한마디에 흔들리는 게 너무 크다. 배당주, 방어주, 기술 외의 분야에 대한 투자도 같이 가져가고 있다.

새로운 질서 독서토론 후기

안양사람 — Sat, 29 Nov 2025 21:09:43 +0900

서론

지인이 직무 관련 독서토론을 하는 것을 보고 나도 관심이 가서 추천해달라고 했었다. 그렇게 추천을 받고 오랜 시간이 지난 후에야 독서토론에 참여하게 되었다. 이번에는 새로운 질서라는 책을 기반으로 독서토론을 했다. 너무 인상깊게 읽었고 요즘 뜨거운 감자인 AI 관련 주제라서 더 관심이 갔다.

본론

아이스브레이킹부터 시작했다. 역시 이런 모임에는 아이스브레이킹으로 긴장감을 풀고 시작하는게 좋은 것 같다. 가벼운 게임을 진행했는데 나도 나중에 기회가 된다면 이런식으로 아이스브레이킹을 해봐도 괜찮을 것 같다는 생각이 들었다.

몇 가지 기억나는 질문들만 가볍게 적어보겠다.

"이 책에서 꼭 공유하고 싶은 한 줄은 무엇인가요"

마음의 이상주의는 이성의 현실주의와 양립할 수 있으며 전자가 후자를 고귀하게 만든다는 것을 그는 평생에 걸쳐 증명하려고 애썼다.

기억에 남는건 꽤 많았지만 마음을 울린건 그 한 줄이였다. 흔하진 않지만 가끔 나처럼 이 문장에 감명을 받은 사람들이 있다고 했다. 아마 그들 모두 남들이 볼 때는 이성의 현실주의이지만 마음 한 켠에는 마음의 이상주의가 있는 사람들이 아닐까 라는 추측을 해본다.

"기술의 진보를 인류가 긍정적으로 사용할 것인가"

나는 다이너마이트와 비슷하다고 생각한다. 처음에는 인류를 돕기 위해 사용되다가, 언젠가 인류를 위협하고, 언젠가 인류에게 피해를 주며, 그 위험성을 눈으로 보고 나서야 위험성을 막기 위한 제도를 만들 것이라고 생각한다. 그리고 지금은 인류를 위협하는 부분으로 넘어가는 전환기에 있다.

"AI 시대에 나만의 경쟁력은 무엇인가요?"

참 어려운 질문이다. 나는 사실 AI로 인해 직업을 잃어버리는 것을 크게 걱정하는 사람은 아니다. 그 당시 나는 4가지를 얘기했다. 근데 지금 생각해보니 5가지다. 지금 다시 바라보니 나만의 경쟁력이라기에는 조금 약하고 나만의 경쟁력을 키워나가고 있는 부분이 더 정확할 것 같다. 주로 스타트업을 다니다보니 지금 연차면 주니어 취급을 받지 못하는데, 나보다 압도적으로 높은 연차의 분을 보다보니 경쟁력이라는 말을 쓰는게 좀 부끄럽게 느껴지기도 했다.

제품을 보는 능력

나는 플랫폼 관련된 업무를 많이 해왔고 관심도 있지만 본질은 product 개발자라고 생각한다. 제품에서 개선해야될 부분, 어색한 ux, 유저입장에서 어려운 기능인지 등을 판단할 수 있다. 이는 사람도 판단하기 쉽지 않은 부분이다. 그렇기 때문에 AI도 판단하기 쉽지 않다. (물론 나의 그런 능력이 진짜 그렇게 뛰어나냐고 물어보면 자신있게 대답하기는 어렵다. 또한, 언젠가 AI가 대체할 수 있는 부분이기도 하다.)

개발전체를 아는 능력

나는 원래부터 프론트개발자가 될 생각없이 풀스택으로 공부했던 사람이고 다른 분야에도 관심이 있기 때문에 가벼운 서비스정도는 만들 수 있다. 0만큼 아는 것과 1만큼 아는 것은 그래도 꽤 큰 차이가 있기 때문에 언젠가 AI를 이용해서 1인 기업을 차릴수도 있다.(물론 이건 정말 쉽지 않다. 지금 그럴 생각도 없고)

비지니스를 보는 능력

좋은 제품을 만든다고 돈을 잘버는건 아니다. 비지니스를 이해해야한다. 이전에 비하면 비지니스를 꽤 많이 같이 보고 있다는 생각을 한다.(이건 경쟁력이라고 하기에 진짜 민망할 수준이다. 냉정하게 말하면 비지니스를 가볍게 이해하고 그걸 기반으로 개발적 의사결정을 할 수 있는 수준아닐까? 라는 생각이 든다.)

AI에 관심이 있고 잘 사용하는 능력

나는 항상 AI를 적극적으로 사용하려고 다양한 노력들을 하고 있다. AI 관련된 서비스를 0부터 만들어보기도 했고 AI 기반의 신규 제품을 기획하고 이끌어가는 경험도 있다. 잘 사용하기 위해서 다양한 고민들도 하고 레퍼런스들도 보고 있다.(이정도로는 조금 부족해서 AI 기반의 가벼운 서비스를 한 번 만들어볼까 생각중이다.)

커뮤니케이션 능력

책에서는 AI가 여러 분야의 지식들을 통합할 수 있다는 얘기를 한다. 그렇다고해서 회사에서 일어나는 모든 분야의 지식들을 통합할 수 있다는 것은 아니다. 나는 AI 시대에는 문과적 능력이 더 중요하다고 생각하는 사람이다. 그 중 하나가 문서화고 이게 되지 않으면 지식을 통합하는게 불가능하다. 그리고 이 문서화를 하기 위해서는 커뮤니케이션이 필수적으로 이뤄져야 한다. 나는 신입부터 지속적으로 이 능력을 기르고 있다. 원래는 커뮤니케이션이 가장 큰 결함이였지만, 어느새 특정 부분에서는 이게 내 장점이 되기도 했다. 이대로 시간이 더 흐르면 정말 차별화된 능력이 될 수 있지않을까? 라는 생각을 한다.

어떤분은 AI 시대에는 CEO가 되어야한다고 말했다. 주저리 주저리 여러 얘기를 했지만 결국 내가 써놓은 것들은 대부분 CEO가 갖춰야할 역량이 아닌가 싶다. 나는 사실 AI 시대에는 CTO가 되어야한다고 생각했다. CEO냐 CTO냐 조금 다른 부분은 있지만 결국 여러 분야를 골고루 다 잘하는 사람이 되어야하는건가? 라는 생각도 든다. 그런 측면에서는 내가 스타트업을 다니는게 꽤 이점이 있다.

위에 적지는 않았지만 학습을 게을리하지 않는것도 나의 큰 장점이라고 생각한다. 25년이 끝나기 전에 운영체제 공부를 마무리하고, 함수형 DDD 공부를 시작하는 것(이미 강의는 신청함)을 목표로 하고 있다. AI 시대의 가장 큰 문제는 주니어들이 학습의 기회를 잃어버린 것이다. 독후감에서도 얘기했지만 나는 AI를 파트너로 대하고 싶다. 그렇기 때문에 기본 개발 역량을 기르는데도 소홀히 할 생각은 없다. AI가 다 대체할건데 무슨 소용이 있냐고 물어보는 분들이 있을 수 있다. 그 주장이 틀린 주장은 아니라고 생각한다. 하지만, 그렇다고 벌어지지 않을 미래를 확정하며 학습의 기회를 놓쳐버리는게 과연 옳은 선택인지는 진지하게 생각해볼 필요가 있다. AI 시대의 흐름을 따라가는 것은 중요하지만 그렇다고 위험을 감수할 필요는 없다.

"책임감 있는 AI 활용 원칙"

위 원칙을 정하기 위해 다양한 얘기들을 했는데 어느순간 깨달은게 있다. 원칙에 대한 설명이 적혀있는데 이 설명이 너무나도 모호했다. 그리고 이건 흔히 면접에서 사용하는 기법이다. 모호한 질문을 주고 그 질문을 구체화하는지, 어떻게 구체화하는지, 커뮤니케이션은 어떻게 하는지 이런 역량들을 본다. 그리고 이는 면접뿐만아니라 실무에서도 수도 없이 많이 발생한다. 특히 비개발자와 개발자 사이에 모호한 질문들이 더 많이 일어나고 이 모호한 질문들을 구체화시키는건 보통 개발자의 역할이다. 이걸 꽤 늦게 깨달았다. 원래 알고 있었지만 한 번 더 배웠다.

크게 AI 모델 공급자, AI로 서비스를 만드는자, AI를 사용하는자 정도가 나왔는데 이중 하나를 결정하기 쉽지 않아서 우리는 제너럴한 케이스를 생각하기로 했다.

문서에는 이 원칙을 3~5가지 정도의 체크리스트로 만들라고 했다. 그래서 우리는 보안, 윤리, 정확도, 중립, 책임인지 5가지를 정했다. 그리고 이 내용들을 기반으로 내가 발표했다.

발표가 끝나도 나는 뭐가 잘못된지 몰랐다. 정답을 알려주고 나서야 알았다. 이건 체크리스트가 아니다. 체크리스트라는건 체크리스트를 보고 바로 쉽게 판단할 수 있어야 한다. 비행기에서 사용하는 체크리스트는 "안전한가"가 아니라 "1시간전에 점검을 마쳤는가" 처럼 명확해야 한다. 나는 이걸 끝까지 몰랐다는게 너무 아쉬웠다. 최근에 "성과를 내고 싶으면 실행하라"라는 책을 읽었는데 완전 동일한 얘기가 나왔다. 그런데 이 의도를 못알아차린건 반성해야한다. 확실히 이론만 배워서는 현실에 바로 적용할 수 없다. 독서토론 한번에 이런 작은 실패를 경험한건 오히려 행운이다.

후기

너무 좋은 경험이였다. 4시간동안 진행했지만 너무 짧게 느껴졌다.

아쉽지만 이 독서토론은 이날이 마지막이였다.. 마음먹고 신청했는데 단 한번만에 토론이 없어져서 아쉽다. 다음에도 이런 기회가 있으면 (아니 기회를 찾아서) 참여해봐야겠다.

새로운 질서 독후감

안양사람 — Sun, 23 Nov 2025 21:14:01 +0900

마음의 이상주의는 이성의 현실주의와 양립할 수 있으며 전자가 후자를 고귀하게 만든다는 것을 그는 평생에 걸쳐 증명하려고 애썼다.

위 한 문장만으로 이 책을 읽을 가치가 있다고 느꼈다. 나는 슬픈 영화를 봐도 울지 않는 사람인데 눈물이 날뻔했다. 나는 이성의 현실주의에 가까운 사람이다. 그래서 비판적 사고와 긍정적 사고를 하는 사람이라고 생각해왔다. 어쩌면 내 긍정적 사고는 마음의 이상일지도 모른다. 그리고 비판적 사고는 이성의 현실주의와 맞닿아있는 것 같다.
우리 모두는 이상과 현실을 모두 바라본다. 사람에 따라 이상과 현실을 바라보는 비중이 다를뿐이다. 인간이란 원래 그렇지만 최근들어 이분법적인 사고와 그에 따른 갈등이 늘어나는 것 같다. 모두 장단점이 있으니 서로 잘 융화되어서 잘 지냈으면 하는 작은 바람이 있다. 하지만 나는 이미 가치관이 다르다는 이유만으로 전쟁을 하는게 이해되는 순수하지 않은 어른이 되었다. 이 작은 바람도 이상이고 전쟁은 현실일뿐이다.

책을 읽다보니 몇몇곳(탐사, 지구 행성 너머)에서 '인간의 호기심은 막을 수 있는걸까?'라는 생각이 뇌리를 스쳤다. 나는 인간의 호기심은 무엇도 막을 수 없다고 생각한다. 그리고 그건 다양한 역사가 증명한다. 진격의 거인이라는 만화에서 '인간의 탐구심은 누군가가 막는다고 해서 멈출 수도 있는 게 아니오', 원피스라는 만화에서 '실체할지도 모르는 원피스를 찾아 목숨을 걸고 항해하는 것' 등 여러 매체에서도 이를 다루고 있다. 그리고 이게 인류(집단, 개인)를 발전시키기도 멸망시키기도 한다는 것은 너무나도 자명한 사실이다. 그리고 AI가 이 인간의 호기심을 위험으로부터 막을 유일한(?) 수단이다.

공리주의적으로 생각해서 특히 만일 AI가 제 결정의 근거를 설명한다면, 우리의 직관은 먼 미래를 감안한 AI의 판단을 받아들일 것이다. 하지만, 지금 살아가는 우리 인간에게 해로운 정책에 항의하는 사람들이 생길 수 있다. 군사적 갈등도 마찬가지다.

사실 지금 정치도 마찬가지다. 많은 사람들은 자신에게 이득을 가져다주는 정치인에게 투표한다. 세대, 성별, 지역, 직업, 재산 등에 따라 자신에게 이득이 될지 손해가 될지가 명확하다. 그리고 미래를 생각하기보다는 지금 자신의 상황이 더 나아지기 위해 투표한다. 그리고 정치인은 이를 이용한다. 나는 이런 행동이 너무나도 당연하다고 생각하고 지적하고 싶지도 않다. 누군가는 나라를 위해, 미래를 위해 자신의 손해를 감수하지만 당연하게도 이런 선택을 하는 건 소수다. 만약 정말 AI가 정말 뛰어나게 발전해서 미래를 위해 옳은 의사결정을 한다고 해도, 이걸 받아들이는건 어려울 것이다. 그리고 이런 갈등을 조율하는게 인간의 역할이 아닐까 싶다. 그 조율은 투표가 될 수도 있고 강압이 될 수도 있다. 마치 핵폭탄의 개발을 막고 있는 지금의 미국처럼.

현실주의만으로 세상이 흘러가기는 어렵다. 아니 어쩌면 이건 현실주의가 아니라 이상주의라고 봐야될수도 있다. AI가 발전해서 미래의 인류를 위해 우리 세대가 희생한다면 이건 이상주의적인걸까 현실주의적인걸까?

이 책에서는 AI의 이성 통치는 감성이 부족한 문제가 있다고 말한다. 나는 조금 생각이 다르다. 감성적인 부분도 이성적으로 판단할 수 있지 않을까? 이성적으로 상대방의 기분, 감정을 파악하고 논쟁을 승리로 이끄는 행동은 현실 세계에서 꽤나 필요한 방법이다. 그리고 최근 AI의 추론을 살펴보면 내 감정을 생각해서 말하려고 하는게 보인다. 정말 감수성이 필요한 영역까지 가능하냐고 물어볼 수 있는데 나는 그것도 가능하다고 생각한다. 요즘은 MBTI T와 F로 얘기를 많이 하는데 T는 F를 진정으로 공감할 수 없다고 한다. 근데 그건 T의 체력 부족, 능력 부족이라고 생각한다. 설령 나와는 다른 생각을 가지고 있다고 해도 상대방의 생각을 이성적으로 분석하면 그 감정을 이해하고 적절하게 반응할 수 있다. 결국 AI도 충분히 감성적 영역을 다룰 수 있다고 생각한다.

우리는 이와 같은 정치의 불완전한 특성을 보존해야 하며, 결국 이를 AI 시스템의 완벽함과 결합해 AI를 보완적인 파트너로 만들어야 한다.

나도 비슷한 가치관을 가지고 있다. 나는 항상 극단적으로 생각하지 않으려고 한다. 그리고 이건 업무할 때 특히 크게 느껴진다. 하지만 당연하게도, 완전 중앙에 있을 수는 없고 양자택일을 해야하기도 한다.

이건 면접에서도 자주 나오는 질문이다. 'A와 B중 어느것을 선호하시나요?'라는 질문에 나는 '상황에 따라 다르다'고 답변한다. 당연히 면접관은 더 구체적으로 물어볼거고 나는 그 상황을 더 구체화시켜서 이때는 A, 이때는 B를 선택한다고 말한다. 면접관이 한 번 더 가정을 해서 물어보는 경우가 있는데 이때는 99% 확률로 애매한 가정을 한다. 나는 그때도 상황을 구체화시켜서 답변을 하고, 개인적인 선호도를 얘기하기도 한다. 물론 정말 확실하다고 생각하는 질문이라면 특정 답변을 하기도 한다.

아직 경험이 많지는 않지만 내가 느꼈을 때 현재 조직의 문제를 해결하기 위해, 팀원의 이전 (좋은 or 안좋은)경험으로 인해 극단적인 결정이 이뤄지는 경우가 많은 것 같다. 그래서 나는 조금 더 객관적인 사람이 되려고 노력한다. 군대에서는 문제가 생기면 그냥 그 문제가 발생할 상활 자체를 없애버린다. 정치에서도 마찬가지다. 사고가 터져서 전체 수학 여행을 막는다던가, 특정 사고가 바이럴되면 극단적인 결정이 이루어진다던가 너무나도 많은 예시가 있다.

이성적인 영역과 감성적인 영역, 이상주의와 현실주의 모두 다 중요하다. 중요한건 그 극단속에서 적절한 중간 지점을 찾고 최적의 해결책을 찾아내는 것이다.

AI의 발전으로 언젠가 유전자 편집이 가능해질지도 모른다. 20년전에 성형수술이 한참 화재가 되었을 때 비슷한 얘기가 나오기도 했다. '모든 사람이 다 똑같이 성형수술로 잘생기고 예뻐지면 어떤 세상일까'라는 얘기였는데 아마 그때는 부작용이 있기도 하고 개성이라는게 중요하다고 생각해서 반대했던 것 같다. 근데 앞으로의 미래는 외모뿐만 아니라 질환, 성격, 능력까지 바꿀 수 있을지도 모른다.(가능한지, 유전자 질환의 문제가 없는지 등등은 다 AI가 해결해준다고 가정)

나는 인간의 가치가 외적인 모습보다는 내적인 모습에서 나온다고 생각한다. 그래서 외모를 자유자재로 바꿀수있는것에 대한 거부감은 덜하다. 근데 성격, 지적 능력, 가치관까지 바꿀 수 있다면 이건 어떻게 되는걸까. 이건 내가 원하는 게임 캐릭터를 만드는 것과 비슷하다고 느껴진다. 근데 게임 캐릭터는 내가 조종할 수 있다. 그런데 AI를 이용해서 내가 나를 조종한다면 어떻게 되는걸까. 내 이전 기억은 가지고 있지만 성격이 바뀌었기 때문에 이전의 가치관은 현재의 나의 가치관과 전혀 무관할 수 있는건가. 여러가지로 혼란스럽다. 누구나 잘생기고 똑똑하고 이성적이면서 감성적인걸 원한다. 당연히 조금씩 그 정도는 다를거다. 그러면 진짜 게임 캐릭터처럼 능력치를 1씩 조절하는 느낌인걸까? 당연히 이 능력치도 좋고 나쁨의 능력치가 아니라 mbti T VS F 같은 능력일 것이다. 잘 모르겠다. 나는 너무 혼란스럽다. 결국 그렇게 되면 인간은 무엇인지 철학적 질문에 빠지게 된다.

AI는 오늘날 기후 딜레마의 원인으로 지목된다. 이 책의 저자들은 그러한 관점이 지나치게 근시안적이며, 현재의 문제를 해결할 중요한 기회를 놓치게 만들 거라 우려한다.

AI 관련해서 얘기하던 중에 환경에 대한 얘기가 나온적이 있었다. 나도 환경에 큰 관심을 가지고 있는 사람은 아니지만 AI로 인해 걱정이 되는건 사실이다. 나는 지구공학 문제까지 AI가 해결한다고 생각해본적이 없다. '이렇게 접근을 하는게 맞는건가?'라는 생각이 든다. 오히려 AI의 발전으로 인해 환경문제가 더 심각해지고 이걸 해결하기 위한 연구, 지원이 적극적으로 이루어지고 이걸 해결하는데 AI를 적극적으로 활용할 수 있게 도움을 주는 방향이 맞는거아닐까? 그냥 AI가 발전해서 해결할거니까 괜찮다는 시각은 좀 위험해보이기도 한다. 이게 마음의 이상주의라는걸까? 어느정도 저자들의 생각을 알것같다.

우리가 그들과 닮아갈 것인가, 아니면 그들이 우리와 닮아갈 것인가?

인간은 불완전함으로써 완성된다. 완벽한건 인간이 아니라고 생각한다. 그리고 그 완벽하지 않은걸 보완해주는게 기계, AI라고 생각한다. 그리고 이 기계, AI도 완벽하지 않기 때문에 사람이 보완해줘야한다. 이는 책에서 얘기한 공진화의 설명과 일치한다. 생명공학적인 변화가 없어도 이미 사람과 기계는 공진화를 통해 발전하고 있다.

코딩 언어도 기계어, 어셈블리어, C언어 등을 거쳐 파이썬, 자바같은 인간이 다루기 쉬운 언어로 발전해왔다. 인간을 다른 무언가에 맞추는 것은 정말로 큰 변화일 것이다. 나도 원하지 않는다. 나를 도와줄 기계를 원하지 내가 기계가 되는걸 원하지는 않는다.

AI에서 기술적 어려움은 비교적 풀기 쉬운 문제다. 핵심적인 문제는 '선'과 '악' 개념이 자명하지 않다는 점이다.

최근 챗봇관련한 작업을 하고 있는데 나도 비슷한 문제에 부딪혔다. 사실 내가 푸는 문제는 도덕성, 선과 악을 구분할만큼 어려운 문제는 아니다. 현실 세계의 문제를 추상화시키고 상황에 맞는 적당한 가이드만 해주면 된다. 근데 이 가이드라는게 사람마다 생각이 다르다. 고작 이정도의 일도 쉽게 판단할 수 없는데 선악에 대한 문제는 판단하는게 불가능에 가깝다.

나는 그냥 승자가 '선'이라고 생각한다. 그리고 도덕성이라는것도 명확히 할 수 없다. 이건 영원히 불가능하다고 생각한다. 인간이 최종 발전을 한다면 이 판단이 가능해질지도 모르겠지만 나는 그것도 가능하지 않다고 생각한다. 인간은 영원히 발전할거라고 생각한다. 언젠가 끝이 있을거라고 말할지 모르지만 수학에서 무한대의 개념이 존재하듯이 이것도 마찬가지라고 생각한다.

그래서 지금까지의 역사, 지속적으로 발생하는 역사적 사건들을 학습시켜서 다양한 관점과 AI의 추천점수 정도만 제공하면 어떨까 싶다. 이 책에서 계속 얘기했듯이 최종 결정은 AI가 아니라 인간이 해야한다.

이 책의 저자들은 존엄성을 정의할 것을 장려한다.

통제와 효용, 역사적으로 독립적인 인간이 가진 안락함과 완전히 새로운 협응의 가능성 사이에 택해야 하는 고통스러운 선택이다.

냉철한 낙관주의를 품는다면 우리는 새로운 시작을 맞이할 수 있다.

결국 이게 이 책의 핵심적인 내용이다. 존엄성을 AI에게 주입하고(이건 내가 감성을 AI에게 주입할 수 있다는 것과 유사하다.) 극단적이지 않은 중간 입장에서 냉철한 낙관주의(마음의 이상주의와 이성의 현실주의)로 새로운 시작을 받아들이면 된다.

책을 잘 읽지않는 나에게 이 책은 꽤나 어려웠다. 하지만 이 책의 스타일을 깨닫고 적응한 뒤에는 쉽지는 않지만 재밌게 읽었다. 철학, 역사 등으로 이야기를 시작하고 어느샌가 독자는 내용에 빠져들게 된다. 그리고 어느샌가 AI와 무관하게 글을 읽다가 어느순간 AI와 이야기를 연결시킨다. 나는 그 때 '아 이거였구나.' 라는 생각이 들면서 같이 고민하면서 이야기에 빠져든다. 직업 특성상 명확한 문서를 쓰는 경우가 많은데 때로는 장문이지만 빠져들게 하는 글, 화법을 사용해야하는 경우도 있다. 나는 본래 커뮤니케이션 스킬이 좋은 사람은 아닌데 그동안 명확한 커뮤니케이션을 하기 위한 노력을 많이 해왔다. 그래서 그런지 간결하고 명확한 글쓰기에는 익숙하지만, 장문으로 몰입감을 주는 글이나 발표 능력은 부족한 것 같다. 이런 책을 많이 읽고 깊은 대화를 많이 나누면 조금 개선이 되려나 싶은 생각이 든다.

독후감을 오랜만에 써보는데 잘 쓴건지 모르겠다. 책의 전체적인 흐름이 아닌 특정 문구에만 너무 집중한게 아닌가 싶은 생각도 든다. 이 경험이 조금 더 쌓여서 실무에도 도움이 되기를 기대한다.

---

전체 정리

https://github.com/yoonminsang/TIL/blob/main/%08%EC%B1%85/%EC%83%88%EB%A1%9C%EC%9A%B4%EC%A7%88%EC%84%9C/README.md

TIL/ 책/새로운질서/README.md at main · yoonminsang/TIL

Today I Learned. Contribute to yoonminsang/TIL development by creating an account on GitHub.

github.com

독후감(위 블로그글과 동일)

https://github.com/yoonminsang/TIL/blob/main/%08%EC%B1%85/%EC%83%88%EB%A1%9C%EC%9A%B4%EC%A7%88%EC%84%9C/%EB%8F%85%ED%9B%84%EA%B0%90.md

TIL/ 책/새로운질서/독후감.md at main · yoonminsang/TIL

Today I Learned. Contribute to yoonminsang/TIL development by creating an account on GitHub.

github.com

겸손함에서 뻗어나가는 생각들...

안양사람 — Wed, 8 Oct 2025 23:13:34 +0900

옛날부터 겸손해야한다. 겸손해야한다. 여기저기서 10번도 넘게 들었던 말이다. 나는 겸손해야하는 이유가 남에게 미움받지 않기 위해서라고 생각했었는데 지금은 생각이 좀 다르다. 정말 겸손해야하는 이유는 다른데 있다고 생각한다.

능력과 겸손함의 역설

세상을 살다보면 어떤 분야든 나보다 잘하는 사람, 못하는 사람을 모두 만나게 된다. 그리고 특정 분야에서 나보다 못한다고 생각하는 사람의 의견은 무시하거나 "내가 했던 경험인데 그거 아니야" 라고 생각하는 경우가 있다. 근데 막상 들어보면 그 사람의 의견이 가장 좋은 해결책이 되기도 한다. 왜 이런 일이 발생하는 걸까? 나는 가장 큰 이유가 겸손함의 부족함이라고 생각한다.

그리고 이 겸손함은 경력이 많아지고 능력이 생길수록 결여되기 쉬운 부분이다. 경력 20년이 넘은 팀장이 신입 팀원의 의견을 듣고 내가 틀렸음을 인정하는 건 지금의 내가 생각해봐도 쉬운일이 아니다. 겸손이라는 능력치가 정말 높아야 가능할 것 같다.

리더십과 겸손함

이게 탑다운 문화와 연결될 수도 있는데 사실 그건 좀 생각이 다르다. 정말 능력 있는 사람이 있다면 탑다운도 나쁘지 않다. 하지만 실패했을 때 그 책임은 온전히 위에서 져야한다. 역할과 책임이 같이 가야하는데 역할만 가져가는게 문제지 둘 다 가져가는 건 문제가 아니다. 리더라면 언젠가 결정해야할 때가 있고 수평적 문화, 탑다운 문화와 무관하게 최선의 선택을 해야한다. 이때 겸손한 마인드로 팀원들의 의견을 듣고 리더십있게 결정하는게 내가 바라는(되고 싶은) 리더의 모습이다.

쪽팔린 상황을 대하는 방법

우리는 세상을 살다보면 쪽팔린 일들이 많이 생긴다. 그리고 그 쪽팔린 상황을 겪지 않기 위해서 좋은 기회를 포기하기도 한다. 과연 그 상황을 피했다고 해서 쪽팔린 상황을 영원히 겪지 않게 될까? 내 생각에 그렇지 않다. 언젠가 쪽팔린 일은 생긴다. 그냥 실행하는게 인생에 도움이 된다. 만약 쪽팔린 상황을 겪는다면 이불킥 100번하면 된다. 다만 나는 여기서 두가지만 지키면 된다고 생각한다.

첫번째, 회고하기.

경험하고 회고하면 다음에는 더 좋은 결과를 만들 수 있다. 물론 회고했다고 항상 다음에 잘할거라는 보장은 없다. 하지만 최소한 노력이라도 해야한다. 또 잘못되었다면 또 회고하면 된다.

두번째, 겸손하기.

직장생활한지 4년도 안되었는데 겸손하지 못했던 지난 날들이 떠오른다. 내가 그때 겸손했다면 이불킥할일이 없을텐데 생각한다. 조금만 겸손하면 결과도 좋게 나오고 부끄러울 일도 없어진다.

협업하기 좋은 동료가 되기 위한 방법(주석편)

안양사람 — Sat, 27 Sep 2025 19:37:10 +0900

배경

좋은 동료가 되기 위한 많은 조건들이 있다. 그리고 나는 좋은 동료가 되기 위해 어떤 행동을 하고 있는지 생각해보았다. 그리고 꽤 잘하고 있다고 생각하는 것들을 블로그에 하나하나 정리해보려고 한다.

주석을 왜 쓸까

일반적으로 사용되는 주석의 정의는 다음과 같다.

낱말이나 문장의 뜻을 쉽게 풀이함. 또는 그런 글 [1]

개발자가 사용하는 코드에서의 주석도 크게 다르지 않다. 개발에서 주석은 코드의 설명을 쉽게 풀이하거나 추가 설명을 위해 작성한다.

이렇게만 들으면 주석을 그냥 사용하면 끝일것같은데 실무에서는 어떤 문제들이 있을지 하나씩 살펴보겠다.

주석이 문제가 되는 경우

생각보다 주석이 문제가 되는 경우가 종종 있다. 그리고 내 생각에는 모두 해결책이 존재한다.(물론 상황에 따라 다를수는 있지만 정석이라고 부를만한 해결책이 있다고 생각한다.)

코드를 마구잡이로 작성하고 주석으로 퉁치는 행위

해결방법은 명확하다. 코드를 잘 짜야 한다. 주석으로 퉁치려고 하면 안된다. 그런데 이미 유지보수가 불가능할만큼 하드코딩 되어있고 이 기능이 전체 비지니스에 큰 영향을 주는 코드라면 세부적인 주석을 남기는게 오히려 도움이 된다. 나 같은 경우 당장 해결할 수 없지만 생각하는 그림이 있다면 주석으로 남겨놓는 편이다. 그리고 코드리뷰를 통해 팀원이 충분히 납득할만한 주석이면 성공이다. 만약 팀원이 주석을 보고 의문을 표한다면 조금 더 자세히 주석을 남기고 팀원에게 재리뷰를 요청하자.

코드는 변경되었는데 주석은 변경되지 않아서 무의미해진 경우

이건 좀 주관적인 의견에 가깝긴한데 의견을 남겨보겠다. 코드를 변경하는데 주석을 변경하지 않는다면 그건 코드를 변경한 사람이 잘못했다고 생각한다. 굳이 주석을 남겼다는건 필요해서 메모를 해놓은건데 코드만 변경하는건 무책임한 일이다. 물론 실수로 놓쳐지는 경우가 있을 수도 있다. 이건 개발자의 실수로 코드 변경이 누락된 것과 동일하게 생각한다.

그리고 불필요한 주석이 있다면 그 주석은 잘못 작성한 주석이라 그냥 지우면 된다. 잘못된 주석을 걱정하느라 주석을 작성하지 않는 것은 잘못된 문서를 작성할까봐 문서를 작성하지 않는 것과 동일하게 보인다.

주석을 써야만 하는 경우

유의미했던 경험을 조금 적어보겠다.

코드를 마이그레이션하는 경우

foo라는 함수를 전역에서 사용하는데 함수명을 foo2로 변경하기로 결정했다. 코드베이스가 작거나 인원이 작은 팀은 그냥 변경하면 끝이겠지만 그게 어려운 팀도 있다. 나는 보통 이럴 때 다음과 같이 작업한다.

- foo2 함수 생성

- foo함수에서 @deprecated 주석 작성 + 내부 코드를 지우고 foo2함수에 연결

- 만약 인터페이스가 달리지는 경우 조금 더 상세하게 주석으로 설명

- foo함수가 모두 사라졌다면 foo 함수 제거(사라지지 않았다면 다시 한번 팀원들에게 알림)

기존 코드베이스를 신규 코드베이스로 이전하는 경우

아주 자주 있는 경우는 아니지만 프로젝트를 레거시의 수준이 심각해서 점진적인 개선이 이루어지기 힘들다고 생각되는 경우 완전히 신규 코드베이스로 이전하는 회사들도 종종 있다. 이 때 필연적으로 두 가지 코드베이스를 대응하기 위한 코드가 필요하다.(공용으로 많이 사용하는 코드) 이걸 package로 관리할 수 도 있겠지만 그게 가능하지 않은 경우도 있다. 이런 경우 완전히 사용하는 코드가 달라질 수 있고 이 때 주석을 남기면 엄청나게 도움을 준다. 개인적인 경험으로는 이게 있느냐 없느냐에 따라 몇시간까지 작업시간이 차이날 수 있다. 처음부터 주석을 작성하지 못했다면 llm을 이용해 주석을 남기는 것도 좋은 방법이다.

유사한 코드가 여러 곳에 흩어져있는 경우

발견한 사람이 전부 고치면 좋겠다만 현실에선 그게 쉽지 않다. 이때도 주석을 사용하면 다음 작업자에게 작업 방향성을 알려줄 수 있다.

- deprecated 주석과 함께 다른 사용처로 연결하는 케이스

- deprecated 주석을 달고 다른 코드를 사용하라고 안내하기

- note 주석을 달고 유사한 코드가 어떤 코드가 있음을 안내하기(이 경우 코드가 달라져야할 때 쉽게 여러 코드를 대응할 수 있다.)

팀에서 주석 컨벤션 맞추기

주석 컨벤션은 꼭 있어야 한다. 각자 주석을 다는 스타일이 다르다면 이슈 트래킹이 쉽지 않다. 날짜, 이름, annotation(todo, note 등) 정도는 있으면 도움이 된다. snippet에 저장하고 꼭 컨벤션을 맞춰서 사용하자.

예상 질문 답변

주석을 쓰지 않아야 되는 코드를 만들어야한다던데요?

=> 맞습니다. 주석을 쓰지 않아도 되는 코드를 작성하는게 최우선이 되어야 합니다. 그런데 과연 그게 현실세계에서 가능할까요? 문제는 크게 두가지가 있습니다. 첫번째는 코드의 복잡도가 높은 경우입니다. react github를 들어가보면 주석이 정말정말 많습니다. 코드를 잘 못짜서 주석이 많은걸까요? 절대 그렇지는 않을겁니다. 두번째는 코드이외의 여러가지 이해관계가 있는 경우입니다. 회사에서 코드를 작성하다보면 코드만 보고는 그 의도를 파악할 수 없는 경우가 있습니다. 이런 경우는 무조건 코드리뷰 때 왜 이렇게 작성하셨나요? 라는 질문이 나오고(나와야하고) 그에 답변을 합니다. 그리고 이건 이후에 유지보수하는 사람이 또다시 의문점을 가지게 됩니다. 이런 경우는 주석을 꼭 포함해야합니다.(법으로 만들어야함)

조금 더 근본적으로 얘기해보면 주석을 쓰지 않아도 되는 코드를 만드는게 첫번째고 동료들에게 도움을 주기 위해 부가적으로 주석을 작성한다고 생각하면 좋습니다. 즉, 주석을 사용하는 이유는 내 부족한 코드를 설명하기 위해서가 아니라 다음 작업자의 시간을 단축하기 위해서입니다.

문서화

ai가 점점 발전하면서 나는 문서화의 중요성이 더 크게 늘어났다고 생각한다. 물론 ai가 문서화도 잘 해준다. 근데 정돈되지 않은 상태에서 context가 커지게 되면 ai가 해결하지 못한다. ai를 활용해서 문서화를 잘 하는게 관건이다.

이 얘기를 왜 했냐면.. 나는 주석은 가장 기본적인 문서라고 생각한다. 그렇기 때문에 시간내서 문서화 하는 것도 좋지만 기본적으로는 주석을 잘 작성해야한다고 생각한다.

출처

[1] https://namu.wiki/w/%EC%A3%BC%EC%84%9D(%EC%96%B8%EC%96%B4)

소셜 네트워크 서비스의 아키텍처에 대하여 분석하기 1편

안양사람 — Sun, 31 Aug 2025 22:23:42 +0900

배경

취업하기 전 인상깊게 읽은 글이 있다. 절반도 이해하지 못했는데 경력이 쌓이면 언젠가 이해할 수 있겠지? 라고 생각했었다. 그리고 4년차 개발자가 된 지금은 어떤지 알고 싶어졌다. 프론트개발만 하고 있기 때문에 그때와 달라진게 있을까? 싶은 생각도 있지만 CS 지식도 쌓인 만큼 조금 달라졌길 기대한다.

본문

위에서부터 한문단씩 읽으면서 생각을 정리해보겠다.(굳이 설명을 덧붙이지 않아도 되는 부분은 생략)

작성자 OR 굴비 알고리즘의 연산 비용을 계산해 보자. 내가 따르는 친구의 수를 m이라 하고 전체 사용자 수를 n이라고 한다면 전체 사용자 검색 연산의 시간 복잡도는 O(m log(n))이 된다. 물론, 각 사용자별로 정렬된 게시물 레코드 식별자 리스트를 찾은 후에도 각 사용자별 레인지 쿼리를 수행하고 결과를 하나로 병합한 후 다시 병합된 리스트에서 레인지 쿼리를 수행해야 하지만, 이는 앞의 비용들에 비하면 충분히 무시할만한 것이므로 넘어가자. 이쯤 되면, 혹자는 O(m log(n)) 연산이 뭐가 그리 무자비한 것이냐며 역정을 낼 수도 있겠다.

log(n)이 어디서 나오는걸까?

일반적인 해시테이블을 사용하게 된다면 사용자 수가 몇 명이든지 상관없이 O(1)로 접근 가능하다.

옛날에 공부했던 자료구조 책을 꺼내서 해시를 찾아보면 아무리 뛰어난 해시 함수를 사용한다고 해도 충돌을 완전히 피하는 것은 불가능하다고 나와있다. 4000만 이상의 사용자 수가 있다면 당연히 해시 함수를 이용해 O(1)로 접근하는 것은 불가능하다.

사실 데이터베이스를 조금만 공부해보면 많은 데이터베이스는 인덱싱을 위해 B-tree, B+tree를 사용하는 것을 알 수 있다.

그리고 B-tree의 높이는 log(n)이기 때문에 검색 시간은 log(n)이 된다.

그렇다면, 일반적인 게시판 페이징 오퍼레이션에 비해서 상대적으로 얼마나 무거운지 비교해 보자. 전체 게시물의 수를 l이라고 한다면 게시판 페이징 비용은 O(log(l))이다. 사용자별 평균 보유 게시물 수를 k라고 한다면, l은 k * n이기 때문에 사용자 검색과 게시판 페이징 연산 비용의 비교는 O(m log(n)) 대 O(log(kn))로 나타낼 수 있다. 사실, 정확하게 Big O 분류 관점에서 m과 k는 상수로 볼 수 있기 때문에 두 복잡도는 같다고 볼 수 있다. 하지만 굳이 시간 비용을 비교해 보자면 m 대 log(k)/log(n)+1, 즉 평균 친구 수 대 log(사용자별 평균 보유 게시물 수)/log(전체 사용자 수) + 1이다. 확실히 전자의 자릿수가 몇 개 더 많다. Facebook의 통계 데이터를 대입해 보면, 전체 사용자가 약 10억명에 평균 친구 수는 342명[4]이고 월간 평균 게시물 수는 36건[5]이며 연간 단위 파티션 상황에서 연간 누적으로 평균 432개의 게시물을 가진다면 대략 342:1.3 정도로 작성자 검색은 게시판 페이징에 대비 대략 260배 정도나 더 무겁다고 추정할 수 있다. 즉, 모든 사용자가 자신의 모아 보기를 보는 매 순간 이런 비용이 발생한다는 것이다.

이건 고등학교 때 배우는 로그계산식만 기억하고 있다면 알 수 있다. 나도 일반 게시판 기반의 서비스는 개발해본적이 있다. 근데 260배의 비용이 더 발생한다면.. 그리고 유저수가 많다면.. 쿼리최적화도 방법이겠지만 결국에 답은 답은 캐시밖에 없는 것 같다. sns 특성상 캐시를 사용해도 긴 시간을 유지할 수는 없다. 물론 여러개의 캐시를 조합해서 사용해야겠지만 많이 어려워보인다. 특히나 4000만 이상의 많은 사용자는 더 그렇다. 페이스북과 트위터를 예시로 들었는데 두 가지 다 굉장히 복잡해보인다.

이런 시간 비용을 줄이는 방안은 무엇일까? 여기서 반사적으로 생각할 수 있는 대안은 바로 캐시를 적용하는 것이다. 소셜 피드에서는 최신 데이터를 가장 빈번하게 요청하기 마련이다. 하지만 DB 수준의 캐시를 적용하면 다양한 서비스 쿼리 때문에 원하지 않는 데이터 블록이 자동으로 캐싱될 수 있으므로 프로그래밍으로 조절할 수 있는 캐시가 필요하다. LAMP 스택에서 가장 흔하게 쓸 수 있는 memcached를 최신 피드에 대한 look-ahead 캐시로 사용한다면 DB로 가는 트래픽을 크게 줄이고 빠르게 반응할 수 있다. 물론 이런 속도를 공짜로 얻을 수 있는 것은 아니다. 결국, 비즈니스 로직상에서 일관성을 유지하기 위한 상당한 코딩이 필요하기 때문이다.

오 맞췄다. 맞췄다기보다는 너무 당연한 얘기다.

look-ahead 캐시는 미래에 필요할 것으로 예상되는 데이터를 미리 가져와서 캐시에 저장하는 기법이다.

일단 더 읽어보자

이제 시간 복잡도는 어느 정도 줄였다. 하지만 겨우 이 정도로 무자비한 연산이라고는 할 수 없다. 엄청난 데이터양을 생각해 보자. Facebook에는 하루에 10억 개의 상태 메시지가 올라온다.[6] Facebook의 일간 데이터 저장량을 추정해 보면, 상태 메시지에서 이미지 등의 부가 데이터를 제외한 순수 텍스트만 평균적으로 300바이트 정도를 쓴다고 가정했을 때, 상태 데이터 텍스트만 하루에 약 280GB가 쌓인다. 너무나 당연하게도 이 정도 데이터양을 지탱하기 위해서는 여러 서버를 사용할 수밖에 없다. Facebook은 4,000대 이상의 MySQL 샤드와 9,000대 이상의 memcached 샤드를 구성해 사용하고 있다.[7] 이 정도 규모의 샤드라면 데이터를 찾아 사용하기 위한 또 다른 다계층 중간 서버들이 필요하고, 이러한 복잡한 구성 때문에 프로그램 로직은 구성에 묶일 수 밖에 없다. 이러한 엄청난 규모의 샤드상에서 개발하는 그들은 '죽음보다 더 끔찍한 운명(fate worse than death)'이라고 자조하곤 한다.

샤드(sharding): 데이터베이스의 수평적 확장

글로만 봐도 끔찍하다는 생각이 든다. 데이터베이스의 확장은 굉장히 어렵다고 들었는데 저정도의 확장이라면.. 끔찍하다.

혹자는 이런 공간 복잡도는 SNS의 특성만으로 기인한 것은 아니라고 할 수도 있다. 하지만 진짜 문제는 거대한 클러스터를 구성하고 나서야 비로소 보이게 된다. 내 친구들의 데이터가 같은 샤드 내에서 옹기종기 모여 살 수 있었다면 행복했을 것이다. 하지만 샤드 내 데이터가 커진다면 결국 각 친구의 데이터가 곳곳에 흩어져 살 수밖에 없고, 또 새로 사귄 친구의 데이터는 샤드 #3989에 거주하고 있다. 이제, 작성자 OR 굴비 알고리즘은 어떻게 돌릴 수 있을까?

와 내가 윗 문단을 읽고 고민했던 부분이다. 예전에 이 글을 읽어서 그럴수도있는데 이미 알고 있었다. 성장했다?!

가장 먼저 해결할 문제는 사용자의 데이터가 어디에 살고 있는지 주소를 찾을 방법이 있어야 한다는 것이다. 어떤 서버에 데이터가 있는지 하나하나 관리할 수도 있고, 해시 함수를 사용해 해시 결과가 해당 서버로 바로 안내할 수도 있다. 전자는 주소의 유연성이 있지만 그 유연성을 지탱할 거대한 저장소가 필요하고, 후자는 단순하고 저장소가 필요 없지만 유연성이 떨어진다. 이러한 문제를 해결하기 위해 분산 환경에서는 둘의 장점을 혼합해 제공하는 consistent hashing[8] 기반의 구조를 자주 사용한다. 쉽게 설명하자면, 각 데이터의 저장소 주소를 저장하기보다 한정된 전체 주소를 여러 범위로 나누어 각 저장소에 대응시켜 사용하는 방식이다.

이제부터 좀 모르는게 많이 나오기 시작했다.. 구글링 + calude와 함께 했다.

나는 이 문단을 읽고 한 가지 생각이 떠올랐다. id가 하나씩 더해지는 구조라고 가정한다면(물론 id를 uuid가 아니라 이런식으로 만드는건 문제가 있을 수 있다.) 1~10,000까지는 1서버, 10,001~20,000 까지는 2 서버 이런식으로 저장하면 안되나? 라는 생각이 들었다. claude에게 물어보니 이건 Range-based Partitioning이라고 하고 실제로도 많이 사용된다고 한다. 장점도 있지만 아래의 단점이 꽤 치명적으로 느껴졌다.

Range-based Partitioning

단점 목록

핫스팟 문제: 10년전에 페이스북에 가입한 사람들과 1일전에 페이스북에 가입한 사람 중 누가 더 활발하게 활동할까? 높은 확률로 후자일것이다.

데이터 스큐: 가입일과 상관없이 특정 서버에 유저가 몰릴 수 있다.

확장 시 재배치: 확장할 때 데이터의 재배치가 어렵다.

탈퇴 문제(내가 생각함):

데이터 스파스 문제: 오래된 서버는 대부분 탈퇴하고 최근 서버는 대부분 남아있다.

서버 불균형 심화: 위 이유로 서버마다 부하 문제도 있고 유령 서버도 존재한다.

리소스 낭비: 데이터가 낭비되고 있으면 그만큼 리소스도 낭비된다.

다시 생각해보니 게임에서는 Range-based Partitioning을 많이 사용하는 것 같다. 그리고 위에서 단점들을 얘기했지만 모든 아키텍쳐가 그렇듯 하나만 가지고 모든걸 해결할 수는 없다. 여러가지를 조합해서 사용해야한다.

백엔드 기본 지식을 어느정도는 따라가려고 했는데 이런 아키텍쳐 레벨까지 들어가니까 알아야 될게 너무 많은 것 같다. 그냥 이정도 수준의 글을 읽고 인사이트를 얻는 정도로 멈춰야 될 것 같다. 잠깐 이유가 있어서 대규모 데이터 처리에 대해서 관심을 가진적이 있었는데 음.. 뭐 사실 사이드프로젝트 수준이라면 적당한 캐시정도만 사용해도(아니 캐시 사용할일도 솔직히 없지) 다 커버 가능하다. 그리고 요즘은 서버 성능도 좋아져서 서버 확장도 거의 필요하지 않은 것 같다.(db도 마찬가지겠지)(오해가 있을것같은데 mau 많이 나오는 그런 서비스를 얘기하는게 아니다..) 만약 너무 프로젝트가 잘된다면 그 때는 다른 사람에게 넘겨줘야겠지.

consistent hashing

위의 이유로 Range-based Partitioning은 어렵다는 걸 알았다. 이제는 consistent hashing에 대해 알아보자.(나는 처음보는 개념)(개념이 어려운건아닌데 꽤 복잡해서 글을 따로 분리해서 쓸까 하다가 일단은 가볍게 적는다.)

consistent hasing은 우리나라 말로 안정 해시라고 부른다.

서버에 그냥 해시를 사용한다고 가정해보자. 그리고 유저수가 많아져서 서버를 추가한다고 해보자. 그러면 심각한 문제가 생긴다.

기존 서버가 3대가 있어서 해시키에 %3 로직을 통해 서버를 할당하고 있다고 가정해보자. 그런데 서버가 추가된다면 %4를 하게 되고 이때 많은 서버가 이동하게 된다. 즉 일반적인 해시를 사용하면 서버의 추가 제거에 대해 유연하게 대응하지 못한다.

해시 링(hash ring)

이때 해시 링(hash ring)이라는 개념이 등장한다.

링(원)을 그려보자. 그리고 서버들이 링 위에 있다고 가정해보자. 그리고 링 위에는 n개의 공간이 있다.(점이라고 생각하면 쉽다.)

예시와 함께 살펴보자. 공간이 10개가 있고 A(1에 위치),B(6에 위치) 서버가 존재한다고 가정해보자.

이 때 임의의 공간에 접근했을 때 시계방향에서 가장 가까운 서버로 접근하게 된다.

0,1,7,8,9에 접근한다면 A

2,3,4,5,6에 접근한다면 B

이때 C(4에 위치) 서버가 추가된다고 가정해보자. 그러면 2,3,4는 C에 배치될 것이고 나머지는 기존과 동일하다.

그리고 B 서버가 삭제된다고 가정해보자. 그러면 5,6이 A 서버로 배치될 것이다.

위와 같이 비교적 쉽게 추가 제거가 가능해진다.

> 부가 설명

해시 함수로 SHA 256 알고리즘을 사용하면 해시 공간은 2^256만큼의 공간을 사용할 수 있게 된다. 즉 9000대가 아니라 그보다 훨씬 큰 규모의 샤딩도 가능해진다.(물론 페이스북 정도의 규모라고 할지라도 이만큼의 공간은 필요없다.)

서버의 배치도 알고리즘을 통해 적절한 곳에 위치시켜야한다.(균등분포해시함수)

Virtual Nodes(가상 노드)

사실 위의 예시에서도 문제가 하나 발생했다. C 서버가 추가되었을 때 A에서 다른 서버의 약 2배만큼의 부하가 걸리고 있다. 그리고 이는 서버가 적을 때 더 문제가 크게 발생한다.

각 서버를 여러개의 가상 노드로 나누면 이 문제를 해결할 수 있다. 결국 서버가 적어서 편차가 커지는게 문제였는데 가상 노드로 이 편차를 해결한 것이다.

근데 당연히 트레이드오프가 있다. 서버가 추가 제거 되었을 때 가상노드들에 대한 처리가 필요하고 메모리도 더 많이 필요하다.

물론, 그 주소 범위와 저장소의 대응 테이블은 HBase와 같이 master-slave 모델, 또는 Cassandra와 같이 peer-to-peer 모델로 공유할 수도 있다.

master-slave: master 서버에서 모든 정보를 관리해서 특정 데이터가 어떤 (slave)서버에 있는지 알려주는 방식

관리하기가 쉽다. 단, master 서버가 죽으면 큰일난다.

peer-to-peer: 모든 서버가 동등하게 정보를 공유하는 방식.

장애 대응에 유리하다. 단, 서버들간에 데이터 동기화가 복잡하다.

후기

페이스북, 트위터를 간단하게라도 풀스택으로 개발해보고 싶어졌다.(현실적으로 힘들다면 아키텍쳐 레벨정도만이라도) 이런건 글로만 읽어서 배워지지 않는다. 진짜 얕은 경험이라도 해봐야 더 잘 느낄 수 있다고 생각한다. 로컬에서 개발하는거에는 캐시같은게 사실 필요없지만 부하 테스트를 진행하면서 하면 꽤 유의미하겠다 라는 생각이 들었다. 올해는 계획한게 있어서 힘들고 내년 목표로 잡아야겠다.

md형태가 아니다보니 가독성좋게 글 쓰는게 좀 어렵다.. 티스토리에서 md를 애매하게 지원하기는 하는데 진짜 좀 애매하게 지원해서..

블로그 이사를 해야하나 작은 고민이 생긴다.

원본링크

https://d2.naver.com/helloworld/551588

참고링크

https://jiwondev.tistory.com/299

깊이 파고 들기

안양사람 — Sun, 27 Jul 2025 00:56:38 +0900

날것의 생각을 그대로 올립니다.

깨달았다. 나는 깊이 파고 들지 않는다. 우테캠 세번째 프로젝트를 하면서 깨달았는데 지금도 변한게 없다. 여러가지 변명을 대고 싶지만 그건 좋은 방법이 아니라는 것을 알고 있다. 지금까지는 그랬다는 것을 인정하고 앞으로는 변해야한다.

변하기 위한 액션 아이템은 두가지정도 잡았다.

첫번째는 내가 잘 모른다고 생각하는 것들을 깊게 생각해보고 코드로 작성하기. 이건 https://github.com/yoonminsang/web-playground 에 올릴 예정이다. 그 동안 매번 바뀌어왔던 코드 가치관, 그리고 변화 등도 같이 업데이트시켜서 나만의 데이터베이스를 만들려고한다.(코드로 작성하지 않고 그냥 학습한 내용들은 https://github.com/yoonminsang/TIL 에 올리고 있다.)

두번째는 CS다. 운영체제는 이미 책으로 학습, 강의, llm과 질문 답변 등으로 진행을 하고 있었는데 다른 과목들도 필요할 것 같다.

나는 취업전에 네트워크 책을 몇번씩이나 읽었는데 지금도 누군가 깊게 물어본다면 두렵다. 실무에서 쓰이는 정도만 가볍게 아는 느낌이다.

글로 적다보니 약간은 비관적으로 보이는데 그렇지는 않다.

취업전에 운영체제 공부할 때는 진짜 외우는 느낌이였는데, 이번에 공부해보면서 책에 나오지 않은 내용들도 더 깊게 파고들고 흥미도 생겼다. 다른 전공 과목이나 다른 분야도 마찬가지라고 생각한다.

비판적 사고와 긍정적 사고.

경각심을 가지고 긍정적으로 나아가야겠다.