윤민상 블로그

smart brevity 독서모임 후기

안양사람 — Thu, 9 Apr 2026 23:31:30 +0900

오늘의 실천

나의 취미

“나의 취미”를 한 줄로 적어 보세요. 가능하면 10단어가 넘지 않도록.

나는 특별히 취미가 없는 사람이다. 그래서 그나마 요리와 운동을 떠올렸다. 요리는 삼겹살, 스테이크, 파스타, 제육, 계란찜이 생각났고 운동은 헬스, 수영, pt가 생각났다.

한 명씩 발표를 하는데 나만 너무 별 생각없이 단어를 적은 것 같았다. 그래서 다른 사람의 발표를 들으면서 적당히 포장했다.(이것도 발표할 때 얘기했다.)

요리하면 크게 세가지가 생각난다. 시간 소모, 돈 절약, 행복.

요리는 참 시간이 많이 드는 일이다. 게다가 나는 작은 집에서 자취를 하기 때문에 안좋은 인덕션 한 구 밖에 없다. 3개는 욕심이고 2개만 있으면 좋을텐데.. 그래서 나는 주로 불부터 키고 재료를 손질한다. 아마 냉장고를 부탁해를 나가도 15분만에 완성할거다. 물론 퀄리티는 그들보다는 떨어지겠지만.. 물론 가끔은 시간이 많이 드는 요리도 한다. 수비드 머신도 사용해봤고 천천히 양파를 카라멜라이징해 카레도 만들어봤다.

내가 요리를 시작한 계기 중 하나는 돈 절약이다. 가난한 자취생이였던 나는(지금도 크게 다르지는 않다.) 햇반살돈이 아까워 항상 밥을 해먹고, 라면살돈이 없어서 소면으로 비빔국수를 해먹었다. 도시락 싸는 것도 일상이였고 이 습관은 이전 회사를 다니면서도 이 습관은 이어졌다. 다만, 지금은 회사에서 식대 지원이 되어서 요리를 하는 빈도가 많이 줄었다.

앞에서 약간 부정적인 이야기를 했지만 나는 요리할 때 행복하다. 장보러가는 것도 좋아한다. 백화점, 시장, 국내, 해외를 가리지 않는다. 시간도 소모되고 돈을 절약하기 위해 반강제로 요리를 해왔지만 나는 요리할 때 행복하고 이건 내 취미라고 할만하다.

다른 멤버의 취미

한 멤버는 게임이 취미라고 했다. 게임에서 밸런스 패치를 하는데 이건 AI 모델을 변경하는 것과 비슷하다고 했다. A 캐릭터가 좋을때는 A캐릭터를 사용하고, B 캐릭터가 좋을때는 B캐릭터를 사용하고, 마치 claude, chatgpt를 번갈아가며 쓰는 것과 동일하다고 했다.

모임장님의 얘기(글 잘쓰는 방법)

자기 글을 잘 썻나 판단하고 싶다면 3번 작게 소리내어 읽어라. 읽기 힘들때가 있다. 내 귀는 안다. 그러면 무조건 고쳐라.

공백이 두려다면 명사를 먼저 생각해라. 글이 잘 써진다.

한 개의 명사로 3개의 문장을 만들어봐라.

=> 요리해먹으면 돈이 절약된다. 그런데 요리는 시간이 많이 든다. 그래도 요리가 맛있으면 행복하다.

이 문장을 보고 다시 명사를 만들기를 반복하면 글이 쉽게 만들어진다.
AI도 명사를 주면 잘 해준다. 돈(토큰)도 절약된다.
(책: 바바라빈토 논리의 기술 - 성경같은책 재미는 없어. 근데 바이블이야. 한국 대부분책은 그 책에 영향을 받았어.)

아이스브레이킹

새로운 멤버가 있어서 아이스브레이킹을 했다. 오늘의 아이스브레이킹 주제는 오늘의 색깔이다.
내 오늘의 색깔은 빨강이다. 점심은 짬뽕에 저녁은 이치란(봉지라면)을 먹었다. 그래서 빨간색이 생각났다.

책 이야기

공유하고 싶은 한줄
- 간결은 자신감이다. 장황은 두려움이다.(공유까지는 하지 않고 나 혼자만 생각했다.)
- 활기차고 분명하며 솔직담백하게 소통하는 사람이 승자가 될 것이다.
  - 자세한 내용은 독후감 참고
이 책과 생각이 다르다.
- 피드백을 할때는 "당신은 정말 훌륭하지만 더 노력해줫으면 해요" 보다는 "핵심 과제에 더 많은 노력을 기울이세요."라고 말하는게 낫다.
  - 자세한 내용은 독후감 참고
변화가 있었나요?
- 이력서 원래도 간결했지만 몇 단어 더 제거함.
더 깊이 알고 싶다고 생각한 주제
- 스마트브레비티를 써야하는 곳과 쓰지 말아야하는곳? 오늘 스마트브레비티 기반으로 한번 작성해볼까 했는데 그냥 작성하는게 더 좋았다.(크게 공유할만한 내용은 아니라서 공유는 안했다.)

이런 저런 이야기1(모임장님의 얘기)

거절할 때는 만나서 얘기해라. 거절하는 순간 나는 그 사람에게 나쁜놈이다.

우리나라 사람들은 문법에 안맞는 이상한 말을 많이 쓴다. ex) 호감도가 올라간다 X => 호감이 올라간다

코드리뷰 할 때 nit라는 말을 자주 사용한다. 이건 아주 사소하다는 건데 유래는 다음과 같다. 벼룩의 이만큼 사소한

주도권은 뺏기는게 아니라 내어 주는것이다.
(주도권을 잃는 원인은 타인의 action이 아닌 나의 inaction(무대응)이다.)
(llm에게 생각의 과정을 내어주고 있는게 아닌지 고민해봐라)

내 이야기

공포스러웠었던 혹은 어려웠던 경험

팀장님한테 dm왔을 때.

"너무 길다, 줄여라, bullet 형식으로 써라"라는 애기를 들었다. 근데 나는 이야기형식으로 글을 쓰고 싶었다. 실제로 그렇게 쓰는데 잘 쓰는사람들도 있었고 나는 그런 사람이 되고 싶었다. 그 피드백은 맞는 피드백이였고 그때도 지금도 동의한다. 이제는 꽤 많이 성장해서, bullet형태의 글은 잘 쓴다. 하지만 나는 솔직함이 장점인 사람이라 결국 이야기형식으로 풀어쓰는 커뮤니케이션 역량도 길러야한다.

이력서 쓸 때.

나는 몇년동안 꾸준히 이력서를 다듬었다. 꼭 이직을 위해서는 아니다. 이력서의 변화만 봐도 내 written communication이 얼마나 향상되었는지 보인다. 내 고뇌와 노력의 흔적이 남아있다.

나(개발자)에게 글을 잘 쓴 다는건 어떤 의미일까요?

상황에 맞는 글을 쓰는 사람. 다시 되묻는 경우가 적은 사람.

나도 이런 사람이 되기 위해 지금도 노력하고 있다.

최근에 좋은글, 혹은 글을 잘 쓰는 사람과 만난 경혐과 그때 느낀점

전회사 사람 중에 그런 사람이 있었다. 항상 글을 쓰면 복잡한 내용도 짧게 정리되어서 나왔고 글을 읽는데도 오랜 시간이 걸리지 않았다. 그런데 가끔은 더 자세한 경험이 궁금하기도 했다.
스마트 브레비티로 정돈된 글을 쓰지만, 가끔은 조금 길지만 흥미로운 스토리를 들려줘서 사람들이 그 사람의 글을 끝까지 읽게되는 그런 사람이 되고 싶다.

이 클럽이 끝나면 나는 어떤 글을 잘 쓰는 사람이 되고 싶으신가요?

명확한 커뮤니케이션을 하는 사람.

사실 이전에도 그렇게 되기 위해서 노력해왔다. 지금도 마찬가지긴한데 지금은 커뮤니케이션이 예전보다는 좀 올라왔다고 생각해서 아주 많은 시간을 들이지는 않고 있다.

이런 저런 이야기2(모임장님의 얘기 + 우리들의 대화)

면접들어가기전에 이력서 보는 시간

어쩌다보니 이력서, 면접, 이직 이런 주제의 이야기들이 나왔다. 아무래도 커리어에 관심있는 사람들이 모이다보니 자연스럽게 이런 주제의 이야기가 나왔다. 모임장님은 면접가기 전에 자신이 이력서를 몇 분이나 볼 것 같냐고 물었다. 사람들의 답변은 다양했다. 나는 1분이라고 답했다. 모임장님의 답변은 다음과 같았다.

면접가기전에 2시간은 본다. github 보고 들어간다. 포폴 링크도 클린한다. 면접들어가기 직전에 이력서 훑어보는 사람이 있는 회사는 가지마라. 1년에 한번 글 올라오는거 왜 올려놓냐. 면접관도 뽑고 싶어 한다.

처음에는 조금 놀랐다. 그리고 다시 생각해보니 이해가 되었다. 모임장님이 있는 회사의 면접을 본 적이 있었다. 그때 자바스크립트 프로토타입 관련한 질문을 했었는데 내 블로그 글을 언급했다. 나는 그냥 면접보면서 블로그를 찾아봤나? 라는 생각을 했다. 근데 그럴리가 없다.. 아니 대다수는 그러지 않을 것 이다. 나도 면접관으로 들어갔을 때 블로그 글 하나하나 클릭해서 들어갔었다. 그리고 궁금증이 생기기도 실망하기도 했었다. 연차가 높아지면 이런 곳에 시간을 쓰지 않을거라고 생각했다. 실제로 그런 케이스를 보기도 했고.. 하지만 그건 좋지 않은 케이스고 좋은 회사에 책임감있는 좋은 사람들은 그렇지 않을 것이다.

ux

모임장님이 ui ux 얘기는 많이 하는데 그게 뭔지 아냐고 물어봤다. 당연히 사전적 정의를 물어본건 아니다. 마치 수학이 뭐에요? 적분이 뭔데요? 이런 느낌의 질문이랄까?

불쾌감이 ux다.

누구나봐도 알 수 있나? ui다.
썼는데 경험이 어떻냐. 좋얐냐 나쁘냐. ux다.

내 취향을 증명할 수 있어야한다.

불쾌감에 대한 얘기는 정말 공감이 많이 되었다. 진짜 불쾌감을 느끼는 경우가 많다. 꽤 큰 IT 회사의 제품을 쓸때도 마찬가지다. 불쾌감을 느끼지 않는다면 좋은 제품이다. 그리고 좋은 기분을 느낀다면 그건 정말 좋은 제품이다.

면접

누군가가 공고와 자신의 경험이 달라서 약간은 포장된 경험으로 면접을 봐야할지 고민하고 있다는 얘기를 꺼냈다. 나는 이게 (거의) 불가능하다고 생각하는 사람이다. 특히 컬쳐면접같은 경우는 꽤 극한까지 밀어붙이는 경우가 있다. 이럴 때 진실하지 않은 포장된 모습을 끝까지 유지할 수 있을까? 나는 아니라고 생각한다. 그리고 내 단점을 얘기하면 얘기했지 한번도 꾸며낸적은 없다. 그 결과 컬쳐면접에서 떨어진 적은 한번도 없다. 모임장님도 거짓말하는 사람은 바로 티가 난다고 했고, 한 멤버는 면접은 거짓말을 벗겨내는 자리라고 했다. 어느정도는 나도 동의한다. 당연히 뽑고 싶어서 면접을 보는거지만 거짓말을 하는지도 검증하고 싶을 것 같다. 그 증거 중 하나가 레퍼런스 체크다. 이런 귀찮은 일을 지금도 진행하고 있다는건.. 이걸 어느정도 뒷받침한다.

높은 사람과 대화할 때

대표는 아래 팀원들이 무슨 일을 하는지 궁금할까? 상위에 그저 그렇게 보고하는게 아니라, 진짜 그 사람이 무슨 고민을 하고 있고 무슨 문제가 있고 무슨 제품을 개발하고 있는지.
나는 그렇지 않다고 생각했다. 하지만 대표도 궁금하다고 했다.

이정도면 되겠다. 넉놓고 적당히 하는.. 이러면 안된다. 놓아버리지만 않는다면 좋은 보고를 할 수 있다. 놓으면 평범한 보고가 된다. 끊임없이 고민해라. ai한테 대충 써달라고 하면 안된다.

대표는 돈값하는지가 제일 궁금하다.

소모임

글을 잘 쓰기 위한 체크리스트를 만들었다. 이번에도 시간이 모잘라서 확실하게 정하지는 못했다. 크게 두개의 카테고리와 몇개의 체크리스트를 얼추 만들었다.

명료함 (모호하지 않아야 한다)
- 누가 읽어도 동일하게 이해할 수 있는 단어인가?
- 불필요한 중복을 제거했는가?
- 대상의 관심을 끌 수 있는가?
  - 눈길을 끌게한다.(흥미유발, 도발, 리드)
- 읽는 사람이 해야할 행동(cta)이 명확한가?
- 문장을 짧게 썼는가?
- 용어 정의가 되었는가?(사람마다 생각하는게 다르다. 단어는 다른데 의미는 똑같은 경우 고려.)
목적 (맥락에 맞아야 한다)
- 글의 목적이 분명한가?
- 대상을 확인했는가
- 상황을 확인했는가?(시의적절, 적재적소)
- 왜 쓰는지가 설명되었는가?

모임장님의 취향 공유

여행 블로그 글인데 왼쪽과 오른쪽 단이 나눠져있다. 왼쪽은 글이고 오른쪽은 지도다. 그런데 스크롤을 내릴때마다 지도가 줌인아웃된다. 카메라를 2개 써야한다. 이런게 취향이다.

마지막으로 모임장님의 하고 싶은 말

취향이 중요하다.
지금 (ai가) 내 일 못한다고 방심하지마라.

오늘의 멤버

이번주애도 오늘의 멤버 공동 1등에 뽑혔다. 가위바위보를 또 이겨서 모임장님에게 선물을 받았다. 다음에는 공동1등이 아니라 그냥 1등이 되게 더 힘내봐야겠다! 끝!

smart brevity 독후감

안양사람 — Sat, 4 Apr 2026 09:18:44 +0900

간결은 자신감이다. 장황은 두려움이다.

이 책에서 가장 인상깊은 문장이다. 나도 간결하게 쓰고 싶다. 근데 두렵다. 그래서 부연설명을 붙이고 괄호를 넣는다. 몇 년동안 연습해왔지만 아직도 부족하다. 꾸준히 연습해야할 부분이다.

나는 스토리 있는 긴 글을 좋아한다. 진짜 글 잘 쓰는 사람은 글이 길어도 스토리에 빠져들게 하는 힘이 있다고 생각한다. 그리고 그건 지금도 유효하다고 생각한다. 하지만 모든 글을 그렇게 작성해서는 안된다. 특히 정보를 전달하는 글에서는 더더욱. 둘 다 잘해야한다.

이전에도 누군가에게 불릿 형태로 글을 작성해보라고 피드백을 받은적이 있었다. 그때도 알았지만 이 책의 예시를 보면서 확실히 줄글보다 잘 읽힌다는 걸 인정할 수밖에 없었다. 그리고 그 불릿을 잘 쓰는 것 자체가 또 다른 스킬이라는 것도.

"독자가 먼저다 audience first."

너무 당연한데 잘 안지켜질 때가 많다. 글 뿐만이 아니라 이 세상의 모든 결정들에 대입할 수 있다. 특히 내가 몸담은 IT 제품에서는 더 선명하게 보인다. IT 제품이 메인인 회사라면 사용자가 메인이 되어야하는데 그렇지 못한 경우들이 많다. 근데 이게 말처럼 쉽지가 않은게 역량이나 기본기뿐만 아니라 여러 이해 관계자들이 섞여 있어서 그렇다. 조직이 커질수록 이해 관계자들은 많아지고 옳다고 생각하는 방향으로 나아가기보다는 내 상사가 원하는 방향으로 개발하게 되는 경우도 많다.

나는 기본기를 중요시 생각하는데 위 두 문장은 대표적인 기본기 중 하나같다. 내가 정의하는 기본기는 누구나 알고 있지만 잘 챙기기 힘들고, 그 기본기가 탄탄할 때 주위사람들도 몸으로 느끼는 그런걸 얘기한다. 축구로 치면 퍼스트터치, 개발로 치면 함수 나누기 같은 느낌이다.

피드백을 할때는 "당신은 정말 훌륭하지만 더 노력해줫으면 해요" 보다는 "핵심 과제에 더 많은 노력을 기울이세요."라고 말하는게 낫다.

저자의 생각에 동의하지 않는 부분이다. 당연히 조직, 팀, 사람마다 성격이 다르다. 확실한 커뮤니케이션을 선호하는 사람도 있지만 사람은 기계가 아니다. 그 사람의 가치관과 배경, 감정에 공감하는 것도 중요하다. 물론 쿠션어를 너무 많이 써서 핵심이 전달되지 않으면 안된다. 이것도 스킬이다. 만약 내가 악시오스 회사에 다닌다면 확실한 피드백을 주고받을 수 있다. 나는 그런 사람이니까. 하지만 이 책에서 독자가 먼저라고 했듯이 상대방이 받아들이는 것도 생각해야한다.

지우고, 지우고, 지워라. 보내기 전에 어떤 단어, 문장 단락을 지울 수 있는가? 적은 게 더 많은 법이다. 이건 상대방을 위한 일이기도 하다. 우리가 줄인 모든 단어, 문장은 상대방의 시간을 아껴준다.

이력서에서도 이게 정말 중요하다. 현재 회사에서는 그나마 글을 읽어라도 주지만, 이력서가 엉망이면 몇 초만에 불합격된다. 그 기회는 쉽게 오지 않는다. 나는 이력서, 포트폴리오를 줄이기 위해 정말 많은 노력을 해왔다. 그리고 이 책을 보고 난 뒤, 다시 이력서를 봤는데 몇 단어를 줄일 수 있었다. 거의 차이가 없는걸 보고서 커뮤니케이션 스킬이 이전보다 많이 올라왔다는걸 크게 느꼈다.

왜 중요한가

내가 꽤 많이 빠트리고 있었던 부분이다. 왜 중요한지를 적었는데 너무 당연한 얘기라 뺏으면 좋겠다는 피드백을 받은적이 있다. 그 피드백이 틀렸고 이 책이 옳은걸까? 글쎄 그건 단순히 그것만 가지고 판단할 수 없다. 스마트 브레비티 저자처럼 간결하게 글을 적었다면 그런 피드백을 받았을까? 그와 동시에 꽤나 복잡한 기술 문서를 스마트 브레비티로 작성할 수 있을까?
100점짜리 정답은 아무도 모른다. 아니, 그런건 세상에 없다. 다만, 점수를 높이기 위한 방법은 있다. 이 책도 그 방법 중 하나다. written 커뮤니케이션을 이 책 하나만으로 마스터할 수 는 없다. 중요한건 "왜 중요한가를 지금보다 조금 더 잘 어필하는 것", 그리고 "간결하게 글을 작성하는 것"이다.

활기차고 분명하며 솔직담백하게 소통하는 사람이 승자가 될 것이다.

과연 솔직담백하게 소통하는 사람이 승자가 될 수 있을까? 너무 이상주의적인 생각아닐까? 솔직무례와 솔직담백은 한끝차이다. 동일한 커뮤니케이션을 해도 A조직에서는 솔직무례, B조직에서는 솔직담백이라고 평가한다.
주변에서도 솔직함으로 인해 손해를 입는 경우를 종종 본다. 역사적으로도 그렇다. 맥락은 이해하지만 글을 쭉 읽어오면서 현실과 다른 부분을 조금씩 느꼈다.
말은 그렇게 했지만 나 역시 위 문장에 동의한다. 다만 이건 마음의 이상주의이고 현실의 이성주의와는 조금 차이가 있다고 생각할뿐이다.
생각해보면 스마트 브레비티는 상대의 인지 부하를 줄여주겠다는 이성적 배려다. 더 나아가면 피드백도 비슷하다. 피드백을 한다는것자체가 많은 시간을 쓰는 일이고, 쓴소리를 하는것도 불편한 일이다. 피드백은 공격이 아니라 상대를 한걸음 성장시키기 위한 선물이다. 회사에서의 스마트 브레비티 역시 고마운 선물이다.
하지만, 상황에 따라 옷을 다르게 입여야하듯이 모든 상황에서 스마트 브레비티할 수 는 없다. 그리고 그 상황은 개개인이 잘 판단해야한다. 결국 이것도 커뮤니케이션 역량이다.

스마트 브레비티를 적용하면 '보통 사람'처럼 쓰게 된다. 친구와 문자를 주고받을 때는 스타카토처럼 끊어 보내도 즉각 뜻을 이해하지만, 직장에서는 혼란스러운 글을 쓴다는 데 충격을 받았다.

이 문장을 보고 약간 충격받았다. 가끔 회사에서 ROQ(reason of question)라는 말을 쓰고, "그래서 요점이 뭔가요?", "하고싶은 말이 뭔가요?"라는 말을 하게(듣게)된다. 어쩌면 우리 모두는 이런 커뮤니케이션의 필요성을 느끼고 있었을지도 모른다. 쉽게 상처를 받는 감성적인 사람이라고 하더라도..
그리고 이런 감성적인 사람도 ROQ를 물어본다. 즉, 감성적인 사람이라도 회사에서는 "착한데 무슨 말인지 모르겠는 동료"보다 "조금 딱딱해도 업무를 명확하게 하는 동료"를 선호할지도 모른다. 스마트 브레비티는 감정을 없애는게 아니라, 태도가 아닌 도구로 쓰는 것이다.

심리학자가 알려주는 모든 기획자와 프리젠터가 알아야할 사람에 대한 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)