⟪위대한 디자인, 주인의식이 사라지고 주인이 바뀌는 시대⟫

최근 가장 인상 깊게 읽은 UX TRENDS의 글을 의역했습니다. 제 평소 생각을 담아 번역한 것이라 원문을 함께 읽어보시면 좋겠습니다. 위기의식이 여느 때보다 높은 UX 업계에서 어찌어찌 꾸역꾸역 일하는 분들께 작은 공감과 위로가 되길 바랍니다. 원문 제목이 &#39;A Love Letter About Change&#39;였습니다.

2010년대 후반에 정점을 찍었던 UX 열풍이 이제 사그라들고 있습니다. 디자이너들의 영향력은 약화되고, UX는 비즈니스 목표의 원동력이 아닌 부산물이 되어가고 있습니다. 이제 디자인 영향력(통제권)은 디자이너에서 알고리즘, 자동화 도구, 비즈니스 이해관계자로 이동하고 있습니다.

1️⃣ 문제의식이 사라진 디자인 데이터 제공: Figma 등 여러 도구에 디자인 산출물을 올리면서 AI 훈련에 암묵적으로 동의하고 있습니다. 이로 인해 디자인할 자격, 소요 시간, 금전적 가치에 대한 인식은 생각보다 더 빠르게 바뀔 것입니다. 그 영향을 받는 것도 디자이너가 될 테죠.

2️⃣ 비즈니스 중심 디자인: 사용성보다 클릭률을 높이기 위해 사용자 여정을 바꾸고 기만적 패턴을 계속 더하고 있습니다. 빼는 대신 늘리는 디자인에선 의미보다 성장 지표가 우선시 됩니다.

3️⃣ 알고리즘 중심 접근: 깊이 있는 UX 리서치 대신 자동화된 A/B 테스트를 활용하고, 데이터가 의사결정을 주도하게 됩니다. 알고리즘은 모든 고민의 면죄부가 되고 있습니다.

4

The State of UX in 2025 | Walcoln SJ Rhee

최근 가장 인상 깊게 읽은 UX TRENDS의 글을 의역했습니다. 제 평소 생각을 담아 번역한 것이라 원문을 함께 읽어보시면 좋겠습니다. 위기의식이 여느 때보다 높은 UX 업계에서 어찌어찌 꾸역꾸역 일하는 분들께 작은 공감과 위로가 되길 바랍니다. 원문 제목이 'A Love Letter About Change'였습니다.

2010년대 후반에 정점을 찍었던 UX 열풍이 이제 사그라들고 있습니다. 디자이너들의 영향력은 약화되고, UX는 비즈니스 목표의 원동력이 아닌 부산물이 되어가고 있습니다. 이제 디자인 영향력(통제권)은 디자이너에서 알고리즘, 자동화 도구, 비즈니스 이해관계자로 이동하고 있습니다.

1️⃣ 문제의식이 사라진 디자인 데이터 제공: Figma 등 여러 도구에 디자인 산출물을 올리면서 AI 훈련에 암묵적으로 동의하고 있습니다. 이로 인해 디자인할 자격, 소요 시간, 금전적 가치에 대한 인식은 생각보다 더 빠르게 바뀔 것입니다. 그 영향을 받는 것도 디자이너가 될 테죠.

2️⃣ 비즈니스 중심 디자인: 사용성보다 클릭률을 높이기 위해 사용자 여정을 바꾸고 기만적 패턴을 계속 더하고 있습니다. 빼는 대신 늘리는 디자인에선 의미보다 성장 지표가 우선시 됩니다.

3️⃣ 알고리즘 중심 접근: 깊이 있는 UX 리서치 대신 자동화된 A/B 테스트를 활용하고, 데이터가 의사결정을 주도하게 됩니다. 알고리즘은 모든 고민의 면죄부가 되고 있습니다.

4️⃣ 미완성 제품 출시: '완벽보다 빠른 실행'이나 '빠르게 실패하기', 'Lean UX' 같은 개념을 핑계로 준비되지 않은 제품을 출시하고 있습니다. 만드는 이의 애씀이 사라진 제품 경험은 사용자의 애씀이 되거나, CES에서 번쩍 광고하고 사라지는 폭죽과 닮았습니다.

5️⃣ 정치적 환경: 디자이너들은 디자인보다 이해관계자 조정에 에너지를 쏟고, 정리해고 위협 속에서 본질적 역할 대신 생존에 집중합니다. 필요한 Internal Politics와 불필요한 사내 정치를 구분할 필요가 있습니다.

6️⃣ 타인의 인정 갈구: 직장에서 얻지 못하는 인정을 위해 LinkedIn에 자극적인 게시물을 올리고, 깊이 있는 토론보다는 '좋아요' 모으기에 집중합니다. 자신의 루틴을 위한 기록과 보여주기 위한 기록을 구분할 필요가 있습니다.

7️⃣ 기업 주도 디자인 담론: IxDA 같은 독립적인 디자인 커뮤니티 이벤트는 쇠퇴하고, 피그마나 Adobe 같은 기업이 디자인 의제를 결정합니다. 그곳에 가지 못하면 잊히거나 외면받는 것 같은 느낌은 또 다른 Peer Pressure입니다.

그럼에도 변화 속 기회를 찾을 수 있다면

이 순간에도 디자인은 진화하고 있습니다. 이런 변화는 커리어 전환의 기회가 될 수 있습니다. 매니저 트랙으로 나아가거나 사용자 심리, 접근성 분야의 전문가가 되는 길, 혹은 기본으로 돌아가 디자인 본질에 집중하는 방향도 있습니다.

디자인과 UX 리서치의 핵심 가치는 사람에 대한 이해와 공감입니다. 기술은 변해도 이 본질은 변하지 않습니다. 디자인을 진정으로 사랑한다면, 이 변화의 시대에도 의미 있는 길을 찾을 수 있을 것입니다.

Source: 『The State of UX in 2025』, Fabricio Teixeira, Caio Braga 작성

https://www.linkedin.com/posts/redbusbagman_the-state-of-ux-in-2025-activity-7315173201091743744-Gkjy?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAZSc3oBarIEHbo_ENsWiZv-BA5Ud1-qJ3U

최근 가장 인상 깊게 읽은 UX TRENDS의 글을 의역했습니다. 제 평소 생각을 담아 번역한 것이라 원문을 함께 읽어보시면 좋겠습니다. 위기의식이 여느 때보다 높은 UX 업계에서 어찌어찌 꾸역꾸역 일하는 분들께 작은 공감과 위로가 되길 바랍니다. 원문 제목이 'A Love Letter About Change'였습니다. 2010년대 후반에 정점을 찍었던 UX 열풍이 이제 사그라들고 있습니다. 디자이너들의 영향력은 약화되고, UX는 비즈니스 목표의 원동력이 아닌 부산물이 되어가고 있습니다. 이제 디자인 영향력(통제권)은 디자이너에서 알고리즘, 자동화 도구, 비즈니스 이해관계자로 이동하고 있습니다. 1️⃣ 문제의식이 사라진 디자인 데이터 제공: Figma 등 여러 도구에 디자인 산출물을 올리면서 AI 훈련에 암묵적으로 동의하고 있습니다. 이로 인해 디자인할 자격, 소요 시간, 금전적 가치에 대한 인식은 생각보다 더 빠르게 바뀔 것입니다. 그 영향을 받는 것도 디자이너가 될 테죠. 2️⃣ 비즈니스 중심 디자인: 사용성보다 클릭률을 높이기 위해 사용자 여정을 바꾸고 기만적 패턴을 계속 더하고 있습니다. 빼는 대신 늘리는 디자인에선 의미보다 성장 지표가 우선시 됩니다. 3️⃣ 알고리즘 중심 접근: 깊이 있는 UX 리서치 대신 자동화된 A/B 테스트를 활용하고, 데이터가 의사결정을 주도하게 됩니다. 알고리즘은 모든 고민의 면죄부가 되고 있습니다. 4️⃣ 미완성 제품 출시: '완벽보다 빠른 실행'이나 '빠르게 실패하기', 'Lean UX' 같은 개념을 핑계로 준비되지 않은 제품을 출시하고 있습니다. 만드는 이의 애씀이 사라진 제품 경험은 사용자의 애씀이 되거나, CES에서 번쩍 광고하고 사라지는 폭죽과 닮았습니다. 5️⃣ 정치적 환경: 디자이너들은 디자인보다 이해관계자 조정에 에너지를 쏟고, 정리해고 위협 속에서 본질적 역할 대신 생존에 집중합니다. 필요한 Internal Politics와 불필요한 사내 정치를 구분할 필요가 있습니다. 6️⃣ 타인의 인정 갈구: 직장에서 얻지 못하는 인정을 위해 LinkedIn에 자극적인 게시물을 올리고, 깊이 있는 토론보다는 '좋아요' 모으기에 집중합니다. 자신의 루틴을 위한 기록과 보여주기 위한 기록을 구분할 필요가 있습니다. 7️⃣ 기업 주도 디자인 담론: IxDA 같은 독립적인 디자인 커뮤니티 이벤트는 쇠퇴하고, 피그마나 Adobe 같은 기업이 디자인 의제를 결정합니다. 그곳에 가지 못하면 잊히거나 외면받는 것 같은 느낌은 또 다른 Peer Pressure입니다. 그럼에도 변화 속 기회를 찾을 수 있다면 이 순간에도 디자인은 진화하고 있습니다. 이런 변화는 커리어 전환의 기회가 될 수 있습니다. 매니저 트랙으로 나아가거나 사용자 심리, 접근성 분야의 전문가가 되는 길, 혹은 기본으로 돌아가 디자인 본질에 집중하는 방향도 있습니다. 디자인과 UX 리서치의 핵심 가치는 사람에 대한 이해와 공감입니다. 기술은 변해도 이 본질은 변하지 않습니다. 디자인을 진정으로 사랑한다면, 이 변화의 시대에도 의미 있는 길을 찾을 수 있을 것입니다. Source: 『The State of UX in 2025』, Fabricio Teixeira, Caio Braga 작성 https://www.linkedin.com/posts/redbusbagman_the-state-of-ux-in-2025-activity-7315173201091743744-Gkjy?utm_source=share&amp;utm_medium=member_desktop&amp;rcm=ACoAAAZSc3oBarIEHbo_ENsWiZv-BA5Ud1-qJ3U

www.linkedin.com

⟪위대한 디자인, 주인의식이 사라지고 주인이 바뀌는 시대⟫

아는 척하고 혹평하는 사람이 아니라 사랑하고 인내하며 용서할 줄 아는 사람이 늘 승리했습니다. 앞과 뒤가 다른 사람이 아니라 불리한 상황에서도 소신을 지키며 자신에게 불리한 상황도 감수한 사람이 늘 승리했습니다. 눈에 보이지 않는 가치를 지키기 위해 애를 쓰고 그 애를 쓰는 동료의 애씀을 보듬어주는 사람들이 늘 승리했습니다. 굳이 그렇게까지 해야 해? 유난하다며, 예민하다며 “시간 많아?”라는 이야기를 듣더라도 섬세함을 지켜가며 해야 하는 것을 결국 해내는 사람이 늘 승리했습니다.

대단해 보이지 않더라도 내 일을 사랑하고 그 일을 오늘도, 내일도 묵묵하게 하는 사람이 좋습니다.

아는 척하고 혹평하는 사람이 아니라 사랑하고 인내하며 용서할 줄 아는 사람이 늘 승리했습니다. 앞과 뒤가 다른 사람이 아니라 불리한 상황에서도 소신을 지키며 자신에게 불리한 상황도 감수한 사람이 늘 승리했습니다. 눈에 보이지 않는 가치를 지키기 위해 애를 쓰고 그 애를 쓰는 동료의 애씀을 보듬어주는 사람들이 늘 승리했습니다. 굳이 그렇게까지 해야 해? 유난하다며, 예민하다며 “시간 많아?”라는 이야기를 듣더라도 섬세함을 지켜가며 해야 하는 것을 결국 해내는 사람이 늘 승리했습니다. 대단해 보이지 않더라도 내 일을 사랑하고 그 일을 오늘도, 내일도 묵묵하게 하는 사람이 좋습니다.

《오늘 하루 문득 떠올린 애쓰는 마음》

롱블랙 프렌즈 K 여행 중 맘에 드는 숙소를 찾을 때면, 문득 이런 생각이 들죠. ‘이곳이 우리 집이면 얼마나 좋을까.’ 상상을 현실에 가져오는 호텔이 일본에 있다고 해요. 낫어호

낫어호텔 : 그 날짜는 47년 동안 예약 완료되었습니다

'낫어호텔'이라는 일본의 공동소유 부동산 중개회사 이야기를 소개합니다. '호텔계의 테슬라'로 평가받기도 하는 이유를 잘 다루고 있어서 전문 링크를 공유드립니다. 24시간 동안 열람하실 수 있어요!

[ 큐레이터의 문장 🎒 ]

1️⃣ 호텔을 분양하면서 '기간별로' 나눠서 판매하는 방식 - 1년에 10박만 이용하는 방식

2️⃣ 원할 때는 집으로, 아닐 땐 호텔로 운영해서 수익을 내는 방식 - 분양을 받은 후 내가 머물지 않는 기간 동안에는 임대해서 수익을 창출하거나 다른 호텔을 이용하며 교환하는 방식

3️⃣ '아깝다'는 감정에서 시작한 비즈니스 - 누군가 건물을 소유하는 걸 넘어 '잘 쓰게 할 순 없을까?'에서 문제 정의

4️⃣ 호텔 사업에 크라우드 펀딩을 도입해 3D 조감도만으로 호텔을 분양하는 새로운 방식 - 기존의 호텔업에 막대한 비용이 초기부터 들어가고 부도 위험을 갖는 리스크 헷지

5️⃣ 두근거림을 설계해 객실 가동률을 높이는 새로운 방식의 오모테나시

https://www.longblack.co/note/1289?ticket=NT2515d607780b0a12a75b732f784dab4d46e6

'낫어호텔'이라는 일본의 공동소유 부동산 중개회사 이야기를 소개합니다. '호텔계의 테슬라'로 평가받기도 하는 이유를 잘 다루고 있어서 전문 링크를 공유드립니다. 24시간 동안 열람하실 수 있어요! [ 큐레이터의 문장 🎒 ] 1️⃣ 호텔을 분양하면서 '기간별로' 나눠서 판매하는 방식 - 1년에 10박만 이용하는 방식 2️⃣ 원할 때는 집으로, 아닐 땐 호텔로 운영해서 수익을 내는 방식 - 분양을 받은 후 내가 머물지 않는 기간 동안에는 임대해서 수익을 창출하거나 다른 호텔을 이용하며 교환하는 방식 3️⃣ '아깝다'는 감정에서 시작한 비즈니스 - 누군가 건물을 소유하는 걸 넘어 '잘 쓰게 할 순 없을까?'에서 문제 정의 4️⃣ 호텔 사업에 크라우드 펀딩을 도입해 3D 조감도만으로 호텔을 분양하는 새로운 방식 - 기존의 호텔업에 막대한 비용이 초기부터 들어가고 부도 위험을 갖는 리스크 헷지 5️⃣ 두근거림을 설계해 객실 가동률을 높이는 새로운 방식의 오모테나시 https://www.longblack.co/note/1289?ticket=NT2515d607780b0a12a75b732f784dab4d46e6

LongBlack

⟪호텔업을 혁신하는 방법 - '낫어호텔'의 문제 정의⟫

생각보다 프로젝트 제목은 프로덕트 디자인의
많은 것이 담기는데요, 아래 방향을 추천합니다!

✅ [비즈니스 목표] + [UX/UI 개선 방향]

- 상품 구매 전환율 상승을 위한 리스트 뷰 UI 개선 프로젝트
- 검색·필터 UX 개편을 통한 객실 예약 전환율 향상 전략
- B2B 유입률을 높이기 위한 가입 온보딩 프로세스 리디자인
- 계좌 개설 UX 최적화로 이탈률을 낮춘 온보딩 개선

생각보다 프로젝트 제목은 프로덕트 디자인의많은 것이 담기는데요, 아래 방향을 추천합니다! ✅ [비즈니스 목표] + [UX/UI 개선 방향] - 상품 구매 전환율 상승을 위한 리스트 뷰 UI 개선 프로젝트 - 검색·필터 UX 개편을 통한 객실 예약 전환율 향상 전략- B2B 유입률을 높이기 위한 가입 온보딩 프로세스 리디자인- 계좌 개설 UX 최적화로 이탈률을 낮춘 온보딩 개선

프로덕트 디자인 포폴의 난관 = 제목 잘 쓰기?

[🚨4월 예약 오픈] 우디의 초밀착 포폴 컨설팅 오픈 했습니다! 포폴이 100% 만들어지지 않는 편이 컨설팅에 더 좋습니다.
-
https://www.latpeed.com/products/QkCkT

﻿
입사 지원을 하고 서류 전형 결과를 기다립니다. 입사 지원한 회사에서 서류 전형 결과는 일주일 내에 알려 준다고 합니다. 약간 친절하지 않은 회사는 서류 합격한 사람에게만 연락을 준다고 합니다. 그렇게 서류 전형 결과를 기다리다가 안타깝게도 일주일 내에 결과 안내를 받지 못하거나 탈락의 메시지를 받습니다.

그런데 조금 더 속상한 일은 정성껏 준비한 이력서로 입사 지원했을 때, 서류 전형에서 탈락한 이유를 알 수 없다는 것입니다. 입사 지원한 회사에서는 탈락한 이유가 지원자가 절대 부족해서가 아니라고 하지만, 자격 요건에 부합하지 않으니 탈락이라는 결과가 나왔을 것이고, 그럼 자신이 부족한 부분이 있는 것이 아닌가 추측하게 됩니다.

문제는 입사 지원 숫자가 늘어남에 따라 비례하여 서류 전형에서 탈락하는 결과도 쌓인다는 것입니다. 서류 전형에서 탈락하는 결과를 자주 받으면 심리적으로 위축되게 됩니다. 이것은 아무리 멘탈 강도가 슈퍼맨 수준이라도 누구나 흔들리게 됩니다. 사람에게 거절감은 크고 작은 타격을 주어 마음을 아프게 만듭니다.

그렇다고 입사 지원을 멈출 수 없습니다. 서류 전형에서 계속 탈락한다고 도전을 멈추지 말아야 합니다. 도전을 멈추는 순간 앞으로 나갈 수 없습니다. 다만, 무작정 계속 도전하지 말고 탈락의 원인을 분석해 보면 좋겠습니다. 원인을 분석해 보고 부족한 부분을 보완하는 노력을 한다면, 반드시 이전보다 긍정적인 결과를 얻을 수 있다고 믿습니다.

서류 전형 탈락의 이유를 입사 지원한 회사에서 알려주지 않는데, 무슨 재주로 분석을 하라는 말이냐? 정답은 우리 이력서와 입사 지원한 회사의 채용 공고에 있습니다. 먼저 내가 작성한 이력서에 내가 가진 강점이 충분히 드러나고 있는지 점검해 보면 좋겠습니다. 여러분은 자신이 가진 강점에 대해서 정확하게 파악하고 계십니까? 강점은 기술적인 부분과 태도적인 내용을 모두 포함하고 있습니다. 강점을 어필한다고 했을 때, 반드시 기술적인 부분만 유효한 것은 아닙니다. 중요한 것은 본인이 자신 있게 증명할 수 있는 강점을 알고 있으며, 그 강점을 이력서에 객관적으로 증명하고 있는지 확인하는 것입니다.

이력서는 반드시 합격하는 공식이 있는 문서가 아닙니다. 사람마다 굉장히 주관적인 관점으로 바라보는 소설 또는 에세이와 같은 장르의 문서입니다. 따라서 이력서를 읽는 독자의 시선을 사로잡고, 마음을 흔드는 내용이 필요합니다. 그것이 저는 이력서를 쓴 사람의 강점을 어필하는 것이라고 생각합니다. 소설이나 에세이를 쓴 어느 작가의 소설이 어떤 독자에게는 호평을 받고, 어떤 독자에게는 혹평을 받습니다. 이력서도 똑같습니다. ‘나’의 강점을 드러낸 문서를 읽고 어떤 회사의 서류 전형을 검토하는 사람은 합격을 주고, 어떤 회사의 사람은 불합격을 줄 수도 있습니다.

우리가 해야 하는 일은 ‘나’의 강점을 알고 이력서에 객관적으로 증명하는 것뿐입니다. 피드백은 전적으로 독자에게 맡기고 결과를 기다리면 됩니다. 이렇게 하고도 불합격이 된다면, 거절감으로 아쉬워할 것도 연속된 탈락으로 좌절할 이유도 없습니다. ‘나’의 강점을 더 뾰족해 보이도록 다듬고, 내가 쓴 이력서에 담긴 스토리를 호평해 줄 회사와 사람을 만나기 위해 계속 도전하면 됩니다.

서류 전형 결과의 합격 가능성과 탈락 원인 분석은 채용 공고를 보면 이해할 수 있습니다. 채용 공고에 나온 주요 업무와 자격 요건, 우대 사항의 내용을 보고 단어와 문장 하나하나를 체크해 보세요. 내가 가진 경험과 역량에 부합하는 내용이 있다면, 빨간 팬으로 동그라미 칠을 해보세요. 반대로 여러분에게 부족한 부분은 빨간 팬으로 엑스 표시를 해보세요. 그리고 통계를 내어 보는 것입니다. 동그라미와 엑스 표시가 각각 몇 개가 되는지 세아려 보세요. 합격과 불합격의 가능성이 50 대 50이라면, 적어도 동그라미 숫자가 엑스 숫자보다 하나라도 더 있어야 합격 가능성이 있을 것입니다. 채용 담당자 입장에서 냉정하게 평가 항목 100 중에 동그라미 숫자가 80개는 되어야 합격을 줄 것입니다.

이렇게 해도 탈락한 이유를 속이 후련하게 알 수 없다고 느낀다면, 현직 구성원에게 물어보는 방법이 있습니다. 입사 지원한 회사에 메일을 보내어 묻는 것입니다. 조금 더 구체적인 서류 검토 내용을 공유해 줄 수 없는지 정중하게 요청하는 것입니다. 그럼 짧게라도 답변을 더 해주기도 합니다. 아니면 LinkedIn 채널과 같이 현직 구성원과 대화를 나눌 수 있는 서비스를 이용하는 것도 방법입니다. 현직 구성원을 찾아서 메시지를 보내는 것입니다. 당신이 근무하고 있는 회사에 관심이 있는데, 어떤 인재를 원하는지 알고 싶다고 물어보는 것입니다.

탈락의 아픔은 쓰라립니다. 오랜 시간 동안 많은 탈락을 경험해 보아서 그 고통을 이해하고 있습니다. 그럼에도 불구하고 현실을 직시해야 합니다. 부족한 점을 알고 보완해야 더 이상 마음 아픈 탈락을 덜 느낄 수 있습니다.

알고자 하면 길이 보입니다. 오늘도 당당하게 자신과 입사 지원할 회사를 똑바로 바라보고 나아가면 좋겠습니다. 그럼 머지않아 긍정적인 결과를 받아들게 될 것입니다. 그날을 소망하며 오늘도 진심으로 여러분을 응원합니다.

﻿입사 지원을 하고 서류 전형 결과를 기다립니다. 입사 지원한 회사에서 서류 전형 결과는 일주일 내에 알려 준다고 합니다. 약간 친절하지 않은 회사는 서류 합격한 사람에게만 연락을 준다고 합니다. 그렇게 서류 전형 결과를 기다리다가 안타깝게도 일주일 내에 결과 안내를 받지 못하거나 탈락의 메시지를 받습니다. 그런데 조금 더 속상한 일은 정성껏 준비한 이력서로 입사 지원했을 때, 서류 전형에서 탈락한 이유를 알 수 없다는 것입니다. 입사 지원한 회사에서는 탈락한 이유가 지원자가 절대 부족해서가 아니라고 하지만, 자격 요건에 부합하지 않으니 탈락이라는 결과가 나왔을 것이고, 그럼 자신이 부족한 부분이 있는 것이 아닌가 추측하게 됩니다. 문제는 입사 지원 숫자가 늘어남에 따라 비례하여 서류 전형에서 탈락하는 결과도 쌓인다는 것입니다. 서류 전형에서 탈락하는 결과를 자주 받으면 심리적으로 위축되게 됩니다. 이것은 아무리 멘탈 강도가 슈퍼맨 수준이라도 누구나 흔들리게 됩니다. 사람에게 거절감은 크고 작은 타격을 주어 마음을 아프게 만듭니다. 그렇다고 입사 지원을 멈출 수 없습니다. 서류 전형에서 계속 탈락한다고 도전을 멈추지 말아야 합니다. 도전을 멈추는 순간 앞으로 나갈 수 없습니다. 다만, 무작정 계속 도전하지 말고 탈락의 원인을 분석해 보면 좋겠습니다. 원인을 분석해 보고 부족한 부분을 보완하는 노력을 한다면, 반드시 이전보다 긍정적인 결과를 얻을 수 있다고 믿습니다. 서류 전형 탈락의 이유를 입사 지원한 회사에서 알려주지 않는데, 무슨 재주로 분석을 하라는 말이냐? 정답은 우리 이력서와 입사 지원한 회사의 채용 공고에 있습니다. 먼저 내가 작성한 이력서에 내가 가진 강점이 충분히 드러나고 있는지 점검해 보면 좋겠습니다. 여러분은 자신이 가진 강점에 대해서 정확하게 파악하고 계십니까? 강점은 기술적인 부분과 태도적인 내용을 모두 포함하고 있습니다. 강점을 어필한다고 했을 때, 반드시 기술적인 부분만 유효한 것은 아닙니다. 중요한 것은 본인이 자신 있게 증명할 수 있는 강점을 알고 있으며, 그 강점을 이력서에 객관적으로 증명하고 있는지 확인하는 것입니다. 이력서는 반드시 합격하는 공식이 있는 문서가 아닙니다. 사람마다 굉장히 주관적인 관점으로 바라보는 소설 또는 에세이와 같은 장르의 문서입니다. 따라서 이력서를 읽는 독자의 시선을 사로잡고, 마음을 흔드는 내용이 필요합니다. 그것이 저는 이력서를 쓴 사람의 강점을 어필하는 것이라고 생각합니다. 소설이나 에세이를 쓴 어느 작가의 소설이 어떤 독자에게는 호평을 받고, 어떤 독자에게는 혹평을 받습니다. 이력서도 똑같습니다. ‘나’의 강점을 드러낸 문서를 읽고 어떤 회사의 서류 전형을 검토하는 사람은 합격을 주고, 어떤 회사의 사람은 불합격을 줄 수도 있습니다. 우리가 해야 하는 일은 ‘나’의 강점을 알고 이력서에 객관적으로 증명하는 것뿐입니다. 피드백은 전적으로 독자에게 맡기고 결과를 기다리면 됩니다. 이렇게 하고도 불합격이 된다면, 거절감으로 아쉬워할 것도 연속된 탈락으로 좌절할 이유도 없습니다. ‘나’의 강점을 더 뾰족해 보이도록 다듬고, 내가 쓴 이력서에 담긴 스토리를 호평해 줄 회사와 사람을 만나기 위해 계속 도전하면 됩니다. 서류 전형 결과의 합격 가능성과 탈락 원인 분석은 채용 공고를 보면 이해할 수 있습니다. 채용 공고에 나온 주요 업무와 자격 요건, 우대 사항의 내용을 보고 단어와 문장 하나하나를 체크해 보세요. 내가 가진 경험과 역량에 부합하는 내용이 있다면, 빨간 팬으로 동그라미 칠을 해보세요. 반대로 여러분에게 부족한 부분은 빨간 팬으로 엑스 표시를 해보세요. 그리고 통계를 내어 보는 것입니다. 동그라미와 엑스 표시가 각각 몇 개가 되는지 세아려 보세요. 합격과 불합격의 가능성이 50 대 50이라면, 적어도 동그라미 숫자가 엑스 숫자보다 하나라도 더 있어야 합격 가능성이 있을 것입니다. 채용 담당자 입장에서 냉정하게 평가 항목 100 중에 동그라미 숫자가 80개는 되어야 합격을 줄 것입니다. 이렇게 해도 탈락한 이유를 속이 후련하게 알 수 없다고 느낀다면, 현직 구성원에게 물어보는 방법이 있습니다. 입사 지원한 회사에 메일을 보내어 묻는 것입니다. 조금 더 구체적인 서류 검토 내용을 공유해 줄 수 없는지 정중하게 요청하는 것입니다. 그럼 짧게라도 답변을 더 해주기도 합니다. 아니면 LinkedIn 채널과 같이 현직 구성원과 대화를 나눌 수 있는 서비스를 이용하는 것도 방법입니다. 현직 구성원을 찾아서 메시지를 보내는 것입니다. 당신이 근무하고 있는 회사에 관심이 있는데, 어떤 인재를 원하는지 알고 싶다고 물어보는 것입니다. 탈락의 아픔은 쓰라립니다. 오랜 시간 동안 많은 탈락을 경험해 보아서 그 고통을 이해하고 있습니다. 그럼에도 불구하고 현실을 직시해야 합니다. 부족한 점을 알고 보완해야 더 이상 마음 아픈 탈락을 덜 느낄 수 있습니다. 알고자 하면 길이 보입니다. 오늘도 당당하게 자신과 입사 지원할 회사를 똑바로 바라보고 나아가면 좋겠습니다. 그럼 머지않아 긍정적인 결과를 받아들게 될 것입니다. 그날을 소망하며 오늘도 진심으로 여러분을 응원합니다.﻿

탈락 분석

Q) 완전히 새로운 기능을 출시할 때, 위험을 최소화하는 UX 접근 방법이 있을까요? (우디)

A) 🙋‍♀️ 검증된 초기 사용자 그룹에게만 공개하는 Soft Launch 경험이 있습니다. 내부 직원이나 VIP 사용자 그룹을 대상으로 테스트를 진행했고, 주요 버그와 UX 문제를 잡아낼 수 있었습니다. 정식 오픈후에는 동료들과 초기 지표(피처 사용 빈도, 이탈률, 사용자 피드백 등)를 모니터링하면서 점진적 대응을 했습니다. (2년차 프디분)

*신기능 출시에서 발생할 수 있는 리스크를 어떻게 줄이는지, 구체적인 경험을 제시한 점이 좋았습니다.

Q) 완전히 새로운 기능을 출시할 때, 위험을 최소화하는 UX 접근 방법이 있을까요? (우디) A) 🙋‍♀️ 검증된 초기 사용자 그룹에게만 공개하는 Soft Launch 경험이 있습니다. 내부 직원이나 VIP 사용자 그룹을 대상으로 테스트를 진행했고, 주요 버그와 UX 문제를 잡아낼 수 있었습니다. 정식 오픈후에는 동료들과 초기 지표(피처 사용 빈도, 이탈률, 사용자 피드백 등)를 모니터링하면서 점진적 대응을 했습니다. (2년차 프디분) *신기능 출시에서 발생할 수 있는 리스크를 어떻게 줄이는지, 구체적인 경험을 제시한 점이 좋았습니다.

기억남는 디자이너 면접 답변 [14]

﻿
희망 가득한 내일을 기대하며 약속의 땅으로 출발한 지 얼마 지나지 않아 힘든 상황이 펼쳐집니다. 지옥같이 어려운 상황을 벗어난다면 무엇이든 견딜 수 있다고 스스로 다짐한 마음은 순식간에 사라집니다. 그리고 이내 불평과 불만, 원망의 말을 하나씩 쏟아냅니다. 누가 들으라고 하는 것은 아니고 신세를 한탄하는 것입니다.

저는 스스로에게 놀랍니다. 사람은 참 안 변한다는 사실을 직접 체험하고 매번 놀랍니다. 그토록 춥고 힘겨웠던 겨울을 보내고, 이제 봄을 맞아 꽃길만 걸을 줄 알았습니다. 그러나 현실은 녹록지 않다는 것을 깨닫는데 그리 오랜 시간이 필요하지 않습니다. 감사한 마음은 짧고 상황을 한탄하고 원망하는 것은 정말 쉽습니다.

이번에는 진짜 어떤 어려움이 있어도 참고 견뎌야지 굳게 다짐하지만, 정작 어려움이 현실이 되면 인내하기 어렵습니다. 어떻게 하면 이 상황을 벗어날 수 있을까 궁리하며, 오직 벗어나는 것만이 유일한 탈출구라고 여깁니다. 그리고 탈출할 합리적인 이유를 찾아 두리번거립니다. 마치 동물원만 탈출하면 대초원이 펼쳐질 거라고 상상하는 얼룩말 같습니다. 현실은 동물원 밖은 대도시 한복판입니다. (비유가 적절하지 않다면 죄송합니다) 

미래를 기대하며 걷는 약속의 땅으로 가는 길은 험난할 수 있습니다. 약속의 땅이 풍요로울 것을 기대하는 것이지 과정이 무조건 순탄한 것은 아닙니다. 그런데 저는 너무 쉽게 과정도 그러해야 한다고 착각합니다. 그러니 지금까지 땅 근처 구경도 못하고 도로 위를 이리저리 헤맸던 것입니다. 도로는 때론 평탄한 경로도 있었지만, 구불구불 울퉁불퉁 거칠거칠 대부분 제가 기대했던 모양은 아니었습니다. 그런 길 위에서 만났던 사람들과 즐거운 순간도 있었고, 지지고 볶고 아웅다웅했던 지난한 시간도 보냈습니다.

짧디짧은 인내심을 모든 소진한 뒤 새로운 경로를 탐색하여 도전할 때마다 늘 상황은 비슷했습니다. 기대하고 실망하고 원망하며 또 탈출하는 과정의 연속이었습니다. 탈출하면 감사한 마음이 있었지만, 어려움을 만나면 즉시 원망을 쏟아냈습니다. 그러나 어제 깨달았습니다. 제 마음이 잘못되어도 한참 잘못되었다는 사실을 말이죠.

제가 싫어하는 상황을 제외하곤 많은 부분에서 감사할 것을 찾을 수 있었습니다. 어려움을 만나면 제게 좋았던 것을 기억하는 장치가 고장이 납니다. 고마운 마음은 과거를 기억하며 얻을 수 있는 것입니다. 좋은 사람과 상황, 주어진 것들을 기억해야만 감사한 마음을 지속할 수 있습니다. 그래서 늘 평범한 일상을 살면서도 감사할 줄 알아야 합니다. 이러한 태도는 저절로 얻어지는 것이 아니라 연습과 훈련을 통해서 만드는 것입니다.

성장과 성숙을 통해 사람은 변화할 수 있습니다. 우리가 가진 부정적인 특성이 자꾸 발현되어 자책할 것이 아니라 오늘부터 변화하기 위해 노력해 봅시다. 저처럼 어려움을 만나면 쉽게 불평과 불만을 하게 되는 분들이 계시다면, 마음속에서 원망이 올라오는 순간 재빨리 최근에 감사했던 일을 떠올려 보세요. 거짓말처럼 상황이 어렵게 느껴지지 않고 담담하게 여길 수 있습니다.

성장과 성숙은 어려운 일이 아닙니다. 오늘 한 발, 내일 또 한 발 나아가는 과정입니다. 이 세상에 완성된 모습을 가진 것은 없습니다. 한 단계씩 성장하고 성숙해져 가는 것입니다. 다른 사람에게 인정받을 필요도 없습니다. 자신이 생각했을 때, 어제보다 나은 오늘을 살았는가 묻고 내일 다시 한 단계 도전하면 된다고 믿습니다.

이렇게 매일 노력하며 살다가보면 어느 순간 극적인 변화를 맞이할 수 있습니다. 그동안 별 볼일 없는 사람이라고 여겼던 자신이 스스로에게뿐만 아니라 주변 사람들에게도 긍정적인 영향을 주는 존재로 바뀌는 것입니다. 이것은 누구나 할 수 있는 일입니다. 그리고 성숙과 성장은 누구나 해야 하는 일이기도 합니다.

눈에 보이는 내 삶의 영역보다 내면이 깊어지고 넓어지고 싶습니다. 부유해지고 유명해지는 것보다 생각이 깊어지고 마음이 넓은 사람이 되고 싶습니다. 상황을 1차원으로 바라보고 쉽게 판단하지 않고, 깊은 생각과 넓은 마음으로 이해하고 품을 수 있는 성숙한 사람으로 성장하고 싶습니다.

‘다 그렇게 사는 거야’ 아니요. 저와 여러분은 다 그렇게 산다는 핑계로 성장과 성숙을 미루거나 멈추지 않으면 좋겠습니다. 오늘도 어제보다 한 걸음 더 나아지는 우리가 되길 진심으로 응원합니다.

﻿희망 가득한 내일을 기대하며 약속의 땅으로 출발한 지 얼마 지나지 않아 힘든 상황이 펼쳐집니다. 지옥같이 어려운 상황을 벗어난다면 무엇이든 견딜 수 있다고 스스로 다짐한 마음은 순식간에 사라집니다. 그리고 이내 불평과 불만, 원망의 말을 하나씩 쏟아냅니다. 누가 들으라고 하는 것은 아니고 신세를 한탄하는 것입니다. 저는 스스로에게 놀랍니다. 사람은 참 안 변한다는 사실을 직접 체험하고 매번 놀랍니다. 그토록 춥고 힘겨웠던 겨울을 보내고, 이제 봄을 맞아 꽃길만 걸을 줄 알았습니다. 그러나 현실은 녹록지 않다는 것을 깨닫는데 그리 오랜 시간이 필요하지 않습니다. 감사한 마음은 짧고 상황을 한탄하고 원망하는 것은 정말 쉽습니다. 이번에는 진짜 어떤 어려움이 있어도 참고 견뎌야지 굳게 다짐하지만, 정작 어려움이 현실이 되면 인내하기 어렵습니다. 어떻게 하면 이 상황을 벗어날 수 있을까 궁리하며, 오직 벗어나는 것만이 유일한 탈출구라고 여깁니다. 그리고 탈출할 합리적인 이유를 찾아 두리번거립니다. 마치 동물원만 탈출하면 대초원이 펼쳐질 거라고 상상하는 얼룩말 같습니다. 현실은 동물원 밖은 대도시 한복판입니다. (비유가 적절하지 않다면 죄송합니다)&nbsp; 미래를 기대하며 걷는 약속의 땅으로 가는 길은 험난할 수 있습니다. 약속의 땅이 풍요로울 것을 기대하는 것이지 과정이 무조건 순탄한 것은 아닙니다. 그런데 저는 너무 쉽게 과정도 그러해야 한다고 착각합니다. 그러니 지금까지 땅 근처 구경도 못하고 도로 위를 이리저리 헤맸던 것입니다. 도로는 때론 평탄한 경로도 있었지만, 구불구불 울퉁불퉁 거칠거칠 대부분 제가 기대했던 모양은 아니었습니다. 그런 길 위에서 만났던 사람들과 즐거운 순간도 있었고, 지지고 볶고 아웅다웅했던 지난한 시간도 보냈습니다. 짧디짧은 인내심을 모든 소진한 뒤 새로운 경로를 탐색하여 도전할 때마다 늘 상황은 비슷했습니다. 기대하고 실망하고 원망하며 또 탈출하는 과정의 연속이었습니다. 탈출하면 감사한 마음이 있었지만, 어려움을 만나면 즉시 원망을 쏟아냈습니다. 그러나 어제 깨달았습니다. 제 마음이 잘못되어도 한참 잘못되었다는 사실을 말이죠. 제가 싫어하는 상황을 제외하곤 많은 부분에서 감사할 것을 찾을 수 있었습니다. 어려움을 만나면 제게 좋았던 것을 기억하는 장치가 고장이 납니다. 고마운 마음은 과거를 기억하며 얻을 수 있는 것입니다. 좋은 사람과 상황, 주어진 것들을 기억해야만 감사한 마음을 지속할 수 있습니다. 그래서 늘 평범한 일상을 살면서도 감사할 줄 알아야 합니다. 이러한 태도는 저절로 얻어지는 것이 아니라 연습과 훈련을 통해서 만드는 것입니다. 성장과 성숙을 통해 사람은 변화할 수 있습니다. 우리가 가진 부정적인 특성이 자꾸 발현되어 자책할 것이 아니라 오늘부터 변화하기 위해 노력해 봅시다. 저처럼 어려움을 만나면 쉽게 불평과 불만을 하게 되는 분들이 계시다면, 마음속에서 원망이 올라오는 순간 재빨리 최근에 감사했던 일을 떠올려 보세요. 거짓말처럼 상황이 어렵게 느껴지지 않고 담담하게 여길 수 있습니다. 성장과 성숙은 어려운 일이 아닙니다. 오늘 한 발, 내일 또 한 발 나아가는 과정입니다. 이 세상에 완성된 모습을 가진 것은 없습니다. 한 단계씩 성장하고 성숙해져 가는 것입니다. 다른 사람에게 인정받을 필요도 없습니다. 자신이 생각했을 때, 어제보다 나은 오늘을 살았는가 묻고 내일 다시 한 단계 도전하면 된다고 믿습니다. 이렇게 매일 노력하며 살다가보면 어느 순간 극적인 변화를 맞이할 수 있습니다. 그동안 별 볼일 없는 사람이라고 여겼던 자신이 스스로에게뿐만 아니라 주변 사람들에게도 긍정적인 영향을 주는 존재로 바뀌는 것입니다. 이것은 누구나 할 수 있는 일입니다. 그리고 성숙과 성장은 누구나 해야 하는 일이기도 합니다. 눈에 보이는 내 삶의 영역보다 내면이 깊어지고 넓어지고 싶습니다. 부유해지고 유명해지는 것보다 생각이 깊어지고 마음이 넓은 사람이 되고 싶습니다. 상황을 1차원으로 바라보고 쉽게 판단하지 않고, 깊은 생각과 넓은 마음으로 이해하고 품을 수 있는 성숙한 사람으로 성장하고 싶습니다. ‘다 그렇게 사는 거야’ 아니요. 저와 여러분은 다 그렇게 산다는 핑계로 성장과 성숙을 미루거나 멈추지 않으면 좋겠습니다. 오늘도 어제보다 한 걸음 더 나아지는 우리가 되길 진심으로 응원합니다.﻿

원망과 성숙

문제 정의는 UX 포폴의 처음이자 끝입니다.
크게 두 가지를 잊지 마세요 :)

첫째, 문제 정의 시 개인의 편견이 반영되지 않아야 합니다.
- 예를 들어, ‘사용자는 더 빠른 로딩을 원한다’는 관찰자의 편견이 포함된 문제 정의입니다. 더 적절한 정의는 ‘사용자는 페이지 로딩이 3초 이상 걸릴 경우 이탈률이 증가한다.’ 와 같이 근거 및 데이터 중심이 좋습니다.

둘째, 문제와 원인을 혼동하지 말아야 합니다.
😭 버튼 크기가 작아서 사용자가 클릭하기 어렵다.
✅ 문제와 원인을 분리하기
- 사용자는 버튼 클릭 시 오류율이 높다.(문제)
- 버튼의 크기가 작은 것이 원인일 수 있다.(원인 분석)

🔗 우디의 포트폴리오 컨설팅 운영중입니다! (고정 댓글 확인)

문제 정의는 UX 포폴의 처음이자 끝입니다.크게 두 가지를 잊지 마세요 :) 첫째, 문제 정의 시 개인의 편견이 반영되지 않아야 합니다.- 예를 들어, ‘사용자는 더 빠른 로딩을 원한다’는 관찰자의 편견이 포함된 문제 정의입니다. 더 적절한 정의는 ‘사용자는 페이지 로딩이 3초 이상 걸릴 경우 이탈률이 증가한다.’ 와 같이 근거 및 데이터 중심이 좋습니다. 둘째, 문제와 원인을 혼동하지 말아야 합니다.😭 버튼 크기가 작아서 사용자가 클릭하기 어렵다.✅ 문제와 원인을 분리하기- 사용자는 버튼 클릭 시 오류율이 높다.(문제)- 버튼의 크기가 작은 것이 원인일 수 있다.(원인 분석) 🔗 우디의 포트폴리오 컨설팅 운영중입니다! (고정 댓글 확인)

<알쏭달쏭 포폴 속 문제정의.. 그거 어떻게 하는거죠?>

﻿
지금 살고 있는 집으로 이사하면서 동고동락을 함께한 비데가 고장이 났습니다. 지금 살고 있는 집이 올해로 10년이 넘었으니, 짧지 않은 기간 동안 함께해 준 셈입니다. 10년이 지나는 동안 아들과 딸이 태어나 네 식구를 앉혀 주느라 많이 힘들었던 모양입니다. 가전제품 수명이 10년 정도라는 것은 정말 믿기지 않는 진리인가 봅니다.

비데 사용을 선호하는 사람으로 고장이 나서 사용할 수 없는 상황이 난처하게 느껴졌습니다. 그래서 정든 친구를 대신하여 빠르게 새 친구가 필요했습니다. 마침 주말이라 상품 배송은 가능했지만, 설치 기사님의 도움은 받기 어려웠습니다. 그래서 상품을 주문하고 돌아오는 주중을 기다려야 하는 상황이었습니다. 그러나 저는 주말 이틀을 비데 친구 없이 보낼 자신이 없었습니다.

저는 손재주가 있는 듯 없습니다. 어린 시절부터 만들기를 좋아하지 않았고, 잘하지도 못하였습니다. 만들기는 형이 잘했고, 그런 형이 부러웠습니다. 저는 기껏해야 단순한 장난감 정도 조립하는 수준이었습니다. 만들기를 잘 못한다는 것, 그래서 기계나 장비를 잘 다루지 못한다는 것은 커서 애매하고 사소한 이슈가 되었습니다.

먼저 회사가 들어갔는데 컴퓨터라는 장비를 사용하는 것이었습니다. 초등학교 때부터 8비트 컴퓨터를 다룬 경험은 있지만, 고작 2차원적인 게임을 하는 수준이었습니다. 대학생 때도 메일이나 채팅 용도로 사용했지, 업무적으로 문서를 만들거나 그 외 다른 용도로 컴퓨터를 다루어 보지 못했습니다. 그래서 컴퓨터로 하는 모든 일이 새로웠고 어려웠습니다. 그래도 일을 해야 했기에 선배들에게 혹독하게 훈련받았습니다. 덕분에 점점 사람 구실하는 수준으로 컴퓨터를 다룰 수 있게 되었습니다.

이후 결혼을 했는데, 이제는 다루어야 하는 장비가 기하급수적으로  늘어났습니다. 모든 가전제품은 물론이고, 가구 등 모든 살림을 만지고 다듬고 해야 했습니다. 벽에 못을 박는 일이나 변기가 막혔을 때 뚫어야 하는 일도 해야 했습니다. 결혼 전에 부모님과 함께 살면서 한 번도 마주하지 않았던 일을 해야 했기에 비로소 어른이 되는 것인가 생각했습니다. 

하지 않았지만, 해야 하는 일을 하는 심정은 무거운 책임감으로 다가왔습니다. 마치 나라라도 구해야 하는 독립투사, 전쟁터 군인과 같이 비장한 각오로 살림을 다루어야 했던 것입니다. 전등을 갈아 끼워야 하는 일, 싱크대에서 물이 바닥으로 새는 정체 모를 것을 막는 일, 아이들이 벽에 낙서하면 지우는 일 등 한 번도 겪어보지 못한 크고 작은 사건과 사고를 반드시 처리해야 했습니다. 그리고 어떻게 해든 우당탕탕 임무를 완수해 냈습니다.

경험해 보지 않은 일을 처리할 때 느낀 점은, 처음 상황을 마주한 순간에 그 일을 내가 해낼 수 있을까 걱정되고 불안했습니다. 하지만 막상 도전해 보면 불가능한 일은 없었습니다. 때로는 설명서를 보고, 때로는 인터넷을 검색하여 방법을 찾아보면 어렵지 않게 해결할 수 있는 일이 많았습니다. 두려움이 처음 하는 일을 시도하는 것을 방해하여 능력이 없는 사람처럼 느껴질 뿐, 제 안에 충분히 해낼 힘이 있었던 것입니다.

그리고 빠르게 해치우려고 절차를 무시하고 힘으로 일을 대하면 잘 풀리지 않는다는 것을 배웠습니다. 얼추 느낌으로 이렇게 하면 되겠지 하고 덤벼들면 뜻대로 잘되지 않았던 것입니다. 커튼을 빨고 다시 원상태로 천장에 달면서 고리를 마구잡이로 끼우면 순서가 뒤엉켜 다시 처음부터 다시 해야 했습니다. 정확하게 순서를 파악하고 차분하게 하나씩 고리를 맞춰서 달면 오히려 서두른 때보다 빠르게 일을 처리할 수 있었습니다.

어제 새 비데를 설치하기 위해 헌 비데를 제거하는 일에서도 다시 깨달았습니다. 고정 나사를 빼야 했는데, 잘 빠지지 않아서 힘을 쓰느라 30분 이상 소요했습니다. 그런데 알고 보니 고정 나사는 힘으로 잡아 빼는 것이 아니라 변기 밑에 고정 장치를 풀기만 하면 되는 일이었습니다. 3초면 할 수 있었던 일을 앞뒤 가리지 않고 빨리 힘으로 해결하려고 노력하다가 600백 배나 더 올래 걸렸던 것입니다. (계산 맞나요?)

여러분도 처음 도전하는 일이 있나요? 그 일이 어렵게 느껴지나요? 제가 장담합니다. 여러분은 그 일을 충분히 잘 해낼 수 있습니다. 우리 안에 숨겨진 능력을 믿으시길 바랍니다. 다만, 두려워하지 말고 세상 선배들이 해왔던 방식을 찾아보고 차분하게 따라 해 보시기 바랍니다. 그럼 어떤 일도 우리는 해낼 수 있습니다. 원리와 논리만 알면 하지 못할 일은 아무것도 없습니다. 여러분의 새로운 도전을 진심으로 응원합니다.

﻿지금 살고 있는 집으로 이사하면서 동고동락을 함께한 비데가 고장이 났습니다. 지금 살고 있는 집이 올해로 10년이 넘었으니, 짧지 않은 기간 동안 함께해 준 셈입니다. 10년이 지나는 동안 아들과 딸이 태어나 네 식구를 앉혀 주느라 많이 힘들었던 모양입니다. 가전제품 수명이 10년 정도라는 것은 정말 믿기지 않는 진리인가 봅니다. 비데 사용을 선호하는 사람으로 고장이 나서 사용할 수 없는 상황이 난처하게 느껴졌습니다. 그래서 정든 친구를 대신하여 빠르게 새 친구가 필요했습니다. 마침 주말이라 상품 배송은 가능했지만, 설치 기사님의 도움은 받기 어려웠습니다. 그래서 상품을 주문하고 돌아오는 주중을 기다려야 하는 상황이었습니다. 그러나 저는 주말 이틀을 비데 친구 없이 보낼 자신이 없었습니다. 저는 손재주가 있는 듯 없습니다. 어린 시절부터 만들기를 좋아하지 않았고, 잘하지도 못하였습니다. 만들기는 형이 잘했고, 그런 형이 부러웠습니다. 저는 기껏해야 단순한 장난감 정도 조립하는 수준이었습니다. 만들기를 잘 못한다는 것, 그래서 기계나 장비를 잘 다루지 못한다는 것은 커서 애매하고 사소한 이슈가 되었습니다. 먼저 회사가 들어갔는데 컴퓨터라는 장비를 사용하는 것이었습니다. 초등학교 때부터 8비트 컴퓨터를 다룬 경험은 있지만, 고작 2차원적인 게임을 하는 수준이었습니다. 대학생 때도 메일이나 채팅 용도로 사용했지, 업무적으로 문서를 만들거나 그 외 다른 용도로 컴퓨터를 다루어 보지 못했습니다. 그래서 컴퓨터로 하는 모든 일이 새로웠고 어려웠습니다. 그래도 일을 해야 했기에 선배들에게 혹독하게 훈련받았습니다. 덕분에 점점 사람 구실하는 수준으로 컴퓨터를 다룰 수 있게 되었습니다. 이후 결혼을 했는데, 이제는 다루어야 하는 장비가 기하급수적으로&nbsp; 늘어났습니다. 모든 가전제품은 물론이고, 가구 등 모든 살림을 만지고 다듬고 해야 했습니다. 벽에 못을 박는 일이나 변기가 막혔을 때 뚫어야 하는 일도 해야 했습니다. 결혼 전에 부모님과 함께 살면서 한 번도 마주하지 않았던 일을 해야 했기에 비로소 어른이 되는 것인가 생각했습니다.&nbsp; 하지 않았지만, 해야 하는 일을 하는 심정은 무거운 책임감으로 다가왔습니다. 마치 나라라도 구해야 하는 독립투사, 전쟁터 군인과 같이 비장한 각오로 살림을 다루어야 했던 것입니다. 전등을 갈아 끼워야 하는 일, 싱크대에서 물이 바닥으로 새는 정체 모를 것을 막는 일, 아이들이 벽에 낙서하면 지우는 일 등 한 번도 겪어보지 못한 크고 작은 사건과 사고를 반드시 처리해야 했습니다. 그리고 어떻게 해든 우당탕탕 임무를 완수해 냈습니다. 경험해 보지 않은 일을 처리할 때 느낀 점은, 처음 상황을 마주한 순간에 그 일을 내가 해낼 수 있을까 걱정되고 불안했습니다. 하지만 막상 도전해 보면 불가능한 일은 없었습니다. 때로는 설명서를 보고, 때로는 인터넷을 검색하여 방법을 찾아보면 어렵지 않게 해결할 수 있는 일이 많았습니다. 두려움이 처음 하는 일을 시도하는 것을 방해하여 능력이 없는 사람처럼 느껴질 뿐, 제 안에 충분히 해낼 힘이 있었던 것입니다. 그리고 빠르게 해치우려고 절차를 무시하고 힘으로 일을 대하면 잘 풀리지 않는다는 것을 배웠습니다. 얼추 느낌으로 이렇게 하면 되겠지 하고 덤벼들면 뜻대로 잘되지 않았던 것입니다. 커튼을 빨고 다시 원상태로 천장에 달면서 고리를 마구잡이로 끼우면 순서가 뒤엉켜 다시 처음부터 다시 해야 했습니다. 정확하게 순서를 파악하고 차분하게 하나씩 고리를 맞춰서 달면 오히려 서두른 때보다 빠르게 일을 처리할 수 있었습니다. 어제 새 비데를 설치하기 위해 헌 비데를 제거하는 일에서도 다시 깨달았습니다. 고정 나사를 빼야 했는데, 잘 빠지지 않아서 힘을 쓰느라 30분 이상 소요했습니다. 그런데 알고 보니 고정 나사는 힘으로 잡아 빼는 것이 아니라 변기 밑에 고정 장치를 풀기만 하면 되는 일이었습니다. 3초면 할 수 있었던 일을 앞뒤 가리지 않고 빨리 힘으로 해결하려고 노력하다가 600백 배나 더 올래 걸렸던 것입니다. (계산 맞나요?) 여러분도 처음 도전하는 일이 있나요? 그 일이 어렵게 느껴지나요? 제가 장담합니다. 여러분은 그 일을 충분히 잘 해낼 수 있습니다. 우리 안에 숨겨진 능력을 믿으시길 바랍니다. 다만, 두려워하지 말고 세상 선배들이 해왔던 방식을 찾아보고 차분하게 따라 해 보시기 바랍니다. 그럼 어떤 일도 우리는 해낼 수 있습니다. 원리와 논리만 알면 하지 못할 일은 아무것도 없습니다. 여러분의 새로운 도전을 진심으로 응원합니다.﻿

비데를 교체하다가

4월 4일 금요일 저녁엔 시즌5 첫 번째 모임을 가졌습니다. 시즌4부터 함께 모임을 만든 민영 님 덕분에 가장 고민이 많은 첫 모임을 여느 때보다 편안하게 시작할 수 있었습니다. (고맙습니다, 든든한 파트너 민영 님) 이번 모임이 편안했던 건 지난 시즌에서 함께 했던 멤버들이 새로운 시즌을 함께 이어가준 덕분입니다. 혜민 님과 윤정 님과 채영 님, 태희

트레바리 시즌5, 첫 번째 모임을 마치고 – 양보는 하더라고 포기할 수 없는 선에 대하여

4월 4일 금요일 저녁엔 <리서치 하는데요> 시즌5 첫 번째 모임을 가졌습니다. 시즌4부터 함께 모임을 만든 민영 님 덕분에 가장 고민이 많은 첫 모임을 여느 때보다 편안하게 시작할 수 있었습니다. (고맙습니다, 든든한 파트너 민영 님) 이번 모임이 편안했던 건 지난 시즌에서 함께 했던 멤버들이 새로운 시즌을 함께 이어가준 덕분입니다. 혜민 님과 윤정 님과 채영 님, 태희 님, 아름 님이 시즌4에서 또 호준 님과 현 님이 시즌3에 이어서 <리서치 하는데요>를 더 지적으로, 여전히 잔잔하지만 단단하게 만들어주셨습니다. 다섯 번째 시즌이 이어질 수 있도록 지난 모임을 함께 해준 멤버분들께 감사한 마음을 간직하며 이번 시즌 첫 모임을 회고합니다.

모임에서 함께 나눈 지적 대화의 쿠키들

1. 사용자는 각자 자기만의 방식으로 불편을 극복하고 그 불편을 극복한 순간 어떤 것은 더 이상 불편이 아닌게 된다.

식자재 주문 서비스를 만들 때 사장님들이 식당에서 주문하는 모습을 관찰하면서 발견한 것. 크게 인쇄한 종이를 코팅해서 보드마카로 당일 필요한 식자재를 적은 후 사진을 찍어서 카카오톡으로 전송하는 패턴이었다. 디지털화가 되어 있지 않아도 사용자는 자기만의 방법으로 최적화하고 있었다. 그렇다면 디지털 프로덕트가 해야 하는 것은 무엇일까? - 혜민 님의 이야기를 듣고 메모한 것

사용자는 "이렇게도 쓰는구나"를 단적으로 이해하기 쉬운 사례가 있습니다. 구글 검색창에 "따라올 수 있겠나?"를 검색하고 '겹홑낫표'를 복사해서 사용하는 사용자가 있습니다. 기호 이름이 어려운데 문장 안에서 참고한 자료의 출처를 밝힐 때 책 제목이나 신문이름 앞뒤에 사용하는 『』 기호의 이름입니다. 홑낫표(「」)는 소제목이나 예술 작품의 제목, 법률이나 규정을 나타낼 때 주로 사용하죠.

특수부호 입력하기 위해서 윈도우에서 한자키를 사용하시는 경우가 많습니다. 자음을 누르고 한자키를 누르는 방식입니다. 또는 네이버 스마트보드와 같은 도구에 자주 쓰는 문구로 추가해두기도 하죠. 가장 흥미로운 케이스는 트위터에서 본 것으로 '따라올 수 있겠나'입니다. 일단 구글에 "따라올 수 있겠나"를 검색해 보세요. 그럼 첫 번째 검색결과가 디시인사이드의 게시글인데, 검색결과 요약에 " 「 ────따라올 수 있겠나? 웃기고 자빠졌네」 "라는 내용이 나옵니다. 이걸 복사해서 붙여 넣고 가운데 텍스트는 필요한 내용을 바꾸는 방식입니다. 이 트윗은 @meemem_void 님이 올린 것인데, 조회수가 73만 회가 넘었습니다. 사용자는 자기만의 방식이 있고 리서처는 어떤 방식으로 사용하고 있는지 뿐만 아니라 그게 해결해야 하는 문제인지 판단해야 합니다. 단순한 불만이기나 학습해서 해소한 불편인 경우에는 문제가 아닐 수 있습니다.

2. "시간 많아?"라는 질문에 대한 답은 "실패할 시간도 없어 굳이 이렇게까지 하는 겁니다"

"굳이 이렇게까지 해야 하나?"라는 마음이 들면 지금 그럭저럭 잘하고 있다고 스스로를 위로해 줘도 괜찮습니다. 리서치를 잘하기 위해서, 정확하게 하기 위해서는 품이 들고 손과 발, 그리고 입이 바쁩니다. 질을 높이기 위해서 어느 정도의 양이 반드시 필요한 것이 리서치입니다.

때로는 "굳이 이렇게까지 해야 하나?"라는 마음이 들기 전에 누군가 "시간 많으세요?"라고 날이 선 말을 던지기도 합니다. 가치판단을 떠나서 더 나은 경험을 만들기 위해 애쓰는 과정을 공급자의 이해득실로 따질 때 쉽게 나오는 말입니다. 문제를 정의하는 일 자체가, 리서치를 통해 제품 조직에서 임팩트를 만드는 과정 자체가 누군가를 불편하게 하는 속성이 있기 때문입니다. 일정과 예산 안에서 출시를 늦춘다는 것은 누군가 책임을 져야 한다는 것이니까요. 그런데 리서치로 문제를 정의하는 건, 리서처가 자신의 역할을 증명하기 위해서일까요? 혹은 실패 확률을 줄이고 제품이 성공할 수 있도록 만들기 위해서일까요? 리서치는 실패할 확률을 줄이고, 제품이 고객에게 전달하는 가치를 더 높은 타율로 달성할 수 있게 만들기 위해 만드는 일입니다. 그 선한 의도를 전달하는 것까지가 리서처의 일입니다.

만약 그렇게 하고 있는데 조직 내 리서치를 요청하는 동료와 불편한 관계가 형성된다면 그것도 나쁘지 않습니다. 불편한 관계는 일에서 양보하더라도 포기할 수 없는 부분에 대해서 명확하게 커뮤니케이션하고 있다는 것일 수 있으니까요. "이럴 거면 뭐 하러 UT 해요?"라는 말을 들은 적이 있습니다. 동료는 UT를 해서 디자인을 수정하느라 출시 일정이 늦어진다는 것을 대표님께 이야기하기 어려웠을 겁니다. 그렇다고 UT를 해서 심각한 사용성 문제를 발견했고 해결이 되지 않았는데 그대로 출시한다는 것은 괜찮을까요? 결국 "UT를 하느라 디자인 수정이 거듭되고 때문에 출시가 지연되었으니 출시하면 무조건 잘 되어야 한다"라는 마음을 제게 그릇되게 표현했던 것으로 이해했습니다.

UT를 해서 사용성 문제를 검증하는 목적은 사용성을 확보한 상태로 제품을 출시하기 위해서였습니다. 그런데 사용성 만으로 제품이 사랑받지 않습니다. 고집스럽더라도 갈등을 피하지 않고 안 되는 것과 되는 것을 구분해야 합니다. 차라리 충분한 시간이 확보되지 않았을 때에는 빠르게 출시하고 실제 사용자 반응을 빠르게 보면서 Live UT를 통해 문제를 해결하거나 롤백하는 것이 효과적일 수 있습니다. 그럴 땐 거절하는 것까지 리서처의 일입니다.

3. 이 정도면 괜찮지 않아요?

"이 정도면 괜찮다" "당연하다", "쉽다", "직관적이다"라는 것은 상대적 기준입니다. 장애인 사용자가 OTT 스트리밍 서비스를 TV에서 사용할 때 평소 전혀 의식하지 못하는 것을 불편하게 받아들이는 것을 관찰했던 예지 님 이야기가 인상 깊었습니다. 키보드로 검색할 때 '전체 삭제' 버튼이 있는 것과 없는 것의 차이로 느끼는 불편함의 정도는 전혀 다를 수 있습니다. 하나의 버튼을 여러 번 눌러야 하는 것이 누군가에게는 매우 힘이 든 일입니다.

자판에서 'Q'자를 기준으로 왼쪽으로 끝까지 가서 한번 더 누르면 맨 오른쪽 자판으로 선택영역이 넘어갈 것이라고 예상했지만 막혔을 때, 누군가에게 삼킬 수 있는 불만이 누군가에게는 좌절이 될 수 있습니다. 놓치고 있는 사용자 그룹이 있는 것은 아닌지, 비즈니스 논리 앞에 사용자를 충분히 대변하고 있는지 조직 내에서 가장 예민하게 반응하는 것이 리서처의 일입니다.

https://redbusbagman.com/trevariseason51/

4월 4일 금요일 저녁엔 &lt;리서치 하는데요&gt; 시즌5 첫 번째 모임을 가졌습니다. 시즌4부터 함께 모임을 만든 민영 님 덕분에 가장 고민이 많은 첫 모임을 여느 때보다 편안하게 시작할 수 있었습니다. (고맙습니다, 든든한 파트너 민영 님) 이번 모임이 편안했던 건 지난 시즌에서 함께 했던 멤버들이 새로운 시즌을 함께 이어가준 덕분입니다. 혜민 님과 윤정 님과 채영 님, 태희 님, 아름 님이 시즌4에서 또 호준 님과 현 님이 시즌3에 이어서 &lt;리서치 하는데요&gt;를 더 지적으로, 여전히 잔잔하지만 단단하게 만들어주셨습니다. 다섯 번째 시즌이 이어질 수 있도록 지난 모임을 함께 해준 멤버분들께 감사한 마음을 간직하며 이번 시즌 첫 모임을 회고합니다. 모임에서 함께 나눈 지적 대화의 쿠키들 1. 사용자는 각자 자기만의 방식으로 불편을 극복하고 그 불편을 극복한 순간 어떤 것은 더 이상 불편이 아닌게 된다. 식자재 주문 서비스를 만들 때 사장님들이 식당에서 주문하는 모습을 관찰하면서 발견한 것. 크게 인쇄한 종이를 코팅해서 보드마카로 당일 필요한 식자재를 적은 후 사진을 찍어서 카카오톡으로 전송하는 패턴이었다. 디지털화가 되어 있지 않아도 사용자는 자기만의 방법으로 최적화하고 있었다. 그렇다면 디지털 프로덕트가 해야 하는 것은 무엇일까? - 혜민 님의 이야기를 듣고 메모한 것 사용자는 "이렇게도 쓰는구나"를 단적으로 이해하기 쉬운 사례가 있습니다. 구글 검색창에 "따라올 수 있겠나?"를 검색하고 '겹홑낫표'를 복사해서 사용하는 사용자가 있습니다. 기호 이름이 어려운데 문장 안에서 참고한 자료의 출처를 밝힐 때 책 제목이나 신문이름 앞뒤에 사용하는 『』 기호의 이름입니다. 홑낫표(「」)는 소제목이나 예술 작품의 제목, 법률이나 규정을 나타낼 때 주로 사용하죠. 특수부호 입력하기 위해서 윈도우에서 한자키를 사용하시는 경우가 많습니다. 자음을 누르고 한자키를 누르는 방식입니다. 또는 네이버 스마트보드와 같은 도구에 자주 쓰는 문구로 추가해두기도 하죠. 가장 흥미로운 케이스는 트위터에서 본 것으로 '따라올 수 있겠나'입니다. 일단 구글에 "따라올 수 있겠나"를 검색해 보세요. 그럼 첫 번째 검색결과가 디시인사이드의 게시글인데, 검색결과 요약에 " 「 ────따라올 수 있겠나? 웃기고 자빠졌네」 "라는 내용이 나옵니다. 이걸 복사해서 붙여 넣고 가운데 텍스트는 필요한 내용을 바꾸는 방식입니다. 이 트윗은 @meemem_void 님이 올린 것인데, 조회수가 73만 회가 넘었습니다. 사용자는 자기만의 방식이 있고 리서처는 어떤 방식으로 사용하고 있는지 뿐만 아니라 그게 해결해야 하는 문제인지 판단해야 합니다. 단순한 불만이기나 학습해서 해소한 불편인 경우에는 문제가 아닐 수 있습니다. 2. "시간 많아?"라는 질문에 대한 답은 "실패할 시간도 없어 굳이 이렇게까지 하는 겁니다" "굳이 이렇게까지 해야 하나?"라는 마음이 들면 지금 그럭저럭 잘하고 있다고 스스로를 위로해 줘도 괜찮습니다. 리서치를 잘하기 위해서, 정확하게 하기 위해서는 품이 들고 손과 발, 그리고 입이 바쁩니다. 질을 높이기 위해서 어느 정도의 양이 반드시 필요한 것이 리서치입니다. 때로는 "굳이 이렇게까지 해야 하나?"라는 마음이 들기 전에 누군가 "시간 많으세요?"라고 날이 선 말을 던지기도 합니다. 가치판단을 떠나서 더 나은 경험을 만들기 위해 애쓰는 과정을 공급자의 이해득실로 따질 때 쉽게 나오는 말입니다. 문제를 정의하는 일 자체가, 리서치를 통해 제품 조직에서 임팩트를 만드는 과정 자체가 누군가를 불편하게 하는 속성이 있기 때문입니다. 일정과 예산 안에서 출시를 늦춘다는 것은 누군가 책임을 져야 한다는 것이니까요. 그런데 리서치로 문제를 정의하는 건, 리서처가 자신의 역할을 증명하기 위해서일까요? 혹은 실패 확률을 줄이고 제품이 성공할 수 있도록 만들기 위해서일까요? 리서치는 실패할 확률을 줄이고, 제품이 고객에게 전달하는 가치를 더 높은 타율로 달성할 수 있게 만들기 위해 만드는 일입니다. 그 선한 의도를 전달하는 것까지가 리서처의 일입니다. 만약 그렇게 하고 있는데 조직 내 리서치를 요청하는 동료와 불편한 관계가 형성된다면 그것도 나쁘지 않습니다. 불편한 관계는 일에서 양보하더라도 포기할 수 없는 부분에 대해서 명확하게 커뮤니케이션하고 있다는 것일 수 있으니까요. "이럴 거면 뭐 하러 UT 해요?"라는 말을 들은 적이 있습니다. 동료는 UT를 해서 디자인을 수정하느라 출시 일정이 늦어진다는 것을 대표님께 이야기하기 어려웠을 겁니다. 그렇다고 UT를 해서 심각한 사용성 문제를 발견했고 해결이 되지 않았는데 그대로 출시한다는 것은 괜찮을까요? 결국 "UT를 하느라 디자인 수정이 거듭되고 때문에 출시가 지연되었으니 출시하면 무조건 잘 되어야 한다"라는 마음을 제게 그릇되게 표현했던 것으로 이해했습니다. UT를 해서 사용성 문제를 검증하는 목적은 사용성을 확보한 상태로 제품을 출시하기 위해서였습니다. 그런데 사용성 만으로 제품이 사랑받지 않습니다. 고집스럽더라도 갈등을 피하지 않고 안 되는 것과 되는 것을 구분해야 합니다. 차라리 충분한 시간이 확보되지 않았을 때에는 빠르게 출시하고 실제 사용자 반응을 빠르게 보면서 Live UT를 통해 문제를 해결하거나 롤백하는 것이 효과적일 수 있습니다. 그럴 땐 거절하는 것까지 리서처의 일입니다. 3. 이 정도면 괜찮지 않아요? "이 정도면 괜찮다" "당연하다", "쉽다", "직관적이다"라는 것은 상대적 기준입니다. 장애인 사용자가 OTT 스트리밍 서비스를 TV에서 사용할 때 평소 전혀 의식하지 못하는 것을 불편하게 받아들이는 것을 관찰했던 예지 님 이야기가 인상 깊었습니다. 키보드로 검색할 때 '전체 삭제' 버튼이 있는 것과 없는 것의 차이로 느끼는 불편함의 정도는 전혀 다를 수 있습니다. 하나의 버튼을 여러 번 눌러야 하는 것이 누군가에게는 매우 힘이 든 일입니다. 자판에서 'Q'자를 기준으로 왼쪽으로 끝까지 가서 한번 더 누르면 맨 오른쪽 자판으로 선택영역이 넘어갈 것이라고 예상했지만 막혔을 때, 누군가에게 삼킬 수 있는 불만이 누군가에게는 좌절이 될 수 있습니다. 놓치고 있는 사용자 그룹이 있는 것은 아닌지, 비즈니스 논리 앞에 사용자를 충분히 대변하고 있는지 조직 내에서 가장 예민하게 반응하는 것이 리서처의 일입니다. https://redbusbagman.com/trevariseason51/

REDBUSBAGMAN | 빨간색 버스에 가방을 메고 탑니다

《트레바리 시즌5, 첫 번째 모임을 마치고》

In this paper, we revisit one of the simplest problems in data structures: the task of inserting elements into an open-addressed hash table so that elements can later be retrieved with as few probes as possible. We show that, even without reordering elements over time, it is possible to construct a hash table that achieves far better expected search complexities (both amortized and worst-case) than were previously thought possible. Along the way, we disprove the central conjecture left by Yao in his seminal paper ``Uniform Hashing is Optimal''. All of our results come with matching lower bounds.

Optimal Bounds for Open Addressing Without Reordering

📰 대학생이 40년만에 해시테이블의 성능 향상을 이뤄냈다고

해시테이블 알고리즘은 워낙 오래된 연구라서 아무도 그 이상 최적화하기 어렵다고 생각했는데, Andrew Krapivin이라는 학부생이 그 틀을 깨고 알고리즘을 발명했다는 것이 재미난 포인트입니다.

역시 아직 미해결 문제는 많고, 상식이라는 고정관념에 쩌들지 않은 ㅎㅎ 새로운 세대만이 해결할 수 있는 문제도 많지 않나 싶네요.

논문: https://arxiv.org/abs/2501.02305

기사: https://www.wired.com/story/undergraduate-upends-a-40-year-old-data-science-conjecture/

📰 대학생이 40년만에 해시테이블의 성능 향상을 이뤄냈다고 해시테이블 알고리즘은 워낙 오래된 연구라서 아무도 그 이상 최적화하기 어렵다고 생각했는데, Andrew Krapivin이라는 학부생이 그 틀을 깨고 알고리즘을 발명했다는 것이 재미난 포인트입니다. 역시 아직 미해결 문제는 많고, 상식이라는 고정관념에 쩌들지 않은 ㅎㅎ 새로운 세대만이 해결할 수 있는 문제도 많지 않나 싶네요. 논문: https://arxiv.org/abs/2501.02305 기사: https://www.wired.com/story/undergraduate-upends-a-40-year-old-data-science-conjecture/

arXiv.org

📰 대학생이 40년만에 해시테이블의 성능 향상을 이뤄냈다고

해시

Self-hosted news, content, updates, launches, events, and more

selfh.st - Self-hosted content and software

중앙화된 서비스에 지친 분들을 위한 셀프 호스팅 솔루션 총정리입니다!
1년 이상 안정적으로 운영해본 경험을 바탕으로 정리했다고 해요!

🐳 컨테이너 런타임:
 * 초보자는 Docker로 시작하세요 (풍부한 문서+커뮤니티)
 * 보안 중시하면 Podman (루트리스 구조)
 * 도전정신 있다면 Kubernetes (복잡하지만 학습 가치↑)

🖥️ 웹 관리툴:
 * Portainer: 안정적이고 직관적인 관리 도구
 * Dockge: 간단하고 가벼운 신규 솔루션

🔒 리버스프록시/VPN:
 * Pangolin: "셀프 호스팅용 Cloudflare" (강추!)
 * NPM: 쉬운 웹UI, 불안정한 면도 있음
 * NetBird: WireGuard 기반 자동 VPN 구성

더 많은 셀프호스팅 솔루션은
awesome-selfhosted
레포나 Selfh.st 참고 하세요!

https://news.hada.io/topic?id=20108

중앙화된 서비스에 지친 분들을 위한 셀프 호스팅 솔루션 총정리입니다! 1년 이상 안정적으로 운영해본 경험을 바탕으로 정리했다고 해요! 🐳 컨테이너 런타임:<ul ><li>초보자는 Docker로 시작하세요 (풍부한 문서+커뮤니티)</li><li>보안 중시하면 Podman (루트리스 구조)</li><li>도전정신 있다면 Kubernetes (복잡하지만 학습 가치↑)</li></ul> 🖥️ 웹 관리툴:<ul ><li>Portainer: 안정적이고 직관적인 관리 도구</li><li>Dockge: 간단하고 가벼운 신규 솔루션</li></ul> 🔒 리버스프록시/VPN:<ul ><li>Pangolin: "셀프 호스팅용 Cloudflare" (강추!)</li><li>NPM: 쉬운 웹UI, 불안정한 면도 있음</li><li>NetBird: WireGuard 기반 자동 VPN 구성</li></ul> 더 많은 셀프호스팅 솔루션은 <code >awesome-selfhosted</code> 레포나 Selfh.st 참고 하세요! https://news.hada.io/topic?id=20108

selfh.st

🚀 [2025 셀프 호스팅 가이드]

코딩 인터뷰를 하던 중 지원자로부터 AI를 써도 되겠냐는 질문을 받았습니다. 인터넷 검색을 해도 되냐고 물어보는 지원자는 종종 만나는데, AI를 써도 되느냐는 질문은 처음 받아봐서 좀 당황스럽더군요. 어떤 용도로 AI를 사용하시려는지 물어보았고, 익숙치 않은 프로그래밍 언어의 사용법을 찾기 위해서라는 답변을 들었습니다. 지원자가 대학생이어서 특정 언어를 능숙하게 다룰 거라는 기대는 없었습니다. 그래서 화면을 공유하는 전제 하에 AI를 사용하도록 허락하였죠.

지원자는 ChatGPT를 열고 해당 언어에서 어떻게 힙(heap) 자료구조를 사용하는지 물어보았습니다. 언제나 그렇듯 ChatGPT는 어떻게 힙을 생성하고, 원소를 추가/삭제하는지에 대해서 아주 상세하게 적어주기 시작했습니다. 그러나 너무나 친절한 나머지 ChatGPT는 힙을 활용할 수 있는 대표적인 사례까지 나열해줬는데, 그 중에 인터뷰에서 출제한 문제가 포함되어 있었습니다. (Co-op 채용이라서 아주 기초 수준의 문제였거든요 😅)

당황한 기색이 역력한 지원자는 급하게 화면을 전환하였습니다. 하지만 그 이후부터는 계속해서 신경이 쓰이는지 인터뷰에 집중을 하지 못하는 모습이었습니다. 결국은 시간 내에 답안을 완성하지 못했고, 본인이 작성한 코드에 대해서도 명확히 설명하지 못했습니다. 아무래도 스스로 망했다고 생각하고 이미 인터뷰를 포기한 느낌을 받았습니다. 첫 번째 문제는 잘 푸셨기 때문에, 오히려 두 번째 문제에서 AI를 쓰지 않으셨다면 합격하실 수도 있으셨을 것 같아서 참 안타까웠습니다.

인터뷰가 끝나고 많은 생각이 들었습니다. 이미 AI가 대학생들의 삶에 깊숙히 스며든 것 같고, 현직 개발자들도 AI의 도움을 받아 업무를 수행하고 있는 상황이죠. 코딩 인터뷰라고 해서 AI를 쓰지 못하게 할 이유가 있을까요? 과연 저처럼 불완전한 인간이 면접관으로서 AI로 인해 거의 신급의 지능을 갖게 된 지원자들을 평가할 수 있을까요? 어디까지가 AI의 버프이고 어디까지가 지원자의 순수한 능력인지 어떻게 판단할 수 있을까요?

코딩 인터뷰를 하던 중 지원자로부터 AI를 써도 되겠냐는 질문을 받았습니다. 인터넷 검색을 해도 되냐고 물어보는 지원자는 종종 만나는데, AI를 써도 되느냐는 질문은 처음 받아봐서 좀 당황스럽더군요. 어떤 용도로 AI를 사용하시려는지 물어보았고, 익숙치 않은 프로그래밍 언어의 사용법을 찾기 위해서라는 답변을 들었습니다. 지원자가 대학생이어서 특정 언어를 능숙하게 다룰 거라는 기대는 없었습니다. 그래서 화면을 공유하는 전제 하에 AI를 사용하도록 허락하였죠. 지원자는 ChatGPT를 열고 해당 언어에서 어떻게 힙(heap) 자료구조를 사용하는지 물어보았습니다. 언제나 그렇듯 ChatGPT는 어떻게 힙을 생성하고, 원소를 추가/삭제하는지에 대해서 아주 상세하게 적어주기 시작했습니다. 그러나 너무나 친절한 나머지 ChatGPT는 힙을 활용할 수 있는 대표적인 사례까지 나열해줬는데, 그 중에 인터뷰에서 출제한 문제가 포함되어 있었습니다. (Co-op 채용이라서 아주 기초 수준의 문제였거든요 😅) 당황한 기색이 역력한 지원자는 급하게 화면을 전환하였습니다. 하지만 그 이후부터는 계속해서 신경이 쓰이는지 인터뷰에 집중을 하지 못하는 모습이었습니다. 결국은 시간 내에 답안을 완성하지 못했고, 본인이 작성한 코드에 대해서도 명확히 설명하지 못했습니다. 아무래도 스스로 망했다고 생각하고 이미 인터뷰를 포기한 느낌을 받았습니다. 첫 번째 문제는 잘 푸셨기 때문에, 오히려 두 번째 문제에서 AI를 쓰지 않으셨다면 합격하실 수도 있으셨을 것 같아서 참 안타까웠습니다. 인터뷰가 끝나고 많은 생각이 들었습니다. 이미 AI가 대학생들의 삶에 깊숙히 스며든 것 같고, 현직 개발자들도 AI의 도움을 받아 업무를 수행하고 있는 상황이죠. 코딩 인터뷰라고 해서 AI를 쓰지 못하게 할 이유가 있을까요? 과연 저처럼 불완전한 인간이 면접관으로서 AI로 인해 거의 신급의 지능을 갖게 된 지원자들을 평가할 수 있을까요? 어디까지가 AI의 버프이고 어디까지가 지원자의 순수한 능력인지 어떻게 판단할 수 있을까요?

코딩 인터뷰 중 AI를 사용해도 될까요...? 🤔

Java에서 병렬 처리나 비동기 작업을 구현할 때 Thread를 직접 생성해 사용하는 방식은 더 이상 일반적이지 않습니다. 요즘 Java에서는 ExecutorService를 사용하여 스레드 풀(Thread Pool)을 효율적으로 관리하는 것이 표준입니다. 특히 Executors 클래스에서 제공하는 팩토리 메서드들을 활용하면 다양한 유형의 스레드 풀을 간편하게 생성할 수 있습니다.이번 글에서는 Executors가 제공하는 대표적인 스레드 풀 4종류를 살펴보고, 각각의 사용 시나리오와 주의할 점을 예제 중심으로 정리해보겠습니다. newFixedThreadPool(int nThreads)이 메서드는 정해진 개수만큼의 스레드를 미리 생성하고, 그 스레드들이 재사용되며 작업을 처리합니다. 더 많은 작업이 들어오면..

Java의 ExecutorService 스레드 풀 정복하기

이번 글에서는 Executors가 제공하는 대표적인 스레드 풀 4종류를 살펴보고, 각각의 사용 시나리오와 주의할 점을 예제 중심으로 정리해보겠습니다.
 
newFixedThreadPool(int nThreads)
이 메서드는 정해진 개수만큼의 스레드를 미리 생성하고, 그 스레드들이 재사용되며 작업을 처리합니다. 더 많은 작업이 들어오면 내부 큐에 쌓이고, 기존 스레드들이 작업을 처리하면 순차적으로 소비됩니다.
ExecutorService executor = Executors.newFixedThreadPool(4); 

✅ 사용 시점
 * 처리할 작업량은 많지만, 동시에 처리해야 하는 작업 수를 제한하고 싶은 경우
 * CPU 자원을 고르게 사용하며, 안정적인 처리량을 원하는 경우
🧪 예시
for (int i = 0; i < 10; i++) {
 final int taskId = i;
 executor.submit(() -> {
 System.out.println("Task " + taskId + " executed by " + Thread.currentThread().getName());
 Thread.sleep(1000); // 모의 작업
 });
}

⚠️ 주의
 * 과도하게 큰 작업 큐가 쌓일 수 있음 → 메모리 사용량 증가
 * 스레드 수는 CPU 코어 수나 애플리케이션 특성에 맞게 설정해야 함
 
newCachedThreadPool()
이 스레드 풀은 요청이 많으면 새로운 스레드를 계속 생성하고, 특정 기간 동안 사용되지 않으면 제거합니다. 캐시된 스레드를 재사용하므로 빠르고 유연합니다.
ExecutorService executor = Executors.newCachedThreadPool();

✅ 사용 시점
 * 작업이 짧고 빠르게 끝나는 I/O 중심의 작업일 때
 * 짧은 burst가 자주 발생하는 상황에서 유용
🧪 예시
for (int i = 0; i < 100; i++) {
 final int taskId = i;
 executor.submit(() -> {
 System.out.println("Task " + taskId + " executed by " + Thread.currentThread().getName());
 });
} 

⚠️ 주의
 * 요청이 많을 경우 스레드가 무제한으로 늘어나 과부하가 될 수 있음
 → 실제 운영에서는 ThreadPoolExecutor로 커스텀 제어 필요
 
newSingleThreadExecutor()
항상 단 하나의 스레드만 사용하여 작업을 처리합니다. 작업은 FIFO 순서로 실행되며, 순서가 중요한 로직에 적합합니다.
ExecutorService executor = Executors.newSingleThreadExecutor();

✅ 사용 시점
 * 작업 순서가 중요할 때
 * 하나의 리소스(DB, 파일 등)에 대해 직렬화된 접근이 필요할 때
🧪 예시
for (int i = 0; i < 5; i++) {
 final int taskId = i;
 executor.submit(() -> {
 System.out.println("Processing task " + taskId);
 Thread.sleep(500);
 });
} 

⚠️ 주의
 * 하나의 스레드에 의존하기 때문에 처리량은 낮음
 * 스레드가 죽으면 새로운 스레드로 대체되므로 중단되지는 않음
 
newScheduledThreadPoool(int corePoolSize)
지연 실행(delay)이나 주기적인 작업(interval) 실행에 특화된 스레드 풀입니다. ScheduledExecutorService를 반환하며, Java의 타이머 역할도 수행할 수 있습니다.
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);

✅ 사용 시점
 * 주기적인 백업 작업, 모니터링, 알림 전송 등
 * 특정 시간 후 작업을 실행하고 싶을 때
🧪 예시
scheduler.scheduleAtFixedRate(() -> {
 System.out.println("Heartbeat sent by " + Thread.currentThread().getName());
}, 1, 5, TimeUnit.SECONDS); // 1초 후 시작, 5초마다 반복

⚠️ 주의
 * 작업이 너무 오래 걸리면 다음 주기 작업이 지연될 수 있음
 → 처리 시간이 일정하지 않다면 scheduleWithFixedDelay()를 고려
 
 
🧠 마무리
Java에서 Executors 팩토리 메서드는 다양한 형태의 스레드 풀을 간단히 생성할 수 있게 도와줍니다. 하지만, 운영 환경에서는 ThreadPoolExecutor를 직접 생성하여 작업 큐, 최대 스레드 수, 거부 정책 등을 세밀하게 조절하는 것이 더욱 안전하고 확장성 있는 선택입니다.

이번 글에서는 Executors가 제공하는 대표적인 스레드 풀 4종류를 살펴보고, 각각의 사용 시나리오와 주의할 점을 예제 중심으로 정리해보겠습니다.&nbsp;newFixedThreadPool(int nThreads)이 메서드는 정해진 개수만큼의 스레드를 미리 생성하고, 그 스레드들이 재사용되며 작업을 처리합니다. 더 많은 작업이 들어오면 내부 큐에 쌓이고, 기존 스레드들이 작업을 처리하면 순차적으로 소비됩니다.<pre ><code class="language-java">ExecutorService executor = Executors.newFixedThreadPool(4);&nbsp;</code></pre>✅ 사용 시점<ul ><li>처리할 작업량은 많지만, 동시에 처리해야 하는 작업 수를 제한하고 싶은 경우</li><li>CPU 자원을 고르게 사용하며, 안정적인 처리량을 원하는 경우</li></ul>🧪 예시<pre ><code class="language-java">for (int i = 0; i &lt; 10; i++) {
 final int taskId = i;
 executor.submit(() -&gt; {
 System.out.println("Task " + taskId + " executed by " + Thread.currentThread().getName());
 Thread.sleep(1000); // 모의 작업
 });
}</code></pre>⚠️ 주의<ul ><li>과도하게 큰 작업 큐가 쌓일 수 있음 → 메모리 사용량 증가</li><li>스레드 수는 CPU 코어 수나 애플리케이션 특성에 맞게 설정해야 함</li></ul>&nbsp;newCachedThreadPool()이 스레드 풀은 요청이 많으면 새로운 스레드를 계속 생성하고, 특정 기간&nbsp;동안 사용되지 않으면 제거합니다. 캐시된 스레드를 재사용하므로 빠르고 유연합니다.<pre ><code class="language-java">ExecutorService executor = Executors.newCachedThreadPool();</code></pre>✅ 사용 시점<ul ><li>작업이 짧고 빠르게 끝나는 I/O 중심의 작업일 때</li><li>짧은 burst가 자주 발생하는 상황에서 유용</li></ul>🧪 예시<pre ><code class="language-java">for (int i = 0; i &lt; 100; i++) {
 final int taskId = i;
 executor.submit(() -&gt; {
 System.out.println("Task " + taskId + " executed by " + Thread.currentThread().getName());
 });
}&nbsp;</code></pre>⚠️ 주의<ul ><li>요청이 많을 경우 스레드가 무제한으로 늘어나 과부하가 될 수 있음 → 실제 운영에서는 ThreadPoolExecutor로 커스텀 제어 필요</li></ul>&nbsp;newSingleThreadExecutor()항상 단 하나의 스레드만 사용하여 작업을 처리합니다. 작업은 FIFO 순서로 실행되며, 순서가 중요한 로직에 적합합니다.<pre ><code class="language-java">ExecutorService executor = Executors.newSingleThreadExecutor();</code></pre>✅ 사용 시점<ul ><li>작업 순서가 중요할 때</li><li>하나의 리소스(DB, 파일 등)에 대해 직렬화된 접근이 필요할 때</li></ul>🧪 예시<pre ><code class="language-java">for (int i = 0; i &lt; 5; i++) {
 final int taskId = i;
 executor.submit(() -&gt; {
 System.out.println("Processing task " + taskId);
 Thread.sleep(500);
 });
}&nbsp;</code></pre>⚠️ 주의<ul ><li>하나의 스레드에 의존하기 때문에 처리량은 낮음</li><li>스레드가 죽으면 새로운 스레드로 대체되므로 중단되지는 않음</li></ul>&nbsp;newScheduledThreadPoool(int corePoolSize)지연 실행(delay)이나 주기적인 작업(interval) 실행에 특화된 스레드 풀입니다. ScheduledExecutorService를 반환하며, Java의 타이머 역할도 수행할 수 있습니다.<pre ><code class="language-java">ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);</code></pre>✅ 사용 시점<ul ><li>주기적인 백업 작업, 모니터링, 알림 전송 등</li><li>특정 시간 후 작업을 실행하고 싶을 때</li></ul>🧪 예시<pre ><code class="language-java">scheduler.scheduleAtFixedRate(() -&gt; {
 System.out.println("Heartbeat sent by " + Thread.currentThread().getName());
}, 1, 5, TimeUnit.SECONDS); // 1초 후 시작, 5초마다 반복</code></pre>⚠️ 주의<ul ><li>작업이 너무 오래 걸리면 다음 주기 작업이 지연될 수 있음 → 처리 시간이 일정하지 않다면 scheduleWithFixedDelay()를 고려</li></ul>&nbsp;&nbsp;🧠 마무리Java에서 Executors 팩토리 메서드는 다양한 형태의 스레드 풀을 간단히 생성할 수 있게 도와줍니다. 하지만, 운영 환경에서는 ThreadPoolExecutor를 직접 생성하여 작업 큐, 최대 스레드 수, 거부 정책 등을 세밀하게 조절하는 것이 더욱 안전하고 확장성 있는 선택입니다.

덕토피아

🕊️ Java의 ExecutorService 스레드 풀 정복하기

누구나 쉽게 이해할 수 있는 MCP 가이드 : AI 에이전트와 도구 연동의 새로운 표준

이 자료는 AI 에이전트가 Google Calendar, Salesforce와 같은 다양한 외부 도구(API)를 사용하는 데 어려움을 겪는 현재의 문제를 지적합니다. 이를 해결하기 위한 새로운 표준 프로토콜인 MCP(Model Context Protocol)를 소개하며, MCP가 어떻게 AI 에이전트와 도구 간의 '공통 언어' 역할을 하여 상호작용을 원활하게 하는지 설명합니다. 또한, 개발자와 SaaS 기업이 MCP 생태계에 참여하여 더 강력하고 확장 가능한 AI 에이전트를 구축하는 방법을 안내합니다.

(참고) 가이드 전체 내용은 Gemini 2.5 Pro로 작성되었으며, 이미지 정리본은 GPT-4o 를 이용하여 생성하였습니다.

======================================
📘 1. 왜 에이전트에게 새로운 표준이 필요한가 – MCP 소개
======================================

🚀 미래는 에이전트 중심입니다 (The Future Is Agentic)
ChatGPT 시대를 맞아, 우리 모두는 AI가 얼마나 강력할 수 있는지 엿볼 수 있었습니다. 하지만 진정한 생산성은 단순히 AI와 대화하는 것에서 오는 것이 아니라, AI가 우리를 위해 실제로 일을 처리할 수 있을 때 발휘됩니다.
바로 이 지점에서 에이전트가 필요합니다.

에이전트는 단순한 챗봇이 아닙니다. 회의 예약, 보고서 작성, 데이터 분석과 같이 실제 도구(Google Calendar, Salesforce, Notion 등)를 사용하여 행동을 취하는 AI입니다.
하지만 여기에 문제가 있습니다.

❗️ 오늘날의 에이전트는 여전히 제한적입니다.
AI에게 이렇게 요청한다고 상상해 보세요.

“이번 주 나의 모든 1:1 미팅을 찾아서, 논의 내용을 요약하고, 후속 이메일 초안을 작성해 줄 수 있니?”
오늘날 대부분의 AI 에이전트는 아마 멈춰버릴 것입니다.
왜일까요? 그들이 사용하는 도구, 즉 여러 서비스의 API들이 마치 수백 개의 다른 방언처럼 제각각이기 때문입니다.

모든 도구 (Tools) 는 다음을 가지고 있습니다.

- 자체 인증 규칙
- 고유한 데이터 형식
- 다른 기능 및 엔드포인트
개발자들은 모든 도구에 대해 맞춤 코드를 작성해야 하는 문제를 당면하게 됩니다. 이는 느리고, 불안정하며, 확장 가능하지 않습니다.

🧩 빠진 조각: 도구를 위한 공통 언어
만약 이 모든 도구들이 AI 에이전트와 소통할 수 있는 표준적인 방법이 있다면 어떨까요?
마치 HTML이 웹을 표준화하고, REST가 API를 표준화했듯이 이제 AI 에이전트를 위한 표준이 필요합니다.

이것이 바로 MCP (Model Context Protocol)입니다.

AI 에이전트가 실제 도구를 쉽게 이해하고 상호작용할 수 있도록 설계된 새로운 프로토콜입니다.
시작해 봅시다.

============================
📘 2. MCP란 무엇이며 어떻게 작동하는가?
============================
🧠 큰 그림부터 시작해 봅시다.
MCP (Model Context Protocol)는 AI 에이전트(LLM 기반)와 그들이 사용해야 하는 도구(Google Calendar, Salesforce, Notion 등) 사이에서 번역가 역할을 하는 새로운 표준입니다.

MCP를 에이전트가 다음을 이해하는 데 도움이 되는 "만능 리모컨"이라고 생각하세요.

- 어떤 도구를 사용할 수 있는지
- 그 도구들이 무엇을 할 수 있는지
- 어떻게 안전하고 효율적으로 사용할 수 있는지

🔍 주요 개념

- MCP 클라이언트: LLM을 사용하는 AI 에이전트 또는 앱입니다. 다음과 같은 요청을 보냅니다:
ㄴ “이 도구는 무엇을 할 수 있나요?”
ㄴ “이 함수를 실행해 주세요.”

- MCP 서버: SaaS 도구와의 다리 역할을 합니다. 다음을 설명합니다:
ㄴ 사용 가능한 기능 (예: "회의 생성", "노트 가져오기")
ㄴ 관련 데이터를 일관된 형식으로
ㄴ LLM이 이해할 수 있는 방식으로 지침 제공

- 컨텍스트 스키마: 도구의 기능을 LLM이 읽을 수 있도록 구조화되고 통합된 형식입니다. 마치 모든 도구를 쉽게 탐색할 수 있는 API 플레이그라운드로 바꾸는 것과 같습니다.

🔁 이것이 왜 중요한가
- MCP가 없다면: AI 에이전트는 모든 도구를 사용하기 위해 수작업으로 코딩해야 합니다 = 느리고 비용이 많이 듭니다.
- MCP가 있다면: 도구는 에이전트에게 플러그 앤 플레이 방식이 됩니다 = 빠르고 확장 가능합니다.

✅ 실제 예시
에이전트가 다음 작업을 수행하기를 원하십니까?

“Asana에서 모든 높은 우선순위 작업을 찾고, 프로젝트 상태를 요약하고, 팀에 알림 보내기”

MCP를 사용하면,
1. Asana MCP 서버가 그 기능을 설명합니다 (list_projects, get_tasks 등).
2. 에이전트는 이러한 작업을 탐색, 호출 및 결합할 수 있습니다.
3. 그 결과 맞춤 코드 없이 완전히 자동화된 워크플로우가 가능해집니다.

=================================
📘 3. 도구가 어떻게 에이전트의 능력을 결정하는가
=================================

🛠 모든 도구가 동일하지는 않습니다
인간 조수가 일을 처리하기 위해 적절한 기술 세트가 필요한 것처럼,
AI 에이전트의 성능은 사용할 수 있는 도구에 따라 달라집니다.

도구에는 두 가지 주요 유형이 있습니다.

1️⃣ 다기능 도구 (Multi-Function Tools) : 하나의 도구, 여러 작업 – 스위스 아미 나이프처럼
이 도구들은 여러 관련 작업을 하나의 강력한 인터페이스로 묶습니다.
단일 단계가 아닌 전체 워크플로우를 수행하도록 설계되었습니다.

🧠 예시
다기능 도구를 사용하는 Calendar Agent는 다음을 처리할 수 있습니다.
- 모든 미팅 찾기 (유형별 필터링 = 1:1)
- 메타데이터 추출 (제목, 참석자, 시간)
- 미팅 노트 읽기
- 주간 요약 생성
이 모든 것을 한 번에 처리합니다 – 5개의 다른 도구를 호출할 필요가 없습니다.

📌 중요한 이유
도구 수가 적을수록 = 오케스트레이션이 단순해짐 = 더 빠르고 스마트한 에이전트.

2️⃣ 다중 도구 에이전트 (Multi-Tool Agents) - 함께 작동하는 에이전트 – 전문가 팀처럼
때로는 단일 도구만으로는 모든 것을 할 수 없습니다.
대신, 마치 팀 내의 사람들처럼 각기 다른 도구를 사용하는 에이전트들이 협업합니다.

🧠 예시
목표: 주요 고객에게 맞춤형 이메일 캠페인 보내기.
🧑‍💼 에이전트 1: Salesforce에서 고객 데이터 가져오기
📊 에이전트 2: Google Sheets에서 데이터 분석하기
📬 에이전트 3: Mailchimp를 통해 이메일 보내기
이를 에이전트 시스템(System of Agents) 또는 MAS (Multi-Agent System)라고 합니다.

📌 중요한 이유
에이전트는 강점을 결합하고 더 넓은 범위를 커버할 수 있습니다 – 마치 회사의 마이크로서비스처럼.

🤖 왜 ChatGPT만으로는 충분하지 않은가
오늘날 대부분의 맞춤형 GPT는 너무 단순합니다

- 제한된 작업
- 메모리 없음
- 다른 에이전트와 협업 불가
- "단일 도구" 사일로에 갇혀 있음

이것이 바로 AutoGen, CrewAI, LangGraph와 같은 강력한 프레임워크가 등장한 이유입니다 – 다기능 및 다중 에이전트 기능을 잠금 해제하기 위해.

🧭 도구 = 에이전트 뒤의 진정한 엔진
단순히 어떤 LLM을 사용하는지에 대한 문제가 아닙니다.
어떤 도구를 제공하고, 그것들이 어떻게 연결되어 있는지에 대한 문제입니다.

=========================
📘 4. MCP의 현실적인 과제와 한계점
=========================

MCP는 AI 에이전트와 도구 연동의 방식을 혁신할 잠재력을 지니고 있지만, 새로운 표준으로서 현실적인 과제와 잠재적 한계점 또한 고려해야 합니다.

😫 넘어야 할 현실적인 장벽들
MCP가 이상적인 솔루션처럼 보일 수 있지만, 성공적인 정착과 확산을 위해서는 다음과 같은 현실적인 문제들을 해결해야 합니다.

느린 채택 속도 (Slow Adoption Rate)
- 가장 큰 허들: 새로운 표준의 성공은 얼마나 많은 플레이어가 참여하느냐에 달려있습니다. SaaS 기업들이 MCP 서버 구축에 투자하고, 에이전트 개발자들이 이를 적극적으로 사용해야만 생태계가 활성화됩니다. 초기에는 '닭과 달걀' 문제에 직면할 수 있습니다.
- 모든 도구 제공자가 표준화된 단일 인터페이스를 선호하지 않을 수 있으며, 자체 API 생태계를 강화하는 것을 우선시할 수 있습니다.

구현 및 유지보수의 복잡성 (Complexity of Implementation & Maintenance)
- 서버 측 부담: MCP가 에이전트 클라이언트 개발을 단순화할 수 있지만, SaaS 도구 제공자 입장에서는 자사의 복잡한 API 기능과 데이터 모델을 MCP 표준 스키마에 정확하게 매핑하고, 안전하며 효율적인 MCP 서버를 구축 및 유지보수하는 것이 상당한 기술적, 비용적 부담이 될 수 있습니다.
- 지속적 업데이트: 기반이 되는 도구의 API가 변경되거나 MCP 표준 자체가 발전함에 따라 지속적인 업데이트와 버전 관리가 필요합니다.

표준화의 명암 (Pros and Cons of Standardization)
- 기능 제약 가능성: 모든 도구의 고유하고 세분화된 기능을 단일 표준으로 완벽하게 포괄하기는 어렵습니다. 초기 표준은 '최소 공통분모'에 집중하게 되어, 특정 도구의 고급 기능이나 특수 기능을 MCP를 통해 활용하는 데 제약이 따를 수 있습니다. 때로는 여전히 직접적인 API 호출이 필요할 수 있습니다.
- 표준의 경직성: 표준이 한번 자리 잡으면 변경하기 어려울 수 있으며, 빠르게 변화하는 AI 및 API 기술 발전을 민첩하게 따라가지 못할 수 있습니다.

성능 및 보안 문제 (Performance & Security Concerns)
- 잠재적 성능 저하: MCP라는 중개 계층(layer)이 추가되면서, 이론적으로는 직접 API를 호출하는 것보다 약간의 지연 시간(latency)이 발생할 수 있습니다. 대부분의 경우 무시할 만한 수준일 수 있으나, 실시간성이 중요한 애플리케이션에서는 고려 사항이 될 수 있습니다.
- 보안 책임: 표준화된 인터페이스는 잠재적인 공격 표면(attack surface)도 표준화할 수 있습니다. MCP 서버와 클라이언트 간의 인증, 권한 부여, 데이터 암호화 등 보안 메커니즘을 철저히 구현하는 것이 매우 중요하며, 이에 대한 책임은 각 서버 구현 주체에게 있습니다.

기술 성숙도 및 생태계 지원 (Maturity & Ecosystem Support)
- 초기 단계: MCP는 비교적 새로운 개념이므로, 관련 개발 도구, 디버깅 툴, 테스트 프레임워크, 풍부한 문서, 커뮤니티 지원 등이 아직 부족할 수 있습니다. 이는 초기 도입 및 문제 해결을 어렵게 만들 수 있습니다.

💡 결론: 균형 잡힌 시각 필요
MCP는 에이전트 기반 자동화의 중요한 발전을 약속하지만, 위와 같은 현실적인 과제들을 간과해서는 안 됩니다. 이러한 문제들은 대부분의 신기술 표준화 과정에서 나타나는 현상이며, MCP 생태계 참여자들의 지속적인 노력, 피드백, 협력을 통해 점진적으로 해결될 수 있을 것입니다. MCP의 성공 여부는 이러한 과제들을 얼마나 효과적으로 극복하느냐에 달려있습니다.

=======================
📘 5. MCP 생태계에 참여하는 방법
=======================

🎯 왜 관심을 가져야 하는가
만약 당신의 제품이 SaaS 도구이고, AI 에이전트가 사용하기를 원한다면, 지금이 MCP 생태계에 진입하기에 완벽한 시기입니다.
- LLM 기반 에이전트에게 발견될 수 있습니다.
- 맞춤 통합 없이 에이전트가 당신의 도구를 사용하게 할 수 있습니다.
- 기업 IT부터 소비자 AI까지 성장하는 에이전트 앱 시장에 진입할 수 있습니다.

🚪 참여 방법: 3가지 방법

1️⃣ MCP 서버 구축하기
당신의 도구 기능을 MCP 호환 인터페이스로 전환하세요.

🔧 필요한 것
- 도구의 기능(call_tool, list_tools) 설명하기
- call_resource, list_resources를 통해 데이터 노출하기
- 표준 컨텍스트 스키마 따르기
마치 공개 API를 구축하는 것과 같지만, LLM을 위한 것입니다.

💡 팁: 기존 에이전트 프레임워크(예: LangGraph, AutoGen)를 사용하여 개발 속도를 높이세요.

2️⃣ 마켓플레이스에 호스팅 또는 등록하기
MCP 서버가 활성화되면 MCP 레지스트리나 마켓플레이스에 게시하세요.
- 당신의 도구를 모든 MCP 호환 클라이언트가 발견할 수 있도록 만드세요.
- AI 에이전트가 당신의 제품을 찾고, 이해하고, 사용하도록 하세요.
- 일부 플랫폼(예: Claude, MySnap)은 이미 이 플러그 앤 플레이 모델을 지원합니다.

3️⃣ MCP를 클라이언트로 사용하기
MCP를 통해 도구에 연결하는 자체 AI 에이전트나 LLM 앱을 구축할 수도 있습니다.
- 더 이상 각 API에 대한 맞춤 래퍼를 작성할 필요가 없습니다.
- 기존 MCP 서버에 연결하고 워크플로우를 더 빠르게 구축하세요.
- 내부 자동화 도구나 고객 대면 AI 앱에 적합합니다.

🌱 선도자 = 큰 이점 (Early Movers = Huge Advantage)
MCP는 아직 초기 단계이지만, 기반은 현실적이고 작동하고 있습니다.
지금 참여함으로써 다음을 할 수 있습니다

✅ 떠오르는 표준에 영향을 미치기
✅ 다른 이들보다 먼저 당신의 도구의 LLM 인터페이스 형성하기
✅ 생태계가 확장됨에 따라 함께 성장하기

📌 결론
만약 REST가 웹 시대의 API 표준이었다면, MCP는 에이전트 시대의 프로토콜 표준이 될 수 있습니다. 지금이 준비할 황금 같은 기회입니다.

🧭 구축할 준비가 되셨나요?
핵심 도구 기능을 식별하고 MCP 형식으로 구조화하는 것부터 시작하세요.
모든 것을 지원할 필요는 없습니다 – 에이전트가 시작할 수 있을 만큼만 지원하면 됩니다.

에이전트의 시대(Agentic era)가 오고 있습니다. 늦지 마세요.

도움이 되셨다면 좋아요 부탁드립니다.

누구나 쉽게 이해할 수 있는 MCP 가이드 : AI 에이전트와 도구 연동의 새로운 표준 이 자료는 AI 에이전트가 Google Calendar, Salesforce와 같은 다양한 외부 도구(API)를 사용하는 데 어려움을 겪는 현재의 문제를 지적합니다. 이를 해결하기 위한 새로운 표준 프로토콜인 MCP(Model Context Protocol)를 소개하며, MCP가 어떻게 AI 에이전트와 도구 간의 '공통 언어' 역할을 하여 상호작용을 원활하게 하는지 설명합니다. 또한, 개발자와 SaaS 기업이 MCP 생태계에 참여하여 더 강력하고 확장 가능한 AI 에이전트를 구축하는 방법을 안내합니다. (참고) 가이드 전체 내용은 Gemini 2.5 Pro로 작성되었으며, 이미지 정리본은 GPT-4o 를 이용하여 생성하였습니다. ====================================== 📘 1. 왜 에이전트에게 새로운 표준이 필요한가 – MCP 소개 ====================================== 🚀 미래는 에이전트 중심입니다 (The Future Is Agentic) ChatGPT 시대를 맞아, 우리 모두는 AI가 얼마나 강력할 수 있는지 엿볼 수 있었습니다. 하지만 진정한 생산성은 단순히 AI와 대화하는 것에서 오는 것이 아니라, AI가 우리를 위해 실제로 일을 처리할 수 있을 때 발휘됩니다. 바로 이 지점에서 에이전트가 필요합니다. 에이전트는 단순한 챗봇이 아닙니다. 회의 예약, 보고서 작성, 데이터 분석과 같이 실제 도구(Google Calendar, Salesforce, Notion 등)를 사용하여 행동을 취하는 AI입니다. 하지만 여기에 문제가 있습니다. ❗️ 오늘날의 에이전트는 여전히 제한적입니다. AI에게 이렇게 요청한다고 상상해 보세요. “이번 주 나의 모든 1:1 미팅을 찾아서, 논의 내용을 요약하고, 후속 이메일 초안을 작성해 줄 수 있니?” 오늘날 대부분의 AI 에이전트는 아마 멈춰버릴 것입니다. 왜일까요? 그들이 사용하는 도구, 즉 여러 서비스의 API들이 마치 수백 개의 다른 방언처럼 제각각이기 때문입니다. 모든 도구 (Tools) 는 다음을 가지고 있습니다. - 자체 인증 규칙 - 고유한 데이터 형식 - 다른 기능 및 엔드포인트 개발자들은 모든 도구에 대해 맞춤 코드를 작성해야 하는 문제를 당면하게 됩니다. 이는 느리고, 불안정하며, 확장 가능하지 않습니다. 🧩 빠진 조각: 도구를 위한 공통 언어 만약 이 모든 도구들이 AI 에이전트와 소통할 수 있는 표준적인 방법이 있다면 어떨까요? 마치 HTML이 웹을 표준화하고, REST가 API를 표준화했듯이 이제 AI 에이전트를 위한 표준이 필요합니다. 이것이 바로 MCP (Model Context Protocol)입니다. AI 에이전트가 실제 도구를 쉽게 이해하고 상호작용할 수 있도록 설계된 새로운 프로토콜입니다. 시작해 봅시다. ============================ 📘 2. MCP란 무엇이며 어떻게 작동하는가? ============================ 🧠 큰 그림부터 시작해 봅시다. MCP (Model Context Protocol)는 AI 에이전트(LLM 기반)와 그들이 사용해야 하는 도구(Google Calendar, Salesforce, Notion 등) 사이에서 번역가 역할을 하는 새로운 표준입니다. MCP를 에이전트가 다음을 이해하는 데 도움이 되는 "만능 리모컨"이라고 생각하세요. - 어떤 도구를 사용할 수 있는지 - 그 도구들이 무엇을 할 수 있는지 - 어떻게 안전하고 효율적으로 사용할 수 있는지 🔍 주요 개념 - MCP 클라이언트: LLM을 사용하는 AI 에이전트 또는 앱입니다. 다음과 같은 요청을 보냅니다: ㄴ “이 도구는 무엇을 할 수 있나요?” ㄴ “이 함수를 실행해 주세요.” - MCP 서버: SaaS 도구와의 다리 역할을 합니다. 다음을 설명합니다: ㄴ 사용 가능한 기능 (예: "회의 생성", "노트 가져오기") ㄴ 관련 데이터를 일관된 형식으로 ㄴ LLM이 이해할 수 있는 방식으로 지침 제공 - 컨텍스트 스키마: 도구의 기능을 LLM이 읽을 수 있도록 구조화되고 통합된 형식입니다. 마치 모든 도구를 쉽게 탐색할 수 있는 API 플레이그라운드로 바꾸는 것과 같습니다. 🔁 이것이 왜 중요한가 - MCP가 없다면: AI 에이전트는 모든 도구를 사용하기 위해 수작업으로 코딩해야 합니다 = 느리고 비용이 많이 듭니다. - MCP가 있다면: 도구는 에이전트에게 플러그 앤 플레이 방식이 됩니다 = 빠르고 확장 가능합니다. ✅ 실제 예시 에이전트가 다음 작업을 수행하기를 원하십니까? “Asana에서 모든 높은 우선순위 작업을 찾고, 프로젝트 상태를 요약하고, 팀에 알림 보내기” MCP를 사용하면, 1. Asana MCP 서버가 그 기능을 설명합니다 (list_projects, get_tasks 등). 2. 에이전트는 이러한 작업을 탐색, 호출 및 결합할 수 있습니다. 3. 그 결과 맞춤 코드 없이 완전히 자동화된 워크플로우가 가능해집니다. ================================= 📘 3. 도구가 어떻게 에이전트의 능력을 결정하는가 ================================= 🛠 모든 도구가 동일하지는 않습니다 인간 조수가 일을 처리하기 위해 적절한 기술 세트가 필요한 것처럼, AI 에이전트의 성능은 사용할 수 있는 도구에 따라 달라집니다. 도구에는 두 가지 주요 유형이 있습니다. 1️⃣ 다기능 도구 (Multi-Function Tools) : 하나의 도구, 여러 작업 – 스위스 아미 나이프처럼 이 도구들은 여러 관련 작업을 하나의 강력한 인터페이스로 묶습니다. 단일 단계가 아닌 전체 워크플로우를 수행하도록 설계되었습니다. 🧠 예시 다기능 도구를 사용하는 Calendar Agent는 다음을 처리할 수 있습니다. - 모든 미팅 찾기 (유형별 필터링 = 1:1) - 메타데이터 추출 (제목, 참석자, 시간) - 미팅 노트 읽기 - 주간 요약 생성 이 모든 것을 한 번에 처리합니다 – 5개의 다른 도구를 호출할 필요가 없습니다. 📌 중요한 이유 도구 수가 적을수록 = 오케스트레이션이 단순해짐 = 더 빠르고 스마트한 에이전트. 2️⃣ 다중 도구 에이전트 (Multi-Tool Agents) - 함께 작동하는 에이전트 – 전문가 팀처럼 때로는 단일 도구만으로는 모든 것을 할 수 없습니다. 대신, 마치 팀 내의 사람들처럼 각기 다른 도구를 사용하는 에이전트들이 협업합니다. 🧠 예시 목표: 주요 고객에게 맞춤형 이메일 캠페인 보내기. 🧑‍💼 에이전트 1: Salesforce에서 고객 데이터 가져오기 📊 에이전트 2: Google Sheets에서 데이터 분석하기 📬 에이전트 3: Mailchimp를 통해 이메일 보내기 이를 에이전트 시스템(System of Agents) 또는 MAS (Multi-Agent System)라고 합니다. 📌 중요한 이유 에이전트는 강점을 결합하고 더 넓은 범위를 커버할 수 있습니다 – 마치 회사의 마이크로서비스처럼. 🤖 왜 ChatGPT만으로는 충분하지 않은가 오늘날 대부분의 맞춤형 GPT는 너무 단순합니다 - 제한된 작업 - 메모리 없음 - 다른 에이전트와 협업 불가 - "단일 도구" 사일로에 갇혀 있음 이것이 바로 AutoGen, CrewAI, LangGraph와 같은 강력한 프레임워크가 등장한 이유입니다 – 다기능 및 다중 에이전트 기능을 잠금 해제하기 위해. 🧭 도구 = 에이전트 뒤의 진정한 엔진 단순히 어떤 LLM을 사용하는지에 대한 문제가 아닙니다. 어떤 도구를 제공하고, 그것들이 어떻게 연결되어 있는지에 대한 문제입니다. ========================= 📘 4. MCP의 현실적인 과제와 한계점 ========================= MCP는 AI 에이전트와 도구 연동의 방식을 혁신할 잠재력을 지니고 있지만, 새로운 표준으로서 현실적인 과제와 잠재적 한계점 또한 고려해야 합니다. 😫 넘어야 할 현실적인 장벽들 MCP가 이상적인 솔루션처럼 보일 수 있지만, 성공적인 정착과 확산을 위해서는 다음과 같은 현실적인 문제들을 해결해야 합니다. 느린 채택 속도 (Slow Adoption Rate) - 가장 큰 허들: 새로운 표준의 성공은 얼마나 많은 플레이어가 참여하느냐에 달려있습니다. SaaS 기업들이 MCP 서버 구축에 투자하고, 에이전트 개발자들이 이를 적극적으로 사용해야만 생태계가 활성화됩니다. 초기에는 '닭과 달걀' 문제에 직면할 수 있습니다. - 모든 도구 제공자가 표준화된 단일 인터페이스를 선호하지 않을 수 있으며, 자체 API 생태계를 강화하는 것을 우선시할 수 있습니다. 구현 및 유지보수의 복잡성 (Complexity of Implementation &amp; Maintenance) - 서버 측 부담: MCP가 에이전트 클라이언트 개발을 단순화할 수 있지만, SaaS 도구 제공자 입장에서는 자사의 복잡한 API 기능과 데이터 모델을 MCP 표준 스키마에 정확하게 매핑하고, 안전하며 효율적인 MCP 서버를 구축 및 유지보수하는 것이 상당한 기술적, 비용적 부담이 될 수 있습니다. - 지속적 업데이트: 기반이 되는 도구의 API가 변경되거나 MCP 표준 자체가 발전함에 따라 지속적인 업데이트와 버전 관리가 필요합니다. 표준화의 명암 (Pros and Cons of Standardization) - 기능 제약 가능성: 모든 도구의 고유하고 세분화된 기능을 단일 표준으로 완벽하게 포괄하기는 어렵습니다. 초기 표준은 '최소 공통분모'에 집중하게 되어, 특정 도구의 고급 기능이나 특수 기능을 MCP를 통해 활용하는 데 제약이 따를 수 있습니다. 때로는 여전히 직접적인 API 호출이 필요할 수 있습니다. - 표준의 경직성: 표준이 한번 자리 잡으면 변경하기 어려울 수 있으며, 빠르게 변화하는 AI 및 API 기술 발전을 민첩하게 따라가지 못할 수 있습니다. 성능 및 보안 문제 (Performance &amp; Security Concerns) - 잠재적 성능 저하: MCP라는 중개 계층(layer)이 추가되면서, 이론적으로는 직접 API를 호출하는 것보다 약간의 지연 시간(latency)이 발생할 수 있습니다. 대부분의 경우 무시할 만한 수준일 수 있으나, 실시간성이 중요한 애플리케이션에서는 고려 사항이 될 수 있습니다. - 보안 책임: 표준화된 인터페이스는 잠재적인 공격 표면(attack surface)도 표준화할 수 있습니다. MCP 서버와 클라이언트 간의 인증, 권한 부여, 데이터 암호화 등 보안 메커니즘을 철저히 구현하는 것이 매우 중요하며, 이에 대한 책임은 각 서버 구현 주체에게 있습니다. 기술 성숙도 및 생태계 지원 (Maturity &amp; Ecosystem Support) - 초기 단계: MCP는 비교적 새로운 개념이므로, 관련 개발 도구, 디버깅 툴, 테스트 프레임워크, 풍부한 문서, 커뮤니티 지원 등이 아직 부족할 수 있습니다. 이는 초기 도입 및 문제 해결을 어렵게 만들 수 있습니다. 💡 결론: 균형 잡힌 시각 필요 MCP는 에이전트 기반 자동화의 중요한 발전을 약속하지만, 위와 같은 현실적인 과제들을 간과해서는 안 됩니다. 이러한 문제들은 대부분의 신기술 표준화 과정에서 나타나는 현상이며, MCP 생태계 참여자들의 지속적인 노력, 피드백, 협력을 통해 점진적으로 해결될 수 있을 것입니다. MCP의 성공 여부는 이러한 과제들을 얼마나 효과적으로 극복하느냐에 달려있습니다. ======================= 📘 5. MCP 생태계에 참여하는 방법 ======================= 🎯 왜 관심을 가져야 하는가 만약 당신의 제품이 SaaS 도구이고, AI 에이전트가 사용하기를 원한다면, 지금이 MCP 생태계에 진입하기에 완벽한 시기입니다. - LLM 기반 에이전트에게 발견될 수 있습니다. - 맞춤 통합 없이 에이전트가 당신의 도구를 사용하게 할 수 있습니다. - 기업 IT부터 소비자 AI까지 성장하는 에이전트 앱 시장에 진입할 수 있습니다. 🚪 참여 방법: 3가지 방법 1️⃣ MCP 서버 구축하기 당신의 도구 기능을 MCP 호환 인터페이스로 전환하세요. 🔧 필요한 것 - 도구의 기능(call_tool, list_tools) 설명하기 - call_resource, list_resources를 통해 데이터 노출하기 - 표준 컨텍스트 스키마 따르기 마치 공개 API를 구축하는 것과 같지만, LLM을 위한 것입니다. 💡 팁: 기존 에이전트 프레임워크(예: LangGraph, AutoGen)를 사용하여 개발 속도를 높이세요. 2️⃣ 마켓플레이스에 호스팅 또는 등록하기 MCP 서버가 활성화되면 MCP 레지스트리나 마켓플레이스에 게시하세요. - 당신의 도구를 모든 MCP 호환 클라이언트가 발견할 수 있도록 만드세요. - AI 에이전트가 당신의 제품을 찾고, 이해하고, 사용하도록 하세요. - 일부 플랫폼(예: Claude, MySnap)은 이미 이 플러그 앤 플레이 모델을 지원합니다. 3️⃣ MCP를 클라이언트로 사용하기 MCP를 통해 도구에 연결하는 자체 AI 에이전트나 LLM 앱을 구축할 수도 있습니다. - 더 이상 각 API에 대한 맞춤 래퍼를 작성할 필요가 없습니다. - 기존 MCP 서버에 연결하고 워크플로우를 더 빠르게 구축하세요. - 내부 자동화 도구나 고객 대면 AI 앱에 적합합니다. 🌱 선도자 = 큰 이점 (Early Movers = Huge Advantage) MCP는 아직 초기 단계이지만, 기반은 현실적이고 작동하고 있습니다. 지금 참여함으로써 다음을 할 수 있습니다 ✅ 떠오르는 표준에 영향을 미치기 ✅ 다른 이들보다 먼저 당신의 도구의 LLM 인터페이스 형성하기 ✅ 생태계가 확장됨에 따라 함께 성장하기 📌 결론 만약 REST가 웹 시대의 API 표준이었다면, MCP는 에이전트 시대의 프로토콜 표준이 될 수 있습니다. 지금이 준비할 황금 같은 기회입니다. 🧭 구축할 준비가 되셨나요? 핵심 도구 기능을 식별하고 MCP 형식으로 구조화하는 것부터 시작하세요. 모든 것을 지원할 필요는 없습니다 – 에이전트가 시작할 수 있을 만큼만 지원하면 됩니다. 에이전트의 시대(Agentic era)가 오고 있습니다. 늦지 마세요. 도움이 되셨다면 좋아요 부탁드립니다.

누구나 쉽게 이해할 수 있는 MCP 가이드

똑닥닷컴 SEO(a.k.a. 네이버 월 노출 수 1000만 달성기) | 비브로스 기술 블로그

어떤 접근으로 노출수를 높였는지 단계별로 잘 나와있네요.
https://boostbrothers.github.io/2025-03-04-ddocdoc-com-seo/

어떤 접근으로 노출수를 높였는지 단계별로 잘 나와있네요.https://boostbrothers.github.io/2025-03-04-ddocdoc-com-seo/

boostbrothers.github.io

똑닥: SEO 최적화 사례

첫 회사에서 5년 정도 보낸 후 대기업이 가보고 싶다는 생각이 들었습니다.
다른 곳에 이력서도 넣어보지 않은 채 일단 그만뒀습니다.

그리고 이력서를 쓰기 시작했는데...
아는 사람도 하나 없어 지인 추천 없이 홈페이지를 통해서 지원서를 썼습니다.
네이버, 다음, SK컴즈, NC소프트, 넥슨 같은 곳들.

근데 기다려도 답장이 오질 않더군요.
5년 가까이 열심히 했고 자신감도 많이 생겼는데 밖에서 보는 내 수준은 이런거였구나.

한 달 정도 지났을 뿐인데 초조함이 엄청 커졌습니다.
나 혹시 새되는 거 아냐? 그럼 내 인생 어떻게 되는거지?
다른 회사를 먼저 알아보고 그만둘 걸.
큰일났단 생각에 소름이 바짝 돋았습니다.

엔씨, 넥슨, 다음에서는 연락도 안 왔고, 네이버에서 연락이 왔습니다.
이력서를 내고 한 달 지나 연락이 왔는데...
지금 생각해보면 제 이력서를 보고 픽해준 네이버 누군가가 인생의 은인입니다.
만약 흘려 넘겨 버렸으면 나는 지금 뭘하고 있을까? 시간이 지날수록 초조한 맘이 커져서 그 어떤 이상한 회사라도 얼씨구나 들어갔을 것 같습니다.

이후에도 다른 회사를 알아보기 전에 회사를 그만두었습니다만 처음 만큼 긴장되거나 초조하진 않았습니다. 스스로에 대한 자신감이 없었기 때문이었던 것 같습니다.

(인생에서 불안했던 시기를 생각해보다가 쓴 글일 뿐 절대 이렇게 하라고 추천하는 것은 아닙니다)

첫 회사에서 5년 정도 보낸 후 대기업이 가보고 싶다는 생각이 들었습니다.다른 곳에 이력서도 넣어보지 않은 채 일단 그만뒀습니다. 그리고 이력서를 쓰기 시작했는데...아는 사람도 하나 없어 지인 추천 없이 홈페이지를 통해서 지원서를 썼습니다.네이버, 다음, SK컴즈, NC소프트, 넥슨 같은 곳들. 근데 기다려도 답장이 오질 않더군요.5년 가까이 열심히 했고 자신감도 많이 생겼는데 밖에서 보는 내 수준은 이런거였구나. 한 달 정도 지났을 뿐인데 초조함이 엄청 커졌습니다.나 혹시 새되는 거 아냐? 그럼 내 인생 어떻게 되는거지?다른 회사를 먼저 알아보고 그만둘 걸.큰일났단 생각에 소름이 바짝 돋았습니다. 엔씨, 넥슨, 다음에서는 연락도 안 왔고, 네이버에서 연락이 왔습니다.이력서를 내고 한 달 지나 연락이 왔는데...지금 생각해보면 제 이력서를 보고 픽해준 네이버 누군가가 인생의 은인입니다.만약 흘려 넘겨 버렸으면 나는 지금 뭘하고 있을까? 시간이 지날수록 초조한 맘이 커져서 그 어떤 이상한 회사라도 얼씨구나 들어갔을 것 같습니다. 이후에도 다른 회사를 알아보기 전에 회사를 그만두었습니다만 처음 만큼 긴장되거나 초조하진 않았습니다. 스스로에 대한 자신감이 없었기 때문이었던 것 같습니다. (인생에서 불안했던 시기를 생각해보다가 쓴 글일 뿐 절대 이렇게 하라고 추천하는 것은 아닙니다)

다른 회사를 먼저 알아보지 않고 퇴사하면

YouTube에서 마음에 드는 동영상과 음악을 감상하고, 직접 만든 콘텐츠를 업로드하여 친구, 가족뿐 아니라 전 세계 사람들과 콘텐츠를 공유할 수 있습니다.

 - YouTube

먼저, 성능 최적화와 보안 이슈 등을 얘기할 수 있을것 같아요.

물론 초개인화된 데이터를 처리하는 역할을
모두 서버에서 담당한다면 서버 부하가 커질 수도 있지만,

그럼에도 위와 같은 이유들로
서버에서 Data fetching 을 하는게 유리한 때가 있어서요.

이러한 이유에 대해 좀 더 자세히 설명해보았습니다.

https://youtu.be/vJGk4iLo-Ak

먼저, 성능 최적화와 보안 이슈 등을 얘기할 수 있을것 같아요. 물론 초개인화된 데이터를 처리하는 역할을모두 서버에서 담당한다면 서버 부하가 커질 수도 있지만, 그럼에도 위와 같은 이유들로서버에서 Data fetching 을 하는게 유리한 때가 있어서요. 이러한 이유에 대해 좀 더 자세히 설명해보았습니다. https://youtu.be/vJGk4iLo-Ak

youtu.be

왜 Data fetching 을 서버에서 해야할까요?

사용자가 공유한 콘텐츠

폴인에서 시리즈로 공개한 '토스팀에게 듣다: 토스 10주년 '10 to 100''에서 프로덕트 디자인 부문의 글을 소개합니다. 프로덕트 디자인 헤드를 맡고 있는 강수영 님이 2015년부터 2025년까지 토스에서의 프로덕트 디자인을 어떻게 바라보고, 어떤 고민과 도전으로 현재에 이르렀는지 담담하게 전달하는 내용입니다. 요약을 먼저 보시더라도 전문을 꼭 살펴보시면 좋겠습니다.

2개의 문장으로 결론을 요약하자면 사용자 경험을 고민하는 사람이라면, 디자인하는 사람이라면 '수단과 목적을 헷갈리지 말자'라는 것이었습니다. '만약 헷갈리지만 않는다면 안 되는 건 거의 없다.'입니다.

[ 큐레이터의 문장 🎒 ]

1. 태동기(2015~18): 디자인도, 일하는 방식도 단순하게 

 * ① 필요 없는 정보는 과감히 쳐내기
   ② 한 화면에서 어딜 봐야 할지 명확히 알려주기

2. 성장기(2018~22): 체계를 통한 일관성 쌓기

토스만의 디자인 시스템을 만들고 토스만의 서체도 만들면서 어디서든 '토스 디자인이다'라고 알 수 있게 만든 시기였습니다. 동시에 4가지를 새롭게 시도했습니다.

 * ① 3D 그래픽 - 시네마4D라는 툴을 직접 배워가며 내부에서 디벨롭
 * ② UX 라이팅 - A/B테스트를 통해 제품속 문구를 결정하면서 클릭율 최대 300% 증가
 * ③ 유저 테스트 - 토스의 UT 문화가 생긴 시기로 전문 업체와 계약해서 테스트, 정성 테스트를 반복해 가입 퍼널을 만들고 수치로 성과까지 증명
 * ④ 로고 리브랜딩 - '공 던지듯 쉬운 금융', '우리는 금융이 아니다', '토스에 갇히면 안 된다'

3. 진화기(2022~2024): 금융 너머를 바라보는 시대의 디자인

마이데이터 시기에 조회, 송금, 혜택을 중심으로 한 홈화면을 만든 시기. 대출, 카드, 보험, 신용대출 등 여러 기능을 동일한 인터랙션으로 하나의 경험을 하듯이 만드는 것에 주안점을 두고 매출까지 개선하는 것으로 디자인의 역할을 확대했습니다. 이 시기엔 3D로 만든 새로운 로고를 선보였습니다.

4. 토스의 지금(2025~): 어디서나 편리한 디자인을 고민할 때

토스가 금융상품을 넘어 커머스, 모바일을 넘어 오프라인 단말기까지 새로운 접점이 생기면서 덩치가 커졌습니다. B2B 고객도 많아졌고 고객이 토스 앱 안에서 자기만의 사업을 하려는 니즈가 있었기에 '툴 프로덕트 디자이너'라는 직군까지 생겼습니다. 내부 구성원을 위한 툴도 만들어진 시기였죠.

 1. 토스 내비게이션 스코어 - 유저에게 직접 묻고 '이 기능 어디에 있을 것 같나요?'에 대한 답변을 히트맵 형태로 표현해서 (만드는 사람이) 예상한 것과 (쓰는 사람이) 이해하고 기대하는 것 사이의 격차가 얼마나 큰지 확인할 수 있는 방법입니다.
 2. 휴리봇 - 휴리봇은 토스 유저처럼 답변하는 생성형 AI예요. 디자인한 화면을 보여주며 질문하면 실제 유저처럼 답변하는 거예요. 기존 유저 테스트를 완전히 대체할 수는 없지만, 시간을 아끼는 데 큰 도움이 됩니다.
 3. 토스트 - 토스 스타일로 그림을 알아서 그려주는 '토스트'도 개발했어요. 정보를 입력하면 몇 분 만에 그래픽이 만들어지죠. 토스 그래픽 디자이너가 만든 것과 같은 퀄리티, 톤으로요. 디자이너들이 더 중요한 문제에 집중할 수 있도록 일손을 덜어주는 역할을 잘 해내고 있습니다. 
 4. 랠리(Rally) - 인터랙션을 잘 만들려면 디자이너의 역량, 구현 기술, 개발 인력이 모두 필요한데요. 인터랙션팀 주도로 구현 비용을 획기적으로 낮추기 위해 랠리라는 프로그래밍 언어를 자체 개발했어요.

https://www.folin.co/article/10450/gift/Fspn7szhf5iFFggpgu0Ryq7GKd3D6XF5

폴인에서 시리즈로 공개한 '토스팀에게 듣다: 토스 10주년 '10 to 100''에서 프로덕트 디자인 부문의 글을 소개합니다. 프로덕트 디자인 헤드를 맡고 있는 강수영 님이 2015년부터 2025년까지 토스에서의 프로덕트 디자인을 어떻게 바라보고, 어떤 고민과 도전으로 현재에 이르렀는지 담담하게 전달하는 내용입니다. 요약을 먼저 보시더라도 전문을 꼭 살펴보시면 좋겠습니다. 2개의 문장으로 결론을 요약하자면 사용자 경험을 고민하는 사람이라면, 디자인하는 사람이라면 '수단과 목적을 헷갈리지 말자'라는 것이었습니다. '만약 헷갈리지만 않는다면 안 되는 건 거의 없다.'입니다. [ 큐레이터의 문장 🎒 ] 1. 태동기(2015~18): 디자인도, 일하는 방식도 단순하게&nbsp; <ul ><li>① 필요 없는 정보는 과감히 쳐내기 ② 한 화면에서 어딜 봐야 할지 명확히 알려주기</li></ul> 2. 성장기(2018~22): 체계를 통한 일관성 쌓기 토스만의 디자인 시스템을 만들고 토스만의 서체도 만들면서 어디서든 '토스 디자인이다'라고 알 수 있게 만든 시기였습니다. 동시에 4가지를 새롭게 시도했습니다. <ul ><li>① 3D 그래픽 - 시네마4D라는 툴을 직접 배워가며 내부에서 디벨롭</li><li>② UX 라이팅 - A/B테스트를 통해 제품속 문구를 결정하면서 클릭율 최대 300% 증가</li><li>③ 유저 테스트 - 토스의 UT 문화가 생긴 시기로 전문 업체와 계약해서 테스트, 정성 테스트를 반복해 가입 퍼널을 만들고 수치로 성과까지 증명</li><li>④ 로고 리브랜딩 - '공 던지듯 쉬운 금융', '우리는 금융이 아니다', '토스에 갇히면 안 된다'</li></ul> 3. 진화기(2022~2024): 금융 너머를 바라보는 시대의 디자인 마이데이터 시기에 조회, 송금, 혜택을 중심으로 한 홈화면을 만든 시기. 대출, 카드, 보험, 신용대출 등 여러 기능을 동일한 인터랙션으로 하나의 경험을 하듯이 만드는 것에 주안점을 두고 매출까지 개선하는 것으로 디자인의 역할을 확대했습니다. 이 시기엔 3D로 만든 새로운 로고를 선보였습니다. 4. 토스의 지금(2025~): 어디서나 편리한 디자인을 고민할 때 토스가 금융상품을 넘어 커머스, 모바일을 넘어 오프라인 단말기까지 새로운 접점이 생기면서 덩치가 커졌습니다. B2B 고객도 많아졌고 고객이 토스 앱 안에서 자기만의 사업을 하려는 니즈가 있었기에 '툴 프로덕트 디자이너'라는 직군까지 생겼습니다. 내부 구성원을 위한 툴도 만들어진 시기였죠. <ol ><li>토스 내비게이션 스코어 - 유저에게 직접 묻고 '이 기능 어디에 있을 것 같나요?'에 대한 답변을 히트맵 형태로 표현해서 (만드는 사람이) 예상한 것과 (쓰는 사람이) 이해하고 기대하는 것 사이의 격차가 얼마나 큰지 확인할 수 있는 방법입니다.</li><li>휴리봇 - 휴리봇은 토스 유저처럼 답변하는 생성형 AI예요. 디자인한 화면을 보여주며 질문하면 실제 유저처럼 답변하는 거예요. 기존 유저 테스트를 완전히 대체할 수는 없지만, 시간을 아끼는 데 큰 도움이 됩니다.</li><li>토스트 - 토스 스타일로 그림을 알아서 그려주는 '토스트'도 개발했어요. 정보를 입력하면 몇 분 만에 그래픽이 만들어지죠. 토스 그래픽 디자이너가 만든 것과 같은 퀄리티, 톤으로요. 디자이너들이 더 중요한 문제에 집중할 수 있도록 일손을 덜어주는 역할을 잘 해내고 있습니다.&nbsp;</li><li>랠리(Rally) - 인터랙션을 잘 만들려면 디자이너의 역량, 구현 기술, 개발 인력이 모두 필요한데요. 인터랙션팀 주도로 구현 비용을 획기적으로 낮추기 위해 랠리라는 프로그래밍 언어를 자체 개발했어요.</li></ol> https://www.folin.co/article/10450/gift/Fspn7szhf5iFFggpgu0Ryq7GKd3D6XF5

www.folin.co

《디자인하는 사람이라면 '수단과 목적을 헷갈리지 말자'》

1. “다른 사람을 존중하라”고 설교하지만, 정작 자신은 직원들을 신뢰하지도 존중하지도 않습니다.

2. ‘팀워크’라는 말을 입에 달고 다니지만, 팀플레이를 맹목적인 복종으로만 해석합니다.

3. 끔찍할 정도로 우유부단합니다. 중요한 결정을 내려야 할 때마다 미루고, 수도 없이 분석만 하고 의사결정은 내리지 않습니다. 그 결과, 회사는 결국 중요한 기회를 놓치고, 작은 문제들마저 심각한 위기로까지 커집니다.

4. 우선순위를 정하지 않고, 직원들에게 10~20개 실천 항목을 한꺼번에 제시하며 모두 다 우리에게 최우선사항이라고 말합니다.

5. 자기 집무실에 틀어박혀서 직원들이 어떻게 일하는지를 살피지 않습니다.

6. 사람들을 끊임없이 비판할 뿐, 긍정적인 피드백은 거의 하지 않습니다. 직원이 딱 한 번 실수를 한 것을 두고 영원히 괴롭힙니다. 그 결과, 실수를 통해 교훈을 얻을 수 있는 기회 자체를 박탈합니다.

7. 회사의 비전을 놓고 직원들과 효과적으로 소통하지 않습니다. 그로 인해 직원들은 회사에 비전이 없다고 느끼고, 어디로 가야 할지 몰라서 회사는 우왕좌왕합니다.

8. 말을 할 때나 글을 쓸 때 복잡하고 따분하기만 하고, 온갖 전문 용어를 남발합니다. 그래서 직원들에게 건설적인 영감을 주기는커녕 지루하고 혼란스럽게 만듭니다.

9. 정체된 상태임에도 새롭거나 대담한 도전을 하는 것을 꺼립니다. 그래서 결국 야망을 가진 직원들은 회사를 떠납니다.

- 짐 콜린스 외, <좋은 리더를 넘어 위대한 리더로> 중

1. “다른 사람을 존중하라”고 설교하지만, 정작 자신은 직원들을 신뢰하지도 존중하지도 않습니다. 2. ‘팀워크’라는 말을 입에 달고 다니지만, 팀플레이를 맹목적인 복종으로만 해석합니다. 3. 끔찍할 정도로 우유부단합니다. 중요한 결정을 내려야 할 때마다 미루고, 수도 없이 분석만 하고 의사결정은 내리지 않습니다. 그 결과, 회사는 결국 중요한 기회를 놓치고, 작은 문제들마저 심각한 위기로까지 커집니다. 4. 우선순위를 정하지 않고, 직원들에게 10~20개 실천 항목을 한꺼번에 제시하며 모두 다 우리에게 최우선사항이라고 말합니다. 5. 자기 집무실에 틀어박혀서 직원들이 어떻게 일하는지를 살피지 않습니다. 6. 사람들을 끊임없이 비판할 뿐, 긍정적인 피드백은 거의 하지 않습니다. 직원이 딱 한 번 실수를 한 것을 두고 영원히 괴롭힙니다. 그 결과, 실수를 통해 교훈을 얻을 수 있는 기회 자체를 박탈합니다. 7. 회사의 비전을 놓고 직원들과 효과적으로 소통하지 않습니다. 그로 인해 직원들은 회사에 비전이 없다고 느끼고, 어디로 가야 할지 몰라서 회사는 우왕좌왕합니다. 8. 말을 할 때나 글을 쓸 때 복잡하고 따분하기만 하고, 온갖 전문 용어를 남발합니다. 그래서 직원들에게 건설적인 영감을 주기는커녕 지루하고 혼란스럽게 만듭니다. 9. 정체된 상태임에도 새롭거나 대담한 도전을 하는 것을 꺼립니다. 그래서 결국 야망을 가진 직원들은 회사를 떠납니다. - 짐 콜린스 외, &lt;좋은 리더를 넘어 위대한 리더로&gt; 중

최악의 리더들이 가진 특징 9가지

왜 이렇게 구성했는지? 진솔한 과정이 녹아있는지? | 템플릿화된 포트폴리오는 답이 절대 아닙니다. 3~4월 코칭한 UX/UI 멘티 9명이 서류와 최종 합격 소식을 전해왔습니다. 대기업 2명 유니콘 6명 에이전시 1명  합격 멘티 포트폴리오들은 비주얼 중심 구성이 아니었습니다. 대신 거의 모든 부분에 '왜 이렇게 디자인을 했지?'라는 솔직하고 치밀한 답변이 있었습니다. 스크롤 길이를 짧게 만든 이유, 버튼에 텍

지금, 합격하는 UX 포트폴리오란?

“템플릿화된 포트폴리오는 더 이상 답이 아닙니다”

- 템플릿 탈출 – ‘왜’가 스며든 화면 구성
- 개념보다 맥락 – 언제나 실제 사용자 고충에서 시작
- 추상화에서 벗어나기 – 약 30% < 31.5%
- 프로젝트 제목부터 목적을 드러내기

https://brunch.co.kr/@cliche-cliche/277

“템플릿화된 포트폴리오는 더 이상 답이 아닙니다” - 템플릿 탈출 – ‘왜’가 스며든 화면 구성- 개념보다 맥락 – 언제나 실제 사용자 고충에서 시작- 추상화에서 벗어나기 – 약 30% &lt; 31.5%- 프로젝트 제목부터 목적을 드러내기 https://brunch.co.kr/@cliche-cliche/277

Brunch Story

미리캔버스 프론트엔드 엔지니어

김재훈

문제해결에 도움되는 기술을 좋아합니다.
미리캔버스 웹&앱을 개발중이며, FSD에 관심있어서
사이드 프로젝트에 적용하고 블로그에 기록중입니다.

UI/UX 기획자

김유한

함께 웃으며 즐겁게 일하고, 늘 성장하기 원하는 기획자 입니다 : )
#기획자 #UIUX #앱기획 #웹기획 #BO기획 #커머스 #공공기관

UXUI디자이너

이지현

지금, 합격하는 UX/UI 포트폴리오의 특징?

글로벌 앱을 만드는 픽소의 프로덕트 디자이너, 신선 식재료 브랜드 정육각의 디자인 디렉터로 일했습니다. 현재는 디자인 관련 글을 쓰는 작가로 활동 중이며, 디자인 윤리 커뮤니티 '인간을 위한 디자인'을 운영 중이기도 합니다.

우디디자인랩

🦄 [유니콘·빅테크 합격한] UX/UI 포폴 컨설팅(링크 확인)
⚪️ 우디디자인랩 대표ㅣ강연·취업 코칭
⚪️ [스테디셀러] 사용자를 사로잡는 UX/UI 실전 가이드
⚪️ [1.4K] 디자인 취업 고민 오픈채팅 운영중

지금, 합격하는 UX/UI 포트폴리오의 특징?

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필