01 . 직업적, 직무적 특성상 제 주위에는 크리에이티브 한 분들이 많습니다. 가끔 '진짜 대단하다. 어떻게 저렇게 풀어낼 수 있을까?' 싶을 정도로 본인의 생각을 뛰어난 결과물로 표현해 내는 분들도 많이 계시죠. 그럴 땐 좋은 인풋과 자극을 주는 사람들이 곁에 있다는 사실만으로도 늘 긴장하게 되고 한편으로는 제가 하는 일에 더 큰 애착도 느낄 수 있어 여러모로 운이 좋다고 여겨질 때가 많습니다.

02 . 하지만 모든 것에는 장단이 존재하듯이 크리에이티브 한 사람들에게도 단점은 존재합니다. 물론 이 역시 그저 지극히 개인적인 경험에서 비롯된 것이기에 마냥 일반화하기 어렵고, 마치 수박의 씨처럼 큰 장점들 속에 콕콕 박혀있는 작디작은 부분일지 모르기에 조심스러운 맘이 앞서지만 때로는 부족한 포인트를 짚고 넘어가는 것도 중요하단 생각이 들었습니다. 그래서 오늘은 크리에이티브 한 사람들이 쉽게 빠질 수 있는 함정에 대한 이야기를 한 번 해보려고 합니다.

03 . 가장 먼저 주의해야 할 부분은 '뭔가 설명하는 것을 귀찮아하는 습성'입니다. 크리에이티브 한 사람들 중에는 후천적으로 길러진 역량을 가진 사람도 있지만 분명 타고난 능력을 갖춘 사람도 있습니다. 그런데 이들의 경우 자신이 가진 능력을 빠르게 결과물로 전화할 수 있는 역량이 크기 때문에 누군가에게 이 과정을 잘 설명해 주거나 이해시키려고 하지 않습니다. 오히려 '이상하다. 왜 다른 사람들은 이렇게 못하지?'라는 생각으로 그냥 본인이 모든 일을 해결하려는 경향까지 보이고 말죠. 이건 예술가에겐 탁월함일지 모르지만 협업을 해야 하는 우리 같은 사람들에게는 꽤 치명적인 단점이 되기도 합니다.

04 . 그리고 이런 성향은 '프로세스나 시스템을 만드는 것에 부정적인 뉘앙스'를 보이는 것으로 발현되기도 합니다. 본인들에겐 좋은 과정을 만들어 놓는 것, 다른 사람이나 뒤따라오는 후배들도 배우고 익힐 수 있도록 공유하는 것보다 우선 멋진 결과물을 창작해 내는 것이 더 중요하기 때문이죠. 물론 프로세스나 툴, 시스템 등이 그런 뛰어난 역량을 가진 사람들의 발목을 잡는 역할을 해서는 안 되겠지만 효율화와 내재화라는 측면에서는 크리에이티브도 어느 정도 체계를 갖출 필요는 반드시 있습니다.

05 . 더불어 개인적으로는 이게 가장 치명적인 단점이라고 생각하는데요, 창의적인 사람들의 경우 본인이 확신하는 영감이 올 때까지 스스로 작업에 딜레이를 거는 경우가 있습니다, 즉 조금이라도 더 좋은 결과를 만들어 내고자 조금이라도 더 디테일을 붙잡고 있고자 하는 과정에서 데드라인을 못 맞추는 경우가 빈번해진다는 것이죠. 저는 농담반 진담반으로 '레오나르도 다빈치를 무한 존경할 수 없는 유일한 이유 중 하나는 그가 데드라인을 못 맞추는 사람이었기 때문'이라는 말을 하는데, 조직에서 공동의 목표를 위해 함께 일해야 하는 사람들에겐 말해 무엇할까요... 일정이 지나고 나면 크리에이티브도 크리에이티브할 수 없는 것이니 말입니다.

06 . 마지막은 바로 '다름을 위한 다름'입니다. 이건 어느 정도 예상하실 수 있겠지만 크리에이티브를 표방하는 사람들은 언제나 새로움에 대한 갈망이 큽니다. 물론 이 자체로도 훌륭한 자질이라고 할 수 있겠으나 때로는 이런 기질이 기존의 작업물과 무조건 다른 방식을 따라야 한다는 강박으로 이어지기도 하죠. 그래서 심지어 자신이 담당한 작업물마저 부정의 부정을 거듭하며 모두 레거시로 만들어버리는 실수를 범하기도 합니다. 늘 새로워야 한다는 것도 과거에 대한 명확한 회고와 가치 판단에 따른 것이어야 함을 잊어서는 안되는 이유죠.

07 . 여러 가지 단점을 열거해 봤지만 저는 이런 함정에 빠지지 않기 위해서는 딱 하나의 능력이 필요하다고 생각합니다. 바로 내 머릿속에 있는 추상적인 개념을 곧바로 작업물로 옮기기 전에 꼭 이 변환의 과정을 공통의 언어로 기록하는 것이죠. 쉽게 설명하자면 A라는 생각이 어떻게 B라는 과정으로 옮겨졌는지 그리고 왜 그렇게 하기로 결정한 것인지에 대해 다른 사람들도 이해하고 납득할 수 있는 설명의 구조를 만들어 놓는 것이 매우 매우 중요하다는 것입니다.

08 . 그래야 함께 협업하는 사람들이 봤을 때 우리는 왜 이런 결정을 했는지에 대해 의견을 모으거나 반론을 제시할 수 있고 또 다른 작업을 이어갈 때 무엇을 참고하고 무엇을 디벨롭 할지를 선택할 수 있습니다. 만약 귀찮다는 이유로, 시간이 없다는 이유로, 비효율적이라는 이유로 이 과정을 생략하면 함께 일하는 누군가는 매번 맨땅에 헤딩하듯 처음부터 새로 고민하고 다시 쌓아 올려야 하기 때문입니다. 따지고 보면 이만큼 비효율적인 것도 없죠.

09 . 그러니 본인이 되었건 아니면 함께 일하는 주위의 누군가이건 간에 크리에이티브를 추구하는 사람이 있다면 그 장점에 비해 단점 역시 명확히 인지하고 이를 잘 보완할 수 있는 노력을 해야 함이 분명합니다. 그리고 제가 이런 말씀을 드리는 이유 역시 '크리에이티브 한 사람은 이런 단점이 있습니다'라는 의미가 아닌 '크리에이티브를 추구하다 보면 이런 함정에 쉽게 빠질 수도 있습니다'라는 것이니 비판 모드보다는 주의 모드로 인지해 주시기를 부탁드리는 바입니다.

10 . 예전에 함께 일하던 디자이너 한 분이 이런 말씀을 하셨습니다.
"저는 제가 격일제로 크리에이티브할 수 있으면 좋겠어요. 월, 수, 금은 희번뜩한 영감을 막 떠올릴 수 있으면 좋겠고 화, 목에는 그걸 객관적으로 평가하고 바라볼 수 있는 메타인지를 발휘할 수 있으면 좋겠거든요."
듣고 나서 한참을 웃었던 기억이 나지만 저는 그 자체만으로도 아주 훌륭한 자질을 가진 인재라고 생각했습니다. 좋은 크리에이티브에 대한 욕심과 무엇을 조심해야 할지 아는 통찰력을 함께 가지고 있는 것으로 보였으니 말입니다. 이렇게 밸런스를 잘 잡아가려고 스스로 노력하는 사람에 어쩌면 좋은 영감이 더 많이, 더 자주 찾아가는 것은 아닐까요?

01 . 직업적, 직무적 특성상 제 주위에는 크리에이티브 한 분들이 많습니다. 가끔 '진짜 대단하다. 어떻게 저렇게 풀어낼 수 있을까?' 싶을 정도로 본인의 생각을 뛰어난 결과물로 표현해 내는 분들도 많이 계시죠. 그럴 땐 좋은 인풋과 자극을 주는 사람들이 곁에 있다는 사실만으로도 늘 긴장하게 되고 한편으로는 제가 하는 일에 더 큰 애착도 느낄 수 있어 여러모로 운이 좋다고 여겨질 때가 많습니다. 02 . 하지만 모든 것에는 장단이 존재하듯이 크리에이티브 한 사람들에게도 단점은 존재합니다. 물론 이 역시 그저 지극히 개인적인 경험에서 비롯된 것이기에 마냥 일반화하기 어렵고, 마치 수박의 씨처럼 큰 장점들 속에 콕콕 박혀있는 작디작은 부분일지 모르기에 조심스러운 맘이 앞서지만 때로는 부족한 포인트를 짚고 넘어가는 것도 중요하단 생각이 들었습니다. 그래서 오늘은 크리에이티브 한 사람들이 쉽게 빠질 수 있는 함정에 대한 이야기를 한 번 해보려고 합니다. 03 . 가장 먼저 주의해야 할 부분은 '뭔가 설명하는 것을 귀찮아하는 습성'입니다. 크리에이티브 한 사람들 중에는 후천적으로 길러진 역량을 가진 사람도 있지만 분명 타고난 능력을 갖춘 사람도 있습니다. 그런데 이들의 경우 자신이 가진 능력을 빠르게 결과물로 전화할 수 있는 역량이 크기 때문에 누군가에게 이 과정을 잘 설명해 주거나 이해시키려고 하지 않습니다. 오히려 '이상하다. 왜 다른 사람들은 이렇게 못하지?'라는 생각으로 그냥 본인이 모든 일을 해결하려는 경향까지 보이고 말죠. 이건 예술가에겐 탁월함일지 모르지만 협업을 해야 하는 우리 같은 사람들에게는 꽤 치명적인 단점이 되기도 합니다. 04 . 그리고 이런 성향은 '프로세스나 시스템을 만드는 것에 부정적인 뉘앙스'를 보이는 것으로 발현되기도 합니다. 본인들에겐 좋은 과정을 만들어 놓는 것, 다른 사람이나 뒤따라오는 후배들도 배우고 익힐 수 있도록 공유하는 것보다 우선 멋진 결과물을 창작해 내는 것이 더 중요하기 때문이죠. 물론 프로세스나 툴, 시스템 등이 그런 뛰어난 역량을 가진 사람들의 발목을 잡는 역할을 해서는 안 되겠지만 효율화와 내재화라는 측면에서는 크리에이티브도 어느 정도 체계를 갖출 필요는 반드시 있습니다. 05 . 더불어 개인적으로는 이게 가장 치명적인 단점이라고 생각하는데요, 창의적인 사람들의 경우 본인이 확신하는 영감이 올 때까지 스스로 작업에 딜레이를 거는 경우가 있습니다, 즉 조금이라도 더 좋은 결과를 만들어 내고자 조금이라도 더 디테일을 붙잡고 있고자 하는 과정에서 데드라인을 못 맞추는 경우가 빈번해진다는 것이죠. 저는 농담반 진담반으로 '레오나르도 다빈치를 무한 존경할 수 없는 유일한 이유 중 하나는 그가 데드라인을 못 맞추는 사람이었기 때문'이라는 말을 하는데, 조직에서 공동의 목표를 위해 함께 일해야 하는 사람들에겐 말해 무엇할까요... 일정이 지나고 나면 크리에이티브도 크리에이티브할 수 없는 것이니 말입니다. 06 . 마지막은 바로 '다름을 위한 다름'입니다. 이건 어느 정도 예상하실 수 있겠지만 크리에이티브를 표방하는 사람들은 언제나 새로움에 대한 갈망이 큽니다. 물론 이 자체로도 훌륭한 자질이라고 할 수 있겠으나 때로는 이런 기질이 기존의 작업물과 무조건 다른 방식을 따라야 한다는 강박으로 이어지기도 하죠. 그래서 심지어 자신이 담당한 작업물마저 부정의 부정을 거듭하며 모두 레거시로 만들어버리는 실수를 범하기도 합니다. 늘 새로워야 한다는 것도 과거에 대한 명확한 회고와 가치 판단에 따른 것이어야 함을 잊어서는 안되는 이유죠. 07 . 여러 가지 단점을 열거해 봤지만 저는 이런 함정에 빠지지 않기 위해서는 딱 하나의 능력이 필요하다고 생각합니다. 바로 내 머릿속에 있는 추상적인 개념을 곧바로 작업물로 옮기기 전에 꼭 이 변환의 과정을 공통의 언어로 기록하는 것이죠. 쉽게 설명하자면 A라는 생각이 어떻게 B라는 과정으로 옮겨졌는지 그리고 왜 그렇게 하기로 결정한 것인지에 대해 다른 사람들도 이해하고 납득할 수 있는 설명의 구조를 만들어 놓는 것이 매우 매우 중요하다는 것입니다. 08 . 그래야 함께 협업하는 사람들이 봤을 때 우리는 왜 이런 결정을 했는지에 대해 의견을 모으거나 반론을 제시할 수 있고 또 다른 작업을 이어갈 때 무엇을 참고하고 무엇을 디벨롭 할지를 선택할 수 있습니다. 만약 귀찮다는 이유로, 시간이 없다는 이유로, 비효율적이라는 이유로 이 과정을 생략하면 함께 일하는 누군가는 매번 맨땅에 헤딩하듯 처음부터 새로 고민하고 다시 쌓아 올려야 하기 때문입니다. 따지고 보면 이만큼 비효율적인 것도 없죠. 09 . 그러니 본인이 되었건 아니면 함께 일하는 주위의 누군가이건 간에 크리에이티브를 추구하는 사람이 있다면 그 장점에 비해 단점 역시 명확히 인지하고 이를 잘 보완할 수 있는 노력을 해야 함이 분명합니다. 그리고 제가 이런 말씀을 드리는 이유 역시 '크리에이티브 한 사람은 이런 단점이 있습니다'라는 의미가 아닌 '크리에이티브를 추구하다 보면 이런 함정에 쉽게 빠질 수도 있습니다'라는 것이니 비판 모드보다는 주의 모드로 인지해 주시기를 부탁드리는 바입니다. 10 . 예전에 함께 일하던 디자이너 한 분이 이런 말씀을 하셨습니다."저는 제가 격일제로 크리에이티브할 수 있으면 좋겠어요. 월, 수, 금은 희번뜩한 영감을 막 떠올릴 수 있으면 좋겠고 화, 목에는 그걸 객관적으로 평가하고 바라볼 수 있는 메타인지를 발휘할 수 있으면 좋겠거든요."듣고 나서 한참을 웃었던 기억이 나지만 저는 그 자체만으로도 아주 훌륭한 자질을 가진 인재라고 생각했습니다. 좋은 크리에이티브에 대한 욕심과 무엇을 조심해야 할지 아는 통찰력을 함께 가지고 있는 것으로 보였으니 말입니다. 이렇게 밸런스를 잘 잡아가려고 스스로 노력하는 사람에 어쩌면 좋은 영감이 더 많이, 더 자주 찾아가는 것은 아닐까요?

크리에이티브 한 사람들이 주의해야 할 함정들

7번 내용이 많이 공감됩니다. 크리에이티브를 떠나 기획을 하다보면 일정에 쫓겨 핵심 가치를 설명하는것을 등한시하고 기능적 요구사항만을 우선적으로 작성하고 전달하게 되는데, 왜 이런 기획안이 나오게 되었는지를 기록으로 남겨두지 않으면 기능의 가치보다 편리함에 포커스가 맞춰지는 경우가 많았던 것 같습니다.
결과에 도달하게된 과정을 틈틈이 기록하고 잘 정리해서 문서에 담을 수 있는 기획자가 되도록 짚어주신 내용들을 잘 담아두려 합니다!
좋은 생각 나눠주셔서 감사합니다! 🙇‍♂️

 * 2024년 06월 23일. 오늘로서 구글 팟캐스트 서비스가 종료됩니다. 사용자수가 줄어들어서 어쩔 수 없다고 하지만 개인적으로 잘 쓰고 있는 유저로서는 아쉽네요.
 * 안드로이드 유저는 어디에서 해외 팟캐스트를 들어야 할까요? 스포티파이 팟캐스트도 유료 구독을 해야하지만 들을 수 있는 구조인거 같고, 애플 팟캐스트는 안드로이드에서는 사용할 수 없네요.

<ul ><li>2024년 06월 23일. 오늘로서 구글 팟캐스트 서비스가 종료됩니다. 사용자수가 줄어들어서 어쩔 수 없다고 하지만 개인적으로 잘 쓰고 있는 유저로서는 아쉽네요.</li><li>안드로이드 유저는 어디에서 해외 팟캐스트를 들어야 할까요? 스포티파이 팟캐스트도 유료 구독을 해야하지만 들을 수 있는 구조인거 같고, 애플 팟캐스트는 안드로이드에서는 사용할 수 없네요.</li></ul>

구글 팟캐스트 종료 😭

유튜브 부서로 핏캐스트 사업이 이전된걸로 얼핏 들었는데. 유튜브 서비스 내에 팟캐스트 메뉴가 생기지 않았나요?

덧) 스샷처럼 유튜브 뮤직에 생긴걸로 알아요.

MSV 소셜임팩트 '시니어' 시리즈를 읽고 | 고연령 사용자가 디지털 기기 사용에 익숙하지 않은 것이 시력, 청각, 운동능력 등 신체적인 기능 저하에만 따른 것으로 여기는 것은 가장 큰 오해다. - 컴퓨터 공학자 제프 존슨(Jeff Johnson) 우리는 노인을 위한 디자인에서 흔히 신체적 노화와 퇴화에 중점을 둡니다.

18화 고령 UX의 진짜 문제는 시력과 청각이 아니라고?

고연령 사용자가 디지털 기기 사용에 익숙하지 않은 이유는 단순히 신체적 기능 저하 때문만은 아닙니다. 사실 유년기에 형성된 멘탈 모델이 현대의 디지털 인터페이스와 맞지 않기 때문이죠. 시니어들이 유독 세 줄의 메뉴 버튼이나 아이콘을 이해하는 데 어려움을 겪는 것도 이러한 이유입니다.

- 멘탈 모델 차원에서 보면 정보가 숨어있는 위계적인 UX는 물리 버튼에 익숙한 시니어의 멘탈 모델과 잘 맞지 않습니다.
- 보이스 어시스턴트를 선호하는 이유도 멘탈 모델과 관련이 있습니다.

👉 [더 읽기](https://brunch.co.kr/@cliche-cliche/233)

고연령 사용자가 디지털 기기 사용에 익숙하지 않은 이유는 단순히 신체적 기능 저하 때문만은 아닙니다. 사실 유년기에 형성된 멘탈 모델이 현대의 디지털 인터페이스와 맞지 않기 때문이죠. 시니어들이 유독 세 줄의 메뉴 버튼이나 아이콘을 이해하는 데 어려움을 겪는 것도 이러한 이유입니다. - 멘탈 모델 차원에서 보면 정보가 숨어있는 위계적인 UX는 물리 버튼에 익숙한 시니어의 멘탈 모델과 잘 맞지 않습니다.- 보이스 어시스턴트를 선호하는 이유도 멘탈 모델과 관련이 있습니다. 👉 [더 읽기](https://brunch.co.kr/@cliche-cliche/233)

Brunch Story

고령 UX의 진짜 문제는 시력과 청각이 아니라고? 🤔

계란후라이 971

🏃🏻‍♀️ 순발력이 부족한 사람이 롤플레이 면접에 대처하는 방법
직무에 관계없이 채용 면접을 진행하는 중 입사 지원자에게 상황을 가정하여 본인 생각을 이야기해 보라는 질문을 받을 수 있습니다. 입사하게 된다면 진짜 마주해야 하는 현실적인 문제를 입사 지원자에게 미리 보여 주는 것입니다. 그리고 실제 일어날 수 있는 문제를 합리적으로 해결 가능한 지식과 경험이 있는 사람인지 확인하는 목적의 질문입니다.

면접에서 받는 거의 모든 질문이 어렵지만, 특히 위와 같은 미래 가정형 질문은 숱한 면접을 치러 온 저 같은 능구렁이에게도 어렵습니다. 왜 어렵냐면 머릿속에 있는 지식과 경험을 갑자기 불러와 정리된 말로 설명해야 하기 때문입니다. 분명히 뇌라는 기억장치 안에 질문받은 내용에 대한 지식과 경험이 있는데, 다양한 내용 중 가장 적합한 어떤 내용을 꺼내야 하는지 헷갈립니다.
가뜩이나 면접 상황이 긴장되는 데 예상하지 못한 질문을 받으면 더 당황하여 빠르게 대처하지 못하여 횡설수설하게 됩니다. 이는 순발력이라고 하는 순간적으로 판단하여 말하거나 행동하는 능력입니다. 저는 근육의 순발력은 제법 괜찮은 편인데, 말하는 순발력은 많이 아쉽습니다. 그래서 미리 생각해 보았거나 이전에 비슷한 내용으로 말해 본 경험이 있는 준비된 말하기는 잘하지만, 갑자기 누가 묻는 말에 답변은 그렇게 잘하지 못하는 편입니다. 따라서 저와 같이 말하기 순발력이 부족하다고 생각하는 분들이 계시다면 면접을 대비하여 입사 지원하는 회사와 직무에 대한 정보를 비탕으로 상상 훈련을 해보시길 추천해요.

시뮬레이션은 실제 일어날 수 있는 상황을 모의실험을 통해 결과를 예측해 보는 것입니다. 입사 지원한 회사로 첫 출근 순간부터 입사 후 일주일, 한 달, 3개월, 6개월, 1년의 모습을 상상하여 그려 보는 것입니다. 특히 채용공고에서 확인할 수 있는 주요 업무 내용을 바탕으로 입사 후 어떤 일을 하게 될지, 업무를 하면서 어떤 어려움을 겪게 될지 예측해 보고 어려움을 극복할 방안을 미리 고민해 봐야 합니다.

이와 같은 상상 훈련이 좋은 이유는 면접 대비 효과뿐만 아니라 입사 지원하는 역할이 자신과 잘 맞는지, 자신이 해결 가능한 미션이 맞는지 판단할 수 있습니다.
만약 미션을 잘 수행하지 못한 것 같다면 해당 포지션이 자신에게 얼마나 매력적인지에 관계없이 도전하지 않는 것이 맞습니다.
실제로 해보지 않으면 모르는 것 아니냐고 반문할 수 있겠지만, 우리의 지식과 경험이라는 데이터를 근거로 상상했을 때 잘 해결되지 않은 문제라면, 실제 입사 후 상상으로 떠올린 문제를 현실로 마주했을 때 높은 확률로 문제 해결이 어려울 것입니다.

미래는 예측하기 어렵습니다. 외부 환경의 변화와 내부 사정에 따라 조건값이 달라지기 때문입니다.
현재의 상황을 가정하여 해결해야 하는 문제를 풀기 어렵다면, 미래에 예측할 수 없는 우리에게 주어질 실전 문제는 더 어렵다고 생각합니다.
영업 직무라면 고객에게 제품을 파는 상상을,
서비스 기획 직무라면 문제 발견과 개선 방법을,
전략을 수립하는 직무라면 시장 분석과 미래 성장을 그려 볼 수 있어야 합니다.

취업과 이직은 이렇게 만만하지 않습니다.

계란후라이 971 🏃🏻‍♀️ 순발력이 부족한 사람이 롤플레이 면접에 대처하는 방법직무에 관계없이 채용 면접을 진행하는 중 입사 지원자에게 상황을 가정하여 본인 생각을 이야기해 보라는 질문을 받을 수 있습니다. 입사하게 된다면 진짜 마주해야 하는 현실적인 문제를 입사 지원자에게 미리 보여 주는 것입니다. 그리고 실제 일어날 수 있는 문제를 합리적으로 해결 가능한 지식과 경험이 있는 사람인지 확인하는 목적의 질문입니다.​면접에서 받는 거의 모든 질문이 어렵지만, 특히 위와 같은 미래 가정형 질문은 숱한 면접을 치러 온 저 같은 능구렁이에게도 어렵습니다. 왜 어렵냐면 머릿속에 있는 지식과 경험을 갑자기 불러와 정리된 말로 설명해야 하기 때문입니다. 분명히 뇌라는 기억장치 안에 질문받은 내용에 대한 지식과 경험이 있는데, 다양한 내용 중 가장 적합한 어떤 내용을 꺼내야 하는지 헷갈립니다.가뜩이나 면접 상황이 긴장되는 데 예상하지 못한 질문을 받으면 더 당황하여 빠르게 대처하지 못하여 횡설수설하게 됩니다. 이는 순발력이라고 하는 순간적으로 판단하여 말하거나 행동하는 능력입니다. 저는 근육의 순발력은 제법 괜찮은 편인데, 말하는 순발력은 많이 아쉽습니다. 그래서 미리 생각해 보았거나 이전에 비슷한 내용으로 말해 본 경험이 있는 준비된 말하기는 잘하지만, 갑자기 누가 묻는 말에 답변은 그렇게 잘하지 못하는 편입니다. 따라서 저와 같이 말하기 순발력이 부족하다고 생각하는 분들이 계시다면 면접을 대비하여 입사 지원하는 회사와 직무에 대한 정보를 비탕으로 상상 훈련을 해보시길 추천해요.​시뮬레이션은 실제 일어날 수 있는 상황을 모의실험을 통해 결과를 예측해 보는 것입니다. 입사 지원한 회사로 첫 출근 순간부터 입사 후 일주일, 한 달, 3개월, 6개월, 1년의 모습을 상상하여 그려 보는 것입니다. 특히 채용공고에서 확인할 수 있는 주요 업무 내용을 바탕으로 입사 후 어떤 일을 하게 될지, 업무를 하면서 어떤 어려움을 겪게 될지 예측해 보고 어려움을 극복할 방안을 미리 고민해 봐야 합니다.​이와 같은 상상 훈련이 좋은 이유는 면접 대비 효과뿐만 아니라 입사 지원하는 역할이 자신과 잘 맞는지, 자신이 해결 가능한 미션이 맞는지 판단할 수 있습니다.만약 미션을 잘 수행하지 못한 것 같다면 해당 포지션이 자신에게 얼마나 매력적인지에 관계없이 도전하지 않는 것이 맞습니다.실제로 해보지 않으면 모르는 것 아니냐고 반문할 수 있겠지만, 우리의 지식과 경험이라는 데이터를 근거로 상상했을 때 잘 해결되지 않은 문제라면, 실제 입사 후 상상으로 떠올린 문제를 현실로 마주했을 때 높은 확률로 문제 해결이 어려울 것입니다.​미래는 예측하기 어렵습니다. 외부 환경의 변화와 내부 사정에 따라 조건값이 달라지기 때문입니다.현재의 상황을 가정하여 해결해야 하는 문제를 풀기 어렵다면, 미래에 예측할 수 없는 우리에게 주어질 실전 문제는 더 어렵다고 생각합니다.영업 직무라면 고객에게 제품을 파는 상상을,서비스 기획 직무라면 문제 발견과 개선 방법을,전략을 수립하는 직무라면 시장 분석과 미래 성장을 그려 볼 수 있어야 합니다.​취업과 이직은 이렇게 만만하지 않습니다.

꿈을 찾는 사람에게 보내는 158 번째 편지

지난 <LLM의 위치 에너지가 변하고 있다> 포스팅에서 말씀드린 세일즈포스의 LLM 평가 프레임워크가 태블로 대시보드를 통해 공개되었습니다.

아래 링크를 클릭해 보시면 "실제 CRM 데이터를 사용하여 정확성, 비용, 속도, 신뢰 및 안전의 네 가지 주요 영역에서 15개 정도의 LLM, SLM을 평가하는데 꽤 재밌습니다.

저도 시나리오에 기반한 평가결과를 보았는데요. 제 시나리오는 CRM에서 가장 많이 사용하는 "영업활동 관련 메일 내용을 자동으로 요약하는 과정에 대해 ChatGPT-4o, 소형 Llama 3 8B, Gemini Pro 1.5를 '정확도', '비용', '속도', '신뢰/안전도'를 평가표를 보았습니다.

첨부한 화면을 보시면 잘 이해하실 듯 합니다.
정확도에서는 ChatGPT-4o, 신뢰/안전도 에서는 Gemini Pro 1.5가 근소하게 앞서지만, 전체적인 평가에선 소형모델인 Llama 3 8B가 훨씬 비용 대비 효율적(기업에서 가장 선호하는 핵심평가 요소) 입니다. 비싼 비용과 큰 덩치에 따른 상대적 느린 속도를 가진 LLM의 선택에 신중해 진다는 의미입니다.

물론 특정 시나리오 평가 상황임을 염두하시면서 여러분이 직접 평가표를 참고해 보시면 좋을 듯 합니다.

이런 평가 결과는 조직에 큰 가치를 가지며, 이러한 결과를 활용하여 제품 경쟁력과 고객 경험을 개선할 수 있겠지요.

지난 포스팅에서 강조하여 말씀드렸 듯 이런 벤치마크가 중요한 애플리케이션 공급 빅테크에서 지속적으로 나옴에 따라 헤게모니의 무게중심은 빠르게 변하게 될 것으로 예측해 봅니다.

저 글로벌 대표 LLM들 중에 하이퍼클로바 X는 보이지 않습니다. 제대로 국제 리그 평가전을 치뤄봐야 개선점도 나오고 인지도도 생길텐데요. 그냥 한국만 사용하는 네이버 포털, 카카오 톡처럼 되지 않을까 염려가 됩니다.

(세일즈포스의 CRM용 LLM 벤치마크 대시보드: https://public.tableau.com/app/profile/tableausalesstrategy/viz/LLMBenchmarkforCRM/ResultsOverview)

지난 &lt;LLM의 위치 에너지가 변하고 있다&gt; 포스팅에서 말씀드린 세일즈포스의 LLM 평가 프레임워크가 태블로 대시보드를 통해 공개되었습니다. 아래 링크를 클릭해 보시면 "실제 CRM 데이터를 사용하여 정확성, 비용, 속도, 신뢰 및 안전의 네 가지 주요 영역에서 15개 정도의 LLM, SLM을 평가하는데 꽤 재밌습니다. 저도 시나리오에 기반한 평가결과를 보았는데요. 제 시나리오는 CRM에서 가장 많이 사용하는 "영업활동 관련 메일 내용을 자동으로 요약하는 과정에 대해 ChatGPT-4o, 소형 Llama 3 8B, Gemini Pro 1.5를 '정확도', '비용', '속도', '신뢰/안전도'를 평가표를 보았습니다. 첨부한 화면을 보시면 잘 이해하실 듯 합니다. 정확도에서는 ChatGPT-4o, 신뢰/안전도 에서는 Gemini Pro 1.5가 근소하게 앞서지만, 전체적인 평가에선 소형모델인 Llama 3 8B가 훨씬 비용 대비 효율적(기업에서 가장 선호하는 핵심평가 요소) 입니다. 비싼 비용과 큰 덩치에 따른 상대적 느린 속도를 가진 LLM의 선택에 신중해 진다는 의미입니다. 물론 특정 시나리오 평가 상황임을 염두하시면서 여러분이 직접 평가표를 참고해 보시면 좋을 듯 합니다. 이런 평가 결과는 조직에 큰 가치를 가지며, 이러한 결과를 활용하여 제품 경쟁력과 고객 경험을 개선할 수 있겠지요. 지난 포스팅에서 강조하여 말씀드렸 듯 이런 벤치마크가 중요한 애플리케이션 공급 빅테크에서 지속적으로 나옴에 따라 헤게모니의 무게중심은 빠르게 변하게 될 것으로 예측해 봅니다. 저 글로벌 대표 LLM들 중에 하이퍼클로바 X는 보이지 않습니다. 제대로 국제 리그 평가전을 치뤄봐야 개선점도 나오고 인지도도 생길텐데요. 그냥 한국만 사용하는 네이버 포털, 카카오 톡처럼 되지 않을까 염려가 됩니다. (세일즈포스의 CRM용 LLM 벤치마크 대시보드: https://public.tableau.com/app/profile/tableausalesstrategy/viz/LLMBenchmarkforCRM/ResultsOverview)

<세일즈포스 CRM용 LLM 평가 대시보드 공개>

New benchmark and leaderboard give businesses the guidance they need to make smart decisions when evaluating generative AI models for their CRM

Salesforce Announces the World's First LLM Benchmark for CRM

세일즈포스로 부터 매우 의미있는 발표가 나왔습니다.

애플 인텔리전스가 쏘아올린 '내 프로덕트를 완성하기 위해 LLM은 내 선호에 따라 언제라도 여러개의 선택 중 갈아끼울 수 있는 확장 모듈 팩처럼 사용" 하는 결정에 세일즈포스도 비슷한 움직임을 보입니다.

2주전 <세일즈포스의 20%주가 폭락이 시사하는 바>에서 예측한데로, 지금은 무게중심과 시장 주도권이 LLM벤더에게 있어 보이지만, 멀지 않아 LLM이 공공재처럼 (예전의 검색엔진이 하이프였던 것과 비슷) 취급되면, 기업의 데이터와 업무 프로세스, 규정준수가 훨씬 더 크게 보이고 다시 무게중심이 예전으로 돌아올 것이라고 말씀드린바 있습니다.

이 예측을 세일즈포스가 가장 먼저 공격적으로 치고 나갑니다. (사실 비슷한 B2B 빅테크인 SAP와 오라클도 비슷한 행보와 발표를 예정하고 있습니다.)

*발표의 핵심을 짧게 줄여 이야기 하면 이겁니다.
"기업이 비즈니스 애플리케이션에 사용할 LLM을 선택할 때 무엇이 좋은지 고객 정보에 입각한 의사 결정을 내릴 수 있도록 지원하는 벤치마크를 우리가 해 줄게" 입니다. 그리고 그 벤치마크 프레임워크를 내놓는 다는 발표입니다.
이게 왜 의미가 있냐하면요. 기업 고객을 아는 분이면 아주 쉽게 이해가 되는데요.

----고객은 단순히 LLM 성능이 좋은 최고의 모델만을 원하는 것이 아니라, 규정을 준수하고 보안 표준에 적합하며 비용이 많이 들지 않는 최고의 모델이 무엇인지를 본인들의 데이터와 업무 프로세스에서 확인하고자 합니다.--
즉 기업에서 비즈니스 애플리케이션을 위한 LLM을 선택하는 것은 비용, 정확성, 신뢰 및 안전성, 속도 사이에서 균형을 잡아야 하는 최적화 문제이기 때문입니다.
여러분들도 잘 이해가 되시죠?

LLM으로 ChatGPT가 최고라고 해도 하는게 어디서 무엇과 함께 사용해야 좋은지도 모르고 그냥 도입했다간 비용만 비싸고 큰 낭패를 볼 수도 있기 때문입니다. 작은 기업이라면, 굳이 범용 LLM을 사용하지 않고 작은 오픈소스 모델을 사용해도 충분한 효과를 볼 수 있겠지요.
하지만 그것을 누가 검증해 줄까요?

자동차에 들어가는 카 오디오를 예를 들어 설명해 볼까요.
명품 카 스테레오 벤더는 여럿 있지요. 파이오니어, JBL, Blaupunkt, Kenwood 등등요. 여러 관점에 따라 무엇이 최고인지는 평가가 모두 다를 수 있습니다. 중요한 것은 내 자동차, 내 음악 선호도, 도로 컨디션 등등과 궁합이 잘 맞는 것을 고르는게 최고겠지요.

세일즈포스가 그것을 고르는 벤치마크 프레임워크를 발표했다는 것입니다.
LLM 기술 성능 벤치마크가 아닌, 기업 애플리케이션에서 기술 스택의 일부로서 다양한 LLM의 장단점을 이해하고 비즈니스 목표와 우선순위에 맞는 정보에 입각한 의사 결정을 내리는 데 도움을 주기 위해 실제 CRM 영업 및 서비스 시나리오와 데이터를 포함한 광범위한 사용 사례를 통해 AI의 실질적인 비즈니스 유용성을 종합적으로 평가하겠다 입니다.
이렇게 하면 사용자들은 훨씬 마음이 놓이게 됩니다. 우리 데이터와 잘 궁합이 맞는 LLM을 고를 수 있으니까요.

현대 제네니스 G80을 사러갔더니 "고객님 음악 청취 성향과 출퇴근 도로사정, 예산 한도를 생각 해 봤을때 이런 오디오시스템이 가장 적합하다고 나왔습니다, 어떻게 하실까요?" 이런 말 들으면 그렇게 결정하지 않으시겠어요?

이렇게 되면 LLM 벤더들은 애플리케이션 벤더의 벤치마크 프레임워크에서 좀 더 좋은 평가를 받기위해 "꼬리를 흔드는" 위치로 내려올겁니다. 그래야 고객들이 사용할테니까요.

ㅎㅎㅎ 무게중심이 제가 예측한 시기보다도 훨씬 빠르게 돌아오고 있는 듯 합니다. 이제 몇 개의 더 큰 빅테크 기업이 비슷한 발표를 하게되면, 헤게모니는 다시 바뀌게 될 듯 합니다.

세일즈포스로 부터 매우 의미있는 발표가 나왔습니다. 애플 인텔리전스가 쏘아올린 '내 프로덕트를 완성하기 위해 LLM은 내 선호에 따라 언제라도 여러개의 선택 중 갈아끼울 수 있는 확장 모듈 팩처럼 사용" 하는 결정에 세일즈포스도 비슷한 움직임을 보입니다. 2주전 &lt;세일즈포스의 20%주가 폭락이 시사하는 바&gt;에서 예측한데로, 지금은 무게중심과 시장 주도권이 LLM벤더에게 있어 보이지만, 멀지 않아 LLM이 공공재처럼 (예전의 검색엔진이 하이프였던 것과 비슷) 취급되면, 기업의 데이터와 업무 프로세스, 규정준수가 훨씬 더 크게 보이고 다시 무게중심이 예전으로 돌아올 것이라고 말씀드린바 있습니다. 이 예측을 세일즈포스가 가장 먼저 공격적으로 치고 나갑니다. (사실 비슷한 B2B 빅테크인 SAP와 오라클도 비슷한 행보와 발표를 예정하고 있습니다.) *발표의 핵심을 짧게 줄여 이야기 하면 이겁니다."기업이 비즈니스 애플리케이션에 사용할 LLM을 선택할 때 무엇이 좋은지 고객 정보에 입각한 의사 결정을 내릴 수 있도록 지원하는 벤치마크를 우리가 해 줄게" 입니다. 그리고 그 벤치마크 프레임워크를 내놓는 다는 발표입니다.이게 왜 의미가 있냐하면요. 기업 고객을 아는 분이면 아주 쉽게 이해가 되는데요. ----고객은 단순히 LLM 성능이 좋은 최고의 모델만을 원하는 것이 아니라, 규정을 준수하고 보안 표준에 적합하며 비용이 많이 들지 않는 최고의 모델이 무엇인지를 본인들의 데이터와 업무 프로세스에서 확인하고자 합니다.--즉 기업에서 비즈니스 애플리케이션을 위한 LLM을 선택하는 것은 비용, 정확성, 신뢰 및 안전성, 속도 사이에서 균형을 잡아야 하는 최적화 문제이기 때문입니다.여러분들도 잘 이해가 되시죠? LLM으로 ChatGPT가 최고라고 해도 하는게 어디서 무엇과 함께 사용해야 좋은지도 모르고 그냥 도입했다간 비용만 비싸고 큰 낭패를 볼 수도 있기 때문입니다. 작은 기업이라면, 굳이 범용 LLM을 사용하지 않고 작은 오픈소스 모델을 사용해도 충분한 효과를 볼 수 있겠지요.하지만 그것을 누가 검증해 줄까요? 자동차에 들어가는 카 오디오를 예를 들어 설명해 볼까요.명품 카 스테레오 벤더는 여럿 있지요. 파이오니어, JBL, Blaupunkt, Kenwood 등등요. 여러 관점에 따라 무엇이 최고인지는 평가가 모두 다를 수 있습니다. 중요한 것은 내 자동차, 내 음악 선호도, 도로 컨디션 등등과 궁합이 잘 맞는 것을 고르는게 최고겠지요. 세일즈포스가 그것을 고르는 벤치마크 프레임워크를 발표했다는 것입니다.LLM 기술 성능 벤치마크가 아닌, 기업 애플리케이션에서 기술 스택의 일부로서 다양한 LLM의 장단점을 이해하고 비즈니스 목표와 우선순위에 맞는 정보에 입각한 의사 결정을 내리는 데 도움을 주기 위해 실제 CRM 영업 및 서비스 시나리오와 데이터를 포함한 광범위한 사용 사례를 통해 AI의 실질적인 비즈니스 유용성을 종합적으로 평가하겠다 입니다.이렇게 하면 사용자들은 훨씬 마음이 놓이게 됩니다. 우리 데이터와 잘 궁합이 맞는 LLM을 고를 수 있으니까요. 현대 제네니스 G80을 사러갔더니 "고객님 음악 청취 성향과 출퇴근 도로사정, 예산 한도를 생각 해 봤을때 이런 오디오시스템이 가장 적합하다고 나왔습니다, 어떻게 하실까요?" 이런 말 들으면 그렇게 결정하지 않으시겠어요? 이렇게 되면 LLM 벤더들은 애플리케이션 벤더의 벤치마크 프레임워크에서 좀 더 좋은 평가를 받기위해 "꼬리를 흔드는" 위치로 내려올겁니다. 그래야 고객들이 사용할테니까요. ㅎㅎㅎ 무게중심이 제가 예측한 시기보다도 훨씬 빠르게 돌아오고 있는 듯 합니다. 이제 몇 개의 더 큰 빅테크 기업이 비슷한 발표를 하게되면, 헤게모니는 다시 바뀌게 될 듯 합니다.

Salesforce

<LLM의 위치에너지가 빠르게 떨어지고 있습니다.>

01 . 우스갯소리인 줄은 알지만 최근에는 시중에 이런 말이 나돈다는 이야기도 들었습니다. '투자자가 아리송해하거든 그 앞에 AI를 붙여라. 나도 그렇게 투자를 따냈다'고 말입니다. 어디까지 진지하게 받아들여야 하는 건지는 잘 모르겠지만 그래도 이런 소리가 떠돌 때는 그만한 이유가 있을 겁니다. 일각에선 2000년 대 초반 닷컴 버블과 같은 사태가 재현되는 것 아니냐는 우려도 있지만 어찌 되었건 우리는 AI의 시대를 살 것이 분명해 보이긴 하니까 말이죠.

02 . 그리고 이에 뒤따르는 말 역시 늘 비슷비슷합니다. '그럼 앞으로의 시대에서 우리는 뭘 해 먹고(?) 살아야 할 것인가'하는 거죠. 물론 여기도 논란은 존재합니다. 인터넷 시대와는 견줄 수 없을 정도로 파급력이 큰 AI 시대에는 무엇을, 어디까지, 얼마나 규제할 것인지에 대한 틀이 마련되어 있지 않기 때문에 지금 당장 뭔가를 칼같이 예측하고 날카롭게 움직이긴 힘들다는 견해도 있거든요. 마치 하늘을 나는 자동차가 기술적으로 구현하기 어렵다기보다 어떻게 날도록 해줄지 그 규칙이 정립되지 못해서 현 수준에 머물고 있다는 말이 떠오르기도 한 대목이었죠.

03 . 저는 이 과정에서 저만의 조심스러운 예측을 하나 덧붙여보려고 합니다. 그러려면 우선 이 말부터 해야 할 것 같은데요, 얼마 전 아주 친한 친구와 대화를 하다가 문득 이런 이야기를 듣게 되었기 때문이죠.
"영화 'HER'를 보다가 든 생각인데 말야, 인간이 AI와 사랑에 빠진다는 게 꼭 영화에서만 일어날 일은 아닌 것 같아. 난 요즘 조금만 성격이 이상한 사람을 보거나 무례한 사람을 보면 '에잇, 이런 내 인공지능 비서보다도 못한 사람 같으니'라는 생각이 먼저 들거든? 그니까 영화처럼 그런 이성적인 딥한 감정까지 느끼지는 않더라도 앞으로는 '당신하고 얘기하느니 차라리 AI와 이야기하는 게 낫겠네요'라는 평가를 받을 각오도 해야 하는 거지."

04 . 그런데 저도 몇 해 전부터 AI 서비스가 본격적으로 각광을 받기 시작한 그 어느 때쯤에 친구와 비슷한 생각을 해본 적이 있습니다. 지금이야 AI가 지능적인 측면이나 기술적인 측면에서 혹은 정보력의 측면에서 인간을 압도하는 것만 상상하지만 무엇보다 가장 큰 문제는 인간보다 더 나은 성품을 갖게 되는 순간일 거라고 보거든요. AI와 성품이라는 말이 이질적으로 느껴질 수도 있겠지만 사실 조금만 따지고 보면 그리 어려운 문제는 아닐 겁니다. 아니, 오히려 앞으로 AI 서비스의 경쟁력 중에 아주 중요한 부분을 차지할 수 있다고 해야 더 맞겠죠.

05 . 단순히는 아까 말씀드린 것처럼 사람과 대화하는 것보다 AI와 대화하는 것이 더 심리적인 안정감을 가져다줄 수 있을 겁니다. 지금이야 대화라는 걸 할 수 있는 상대의 대부분이 실제 사람으로 규정되어 있다 보니 대화에서 느껴지는 기대치 역시 '저 사람도 인간인데 날 다 이해해 줄 수는 없지'가 기저에 깔려 있겠지만 앞으로의 세상은 좀 다를 수 있거든요. (약간 무섭기도 하지만) '대화'의 상대가 꼭 인간일 필요가 없고 심지어 내 주위에 있는 그저 그런 성품의 사람들보다 나은 수준이라면 인간 대신 AI를 택하게 되는 순간은 반드시 오는 것일 테니까요.

06 . 그러니 우리가 미래에 AI에게 받을 위협으로는 꼭 영화 속에 등장하는 것처럼 무서운 터미네이터가 물리적으로 사람을 공격하거나 인공지능 컴퓨터가 마음대로 핵무기 버튼을 누르는 것 같은 극단적인 상황에 앞서 '인간의 기본적인 자질인 성품에서부터 AI에게 밀리는' 장면이 먼저일 수 있습니다. 저 개인적으로 그게 더 비참한 모습이라고도 생각되어 지고요......

07 . 물론 짜증 내고, 화내고, 서운해하고, 후회하는 등의 다양한 감정 기복이 존재하는 게 인간의 본성이고 매력임은 우리 스스로가 잘 알고 있죠. 지금 이 글을 읽으면서도 '그래도 AI와의 대화와 진짜 인간과의 대화를 단순 비교하는 건 무리가 있지'라고 생각할 분들도 있을 테니까요.
하지만 이건 우리 세대까지의 이야기고 태어난 순간부터 AI 세상에서 자라날 다음 세대는 다른 기준을 갖게 됨이 분명할 겁니다. 그들에게는 어느 순간 AI가 내 삶에 들어온 게 아니라 사람과 AI가 함께 있는 세상 속에 본인이 그저 인간으로 태어난 것 뿐인 거니까요. (이렇게 생각하면 더 오싹하죠...?)

08 . 그래서 저는 AI 시대에 우리가 고민할 것은 AI에 밀려 직업을 잃거나, AI에 지나친 의존도를 가지는 경향이 짙어지는 것뿐 아니라 어떻게 하면 AI보다 더 의미 있고, 더 매력적인 페르소나를 유지하며 살 것인가가 아닐까 합니다. 즉, 인간으로서의 격, 말 그대로 내 인격을 잘 관리하고 가꿔나가는 게 한편으로는 AI 시대를 잘 살아가는 전략일 수도 있으니 말이죠.

09 . 아주 오래전에 봐서 어떤 영화인지 정확히 기억나지는 않지만 대충 이런 대사가 있었던 게 어렴풋이 떠오릅니다.
"세상이 고도로 발달하면 우연한 것이 귀하게 대우받게 될 것이다."
곱씹어 보면 참 맞는 말입니다. 아주 미세한 단위까지 예측하고 통제되는 시대에서는 우연함이 발현될 기회가 점점 줄어갈 테니 예측 불가능한 조합들이 만들어내는 재미난 순간들도 현저히 적어질 수 있겠죠.

10 . 그리고 저는 거기에 이런 말도 하나 더 덧붙여보고 싶습니다.
"인간을 대체할 것이 많아지는 세상에선 좋은 인간들이 더 좋은 대우를 받게 될 것이다."라고 말입니다. 사람 사이에서도 배울 것이 더 많고, 얻을 것이 더 많은 사람에게 의지하게 되는 법인데 그 옵션에 사람이 아닌 것들까지 끼어든다면 그 경쟁은 얼마나 치열해지겠습니까. 더불어 그 경쟁에서 인간이 아닌 것들에게 '인격적으로(!)' 밀린다면 그것만큼 슬픈 것도 없겠죠. 그러니 페르소나란 것도, 성품이라는 것도, 인간다움이라는 것도 앞으로의 시대에서는 더더욱 중요한 위치에 오르게 될지도 모릅니다. 그게 우리의 경쟁력을 결정할 수도 있고 말이죠.

01 . 우스갯소리인 줄은 알지만 최근에는 시중에 이런 말이 나돈다는 이야기도 들었습니다. '투자자가 아리송해하거든 그 앞에 AI를 붙여라. 나도 그렇게 투자를 따냈다'고 말입니다. 어디까지 진지하게 받아들여야 하는 건지는 잘 모르겠지만 그래도 이런 소리가 떠돌 때는 그만한 이유가 있을 겁니다. 일각에선 2000년 대 초반 닷컴 버블과 같은 사태가 재현되는 것 아니냐는 우려도 있지만 어찌 되었건 우리는 AI의 시대를 살 것이 분명해 보이긴 하니까 말이죠. 02 . 그리고 이에 뒤따르는 말 역시 늘 비슷비슷합니다. '그럼 앞으로의 시대에서 우리는 뭘 해 먹고(?) 살아야 할 것인가'하는 거죠. 물론 여기도 논란은 존재합니다. 인터넷 시대와는 견줄 수 없을 정도로 파급력이 큰 AI 시대에는 무엇을, 어디까지, 얼마나 규제할 것인지에 대한 틀이 마련되어 있지 않기 때문에 지금 당장 뭔가를 칼같이 예측하고 날카롭게 움직이긴 힘들다는 견해도 있거든요. 마치 하늘을 나는 자동차가 기술적으로 구현하기 어렵다기보다 어떻게 날도록 해줄지 그 규칙이 정립되지 못해서 현 수준에 머물고 있다는 말이 떠오르기도 한 대목이었죠. 03 . 저는 이 과정에서 저만의 조심스러운 예측을 하나 덧붙여보려고 합니다. 그러려면 우선 이 말부터 해야 할 것 같은데요, 얼마 전 아주 친한 친구와 대화를 하다가 문득 이런 이야기를 듣게 되었기 때문이죠."영화 'HER'를 보다가 든 생각인데 말야, 인간이 AI와 사랑에 빠진다는 게 꼭 영화에서만 일어날 일은 아닌 것 같아. 난 요즘 조금만 성격이 이상한 사람을 보거나 무례한 사람을 보면 '에잇, 이런 내 인공지능 비서보다도 못한 사람 같으니'라는 생각이 먼저 들거든? 그니까 영화처럼 그런 이성적인 딥한 감정까지 느끼지는 않더라도 앞으로는 '당신하고 얘기하느니 차라리 AI와 이야기하는 게 낫겠네요'라는 평가를 받을 각오도 해야 하는 거지." 04 . 그런데 저도 몇 해 전부터 AI 서비스가 본격적으로 각광을 받기 시작한 그 어느 때쯤에 친구와 비슷한 생각을 해본 적이 있습니다. 지금이야 AI가 지능적인 측면이나 기술적인 측면에서 혹은 정보력의 측면에서 인간을 압도하는 것만 상상하지만 무엇보다 가장 큰 문제는 인간보다 더 나은 성품을 갖게 되는 순간일 거라고 보거든요. AI와 성품이라는 말이 이질적으로 느껴질 수도 있겠지만 사실 조금만 따지고 보면 그리 어려운 문제는 아닐 겁니다. 아니, 오히려 앞으로 AI 서비스의 경쟁력 중에 아주 중요한 부분을 차지할 수 있다고 해야 더 맞겠죠. 05 . 단순히는 아까 말씀드린 것처럼 사람과 대화하는 것보다 AI와 대화하는 것이 더 심리적인 안정감을 가져다줄 수 있을 겁니다. 지금이야 대화라는 걸 할 수 있는 상대의 대부분이 실제 사람으로 규정되어 있다 보니 대화에서 느껴지는 기대치 역시 '저 사람도 인간인데 날 다 이해해 줄 수는 없지'가 기저에 깔려 있겠지만 앞으로의 세상은 좀 다를 수 있거든요. (약간 무섭기도 하지만) '대화'의 상대가 꼭 인간일 필요가 없고 심지어 내 주위에 있는 그저 그런 성품의 사람들보다 나은 수준이라면 인간 대신 AI를 택하게 되는 순간은 반드시 오는 것일 테니까요. 06 . 그러니 우리가 미래에 AI에게 받을 위협으로는 꼭 영화 속에 등장하는 것처럼 무서운 터미네이터가 물리적으로 사람을 공격하거나 인공지능 컴퓨터가 마음대로 핵무기 버튼을 누르는 것 같은 극단적인 상황에 앞서 '인간의 기본적인 자질인 성품에서부터 AI에게 밀리는' 장면이 먼저일 수 있습니다. 저 개인적으로 그게 더 비참한 모습이라고도 생각되어 지고요...... 07 . 물론 짜증 내고, 화내고, 서운해하고, 후회하는 등의 다양한 감정 기복이 존재하는 게 인간의 본성이고 매력임은 우리 스스로가 잘 알고 있죠. 지금 이 글을 읽으면서도 '그래도 AI와의 대화와 진짜 인간과의 대화를 단순 비교하는 건 무리가 있지'라고 생각할 분들도 있을 테니까요. 하지만 이건 우리 세대까지의 이야기고 태어난 순간부터 AI 세상에서 자라날 다음 세대는 다른 기준을 갖게 됨이 분명할 겁니다. 그들에게는 어느 순간 AI가 내 삶에 들어온 게 아니라 사람과 AI가 함께 있는 세상 속에 본인이 그저 인간으로 태어난 것 뿐인 거니까요. (이렇게 생각하면 더 오싹하죠...?) 08 . 그래서 저는 AI 시대에 우리가 고민할 것은 AI에 밀려 직업을 잃거나, AI에 지나친 의존도를 가지는 경향이 짙어지는 것뿐 아니라 어떻게 하면 AI보다 더 의미 있고, 더 매력적인 페르소나를 유지하며 살 것인가가 아닐까 합니다. 즉, 인간으로서의 격, 말 그대로 내 인격을 잘 관리하고 가꿔나가는 게 한편으로는 AI 시대를 잘 살아가는 전략일 수도 있으니 말이죠. 09 . 아주 오래전에 봐서 어떤 영화인지 정확히 기억나지는 않지만 대충 이런 대사가 있었던 게 어렴풋이 떠오릅니다. "세상이 고도로 발달하면 우연한 것이 귀하게 대우받게 될 것이다."곱씹어 보면 참 맞는 말입니다. 아주 미세한 단위까지 예측하고 통제되는 시대에서는 우연함이 발현될 기회가 점점 줄어갈 테니 예측 불가능한 조합들이 만들어내는 재미난 순간들도 현저히 적어질 수 있겠죠. 10 . 그리고 저는 거기에 이런 말도 하나 더 덧붙여보고 싶습니다. "인간을 대체할 것이 많아지는 세상에선 좋은 인간들이 더 좋은 대우를 받게 될 것이다."라고 말입니다. 사람 사이에서도 배울 것이 더 많고, 얻을 것이 더 많은 사람에게 의지하게 되는 법인데 그 옵션에 사람이 아닌 것들까지 끼어든다면 그 경쟁은 얼마나 치열해지겠습니까. 더불어 그 경쟁에서 인간이 아닌 것들에게 '인격적으로(!)' 밀린다면 그것만큼 슬픈 것도 없겠죠. 그러니 페르소나란 것도, 성품이라는 것도, 인간다움이라는 것도 앞으로의 시대에서는 더더욱 중요한 위치에 오르게 될지도 모릅니다. 그게 우리의 경쟁력을 결정할 수도 있고 말이죠.

AI보다는 매력적인 페르소나를 가져야 할 테니까

요즘 AI 관련 뉴스나 소식들을 많이 접하게 됩니다. 관련분야에 있지 않아서 잘은 모르지만..전문가?들은 AI의 잘못된 방향의 활용 등에 대해 우려를 표하고 이에대한 규제 장치나 제도 등을 마련해야 한다고 말하고 있었습니다. 가짜뉴스?나 가짜 게시물 등등..AI를 다루는 일부 사람들의 잘못된 욕심?이 많은 사람들에게 예상치 못한 결과를 초래할 수 있기 때문일 것입니다. 또한 AI기술이 발전하면서 지능. 기술. 인격? 등등의 여러 면에서 인간보다 나을 수 있고..그에따른 여러 문제가 있을 것입니다. 걱정이 되기도 합니다. 그렇다면 사람도 잘못된 것은..뒤늦게라도 반성하고 고치는 성찰 능력이 있듯이..AI에게도 자신의 잘못된 점을 인지하고..이를 바로잡도록 하는 과거의 실수를 반복하지 않도록 하는.. 자기점검?자아성찰?능력을 갖도록 설계하는 장치나 제도가 있으면 좋겠다는 생각이 들었습니다. 아울러 무엇이든 인간보다 뛰어난..처음부터 완벽한?..차가운AI보다는..인격적으로? 실수도 하고.(그러나 그 실수가 세상과 많은 사람들에게 큰 피해를 주지 않는..) 무언가를 목표 삼아..실행하는 과정에서 시행착오도 겪는..그렇게 반성하고 성찰하고..넘어져도 다시 일어나 자신의 길을 걸어가는..매우 따뜻하고 인간적인? 친구나 멘토. 스승과 같은 삶의 동반자?와 같은 AI를 설계?하고 만들면..어떨까 하는 생각을 해봤습니다. 감사합니다.

그립은 2019년 2월에 나온 국내 최초 라이브 커머스 플랫폼이야. '모바일 홈쇼핑' 아니냐고? 아니, 좀 달라. 홈쇼핑은 TV 같은 가로 화면이잖아. 그립은 최초로 세로 화면을 구현했어. 틱톡TikTok과 더 닮았달까?

'메모장 그림'에서 시작한 국내 최초 라이브 커머스, [그립]의 5년 성장기 | Ep9

Ep9 오늘 콘텐츠에서 인상 깊은 부분은 '메모장 그림'입니다. 개발자들은 김한나 대표가 만든 '메모장 그림'을 프로토타입 가이드라인처럼 앞에 붙여두고 개발을 했다고 하는데요. 스몰 석세스를 만든 방법 중 하나로 소개하고 있습니다. Low-Fi 프로토타입으로도 개발이 가능하고, 초기 계획안이 실제 제품과 크게 다르지 않을 수 있다는 점이 인상 깊습니다.

[김한나 대표의 '스몰 석세스']

 1. 바텀업 Bottom Up 콜드메일
 
 맨땅에 헤딩해야 한다면, 그 분야의 탑 100을 찾아라.
 100위부터 연락하며 정보를 찾으며 1위를 향해 가라.
 
 2. 인사이트 키워드화
 
 일하면서 얻는 배움을 머릿속에 키워드로 남겨라.
 이를 조합하는 과정에서 아이템이 시작된다. (예: 영상 통화, 세로 화면, 참여형)
 
 3. 메모장 프로토타입
 
 일단 가능한 방식으로 구현하라.
 손으로 그린 투박한 그림에서 시작하더라도 하나씩 발전시키면 된다.
 
 4. 제품 구매 포인트
 
 단순히 제품 그 자체를 넘어, 고객 입장에서 제품을 구매할 이유를 만들어라.
 (예: 게이미피케이션, 단골 문화)
 
 5. 성장 속도는 시장 < 기업 < 개인
 
 기업은 시장보다 빠르게, 리더는 그 기업보다 빠르게 성장해야 한다.

https://www.ep9.co/record/114?seq=1&format=cover&share=185e1f0f21

Ep9 오늘 콘텐츠에서 인상 깊은 부분은 '메모장 그림'입니다. 개발자들은 김한나 대표가 만든 '메모장 그림'을 프로토타입 가이드라인처럼 앞에 붙여두고 개발을 했다고 하는데요. 스몰 석세스를 만든 방법 중 하나로 소개하고 있습니다. Low-Fi 프로토타입으로도 개발이 가능하고, 초기 계획안이 실제 제품과 크게 다르지 않을 수 있다는 점이 인상 깊습니다. [김한나 대표의 '스몰 석세스'] <ol ><li>바텀업 Bottom Up 콜드메일 맨땅에 헤딩해야 한다면, 그 분야의 탑 100을 찾아라. 100위부터 연락하며 정보를 찾으며 1위를 향해 가라. </li><li>인사이트 키워드화 일하면서 얻는 배움을 머릿속에 키워드로 남겨라. 이를 조합하는 과정에서 아이템이 시작된다. (예: 영상 통화, 세로 화면, 참여형) </li><li>메모장 프로토타입 일단 가능한 방식으로 구현하라. 손으로 그린 투박한 그림에서 시작하더라도 하나씩 발전시키면 된다. </li><li>제품 구매 포인트 단순히 제품 그 자체를 넘어, 고객 입장에서 제품을 구매할 이유를 만들어라. (예: 게이미피케이션, 단골 문화) </li><li>성장 속도는 시장 &lt; 기업 &lt; 개인 기업은 시장보다 빠르게, 리더는 그 기업보다 빠르게 성장해야 한다.</li></ol> https://www.ep9.co/record/114?seq=1&amp;format=cover&amp;share=185e1f0f21

⟪'메모장 그림' 가이드라인으로 만든 서비스, 그립⟫

에어프레미아 항공사의 개발자는 어떤 사람일까

https://youtu.be/LyuLubzaD7A?si=WqhLOF72a0NdGNbI
"에어프레미아 랩스" 개발자분의 인터뷰 영상을 보았습니다. 짧게 내용을 요약해서 올려봅니다. 댓글에도 달려있지만 내용에서 가장 기억에 남는 것은 개발자분들의 역할이 단순히 IT업무 하는 사람이 아니라 고착화된 산업에 새로운 변화를 가져오는 사람이라는 부분이 인상적입니다. (뱅샐과 토스가 금융의 혁신을 불러와 덕분에 다른 은행앱들의 사용성이 많이 올라간 예시를 설명해줍니다.)

================
에어프레미아는 HSC와 FSC 사이에 위치한 국내 신생 항공사로, 대한항공보다 넓은 좌석을 대한항공의 80% 가격으로 제공하는 하이브리드 서비스 항공사입니다.
💺사용자에게 매우 중요한 가치인 가격을 보다 실용적이고 합리적인 가격으로 유지하여 중요한 가치를 제공하는 데 초점을 맞춘 전략입니다.
🌐항공 산업의 특성상 전 세계 대부분의 항공사는 1900년대부터 사용되어 온 예약 등 다양한 기능을 위한 전용 솔루션을 사용하고 있습니다.
📱에어프레미아는 모바일 앱 개발의 초기 계획 단계에 있으며 잦은 정책 및 노선 변경을 효과적으로 처리하기 위해 '네이티브 플러스 웹뷰' 방식을 사용할 계획입니다.
💡에어프레미아의 CEO의 비전은 IT를 통한 혁신으로 다른 항공사와 차별화하여 기존 항공 산업을 선도하고 변화시키는 것입니다.
🤝레거시 산업을 혁신할 때는 여러 가지 어려움이 발생하고, 서로 다른 문화를 가진 두 조직이 만나면 갈등이 불가피합니다. 하지만 IT팀과 현업 모두 서로를 이해하고 협력하기 위해 노력하고 있습니다.
🎯에어프레미아 랩스 팀은 다양한 현실적인 도전과 문화 충돌에 직면해 있지만 항공과 여행의 혁신이라는 비전을 공유하며 모두가 어려움을 극복하기 위해 열심히 노력하고 있습니다.

이런 도메인에서 일해봐도 재미있을거 같네요!

https://youtu.be/LyuLubzaD7A?si=WqhLOF72a0NdGNbI"에어프레미아 랩스" 개발자분의 인터뷰 영상을 보았습니다. 짧게 내용을 요약해서 올려봅니다. 댓글에도 달려있지만 내용에서 가장 기억에 남는 것은 개발자분들의 역할이 단순히 IT업무 하는 사람이 아니라 고착화된 산업에 새로운 변화를 가져오는 사람이라는 부분이 인상적입니다. (뱅샐과 토스가 금융의 혁신을 불러와 덕분에 다른 은행앱들의 사용성이 많이 올라간 예시를 설명해줍니다.) ================에어프레미아는 HSC와 FSC 사이에 위치한 국내 신생 항공사로, 대한항공보다 넓은 좌석을 대한항공의 80% 가격으로 제공하는 하이브리드 서비스 항공사입니다.💺사용자에게 매우 중요한 가치인 가격을 보다 실용적이고 합리적인 가격으로 유지하여 중요한 가치를 제공하는 데 초점을 맞춘 전략입니다.🌐항공 산업의 특성상 전 세계 대부분의 항공사는 1900년대부터 사용되어 온 예약 등 다양한 기능을 위한 전용 솔루션을 사용하고 있습니다.📱에어프레미아는 모바일 앱 개발의 초기 계획 단계에 있으며 잦은 정책 및 노선 변경을 효과적으로 처리하기 위해 '네이티브 플러스 웹뷰' 방식을 사용할 계획입니다.💡에어프레미아의 CEO의 비전은 IT를 통한 혁신으로 다른 항공사와 차별화하여 기존 항공 산업을 선도하고 변화시키는 것입니다.🤝레거시 산업을 혁신할 때는 여러 가지 어려움이 발생하고, 서로 다른 문화를 가진 두 조직이 만나면 갈등이 불가피합니다. 하지만 IT팀과 현업 모두 서로를 이해하고 협력하기 위해 노력하고 있습니다.🎯에어프레미아 랩스 팀은 다양한 현실적인 도전과 문화 충돌에 직면해 있지만 항공과 여행의 혁신이라는 비전을 공유하며 모두가 어려움을 극복하기 위해 열심히 노력하고 있습니다. 이런 도메인에서 일해봐도 재미있을거 같네요!

YouTube

항공업계의 디지털 혁신, 에어프레미아 랩스가 이끈다

계란후라이 972

취업과 이직을 준비하고 도전하는 분들이 많이 힘들어하고 계신 줄 압니다. 제가 뭐라고 위로의 말을 건네면 좋을지, 어떤 말이 위로가 될 수 있을지 고민입니다.
힘든 것은 지금 직장을 다니고 계신 분들도 만만치 않으시죠. 사람과 문화, 일에 대한 고민으로 밤잠을 설치고 계실 줄 압니다.
우리 모두 어렵고 힘든 시기를 보내고 있습니다.

다만,
어렵고 힘들어도 지금 하고 있는 도전을 절대로 포기하지 않았으면 합니다. 오늘 거절당하고 내일 비교 당해도 절대 우리가 부족해서 그런 것은 아니라고 믿습니다. 지금 힘든 것은 아주 잠깐 찰나의 순간입니다. 행복이 그렇듯 고통도 반짝하고 금방 지나갈 것입니다.
오히려 고난받고 있다고 느끼는 이 시간이 우리에게 기회일 수 있습니다. 평소보다 더 차갑고 냉정하게 상황을 들여다보고 말하며 행동합시다.

눈물 흘리지도 말고 스스로 불쌍하다고 주눅 들어 하지 마세요. 우리를 아프게 하는 사건이 우리의 모든 것을 대변하지 않습니다. 그저 운이 좋지 않아서 길을 걷다가 개가 싼 똥을 밟은 정도로 취급하세요.
그리고 다음을 기대합시다.

다음에 만날 사람과 직장, 일을 기대하세요. 그곳이 어디든 무엇이든 우리에게 최고로 좋은 만남이 될 것입니다.

당장 돈이 없다면 밖으로 나가 일을 합시다. 번듯한 회사 말고도 정직하게 일해서 돈을 벌 수 있는 방법은 넘쳐납니다. 지금껏 해보 않았던 일에 도전해 보세요. 그 일을 통해 배우고 느낀 인사이트가 그다음 여정을 열어 줄 수도 있다고 생각해요.

마음이 급할수록 여유를 갖기 위해 속도를 낮추세요. 빠르게 노력한다고, 우리 의지와 바램과 같은 속도로 진행되지 않습니다. 마음에 여유를 갖고 천천히 둘러보며 가는 겁니다. 빠르게 하느라 놓치고 실수하는 것보다 제대로 꼼꼼하게 하는 것이 훨씬 좋습니다.

주변 사람들에게 밝게 인사해 보세요. 좋은 하루 보내라고 덕담을 건네 보세요. 상대방을 기분 좋게 만드는 것이 우리의 기분을 회복하는 가장 효과적인 방법입니다. 짜증 나면 짜증 내고 슬퍼서 우는 건 성숙하지 못한 어린아이 같은 행동입니다. 어떤 일이 있더라도 감정보다 이성을 갖기 위해 노력해 보아요.

우리에게 기회는 널려 있습니다. 좁은 문을 통과하기 위해 분투하기보다 상대적으로 지금 수월하게 통과할 수 있는 문을 지나갑시다. 비록 목적지에 조금 돌아가는 길 같아 보이지만, 목적지에 못 가거나 중간에 힘들다고 포기하는 것보다 돌고 돌아 목적지에 도달하는 것이 더 좋습니다.

우리 인생 길이 꽈배기처럼 꼬여 있고, 안개가 자욱한 고속도로 같아 보여도 지금 걷고 있는 그 길이 맞습니다. 더듬더듬 엉금엉금 미로와 장애물을 뚫고 가다 보면 우리가 바라고 원했던 곳에 반드시 도달할 수 있다고 믿어요.

제가 뭐라도 되는 사람은 전혀 아니지만, 저라도 여러분에게 작은 힘과 응원이라도 될 수 있다면, 무엇이든 편하게 말씀 주세요. 저 경청 되게 잘 하거든요. 여러분 이야기 무엇이든 다 들어드릴게요. 그리고 도울 수 있는 최선의 도움도 드릴게요. 오늘도 좋은 하루보내세요.
진심으로 응원해요!

계란후라이 972 취업과 이직을 준비하고 도전하는 분들이 많이 힘들어하고 계신 줄 압니다. 제가 뭐라고 위로의 말을 건네면 좋을지, 어떤 말이 위로가 될 수 있을지 고민입니다.힘든 것은 지금 직장을 다니고 계신 분들도 만만치 않으시죠. 사람과 문화, 일에 대한 고민으로 밤잠을 설치고 계실 줄 압니다.우리 모두 어렵고 힘든 시기를 보내고 있습니다.​다만,어렵고 힘들어도 지금 하고 있는 도전을 절대로 포기하지 않았으면 합니다. 오늘 거절당하고 내일 비교 당해도 절대 우리가 부족해서 그런 것은 아니라고 믿습니다. 지금 힘든 것은 아주 잠깐 찰나의 순간입니다. 행복이 그렇듯 고통도 반짝하고 금방 지나갈 것입니다.오히려 고난받고 있다고 느끼는 이 시간이 우리에게 기회일 수 있습니다. 평소보다 더 차갑고 냉정하게 상황을 들여다보고 말하며 행동합시다.​눈물 흘리지도 말고 스스로 불쌍하다고 주눅 들어 하지 마세요. 우리를 아프게 하는 사건이 우리의 모든 것을 대변하지 않습니다. 그저 운이 좋지 않아서 길을 걷다가 개가 싼 똥을 밟은 정도로 취급하세요.그리고 다음을 기대합시다.​다음에 만날 사람과 직장, 일을 기대하세요. 그곳이 어디든 무엇이든 우리에게 최고로 좋은 만남이 될 것입니다.​당장 돈이 없다면 밖으로 나가 일을 합시다. 번듯한 회사 말고도 정직하게 일해서 돈을 벌 수 있는 방법은 넘쳐납니다. 지금껏 해보 않았던 일에 도전해 보세요. 그 일을 통해 배우고 느낀 인사이트가 그다음 여정을 열어 줄 수도 있다고 생각해요.​마음이 급할수록 여유를 갖기 위해 속도를 낮추세요. 빠르게 노력한다고, 우리 의지와 바램과 같은 속도로 진행되지 않습니다. 마음에 여유를 갖고 천천히 둘러보며 가는 겁니다. 빠르게 하느라 놓치고 실수하는 것보다 제대로 꼼꼼하게 하는 것이 훨씬 좋습니다.​주변 사람들에게 밝게 인사해 보세요. 좋은 하루 보내라고 덕담을 건네 보세요. 상대방을 기분 좋게 만드는 것이 우리의 기분을 회복하는 가장 효과적인 방법입니다. 짜증 나면 짜증 내고 슬퍼서 우는 건 성숙하지 못한 어린아이 같은 행동입니다. 어떤 일이 있더라도 감정보다 이성을 갖기 위해 노력해 보아요.​우리에게 기회는 널려 있습니다. 좁은 문을 통과하기 위해 분투하기보다 상대적으로 지금 수월하게 통과할 수 있는 문을 지나갑시다. 비록 목적지에 조금 돌아가는 길 같아 보이지만, 목적지에 못 가거나 중간에 힘들다고 포기하는 것보다 돌고 돌아 목적지에 도달하는 것이 더 좋습니다.​우리 인생 길이 꽈배기처럼 꼬여 있고, 안개가 자욱한 고속도로 같아 보여도 지금 걷고 있는 그 길이 맞습니다. 더듬더듬 엉금엉금 미로와 장애물을 뚫고 가다 보면 우리가 바라고 원했던 곳에 반드시 도달할 수 있다고 믿어요.​제가 뭐라도 되는 사람은 전혀 아니지만, 저라도 여러분에게 작은 힘과 응원이라도 될 수 있다면, 무엇이든 편하게 말씀 주세요. 저 경청 되게 잘 하거든요. 여러분 이야기 무엇이든 다 들어드릴게요. 그리고 도울 수 있는 최선의 도움도 드릴게요. 오늘도 좋은 하루보내세요.진심으로 응원해요!

꿈을 찾는 사람에게 보내는 159 번째 편지

DevToys is a cross-platform Swiss Army knife for developers. DevToys helps in daily tasks like formatting JSON, comparing text, testing RegExp. No need to use many untruthful websites to do simple tasks with your data.

DevToys - A Swiss Army knife for developers

devtoys는 base64 인코딩 디코딩, uuid 생성, html 인코더 디코더, json <-> yaml 변환, 마크다운 프리뷰 등 다양한 기능을 지원하는데요!

전 개발하다가 가끔 구글에서 json2table web.. 이런 식으로 찾아서 볼 때도 있는데..
이 앱 한개로 다 해결돼요!

(무료라서 무조건 좋군요..ㅋㅋㅋㅋ)

https://devtoys.app/

devtoys는 base64 인코딩 디코딩, uuid 생성, html 인코더 디코더, json &lt;-&gt; yaml 변환, 마크다운 프리뷰 등 다양한 기능을 지원하는데요! 전 개발하다가 가끔 구글에서 json2table web.. 이런 식으로 찾아서 볼 때도 있는데.. 이 앱 한개로 다 해결돼요! (무료라서 무조건 좋군요..ㅋㅋㅋㅋ) https://devtoys.app/

Devtoys

개발자라면 이걸 깔아보는 거 어때요?

 1. Materialized Views:
 * 정의:
   * Materialized View(MV)는 쿼리 결과를 저장하고 있는 데이터베이스 객체입니다. 이렇게만 말하면 SQL 데이터베이스에만 국한된 개념처럼 보이지만 좀 더 넓은 개념의 의미로 보면 Materialized View는 데이터의 사본을 미리 계산하고 저장하여 성능을 향상시키는 기법입니다.
 * When to use:
   * 복잡한 쿼리: 여러 조인, 집계 및 계산을 포함하는 복잡한 쿼리라서 데이터를 직접 쿼리하기 어려울 때
   * 반복적인 읽기 작업: 자주 읽히는 데이터의 경우 Materialized View 기법을 통해서 읽기 성능을 향상 시킬 수 있습니다.
   * 데이터 집계: 집계 연산 (Aggregation, 합계, 평균, 개수 등) 에서 Materialized Views 를 통해 사전 집계된 결과를 제공해서 성능을 향상 시킬 수 있습니다.
   * 서로 다른 데이터 저장소의 기능을 활용하기 위해서. 예를 들면 쓰기에 효율적인 데이터 스토어는 데이터를 저장소 역할로 사용하고, 쿼리와 읽기 성능이 좋은 관계형 데이터 스토어에서 Materialized View 를 저장하는 식으로.
 * How to use:
   * SQL 에서의 Materialized View 는 Materialized View 객체를 생성하고, 갱신 전략과 그것에 맞는 갱신 주기를 설정하고 조회하면 됩니다.
   * 추가로 너무 자주 갱신할 경우 성능에 부담이 되고, 너무 늦게 갱신하면 오래된 데이터를 볼 수 있는 문제가 발생할 수 있습니다.
 * Considerations:
   * 갱신 오버헤드: 갱신 시 리소스가 소요되는 걸 고려해서 갱신 전략과 갱신 주기를 설정하세요.
   * Dsposability and Regeneratibility: Materialized View 가 없어지거나 만료되더라도 원본 데이터에서 다시 만들 수 있어야 합니다.
   * Consistency: Materialized View 는 원본 데이터로 만들어진 별도의 캐싱 데이터 이므로 데이터 일관성이 안 맞을 수 있습니다. 이것에 대한 고려도 필요합니다.
   * 원본 데이터가 단순하거나 쿼리하기 쉽다면 이 기법은 적절하지 않을 수 있습니다.

 2. Indexing:
 * 정의:
   * 데이터베이스의 특정 열에 대해 검색 속도를 향상시키기 위해 데이터 구조를 사용하는 전략입니다.
 * When to use:
   * 빈번한 검색: 자주 검색되는 열에 대해 인덱스를 생성하면 검색 성능을 크게 향상시킬 수 있습니다.
   * JOIN 및 WHERE 절: JOIN이나 WHERE 절에서 자주 사용되는 열에 인덱스를 생성하면 쿼리 성능이 향상됩니다.
   * 정렬과 그룹화: ORDER BY나 GROUP BY 구문에서 자주 사용되는 열에 인덱스를 생성하면 성능이 개선될 수 있습니다.
 * How to use:
   * 데이터베이스에서 인덱스를 사용하는 방법은 간단합니다. 인덱스로 사용할 테이블 칼럼을 선택하고 생성만 하면 사용됩니다.
 * Considerations:
   * 인덱스 오버헤드: 인덱스 생성 및 유지 관리에는 추가 저장 공간과 CPU 자원이 필요합니다. 인덱스가 많아지면 데이터 삽입, 업데이트, 삭제 작업의 성능이 저하될 수 있습니다.
   * 인덱스 선택: 모든 열에 인덱스를 생성하는 것은 바람직하지 않습니다. 자주 사용되는 열과 쿼리 성능에 중요한 열에 인덱스를 생성하는 것이 좋습니다.

 3. Denormalziation
 * 정의:
   * 비정규화(Denormalization)는 데이터베이스의 성능을 향상시키기 위해 데이터를 중복 저장하는 전략입니다. 이는 데이터를 정규화하여 중복을 최소화하는 것과 반대되는 개념으로, 특정 쿼리 성능을 최적화하기 위해 데이터를 중복 저장하여 조인을 줄이고 조회 속도를 향상시킵니다.
 * When to use:
   * 읽기 성능 향상: 데이터 읽기 작업이 빈번하고, 읽기 성능이 중요할 때 비정규화를 통해 데이터를 중복 저장하여 조회 속도를 높일 수 있습니다.
   * 복잡한 조인 줄이기: 여러 테이블을 조인하는 복잡한 쿼리를 자주 실행해야 하는 경우, 비정규화를 통해 조인을 줄이고 쿼리 성능을 향상시킬 수 있습니다.
   * 데이터 통합: 서로 다른 데이터 소스에서 데이터를 통합하여 조회할 때, 비정규화를 통해 데이터를 하나의 테이블에 저장하고 조회 성능을 높일 수 있습니다.
 * How to use:
   * 비정규화를 적용하려면 먼저 어떤 데이터가 중복 저장될지 결정해야 합니다. 자주 사용되는 데이터를 식별하고, 해당 데이터를 중복 저장하여 조회 성능을 향상시킵니다.
 * Considerations:
   * 데이터 일관성: 데이터가 중복 저장되므로 일관성을 유지하기 어려울 수 있습니다. 데이터가 변경될 때마다 비정규화된 데이터를 업데이트해야 하므로, 이를 위한 추가적인 로직이 필요합니다
   * 저장 공간 증가: 비정규화는 데이터를 중복 저장하므로 저장 공간 요구량이 증가할 수 있습니다. 데이터베이스의 저장 공간을 충분히 확보해야 합니다.

 4. Vertical Scaling:
 * 정의:
   * Vertical Scaling(수직적 확장)은 기존 서버나 데이터베이스의 하드웨어 사양을 업그레이드하여 성능을 향상시키는 방법입니다. 주로 CPU, RAM, 스토리지와 같은 자원을 추가하거나 교체하는 방식으로 이루어집니다.
 * When to use:
   * 단일 서버의 성능이 충분하지 않을 때: 현재 사용 중인 서버가 증가하는 데이터 처리량을 감당하지 못할 때 수직적 확장을 통해 성능을 향상시킬 수 있습니다.
   * 애플리케이션 구조가 수평적 확장을 지원하지 않을 때: 애플리케이션이 여러 서버에 분산될 수 없는 경우, 단일 서버의 성능을 높이는 것이 효과적입니다.
   * 쉽게 성능 향상이 필요할 때: 하드웨어 업그레이드는 상대적으로 쉽게 성능을 향상시킬 수 있는 방법입니다.
 * How to use:
   * 하드웨어 업그레이드: 서버의 CPU, RAM, 스토리지 등의 하드웨어를 업그레이드합니다.
   * 가상 머신 또는 클라우드 인스턴스 업그레이드: 클라우드 환경에서는 더 높은 사양의 인스턴스로 업그레이드할 수 있습니다.
 * Considerations:
   * 비용: 수직적 확장은 초기 비용이 높을 수 있습니다. 고성능 하드웨어는 높은 비용을 수반하므로 예산을 고려해야 합니다.
   * 확장 한계: 수직적 확장은 물리적 한계가 있습니다. 하드웨어의 최대 성능에 도달하면 더 이상 확장할 수 없으므로, 장기적인 확장성 계획을 고려해야 합니다.
   * 단일 장애점(Single Point of Failure): 단일 서버에 의존하는 경우, 해당 서버가 장애를 일으키면 전체 시스템이 영향을 받을 수 있습니다. 이 경우 고가용성 및 백업 계획을 수립하는 것이 중요합니다.

 5. Caching:
 * 정의:
   * 캐싱 (Caching) 은 자주 조회되는 데이터를 임시 저장소에 저장하여 데이터베이스 접근을 줄이고 응답 시간을 단축시키는 전략입니다. 메모리나 고속 스토리지를 사용하여 데이터를 임시로 저장함으로써 데이터베이스 성능을 향상시킬 수 있습니다.
 * When to use:
   * 자주 조회되는 데이터: 특정 데이터가 자주 조회되는 경우, 캐싱을 통해 데이터베이스 부하를 줄이고 응답 시간을 개선할 수 있습니다.
   * 읽기 성능 최적화: 읽기 작업이 빈번하고, 빠른 응답 시간이 중요한 경우 캐싱을 통해 성능을 최적화할 수 있습니다.
   * 복잡한 쿼리 결과 캐싱: 복잡한 쿼리를 자주 실행해야 하는 경우, 쿼리 결과를 캐싱하여 성능을 향상시킬 수 있습니다.
   * API 응답 속도 개선: 웹 애플리케이션이나 API의 응답 속도를 개선하기 위해 캐싱을 사용할 수 있습니다.
 * How to use:
   * 캐시 설정: 캐시를 설정하려면 먼저 캐시 저장소를 선택합니다. Redis, Memcached, 로컬 메모리 등을 사용할 수 있습니다.
   * 캐시 정책 결정: 캐시 만료 시간(TTL, Time to Live)과 갱신 정책을 설정합니다. 캐시 만료 시간은 데이터의 유효 기간을 결정하며, 갱신 정책은 캐시 데이터가 만료되거나 갱신될 시점을 결정합니다.
   * 데이터 일관성 유지: 캐시된 데이터와 원본 데이터의 일관성을 유지하기 위한 전략을 마련합니다. 원본 데이터가 변경될 때 캐시를 갱신하거나 무효화하는 로직을 구현합니다.
 * Considerations:
   * 캐시 적중률(Cache Hit Rate): 캐시의 효율성을 높이기 위해 캐시 적중률을 모니터링합니다. 캐시 적중률이 낮다면 캐시 정책을 재검토하여 개선합니다.
   * 데이터 일관성: 캐시된 데이터는 원본 데이터가 변경되었을 때 일관성을 유지하기 어려울 수 있습니다. 데이터가 갱신될 때 캐시를 무효화하거나 갱신하는 전략이 필요합니다.
   * 캐시 오버헤드: 캐싱은 추가 저장 공간과 메모리 사용을 필요로 합니다. 캐시 크기를 적절히 관리하여 메모리 사용량을 최적화해야 합니다.
   * TTL 설정: 캐시 만료 시간을 적절히 설정하여 데이터의 최신성과 성능 사이의 균형을 맞춥니다. 너무 짧으면 캐시의 이점을 살리기 어렵고, 너무 길면 오래된 데이터를 반환할 위험이 있습니다.

 6. Replication:
 * 정의:
   * 데이터베이스 복제(Replication)는 데이터베이스의 데이터를 다른 서버에 복제하여 고가용성 및 성능을 향상시키는 전략입니다. 복제된 데이터베이스는 읽기 작업을 분산시키고, 데이터베이스 장애 시에도 시스템을 지속적으로 운영할 수 있도록 합니다.
 * When to use:
   * 고가용성 요구: 시스템의 고가용성이 중요한 경우, 복제를 통해 장애 시에도 서비스가 중단되지 않도록 할 수 있습니다.
   * 읽기 성능 향상: 읽기 작업이 빈번한 경우, 여러 복제본으로 읽기 작업을 분산시켜 성능을 향상시킬 수 있습니다.
   * 백업 및 복구: 데이터를 다른 서버에 복제함으로써 백업 및 복구 작업을 용이하게 할 수 있습니다.
   * 지연시간 향상: 여러 지역에 걸쳐 데이터를 분산하여 사용자에게 더 가까운 서버에서 데이터를 제공할 수 있습니다.
 * How to use:
   * 마스터-슬레이브 복제: 한 서버(마스터)가 쓰기 작업을 처리하고, 다른 서버들(슬레이브)이 읽기 작업을 처리하도록 설정하도록 할 수 있습니다.
   * 다중 리더 복제: 두 개 이상의 서버가 모두 쓰기 및 읽기 작업을 처리할 수 있도록 설정하도록 할 수 있습니다.
   * 비동기 및 동기 복제: 비동기 복제는 성능이 좋지만 데이터 일관성이 떨어질 수 있고, 동기 복제는 데이터 일관성이 높지만 성능이 저하될 수 있습니다. 필요에 따라 선택합니다.
   * 멀티 스레딩 복제: 복제 작업을 병렬로 처리하여 성능을 향상시키는 방법입니다. 슬레이브 서버에서 여러 스레드를 사용하여 마스터의 데이터를 병렬로 복제합니다.
   * 리더 없는 복제(Leaderless Replication): 모든 노드가 동등한 역할을 하여 데이터 읽기 및 쓰기 작업을 분산 처리하는 방식입니다. 주로 NoSQL 데이터베이스에서 사용되며, 각 노드가 독립적으로 작동하여 고가용성과 확장성을 제공합니다.
 * Considerations:
   * 복제 지연: 네트워크 지연이나 복제 설정에 따라 데이터 복제에 시간이 걸릴 수 있습니다. 복제 지연이 발생한다면 최신 데이터 조회의 어려움, 복제 서버의 성능 저하 등이 일어날 수 있기 때문에 복제 지연을 최소화하기 위한 네트워크 설정 및 모니터링이 필요합니다.
   * 데이터 일관성: 비동기 복제는 실시간으로 데이터가 동기화되지 않으므로 일관성 문제가 발생할 수 있습니다. 동기 복제를 통해 데이터 일관성을 유지할 수 있지만 성능에 영향을 줄 수 있습니다.
   * 충돌 해결: 마스터-마스터 복제에서는 동일한 데이터에 대한 충돌이 발생할 수 있습니다. 충돌 해결 정책을 마련해야 합니다.

 7. Shrading:
 * 샤딩(Sharding)은 데이터베이스를 여러 개의 작은 단위(샤드)로 분할하여 각각 독립적인 데이터베이스 서버에 저장하는 전략입니다. 각 샤드는 전체 데이터의 일부를 포함하며, 이를 통해 대규모 데이터베이스의 성능과 확장성을 향상시킬 수 있습니다.
 * When to use:
   * 데이터베이스 크기가 매우 큰 경우: 단일 서버가 전체 데이터를 처리하기 어려운 경우 샤딩을 통해 데이터베이스를 분할하여 처리 성능을 높일 수 있습니다.
   * 높은 트래픽: 많은 사용자가 동시에 데이터베이스에 접근할 때 샤딩을 통해 트래픽을 여러 서버에 분산시킬 수 있습니다.
   * 높은 쓰기/읽기 작업: 데이터 쓰기와 읽기 작업이 많은 경우, 샤딩을 통해 특정 샤드에서만 작업을 처리하여 성능을 최적화할 수 있습니다.
   * 데이터 분리 요구: 지리적 위치나 비즈니스 요구에 따라 데이터를 분리하여 저장해야 할 때 샤딩을 활용할 수 있습니다.
 * How to use:
   * 샤드 키 선택: 데이터를 분할할 기준이 되는 샤드 키를 선택합니다. 일반적으로 사용자 ID, 지역 코드, 타임스탬프 등이 샤드 키로 사용됩니다.
   * 샤딩 알고리즘 선택: 샤딩 알고리즘을 선택하여 데이터를 분할합니다. 주요 알고리즘으로는 다음과 같은 두 가지가 있습니다:
     * Range 기반 샤딩: 샤드 키의 범위에 따라 데이터를 분할합니다. 예를 들어, 특정 사용자 ID 범위마다 다른 샤드에 저장합니다.
     * Hashing 기반 샤딩: 샤드 키를 해싱하여 데이터를 분산합니다. 이 방식은 데이터를 고르게 분산시키는 데 유리합니다.
   * 데이터베이스 분할: 샤드 키를 기반으로 데이터를 여러 데이터베이스 서버에 분할 저장합니다.
   * Routing 로직 구현: 데이터베이스 시스템이 자동으로 샤딩을 지원하지 않는 경우, 애플리케이션 레벨에서 샤드 키를 이용해 데이터를 적절한 샤드에 라우팅하는 로직을 구현합니다. MongoDB와 같은 일부 데이터베이스는 이 로직을 자체적으로 지원합니다
 * Considerations:
   * 데이터 일관성: 여러 샤드에 데이터가 분산되므로, 트랜잭션을 처리할 때 데이터 일관성을 유지하는 것이 어려울 수 있습니다. 분산 트랜잭션 관리나 eventual consistency 모델을 고려해야 합니다.
   * 샤드 간 조인: 샤드 간 조인이 필요한 경우 성능 저하가 발생할 수 있습니다. 가능한 샤드 내에서 데이터를 처리하고, 샤드 간 조인을 최소화하는 설계를 고려해야 합니다.
   * 샤드 키 선택: 샤드 키를 적절히 선택하지 않으면 특정 샤드에 데이터가 집중되어 부하가 증가할 수 있습니다. 고르게 분산되는 샤드 키를 선택하는 것이 중요합니다.
   * 리밸런싱 문제: 데이터 분포가 불균형해질 때, 샤드 추가/제거가 발생할 때 리밸런싱 작업이 필요합니다. 이를 위해 데이터 이동 및 재분할 작업을 효율적으로 자동화하는 방법을 마련해야합니다.
   * Hot Spot 문제: 특정 샤드에 데이터가 집중되어 해당 샤드에 과부하가 발생하는 문제가 발생할 수 있습니다.

<ol ><li>Materialized Views:</li></ol><ul ><li>정의:<ul ><li>Materialized View(MV)는 쿼리 결과를 저장하고 있는 데이터베이스 객체입니다. 이렇게만 말하면 SQL 데이터베이스에만 국한된 개념처럼 보이지만 좀 더 넓은 개념의 의미로 보면 Materialized View는 데이터의 사본을 미리 계산하고 저장하여 성능을 향상시키는 기법입니다.</li></ul></li><li>When to use:<ul ><li>복잡한 쿼리: 여러 조인, 집계 및 계산을 포함하는 복잡한 쿼리라서 데이터를 직접 쿼리하기 어려울 때</li><li>반복적인 읽기 작업: 자주 읽히는 데이터의 경우 Materialized View 기법을 통해서 읽기 성능을 향상 시킬 수 있습니다.</li><li>데이터 집계: 집계 연산 (Aggregation, 합계, 평균, 개수 등) 에서 Materialized Views 를 통해 사전 집계된 결과를 제공해서 성능을 향상 시킬 수 있습니다.</li><li>서로 다른 데이터 저장소의 기능을 활용하기 위해서. 예를 들면 쓰기에 효율적인 데이터 스토어는 데이터를 저장소 역할로 사용하고, 쿼리와 읽기 성능이 좋은 관계형 데이터 스토어에서 Materialized View 를 저장하는 식으로.</li></ul></li><li>How to use:<ul ><li>SQL 에서의 Materialized View 는 Materialized View 객체를 생성하고, 갱신 전략과 그것에 맞는 갱신 주기를 설정하고 조회하면 됩니다.</li><li>추가로 너무 자주 갱신할 경우 성능에 부담이 되고, 너무 늦게 갱신하면 오래된 데이터를 볼 수 있는 문제가 발생할 수 있습니다.</li></ul></li><li>Considerations:<ul ><li>갱신 오버헤드: 갱신 시 리소스가 소요되는 걸 고려해서 갱신 전략과 갱신 주기를 설정하세요.</li><li>Dsposability and Regeneratibility: Materialized View 가 없어지거나 만료되더라도 원본 데이터에서 다시 만들 수 있어야 합니다.</li><li>Consistency: Materialized View 는 원본 데이터로 만들어진 별도의 캐싱 데이터 이므로 데이터 일관성이 안 맞을 수 있습니다. 이것에 대한 고려도 필요합니다.</li><li>원본 데이터가 단순하거나 쿼리하기 쉽다면 이 기법은 적절하지 않을 수 있습니다.</li></ul></li></ul> <ol start="2"><li>Indexing:</li></ol><ul ><li>정의:<ul ><li>데이터베이스의 특정 열에 대해 검색 속도를 향상시키기 위해 데이터 구조를 사용하는 전략입니다.</li></ul></li><li>When to use:<ul ><li>빈번한 검색: 자주 검색되는 열에 대해 인덱스를 생성하면 검색 성능을 크게 향상시킬 수 있습니다.</li><li>JOIN 및 WHERE 절: JOIN이나 WHERE 절에서 자주 사용되는 열에 인덱스를 생성하면 쿼리 성능이 향상됩니다.</li><li>정렬과 그룹화: ORDER BY나 GROUP BY 구문에서 자주 사용되는 열에 인덱스를 생성하면 성능이 개선될 수 있습니다.</li></ul></li><li>How to use:<ul ><li>데이터베이스에서 인덱스를 사용하는 방법은 간단합니다. 인덱스로 사용할 테이블 칼럼을 선택하고 생성만 하면 사용됩니다.</li></ul></li><li>Considerations:<ul ><li>인덱스 오버헤드: 인덱스 생성 및 유지 관리에는 추가 저장 공간과 CPU 자원이 필요합니다. 인덱스가 많아지면 데이터 삽입, 업데이트, 삭제 작업의 성능이 저하될 수 있습니다.</li><li>인덱스 선택: 모든 열에 인덱스를 생성하는 것은 바람직하지 않습니다. 자주 사용되는 열과 쿼리 성능에 중요한 열에 인덱스를 생성하는 것이 좋습니다.</li></ul></li></ul> <ol start="3"><li>Denormalziation</li></ol><ul ><li>정의:<ul ><li>비정규화(Denormalization)는 데이터베이스의 성능을 향상시키기 위해 데이터를 중복 저장하는 전략입니다. 이는 데이터를 정규화하여 중복을 최소화하는 것과 반대되는 개념으로, 특정 쿼리 성능을 최적화하기 위해 데이터를 중복 저장하여 조인을 줄이고 조회 속도를 향상시킵니다.</li></ul></li><li>When to use:<ul ><li>읽기 성능 향상: 데이터 읽기 작업이 빈번하고, 읽기 성능이 중요할 때 비정규화를 통해 데이터를 중복 저장하여 조회 속도를 높일 수 있습니다.</li><li>복잡한 조인 줄이기: 여러 테이블을 조인하는 복잡한 쿼리를 자주 실행해야 하는 경우, 비정규화를 통해 조인을 줄이고 쿼리 성능을 향상시킬 수 있습니다.</li><li>데이터 통합: 서로 다른 데이터 소스에서 데이터를 통합하여 조회할 때, 비정규화를 통해 데이터를 하나의 테이블에 저장하고 조회 성능을 높일 수 있습니다.</li></ul></li><li>How to use:<ul ><li>비정규화를 적용하려면 먼저 어떤 데이터가 중복 저장될지 결정해야 합니다. 자주 사용되는 데이터를 식별하고, 해당 데이터를 중복 저장하여 조회 성능을 향상시킵니다.</li></ul></li><li>Considerations:<ul ><li>데이터 일관성: 데이터가 중복 저장되므로 일관성을 유지하기 어려울 수 있습니다. 데이터가 변경될 때마다 비정규화된 데이터를 업데이트해야 하므로, 이를 위한 추가적인 로직이 필요합니다</li><li>저장 공간 증가: 비정규화는 데이터를 중복 저장하므로 저장 공간 요구량이 증가할 수 있습니다. 데이터베이스의 저장 공간을 충분히 확보해야 합니다.</li></ul></li></ul> <ol start="4"><li>Vertical Scaling:</li></ol><ul ><li>정의:<ul ><li>Vertical Scaling(수직적 확장)은 기존 서버나 데이터베이스의 하드웨어 사양을 업그레이드하여 성능을 향상시키는 방법입니다. 주로 CPU, RAM, 스토리지와 같은 자원을 추가하거나 교체하는 방식으로 이루어집니다.</li></ul></li><li>When to use:<ul ><li>단일 서버의 성능이 충분하지 않을 때: 현재 사용 중인 서버가 증가하는 데이터 처리량을 감당하지 못할 때 수직적 확장을 통해 성능을 향상시킬 수 있습니다.</li><li>애플리케이션 구조가 수평적 확장을 지원하지 않을 때: 애플리케이션이 여러 서버에 분산될 수 없는 경우, 단일 서버의 성능을 높이는 것이 효과적입니다.</li><li>쉽게 성능 향상이 필요할 때: 하드웨어 업그레이드는 상대적으로 쉽게 성능을 향상시킬 수 있는 방법입니다.</li></ul></li><li>How to use:<ul ><li>하드웨어 업그레이드: 서버의 CPU, RAM, 스토리지 등의 하드웨어를 업그레이드합니다.</li><li>가상 머신 또는 클라우드 인스턴스 업그레이드: 클라우드 환경에서는 더 높은 사양의 인스턴스로 업그레이드할 수 있습니다.</li></ul></li><li>Considerations:<ul ><li>비용: 수직적 확장은 초기 비용이 높을 수 있습니다. 고성능 하드웨어는 높은 비용을 수반하므로 예산을 고려해야 합니다.</li><li>확장 한계: 수직적 확장은 물리적 한계가 있습니다. 하드웨어의 최대 성능에 도달하면 더 이상 확장할 수 없으므로, 장기적인 확장성 계획을 고려해야 합니다.</li><li>단일 장애점(Single Point of Failure): 단일 서버에 의존하는 경우, 해당 서버가 장애를 일으키면 전체 시스템이 영향을 받을 수 있습니다. 이 경우 고가용성 및 백업 계획을 수립하는 것이 중요합니다.</li></ul></li></ul> <ol start="5"><li>Caching:</li></ol><ul ><li>정의:<ul ><li>캐싱 (Caching) 은 자주 조회되는 데이터를 임시 저장소에 저장하여 데이터베이스 접근을 줄이고 응답 시간을 단축시키는 전략입니다. 메모리나 고속 스토리지를 사용하여 데이터를 임시로 저장함으로써 데이터베이스 성능을 향상시킬 수 있습니다.</li></ul></li><li>When to use:<ul ><li>자주 조회되는 데이터: 특정 데이터가 자주 조회되는 경우, 캐싱을 통해 데이터베이스 부하를 줄이고 응답 시간을 개선할 수 있습니다.</li><li>읽기 성능 최적화: 읽기 작업이 빈번하고, 빠른 응답 시간이 중요한 경우 캐싱을 통해 성능을 최적화할 수 있습니다.</li><li>복잡한 쿼리 결과 캐싱: 복잡한 쿼리를 자주 실행해야 하는 경우, 쿼리 결과를 캐싱하여 성능을 향상시킬 수 있습니다.</li><li>API 응답 속도 개선: 웹 애플리케이션이나 API의 응답 속도를 개선하기 위해 캐싱을 사용할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>캐시 설정: 캐시를 설정하려면 먼저 캐시 저장소를 선택합니다. Redis, Memcached, 로컬 메모리 등을 사용할 수 있습니다.</li><li>캐시 정책 결정: 캐시 만료 시간(TTL, Time to Live)과 갱신 정책을 설정합니다. 캐시 만료 시간은 데이터의 유효 기간을 결정하며, 갱신 정책은 캐시 데이터가 만료되거나 갱신될 시점을 결정합니다.</li><li>데이터 일관성 유지: 캐시된 데이터와 원본 데이터의 일관성을 유지하기 위한 전략을 마련합니다. 원본 데이터가 변경될 때 캐시를 갱신하거나 무효화하는 로직을 구현합니다.</li></ul></li><li>Considerations:<ul ><li>캐시 적중률(Cache Hit Rate): 캐시의 효율성을 높이기 위해 캐시 적중률을 모니터링합니다. 캐시 적중률이 낮다면 캐시 정책을 재검토하여 개선합니다.</li><li>데이터 일관성: 캐시된 데이터는 원본 데이터가 변경되었을 때 일관성을 유지하기 어려울 수 있습니다. 데이터가 갱신될 때 캐시를 무효화하거나 갱신하는 전략이 필요합니다.</li><li>캐시 오버헤드: 캐싱은 추가 저장 공간과 메모리 사용을 필요로 합니다. 캐시 크기를 적절히 관리하여 메모리 사용량을 최적화해야 합니다.</li><li>TTL 설정: 캐시 만료 시간을 적절히 설정하여 데이터의 최신성과 성능 사이의 균형을 맞춥니다. 너무 짧으면 캐시의 이점을 살리기 어렵고, 너무 길면 오래된 데이터를 반환할 위험이 있습니다.</li></ul></li></ul> <ol start="6"><li>Replication:</li></ol><ul ><li>정의:<ul ><li>데이터베이스 복제(Replication)는 데이터베이스의 데이터를 다른 서버에 복제하여 고가용성 및 성능을 향상시키는 전략입니다. 복제된 데이터베이스는 읽기 작업을 분산시키고, 데이터베이스 장애 시에도 시스템을 지속적으로 운영할 수 있도록 합니다.</li></ul></li><li>When to use:<ul ><li>고가용성 요구: 시스템의 고가용성이 중요한 경우, 복제를 통해 장애 시에도 서비스가 중단되지 않도록 할 수 있습니다.</li><li>읽기 성능 향상: 읽기 작업이 빈번한 경우, 여러 복제본으로 읽기 작업을 분산시켜 성능을 향상시킬 수 있습니다.</li><li>백업 및 복구: 데이터를 다른 서버에 복제함으로써 백업 및 복구 작업을 용이하게 할 수 있습니다.</li><li>지연시간 향상: 여러 지역에 걸쳐 데이터를 분산하여 사용자에게 더 가까운 서버에서 데이터를 제공할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>마스터-슬레이브 복제: 한 서버(마스터)가 쓰기 작업을 처리하고, 다른 서버들(슬레이브)이 읽기 작업을 처리하도록 설정하도록 할 수 있습니다.</li><li>다중 리더 복제: 두 개 이상의 서버가 모두 쓰기 및 읽기 작업을 처리할 수 있도록 설정하도록 할 수 있습니다.</li><li>비동기 및 동기 복제: 비동기 복제는 성능이 좋지만 데이터 일관성이 떨어질 수 있고, 동기 복제는 데이터 일관성이 높지만 성능이 저하될 수 있습니다. 필요에 따라 선택합니다.</li><li>멀티 스레딩 복제: 복제 작업을 병렬로 처리하여 성능을 향상시키는 방법입니다. 슬레이브 서버에서 여러 스레드를 사용하여 마스터의 데이터를 병렬로 복제합니다.</li><li>리더 없는 복제(Leaderless Replication): 모든 노드가 동등한 역할을 하여 데이터 읽기 및 쓰기 작업을 분산 처리하는 방식입니다. 주로 NoSQL 데이터베이스에서 사용되며, 각 노드가 독립적으로 작동하여 고가용성과 확장성을 제공합니다.</li></ul></li><li>Considerations:<ul ><li>복제 지연: 네트워크 지연이나 복제 설정에 따라 데이터 복제에 시간이 걸릴 수 있습니다. 복제 지연이 발생한다면 최신 데이터 조회의 어려움, 복제 서버의 성능 저하 등이 일어날 수 있기 때문에 복제 지연을 최소화하기 위한 네트워크 설정 및 모니터링이 필요합니다.</li><li>데이터 일관성: 비동기 복제는 실시간으로 데이터가 동기화되지 않으므로 일관성 문제가 발생할 수 있습니다. 동기 복제를 통해 데이터 일관성을 유지할 수 있지만 성능에 영향을 줄 수 있습니다.</li><li>충돌 해결: 마스터-마스터 복제에서는 동일한 데이터에 대한 충돌이 발생할 수 있습니다. 충돌 해결 정책을 마련해야 합니다.</li></ul></li></ul> <ol start="7"><li>Shrading:</li></ol><ul ><li>샤딩(Sharding)은 데이터베이스를 여러 개의 작은 단위(샤드)로 분할하여 각각 독립적인 데이터베이스 서버에 저장하는 전략입니다. 각 샤드는 전체 데이터의 일부를 포함하며, 이를 통해 대규모 데이터베이스의 성능과 확장성을 향상시킬 수 있습니다.</li><li>When to use:<ul ><li>데이터베이스 크기가 매우 큰 경우: 단일 서버가 전체 데이터를 처리하기 어려운 경우 샤딩을 통해 데이터베이스를 분할하여 처리 성능을 높일 수 있습니다.</li><li>높은 트래픽: 많은 사용자가 동시에 데이터베이스에 접근할 때 샤딩을 통해 트래픽을 여러 서버에 분산시킬 수 있습니다.</li><li>높은 쓰기/읽기 작업: 데이터 쓰기와 읽기 작업이 많은 경우, 샤딩을 통해 특정 샤드에서만 작업을 처리하여 성능을 최적화할 수 있습니다.</li><li>데이터 분리 요구: 지리적 위치나 비즈니스 요구에 따라 데이터를 분리하여 저장해야 할 때 샤딩을 활용할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>샤드 키 선택: 데이터를 분할할 기준이 되는 샤드 키를 선택합니다. 일반적으로 사용자 ID, 지역 코드, 타임스탬프 등이 샤드 키로 사용됩니다.</li><li>샤딩 알고리즘 선택: 샤딩 알고리즘을 선택하여 데이터를 분할합니다. 주요 알고리즘으로는 다음과 같은 두 가지가 있습니다:<ul ><li>Range 기반 샤딩: 샤드 키의 범위에 따라 데이터를 분할합니다. 예를 들어, 특정 사용자 ID 범위마다 다른 샤드에 저장합니다.</li><li>Hashing 기반 샤딩: 샤드 키를 해싱하여 데이터를 분산합니다. 이 방식은 데이터를 고르게 분산시키는 데 유리합니다.</li></ul></li><li>데이터베이스 분할: 샤드 키를 기반으로 데이터를 여러 데이터베이스 서버에 분할 저장합니다.</li><li>Routing 로직 구현: 데이터베이스 시스템이 자동으로 샤딩을 지원하지 않는 경우, 애플리케이션 레벨에서 샤드 키를 이용해 데이터를 적절한 샤드에 라우팅하는 로직을 구현합니다. MongoDB와 같은 일부 데이터베이스는 이 로직을 자체적으로 지원합니다</li></ul></li><li>Considerations:<ul ><li>데이터 일관성: 여러 샤드에 데이터가 분산되므로, 트랜잭션을 처리할 때 데이터 일관성을 유지하는 것이 어려울 수 있습니다. 분산 트랜잭션 관리나 eventual consistency 모델을 고려해야 합니다.</li><li>샤드 간 조인: 샤드 간 조인이 필요한 경우 성능 저하가 발생할 수 있습니다. 가능한 샤드 내에서 데이터를 처리하고, 샤드 간 조인을 최소화하는 설계를 고려해야 합니다.</li><li>샤드 키 선택: 샤드 키를 적절히 선택하지 않으면 특정 샤드에 데이터가 집중되어 부하가 증가할 수 있습니다. 고르게 분산되는 샤드 키를 선택하는 것이 중요합니다.</li><li>리밸런싱 문제: 데이터 분포가 불균형해질 때, 샤드 추가/제거가 발생할 때 리밸런싱 작업이 필요합니다. 이를 위해 데이터 이동 및 재분할 작업을 효율적으로 자동화하는 방법을 마련해야합니다.</li><li>Hot Spot 문제: 특정 샤드에 데이터가 집중되어 해당 샤드에 과부하가 발생하는 문제가 발생할 수 있습니다.</li></ul></li></ul>

반드시 알아야 하는 7가지 데이터베이스 확장성 전략

1️⃣ The C Programming Language

컴퓨터 프로그래밍의 근본 (주니어)

2️⃣ Code Complete

소프트웨어 개발의 모든 것 (주니어, 미드)

3️⃣ Refactoring

소프트웨어 유지보수의 모든 것 (주니어, 미드)

4️⃣ 구글 엔지니어는 이렇게 일한다

소프트웨어 개발 협업에 대한 모든 것 (미드, 시니어)

5️⃣ 최고의 프롬프트 엔지니어링 강의

AI/LLM과 프롬프트 엔지니어링의 근본(주니어, 미드, 시니어)

이상한 것이 끼어있는 것 같지만 착각입니다.

1️⃣ The C Programming Language 컴퓨터 프로그래밍의 근본 (주니어) 2️⃣ Code Complete 소프트웨어 개발의 모든 것 (주니어, 미드) 3️⃣ Refactoring 소프트웨어 유지보수의 모든 것 (주니어, 미드) 4️⃣ 구글 엔지니어는 이렇게 일한다 소프트웨어 개발 협업에 대한 모든 것 (미드, 시니어) 5️⃣ 최고의 프롬프트 엔지니어링 강의 AI/LLM과 프롬프트 엔지니어링의 근본(주니어, 미드, 시니어) 이상한 것이 끼어있는 것 같지만 착각입니다.

모든 개발자를 위한 프로그래밍 책 Top 5

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께

그 누구도 나의 서사를 대신 써주지 않는다

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께

코노님이 작성한 글입니다. 지금처럼 경력자를 후려치는 마케팅이 성행하는 시기에 살펴볼만한 대목이 많네요!

 * 물경력과 성장: 글에서는 '물경력 탈출’과 같은 마케팅이 저연차 개발자들의 불안을 자극하는 것에 대해 비판하며, 진정한 성장의 의미를 탐구합니다.
 * 개인적 경험의 가치: 다양한 경험들이 개발자로서의 성장에 어떻게 기여하는지를 공유하며, 링크드인에 적을 수 없는 경험들도 중요하다고 강조합니다.
 * 자기 인정의 중요성: 필자는 타인의 인정을 넘어 자기 스스로를 인정하는 것이 진정한 성장으로 이어진다고 주장합니다.
 * 본인의 서사 쓰기: 자신의 경험을 소중히 여기고, 타인의 시선에 휘둘리지 않으며, 자신만의 서사를 써나가야 한다고 강조합니다.

https://codingpause.hashnode.dev/about-growing-up

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께 코노님이 작성한 글입니다. 지금처럼 경력자를 후려치는 마케팅이 성행하는 시기에 살펴볼만한 대목이 많네요! <ul ><li>물경력과 성장: 글에서는 '물경력 탈출’과 같은 마케팅이 저연차 개발자들의 불안을 자극하는 것에 대해 비판하며, 진정한 성장의 의미를 탐구합니다.</li><li>개인적 경험의 가치: 다양한 경험들이 개발자로서의 성장에 어떻게 기여하는지를 공유하며, 링크드인에 적을 수 없는 경험들도 중요하다고 강조합니다.</li><li>자기 인정의 중요성: 필자는 타인의 인정을 넘어 자기 스스로를 인정하는 것이 진정한 성장으로 이어진다고 주장합니다.</li><li>본인의 서사 쓰기: 자신의 경험을 소중히 여기고, 타인의 시선에 휘둘리지 않으며, 자신만의 서사를 써나가야 한다고 강조합니다.</li></ul> https://codingpause.hashnode.dev/about-growing-up

코딩 놓으려 했는데

네이버 폼 설문에 바로 참여해 보세요.

[토스 프론트엔드 멘토링] Frontend Accelerator 1기에 지원하기

토스에서는 프론트엔드 멘토링 시스템 Frontend Accelerator 1기를 모집한다고 하네요.
Frontend Accelerator란 4주 동안 토스 프론트엔드 리드와 멘토-멘티의 관계를 맺어 토스 엔지니어링의 일하는 방식을 경험하고, 기술 관련 피드백을 얻는 프로그램인데요.
프로그램 종료 이후, 훌륭한 성장을 이뤄내신 분은 토스 Frontend Developer 채용 서류 패스 기회를 준다고 하니 좋은 기회가 될것 같습니다. 아래는 상세 내용 입니다

멘토링 진행 과정
 * 멘티에게 과제를 부여하고, 멘토는 가이드와 피드백을 주며 멘티가 리팩토링해나가는 과정을 함께합니다.
 * 멘토링은 모두 온라인으로 진행되며, 토스 슬랙 채널과 구글밋 미팅을 기반으로 진행됩니다.

일정
 * 7월 25일 ~ 8월 16일까지 1주일에 1회, 총 4회 정기 미팅을 진행합니다.
 * 이 외 시간에는 멘토와 멘티가 필요에 따라 자유롭게 소통합니다.

지원 대상
 * 프론트엔드 엔지니어로서 빠르게 성장을 경험하고 싶으신 분
 * 토스 프론트엔드 리드와의 네트워킹에 니즈가 있으신 분
 * 토스 프론트엔드 엔지니어가 실제로 마주하게 되는 문제를 함께 고민하고 싶으신 분

지원 자격
 * 3년 이하의 경험을 가진 분이라면 누구나 지원 가능합니다. 실무 경험이 없어도 괜찮습니다.

멘티 선발 과정
 1. 지원: 6월 17일 ~ 6월 26일까지
 2. 테스트: 6월 29일 (지원해주신 모든 분들께 테스트 참여의 기회가 부여됩니다.)
 3. 캐주얼챗: 7월 4일 ~ 7월 5일 중 조율 (테스트 합격자를 대상으로 캐주얼챗을 제안드립니다.)
 4. 선발 결과 발표: 7월 8일
 5. 멘토링 기간: 7월 25일 ~ 8월 16일 (주 1회, 1시간씩 온라인 미팅을 진행합니다.)

지원 방법
 * 6월 17일 ~ 6월 26일까지 이력서 없이 간단한 답변만으로 누구나 지원이 가능합니다.
 * 지원해주신 모든 분들께 6월 29일 온라인 테스트 (20분 소요)의 기회가 부여됩니다.

토스에 채용이 되지 않는다고 해도 멘토링을 하면서 많이 성장할 수 있는 기회가 될것 같습니다. 3년 이하의 주니어 분들은 지원을 해보시는것을 추천드립니다.

토스에서는 프론트엔드 멘토링 시스템 Frontend Accelerator 1기를 모집한다고 하네요.Frontend Accelerator란 4주 동안 토스 프론트엔드 리드와 멘토-멘티의 관계를 맺어 토스 엔지니어링의 일하는 방식을 경험하고, 기술 관련 피드백을 얻는 프로그램인데요.프로그램 종료 이후, 훌륭한 성장을 이뤄내신 분은 토스 Frontend Developer 채용 서류 패스 기회를 준다고 하니 좋은 기회가 될것 같습니다. 아래는 상세 내용 입니다 멘토링 진행 과정<ul ><li>멘티에게 과제를 부여하고, 멘토는 가이드와 피드백을 주며 멘티가 리팩토링해나가는 과정을 함께합니다.</li><li>멘토링은 모두 온라인으로 진행되며, 토스 슬랙 채널과 구글밋 미팅을 기반으로 진행됩니다.</li></ul> 일정<ul ><li>7월 25일 ~ 8월 16일까지 1주일에 1회, 총 4회 정기 미팅을 진행합니다.</li><li>이 외 시간에는 멘토와 멘티가 필요에 따라 자유롭게 소통합니다.</li></ul> 지원 대상<ul ><li>프론트엔드 엔지니어로서 빠르게 성장을 경험하고 싶으신 분</li><li>토스 프론트엔드 리드와의 네트워킹에 니즈가 있으신 분</li><li>토스 프론트엔드 엔지니어가 실제로 마주하게 되는 문제를 함께 고민하고 싶으신 분</li></ul> 지원 자격<ul ><li>3년 이하의 경험을 가진 분이라면 누구나 지원 가능합니다. 실무 경험이 없어도 괜찮습니다.</li></ul> 멘티 선발 과정<ol ><li>지원: 6월 17일 ~ 6월 26일까지</li><li>테스트: 6월 29일 (지원해주신 모든 분들께 테스트 참여의 기회가 부여됩니다.)</li><li>캐주얼챗: 7월 4일 ~ 7월 5일 중 조율 (테스트 합격자를 대상으로 캐주얼챗을 제안드립니다.)</li><li>선발 결과 발표: 7월 8일</li><li>멘토링 기간: 7월 25일 ~ 8월 16일 (주 1회, 1시간씩 온라인 미팅을 진행합니다.)</li></ol> 지원 방법<ul ><li>6월 17일 ~ 6월 26일까지 이력서 없이 간단한 답변만으로 누구나 지원이 가능합니다.</li><li>지원해주신 모든 분들께 6월 29일 온라인 테스트 (20분 소요)의 기회가 부여됩니다.</li></ul> 토스에 채용이 되지 않는다고 해도 멘토링을 하면서 많이 성장할 수 있는 기회가 될것 같습니다. 3년 이하의 주니어 분들은 지원을 해보시는것을 추천드립니다.

네이버 폼

토스 프론트엔드 멘토링 시스템 "Accelerator 1기 모집"

『소프트웨어 장인』에 이은 또 한 권의 '로버트 C. 마틴 시리즈' 베스트셀러!70년 동안 개발자들에게 검증 받은 개발 방법론과 주옥 같은 팁들을 한 권으로 총 정리! `좋은 소프트웨어 설계를 하라`는 말에 명확한 답과 방법을 떠올릴 수 있는가? 개발은 명확한...

읽기 쉬운 코드 - 예스24

안녕하세요. 오늘은 최근에 읽은 책 소개를 하나 할까 합니다.

종종 주니어 개발자 분들과 이야기를 나누다보면 '읽기 좋은 코드란 무엇일까요?' '코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?' 라는 질문을 많이 받곤 합니다. 그 기준은 무엇이고, 어떻게 발전 시킬수 있을지에 대한 고민도 많이 듣게되구요.

종종 주니어 개발자들과의 대화에서 "읽기 좋은 코드란 무엇일까요?", "코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?"에 대한 질문을 많이 받습니다. 그런 코드를 위해 구체적으로 어떤 방식으로 코드를 작성해야 하는지, 발전시킬수 있는지에 대해서도 질문을 많이 듣습니다.

생각나는 여러 기준을 제시하며 대화를 나누곤 했지만, 그러한 기준을 정확히 어디서 배웠고 어떻게 내재화하게 되었는지 생각해보면 그 출처가 명확하지 않았습니다. 나름 선호하는 코드 스타일과 개선이 필요한 코드를 식별하고 규칙을 만들어 적용해왔지만, 도움이 될 수 있는 구체적인 액션 아이템을 제시할때는 어려움을 느끼곤 했습니다.

그러다 최근 이 두 책을 제공받아 읽게 되었습니다. 그러다 최근 두 권의 책을 읽게 되었습니다. 이 책들은 좋은 코드를 작성하기 위한 기준과 코드에 안정성을 부여하는 방법에 대해 명확한 저자의 관점으로 구체적인 예시와 함께 설명하고 있습니다. 여러 곳에서 배운 지식들을 체계적으로 정리하고 재조명할 수 있는 좋은 기회가 되었습니다.

최근 비슷한 고민을 하는 개발자들뿐만 아니라 주니어 개발자들에게도 명확한 지침서가 될 수 있을 것이라 생각되어 다음 책들을 추천합니다. 목차를 확인해보시고 관심이 간다면 주문하여 읽어보시길 바랍니다.

 * 읽기 쉬운 코드: http://gilbut.co/c/24034992MF
 * 코드 작성 가이드: http://gilbut.co/c/24046947nM

안녕하세요. 오늘은 최근에 읽은 책 소개를 하나 할까 합니다. 종종 주니어 개발자 분들과 이야기를 나누다보면 '읽기 좋은 코드란 무엇일까요?' '코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?' 라는 질문을 많이 받곤 합니다. 그 기준은 무엇이고, 어떻게 발전 시킬수 있을지에 대한 고민도 많이 듣게되구요. 종종 주니어 개발자들과의 대화에서 "읽기 좋은 코드란 무엇일까요?", "코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?"에 대한 질문을 많이 받습니다. 그런 코드를 위해 구체적으로 어떤 방식으로 코드를 작성해야 하는지, 발전시킬수 있는지에 대해서도 질문을 많이 듣습니다. 생각나는 여러 기준을 제시하며 대화를 나누곤 했지만, 그러한 기준을 정확히 어디서 배웠고 어떻게 내재화하게 되었는지 생각해보면 그 출처가 명확하지 않았습니다. 나름 선호하는 코드 스타일과 개선이 필요한 코드를 식별하고 규칙을 만들어 적용해왔지만, 도움이 될 수 있는 구체적인 액션 아이템을 제시할때는 어려움을 느끼곤 했습니다. 그러다 최근 이 두 책을 제공받아 읽게 되었습니다. 그러다 최근 두 권의 책을 읽게 되었습니다. 이 책들은 좋은 코드를 작성하기 위한 기준과 코드에 안정성을 부여하는 방법에 대해 명확한 저자의 관점으로 구체적인 예시와 함께 설명하고 있습니다. 여러 곳에서 배운 지식들을 체계적으로 정리하고 재조명할 수 있는 좋은 기회가 되었습니다. 최근 비슷한 고민을 하는 개발자들뿐만 아니라 주니어 개발자들에게도 명확한 지침서가 될 수 있을 것이라 생각되어 다음 책들을 추천합니다. 목차를 확인해보시고 관심이 간다면 주문하여 읽어보시길 바랍니다. <ul ><li>읽기 쉬운 코드: http://gilbut.co/c/24034992MF</li><li>코드 작성 가이드: http://gilbut.co/c/24046947nM</li></ul>

예스24

읽기 쉬운 코드 / 코드 작성 가이드

일본인 정원사 '이 한마디', 엔비디아 젠슨 황 인생 바꿨다, 엔비디아 CEO "日정원사와의 만남이 날 성공하게 만들어" 젠슨 황, 美대학 졸업식 연설 일본 정원사, 찌는 듯한 날에도 묵묵히 나뭇잎·이끼 정리하며 "정원 가꿀 시간은 충분" 말에 인생에서 가장 큰 깨달음 "평생 바치면 시간은 충분 우선순위 정해 집중하라" "매일 아침 중요한 업무부터 봐 출근도 전에 이미 성공적인 하루"

일본인 정원사 '이 한마디', 엔비디아 젠슨 황 인생 바꿨다

우리는 늘 시간에 쫓겨서 살아갑니다.
해야 할 일이 많고, 하고 싶은 일이 많습니다.

회사의 CEO인 젠슨황에게도 그러했을 것입니다.
젠슨황은 1년에 1달동안은 해외에서 일을 한다고 해요.
자녀들이 10살때에 일본에서 1달동안 일을 한적이 있는데,
덥고 습한날 거대한 정원을 대나무 집게로 다듬는 정원사를 보며 물었습니다.

황 : 무엇을 하고 있나요?
정원사 : 죽은 이끼를 따고 있어요.
황: 정원이 너무 넓지 않나요?
정원사 : 25년간 정원을 가꿨고, 앞으로도 시간은 충분합니다.
황 : !!

이 순간이 젠슨황에게 가장 큰 깨달음을 준 시간이라고 해요.
너무나 넓어 보이는 정원이지만,
지금껏 25년간 정원을 가꿔온 정원사는 급하지 않았습니다.
매일 매일 자신을 믿으며 정원을 가꿀뿐이었죠.

직접적으로 겪은 이야기가 아니기에 여러분에게는 크게 와닿지 않을 수 있습니다.
젠슨황은 이렇게 얘기하네요.

'여러분이 평생을 바쳐 완성하고 싶은 기술을 찾기 바랍니다.
많은 일이 일어나고 있고 해야할 일이 많지만
인생의 우선순위를 정하고, 삶의 우선순위를 정하면 시간은 충분할 거예요.'

우리에게는 아직 시간이 많습니다.
우선순위를 정하고 방향을 잘 정해서 나아가봅시다.

https://www.hankyung.com/article/202406171169i

우리는 늘 시간에 쫓겨서 살아갑니다.해야 할 일이 많고, 하고 싶은 일이 많습니다. 회사의 CEO인 젠슨황에게도 그러했을 것입니다.젠슨황은 1년에 1달동안은 해외에서 일을 한다고 해요.자녀들이 10살때에 일본에서 1달동안 일을 한적이 있는데,덥고 습한날 거대한 정원을 대나무 집게로 다듬는 정원사를 보며 물었습니다. 황 : 무엇을 하고 있나요?정원사 : 죽은 이끼를 따고 있어요.황: 정원이 너무 넓지 않나요?정원사 : 25년간 정원을 가꿨고, 앞으로도 시간은 충분합니다.황 : !! 이 순간이 젠슨황에게 가장 큰 깨달음을 준 시간이라고 해요.너무나 넓어 보이는 정원이지만,지금껏 25년간 정원을 가꿔온 정원사는 급하지 않았습니다.매일 매일 자신을 믿으며 정원을 가꿀뿐이었죠. 직접적으로 겪은 이야기가 아니기에 여러분에게는 크게 와닿지 않을 수 있습니다.젠슨황은 이렇게 얘기하네요. '여러분이 평생을 바쳐 완성하고 싶은 기술을 찾기 바랍니다.많은 일이 일어나고 있고 해야할 일이 많지만인생의 우선순위를 정하고, 삶의 우선순위를 정하면 시간은 충분할 거예요.' 우리에게는 아직 시간이 많습니다.우선순위를 정하고 방향을 잘 정해서 나아가봅시다. https://www.hankyung.com/article/202406171169i

한국경제

젠슨황의 인생에 가장 큰깨달음을 준 한마디 - 시간은 충분하다

In business, being a nice person in the room can be more impactful than being the smartest. I share my insights on empathy, respect, and active listening as key skills for successful meetings and creating a positive team environment.

Do not try to be the smartest in the room; try to be the kindest. | Jorge Galindo's blog

"가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요."

"잘 듣고, 존중하고, 공감하고, 해결 중심 접근 방식을 통해 팀의 생산성을 향상 시킬 수 있습니다."

"친절함은 전염성이 있습니다. 당신이 친절하기 시작하면 다른 사람들도 친절해질 것이고, 팀 전체에 영향을 끼칠 것입니다"

"가장 똑똑한 사람은 몇몇 사람이 그리워 하지만, 친절한 사람은 모두가 그리워 합니다"

https://www.jorgegalindo.me/en/blog/posts/do-not-be-the-smartest-in-the-room-try-to-be-the-kindest

"가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요." "잘 듣고, 존중하고, 공감하고, 해결 중심 접근 방식을 통해 팀의 생산성을 향상 시킬 수 있습니다." "친절함은 전염성이 있습니다. 당신이 친절하기 시작하면 다른 사람들도 친절해질 것이고, 팀 전체에 영향을 끼칠 것입니다" "가장 똑똑한 사람은 몇몇 사람이 그리워 하지만, 친절한 사람은 모두가 그리워 합니다" https://www.jorgegalindo.me/en/blog/posts/do-not-be-the-smartest-in-the-room-try-to-be-the-kindest

Jorgegalindo

가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요

들어가며 안녕하세요. LINE+ Contents Service Engineering 조직에서 백엔드 개발을 맡고 있는 양강현, 이병찬입니다. 저희가 속해 있는 Contents Se...

Req-Saver로 캐시의 골칫거리 'Thundering Herd 문제' 쉽게 풀기!

라인에서 Cache를 사용할 때 발생하는 Thundering Herd 문제를 어떻게 해결했는지를 설명한 글입니다.

저도 이번에 이러한 현상을 Thundering Herd라고 부르는지 처음 알게 되었는데 보통 캐시를 쓰게 되면 디비에서 데이터를 가져와서 Redis 같은 캐시에 넣어두고 이후에는 캐시해서 조회해서 빠른 응답을 주게 됩니다. 하지만 캐시의 데이터를 계속 쓸수는 없고 캐시도 데이터가 많아지면 오래된 데이터는 사라지기 때문에 캐시에 데이터가 없거나 하면 디비에 가서 데이터를 가져와서 다시 캐시에 채워주게 됩니다.

이러한 경우 서버가 1대라면 문제가 안되지만 서버가 많고 당연히 사용자 요청도 동시에 많이 이뤄지기 때문에 캐시가 TTL로 없어지거나 하면 수많은 요청이 동시에 캐시에 데이터가 없어서 디비에 가서 디비에서 연결이 몰리고 이 데이터를 다시 캐시에 채워넣으려고 여러번 저장이 이뤄지게 되는데 이 문제를 Thundering Herd 문제라고 합니다.

이 문제를 Req-Saver라는 라이브러리를 만들어서 여러 요청이 들어왔을 때 하나의 요청만 디비에 갔다와서 데이터를 채워넣고 다른 요청은 캐시에 채워진 데이터로 응답하도록 지연시키는 구현을 했고 이를 스프링에 적용해서 성능 비교를 한 결과 평균 51%의 성능이 향상되었다고 합니다.

서비스에 따라 다르긴 하지만 부하가 심한 경우 캐시 만료에 따라 디비나 캐시에 부하가 몰릴 수 있는데 꽤 괜찮은 방법으로 보입니다.

https://techblog.lycorp.co.jp/ko/req-saver-for-thundering-herd-problem-in-cache

라인에서 Cache를 사용할 때 발생하는 Thundering Herd 문제를 어떻게 해결했는지를 설명한 글입니다. 저도 이번에 이러한 현상을 Thundering Herd라고 부르는지 처음 알게 되었는데 보통 캐시를 쓰게 되면 디비에서 데이터를 가져와서 Redis 같은 캐시에 넣어두고 이후에는 캐시해서 조회해서 빠른 응답을 주게 됩니다. 하지만 캐시의 데이터를 계속 쓸수는 없고 캐시도 데이터가 많아지면 오래된 데이터는 사라지기 때문에 캐시에 데이터가 없거나 하면 디비에 가서 데이터를 가져와서 다시 캐시에 채워주게 됩니다. 이러한 경우 서버가 1대라면 문제가 안되지만 서버가 많고 당연히 사용자 요청도 동시에 많이 이뤄지기 때문에 캐시가 TTL로 없어지거나 하면 수많은 요청이 동시에 캐시에 데이터가 없어서 디비에 가서 디비에서 연결이 몰리고 이 데이터를 다시 캐시에 채워넣으려고 여러번 저장이 이뤄지게 되는데 이 문제를 Thundering Herd 문제라고 합니다. 이 문제를 Req-Saver라는 라이브러리를 만들어서 여러 요청이 들어왔을 때 하나의 요청만 디비에 갔다와서 데이터를 채워넣고 다른 요청은 캐시에 채워진 데이터로 응답하도록 지연시키는 구현을 했고 이를 스프링에 적용해서 성능 비교를 한 결과 평균 51%의 성능이 향상되었다고 합니다. 서비스에 따라 다르긴 하지만 부하가 심한 경우 캐시 만료에 따라 디비나 캐시에 부하가 몰릴 수 있는데 꽤 괜찮은 방법으로 보입니다. https://techblog.lycorp.co.jp/ko/req-saver-for-thundering-herd-problem-in-cache

LY Corporation Tech Blog

라인에서 Cache를 사용할 때 발생하는 Thundering He

[#유퀴즈온더블럭] 천우희가 외모 때문에 오디션 떨어졌었다고😲? 예쁘고 귀엽고 사랑스러운데 연기까지 잘해버려서 세상이 질투했나 보다😎

1. “(데뷔 전에 오디션을 볼 떄) ‘배우 할 수 없다. 못 생겼다' 이런 얘기를 많이 들었어요"

2. “그 당시 허탈함이 있었는데, 그렇게 저한테 타격감은 없었어요. 저는 힘들 걸 ‘너무 힘들다' 이러는 성격이 아니고, ‘와~ 얼마나 잘 되려고 (지금) 이럴까?’ 이렇게 생각하는 편이에요"

3. “집에서 알바할 때도, 제가 전을 직접 부쳤거든요. 하면서도 ‘내 인생이 점점 버라이어티해지는군. 재밌겠어', 약간 이렇게 생각하고"

4. “그냥 이런 생각을 많이 했어요. ‘에피소드 하나 더 생긴다고 생각하지 뭐~', 약간 이렇게" (갈등 = 에피소드)

5. “(그런 상황에서도) 내가 할 수 있는 게 뭘까? 좀 자기 객관화를 해야겠다는 생각이 들더라고요. ‘내가 가지고 있는 포지션과 내가 가지고 있는 강점이 뭐지?’라는 생각을 하면서, 제가 나이대에 있는 배우들을 다 검색해봤어요" (=치열한 자료 조사)

6. “다 검색해봤는데, 저랑 느낌이 비슷한 사람은 없더라고요. (그래서) 그냥 그 치기 어린 나이에 생각했던 건 나는 ‘모 아니면 도다’였어요”

7. “크게 절망하지 않았던 게, 좌절하지 않았던 게, ‘(못 생겨서 배우를 할 수 없다면 하면) 내가 한 번 보여주지. 내가 이 얼굴로 배우의 얼굴이 뭐가 좋은지 진짜 보여줄게’, 이런 마음이 있었어요” (=의지력)

8. “똑같은 상황이라도, 저는 결국 ‘마음가짐’이라고 생각하거든요. 힘들다 힘들다 생각하면 그 생각 안에서 (내가) 못 벗어나는 거에요? 그래서 ‘얼마나 잘 되려고 이럴까?'라고 생각하면서 항상 좋은 면을 생각해보려고 하죠"

- 배우 천우희

https://www.youtube.com/watch?v=dyuaT8xyvDg&t=599s

1. “(데뷔 전에 오디션을 볼 떄) ‘배우 할 수 없다. 못 생겼다' 이런 얘기를 많이 들었어요" 2. “그 당시 허탈함이 있었는데, 그렇게 저한테 타격감은 없었어요. 저는 힘들 걸 ‘너무 힘들다' 이러는 성격이 아니고, ‘와~ 얼마나 잘 되려고 (지금) 이럴까?’ 이렇게 생각하는 편이에요" 3. “집에서 알바할 때도, 제가 전을 직접 부쳤거든요. 하면서도 ‘내 인생이 점점 버라이어티해지는군. 재밌겠어', 약간 이렇게 생각하고" 4. “그냥 이런 생각을 많이 했어요. ‘에피소드 하나 더 생긴다고 생각하지 뭐~', 약간 이렇게" (갈등 = 에피소드) 5. “(그런 상황에서도) 내가 할 수 있는 게 뭘까? 좀 자기 객관화를 해야겠다는 생각이 들더라고요. ‘내가 가지고 있는 포지션과 내가 가지고 있는 강점이 뭐지?’라는 생각을 하면서, 제가 나이대에 있는 배우들을 다 검색해봤어요" (=치열한 자료 조사) 6. “다 검색해봤는데, 저랑 느낌이 비슷한 사람은 없더라고요. (그래서) 그냥 그 치기 어린 나이에 생각했던 건 나는 ‘모 아니면 도다’였어요” 7. “크게 절망하지 않았던 게, 좌절하지 않았던 게, ‘(못 생겨서 배우를 할 수 없다면 하면) 내가 한 번 보여주지. 내가 이 얼굴로 배우의 얼굴이 뭐가 좋은지 진짜 보여줄게’, 이런 마음이 있었어요” (=의지력) 8. “똑같은 상황이라도, 저는 결국 ‘마음가짐’이라고 생각하거든요. 힘들다 힘들다 생각하면 그 생각 안에서 (내가) 못 벗어나는 거에요? 그래서 ‘얼마나 잘 되려고 이럴까?'라고 생각하면서 항상 좋은 면을 생각해보려고 하죠" - 배우 천우희 https://www.youtube.com/watch?v=dyuaT8xyvDg&amp;t=599s

배우 천우희의 스토리적 사고

김음 1. 들어가며 2020년 즈음부터 레딧(Reddit) 같은 북미 웹 커뮤니티에서는 리미널공간(liminal space) 이미지와 이야기가 오가고 이제 어느 정도 덩치를 가진 군집이 되었다. 리미널공간의 이미지를 공유하고 느낌을 토로하는 문화는 인터넷 이곳저곳으로 확산되어 이제 트위터나 인스타그램, 틱톡 같은 플랫폼에서도 리미널스페이스를 검색하면 여러 쎄한 공간 이미지를 접할 수 있다.

리미널스페이스론 - 공간주의

저는 여러가지 서브 컬처나 미학적 개념 등에도 관심이 있는데요, 그 중 최근 미국 호러 게임 씬에서 주목을 꽤 받은 '리미널 스페이스' 라는 공간 개념에 대한 글이 있어 공유해 봅니다.

리미널 스페이스가 유발하는 감정은 공허함과 익숙한 것들의 부재에서 오는 으스스함이 있습니다.

공간주의 - 이제 공간에 주의하십시오

운영팀 매니저

심건호

성장하고 싶어서 스타트업에 반걸음 내딛게 되었고
로앤굿에 합류해 세일즈➡운영 업무로 전환 후 빠르게 달려가고 있습니다.

제 나름의 방향과 속도로 성장하고 싶습니다. 
사람에게 관심을 갖고
솔직함과 공감을 바탕으로 경청하고자 합니다.
#끊임없이배우기 #문제를해결하는

Product Manager

김세환

기획자

jejung

<예술을 소유하는 새로운 방법, NFT로 만나는 예술과 콘텐츠의 미래> 저자로 기술 및 예술 콘텐츠 기획과 강연을 하고 있습니다.

리미널 스페이스 (Liminal space)

서비스 기획

글로벌 서비스 기획

지원준

유용하거나, 재미있는 것들에 관심이 많습니다. 거시적인 테크 트렌드와 먹고 마시는 라이프스타일까지 흥미를 두고 있습니다.

리미널 스페이스 (Liminal space)

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필