AI의 정렬(인류에게 유익한 방향으로 학습시키는 것) 문제를 해결하기 위한 팀인 Superalignment팀의 Lead였던 Ilya와 함께 co-lead였던 Jan Leike가 사임하면서, 실질적으로 팀이 (자진)해체 된 것 같습니다.

OpenAI가 Alignment보다 제품화쪽을 더 빠르게 가져가는 쪽으로 우선순위를 높이면서 발생한 구조적인 변화인 것 같습니다. Alignment에 대한 우려가 있긴 하지만, 이로인해 OpenAI의 행보는 더욱 빨라질 것으로 예상됩니다.

그보다, 이러한 변화에서 생각해 볼 수 있는 가설이 다음과 같이 있는데요.

1️⃣ OpenAI는 훨씬 더 나은 모델이 이미 가지고 있음. 그렇지 않다면 ChatGPT로 이미 많은 돈을 벌고 있는 상태에서 GPT-4 수준의 모델을 모든 사람에게 무료로 제공하지 않을 것.

2️⃣ 퇴사하는 팀원(Ilya, Jan등)이 곧 더 큰 능력이 나올 것을 걱정하지 않는다면 정렬에도 신경 쓰지 않을 것. AI가 지금 수준에 머문다면 대부분 문제가 되지 않을 것이기 때문.

Jan Leike가 사임하면서 쓴 글에는 OpenAI가 Alignment(정렬)에 소홀해서 더 이상 함께 할 수 없다고 판단해서 사임했다고 하는데요. 이런 상황들을 보면 아마도 Ilya와 함께 Superalignment와 관련된 회사나 단체를 설립하지 않을까라는 추측이 됩니다.

OpenAI의 이름과 달리 내부의 행보가 Apple만큼이나 비밀리에 진행되고 있는데요. ㅎㅎ 과연 진실은 어디까지일지 사뭇 궁금해집니다.

AI의 정렬(인류에게 유익한 방향으로 학습시키는 것) 문제를 해결하기 위한 팀인 Superalignment팀의 Lead였던 Ilya와 함께 co-lead였던 Jan Leike가 사임하면서, 실질적으로 팀이 (자진)해체 된 것 같습니다. OpenAI가 Alignment보다 제품화쪽을 더 빠르게 가져가는 쪽으로 우선순위를 높이면서 발생한 구조적인 변화인 것 같습니다. Alignment에 대한 우려가 있긴 하지만, 이로인해 OpenAI의 행보는 더욱 빨라질 것으로 예상됩니다. 그보다, 이러한 변화에서 생각해 볼 수 있는 가설이 다음과 같이 있는데요. 1️⃣ OpenAI는 훨씬 더 나은 모델이 이미 가지고 있음. 그렇지 않다면 ChatGPT로 이미 많은 돈을 벌고 있는 상태에서 GPT-4 수준의 모델을 모든 사람에게 무료로 제공하지 않을 것. 2️⃣ 퇴사하는 팀원(Ilya, Jan등)이 곧 더 큰 능력이 나올 것을 걱정하지 않는다면 정렬에도 신경 쓰지 않을 것. AI가 지금 수준에 머문다면 대부분 문제가 되지 않을 것이기 때문. Jan Leike가 사임하면서 쓴 글에는 OpenAI가 Alignment(정렬)에 소홀해서 더 이상 함께 할 수 없다고 판단해서 사임했다고 하는데요. 이런 상황들을 보면 아마도 Ilya와 함께 Superalignment와 관련된 회사나 단체를 설립하지 않을까라는 추측이 됩니다. OpenAI의 이름과 달리 내부의 행보가 Apple만큼이나 비밀리에 진행되고 있는데요. ㅎㅎ 과연 진실은 어디까지일지 사뭇 궁금해집니다.

📰 OpenAI의 Superalignment 팀 해체

'애널리틱스 엔지니어', 혹은 '분석 엔지니어'라고 들어보셨나요? 미국에서는 대략 3~4년 전부터 화제가 되기 시작했고, 한국에서는 작년부터 본격적으로 주목받고 있습니다. 간단히 말해서, 데이터 애널리틱스(분석) 엔지니어는 '데이터를 사용하기 쉽게 만들어주는 요리사'라고 할 수 있는데요. 그들의 고객은 바로 데이터 분석가, 마케터, 기획자 등 데이터를 손에 쥐고 일하는 모든 현업 전문가입니다.

새로운 데이터 직군, 데이터 애널리틱스 엔지니어란? | 요즘IT

* 퍼온 아티클은 '하트카운트' 팀에서 발행한 테크 블로그 아티클입니다

데이터 애널리틱스 엔지니어! (Data Analytics Engineer, 이하 DAE)
우리나라에는 아직 많이 없지만 점점 JD도 늘어나고 있는 새로운 데이터 직군입니다

데이터 엔지니어, 데이터 분석가와 어떤 차이점이 있지? 하고 생각하실 수 있는데요!
오늘 공유드리는 아티클에는 아래의 내용들이 있습니다.
 * DAE는 데이터 활용자(DA, 마케터, 기획자 등)들이 데이터를 잘 활용할 수 있도록 한다.
 * 위와 같은 업무를 위해 데이터 파이프라인, 데이터 테이블 작업을 하고, 데이터 자체에서 끌어낼 수 있는 인사이트도 제공한다.
 * 기존의 데이터 엔지니어와의 차이는 '누구나 데이터를 쉽게 잘 활용할 수 있게'하는 부분에 초점을 맞추어 고민을 한다는 것이다.
 * 전체 데이터 인프라 구축과 관리에 초점이 맞추어진 데이터 엔지니어와 달리 DAE는 분석하기 편하게 마지막 요리를 하는 것이라 생각할 수 있다.
 * DAE가 되기 위해서는 ETL과 파이프라인 구축을 위한 python 스킬, 데이터 웨어하우스와 마트 구축을 위한 SQL 스킬이 필요하다.
 * 앞으로 데이터 활용을 위한 통합형 인재의 수요는 증가할 것이기 때문에 DAE의 전망은 밝다.

DAE는 기존의 데이터 분석가, 데이터 엔지니어의 능력을 다 가진 사람이라고 생각이 됩니다. 엔지니어링에 능력이 있고, 관심이 있는 분석가 혹은 비즈니스 임팩트에 관심이 있는 엔지니어 였다면 이미 그 역할을 하고 있다고도 생각이 되네요! :)

* 퍼온 아티클은 '하트카운트' 팀에서 발행한 테크 블로그 아티클입니다 데이터 애널리틱스 엔지니어! (Data Analytics Engineer, 이하 DAE)우리나라에는 아직 많이 없지만 점점 JD도 늘어나고 있는 새로운 데이터 직군입니다 데이터 엔지니어, 데이터 분석가와 어떤 차이점이 있지? 하고 생각하실 수 있는데요! 오늘 공유드리는 아티클에는 아래의 내용들이 있습니다.<ul ><li>DAE는 데이터 활용자(DA, 마케터, 기획자 등)들이 데이터를 잘 활용할 수 있도록 한다.</li><li>위와 같은 업무를 위해 데이터 파이프라인, 데이터 테이블 작업을 하고, 데이터 자체에서 끌어낼 수 있는 인사이트도 제공한다.</li><li>기존의 데이터 엔지니어와의 차이는 '누구나 데이터를 쉽게 잘 활용할 수 있게'하는 부분에 초점을 맞추어 고민을 한다는 것이다.</li><li>전체 데이터 인프라 구축과 관리에 초점이 맞추어진 데이터 엔지니어와 달리 DAE는 분석하기 편하게 마지막 요리를 하는 것이라 생각할 수 있다.</li><li>DAE가 되기 위해서는 ETL과 파이프라인 구축을 위한 python 스킬, 데이터 웨어하우스와 마트 구축을 위한 SQL 스킬이 필요하다.</li><li>앞으로 데이터 활용을 위한 통합형 인재의 수요는 증가할 것이기 때문에 DAE의 전망은 밝다.</li></ul> DAE는 기존의 데이터 분석가, 데이터 엔지니어의 능력을 다 가진 사람이라고 생각이 됩니다. 엔지니어링에 능력이 있고, 관심이 있는 분석가 혹은 비즈니스 임팩트에 관심이 있는 엔지니어 였다면 이미 그 역할을 하고 있다고도 생각이 되네요! :)

요즘IT

요즘 새로운 직군, '데이터 애널리틱스 엔지니어'

블로그 플랫폼을 세 번 변경했습니다.

블로그 변천사 (텍스트큐브 -> 티스토리 -> GitHub 페이지)

블로그 플랫폼을 세 번 변경했습니다.

텍스트큐브 -> 티스토리 -> GitHub 페이지(with Jekyll)

블로그 선택도 투자와 같습니다.
꾸준히 개선이 이루어지고 검색엔진에도 잘 노출되는 플랫폼을 신중하게 선택해야 합니다.
저는 얼마 못 가 중단된 텍스트큐브를 선택했으니 완전히 실패한 투자였습니다.

한 플랫폼에서 오랫동안 점수를 쌓는 것은 중요합니다.
저는 세 번이나 옮겨 다녔습니다.
옮겨 다니면서 도메인까지 변경해버려서 점수를 많이 잃었을 겁니다.
도메인과 링크들 만큼은 잘 유지했어야 하는데 그러지 못해 아쉽습니다.

플랫폼마다 장단점이 있습니다만, 지금의 GitHub Pages가 그럭저럭 편안하고 마음에 듭니다.
호스팅 서비스를 받으면서도 내 마음대로 커스터마이징 할 수 있으니.
마크다운으로 깔끔하게 표현할 수 있는 것도 좋고 모든 기록이 GitHub에 백업되는 것도 좋습니다.

하지만 검색엔진의 바람을 탈 수 없는 것은 아쉬운 점입니다.
더 많은 사람들이 글을 읽어주고 피드백을 남겨주는 것은 큰 기쁨이니까요.

만약 다시 2008년으로 돌아가서 블로그를 만든다면 네이버 블로그를 선택할 것 같습니다.
그때는 개발자가 네이버 블로그에 글을 쓴다는 것이 뭔가 부끄럽다고 생각을 했습니다.
겉 멋만 들어서 진짜 중요한 걸 못 봤던 건 아닐까?
네이버 블로그가 지금도 사용자의 의견을 들으며 꾸준히 좋아지고 있는 걸 보면서 제 눈이 얼마나 얕았는지 생각해 보게 됩니다.

어쨌든 저는 마지막으로 GitHub Pages를 선택했고…
이 블로그에서 더 이상 이사가지 않고 잘 마무리할 수 있었으면 좋겠습니다. 😁

https://jeho.page/essay/2024/05/19/blog-platform-evolution.html

블로그 플랫폼을 세 번 변경했습니다. 텍스트큐브 -&gt; 티스토리 -&gt; GitHub 페이지(with Jekyll) 블로그 선택도 투자와 같습니다. 꾸준히 개선이 이루어지고 검색엔진에도 잘 노출되는 플랫폼을 신중하게 선택해야 합니다. 저는 얼마 못 가 중단된 텍스트큐브를 선택했으니 완전히 실패한 투자였습니다. 한 플랫폼에서 오랫동안 점수를 쌓는 것은 중요합니다. 저는 세 번이나 옮겨 다녔습니다. 옮겨 다니면서 도메인까지 변경해버려서 점수를 많이 잃었을 겁니다. 도메인과 링크들 만큼은 잘 유지했어야 하는데 그러지 못해 아쉽습니다. 플랫폼마다 장단점이 있습니다만, 지금의 GitHub Pages가 그럭저럭 편안하고 마음에 듭니다. 호스팅 서비스를 받으면서도 내 마음대로 커스터마이징 할 수 있으니. 마크다운으로 깔끔하게 표현할 수 있는 것도 좋고 모든 기록이 GitHub에 백업되는 것도 좋습니다. 하지만 검색엔진의 바람을 탈 수 없는 것은 아쉬운 점입니다. 더 많은 사람들이 글을 읽어주고 피드백을 남겨주는 것은 큰 기쁨이니까요. 만약 다시 2008년으로 돌아가서 블로그를 만든다면 네이버 블로그를 선택할 것 같습니다. 그때는 개발자가 네이버 블로그에 글을 쓴다는 것이 뭔가 부끄럽다고 생각을 했습니다. 겉 멋만 들어서 진짜 중요한 걸 못 봤던 건 아닐까? 네이버 블로그가 지금도 사용자의 의견을 들으며 꾸준히 좋아지고 있는 걸 보면서 제 눈이 얼마나 얕았는지 생각해 보게 됩니다. 어쨌든 저는 마지막으로 GitHub Pages를 선택했고… 이 블로그에서 더 이상 이사가지 않고 잘 마무리할 수 있었으면 좋겠습니다. 😁 https://jeho.page/essay/2024/05/19/blog-platform-evolution.html

K리그 프로그래머

티스토리에서는 왜 옮기셨나요?

🧮💰요즘 S급 리서처들을 빅테크에서 스카웃해오려고 연락하면 “GPU 몇 개나 쓸 수 있어요?”라는 말부터 한다더니, OpenAI도 별수 없구먼 🤣 #틀림

암튼, 걍 재미로 계산해봅시다.

OpenAI가 GPU를 약 20~40만개쯤 사용하고 있는 것으로 예상되는데, 그 중 훈련에 사용하는 GPU를 보수적으로 잡아 10만개라고 한다면, Superalignment에 20%의 GPU를 약속했었으니, 약 2만개.

그렇다는 것은 Ilya 같은 천재를 영입하려면 최소 4만개 정도의 GPU는 가지고 있어야한다는 것. A100 1개에 1만불이니, 2억달러 = 약 3천억.

Ilya 입사하면 3천억원어치 장비 사줘야 함. 🤣 내 맥북 에어 눈 감아. 🥹

🧮💰요즘 S급 리서처들을 빅테크에서 스카웃해오려고 연락하면 “GPU 몇 개나 쓸 수 있어요?”라는 말부터 한다더니, OpenAI도 별수 없구먼 🤣 #틀림 암튼, 걍 재미로 계산해봅시다. OpenAI가 GPU를 약 20~40만개쯤 사용하고 있는 것으로 예상되는데, 그 중 훈련에 사용하는 GPU를 보수적으로 잡아 10만개라고 한다면, Superalignment에 20%의 GPU를 약속했었으니, 약 2만개. 그렇다는 것은 Ilya 같은 천재를 영입하려면 최소 4만개 정도의 GPU는 가지고 있어야한다는 것. A100 1개에 1만불이니, 2억달러 = 약 3천억. Ilya 입사하면 3천억원어치 장비 사줘야 함. 🤣 내 맥북 에어 눈 감아. 🥹

One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are...

Design Docs at Google

Google Design Docs에 대한 설명입니다.

구글 내부에서는 소프트웨어 설계를 정의하는 디자인 문서를 비공식 정으로 사용한다고 합니다. 비공식 문서라서 엄격한 가이드라인이 있는 것은 아니지만 그동안 수많은 디자인 문서가 만들어지면서 유용한 구조가 자리 잡았다고 합니다.

맥락과 목표, 목표가 아닌 것을 명확히 설명하고 실제 디자인에 대한 설명과 다이어그램, 제약 조건을 명시하고 다른 대안이나 우려사항은 없는지를 설명하지만 바쁜 사람들도 쉽게 읽을 수 있을 정도로 짧아야 한다고 합니다.

디자인 문서를 작성하는 것도 비용이기 때문에 작성할 때 고민해야 하는데 보통 의사 결정에 대한 설명 없이 구현에 대한 설명만 있다면 문서를 작성하는 것보다는 바로 프로그래미을 작성하는게 더 좋은 선택이라고 얘기합니다.

이렇게 만든 문서는 반복을 통해서 개선한 뒤 리뷰를 통해서 다듬고 이후에도 계속 유지 관리를 하면서 시간이 지나면 소프트웨어가 만들어 진 후 다시 학습에 사용된다고 합니다.

----

디자인 문서나 테크 스펙을 많은 조직에서 사용합니다만 개인적으로 디자인 문서를 좋아하는 편은 아닙니다. 조직의 상황이나 문제에 따라 다르긴 하겠습니다만 일반적으로는 디자인 문서를 작성하는 것이 실제 할일보다는 너무 장황하게 느껴서 오히려 일이 느려지는 느낌을 많이 받는 편입니다. 실제 일보다 서류 작업이 많은 보수적 조직에 닮아가는 느낌이 어느 정도 있습니다.

물론 문서를 작성하고 형식에 맞게 설명을 하면서 구현자 스스로도 정리를 하게되는 효과도 있고 다른 사람도 이해할 수 있게 문서로 남음으로써 이해도도 높이고 히스토리가 되는 장점도 있다고 생각합니다. 이렇게 되려면 문서의 실용성이 상당히 많이 검증되어야 합니다만 일반적으로는 협업시에 제출해야할 서류 정도로 쓰이는 경우가 많아서 너무 사소한 일에도 문서를 작성해야 하거나 너무 추상적인 문서가 작성되는 상황을 종종 보게 됩니다.

물론 개인 취향이 많이 반영되어 있긴 합니다. 문서의 필요성은 중요하긴 하지만 저는 일반적으로 좀 장황하게 느껴지는 편입니다.

https://www.industrialempathy.com/posts/design-docs-at-google/

Google Design Docs에 대한 설명입니다. 구글 내부에서는 소프트웨어 설계를 정의하는 디자인 문서를 비공식 정으로 사용한다고 합니다. 비공식 문서라서 엄격한 가이드라인이 있는 것은 아니지만 그동안 수많은 디자인 문서가 만들어지면서 유용한 구조가 자리 잡았다고 합니다. 맥락과 목표, 목표가 아닌 것을 명확히 설명하고 실제 디자인에 대한 설명과 다이어그램, 제약 조건을 명시하고 다른 대안이나 우려사항은 없는지를 설명하지만 바쁜 사람들도 쉽게 읽을 수 있을 정도로 짧아야 한다고 합니다. 디자인 문서를 작성하는 것도 비용이기 때문에 작성할 때 고민해야 하는데 보통 의사 결정에 대한 설명 없이 구현에 대한 설명만 있다면 문서를 작성하는 것보다는 바로 프로그래미을 작성하는게 더 좋은 선택이라고 얘기합니다. 이렇게 만든 문서는 반복을 통해서 개선한 뒤 리뷰를 통해서 다듬고 이후에도 계속 유지 관리를 하면서 시간이 지나면 소프트웨어가 만들어 진 후 다시 학습에 사용된다고 합니다. ---- 디자인 문서나 테크 스펙을 많은 조직에서 사용합니다만 개인적으로 디자인 문서를 좋아하는 편은 아닙니다. 조직의 상황이나 문제에 따라 다르긴 하겠습니다만 일반적으로는 디자인 문서를 작성하는 것이 실제 할일보다는 너무 장황하게 느껴서 오히려 일이 느려지는 느낌을 많이 받는 편입니다. 실제 일보다 서류 작업이 많은 보수적 조직에 닮아가는 느낌이 어느 정도 있습니다. 물론 문서를 작성하고 형식에 맞게 설명을 하면서 구현자 스스로도 정리를 하게되는 효과도 있고 다른 사람도 이해할 수 있게 문서로 남음으로써 이해도도 높이고 히스토리가 되는 장점도 있다고 생각합니다. 이렇게 되려면 문서의 실용성이 상당히 많이 검증되어야 합니다만 일반적으로는 협업시에 제출해야할 서류 정도로 쓰이는 경우가 많아서 너무 사소한 일에도 문서를 작성해야 하거나 너무 추상적인 문서가 작성되는 상황을 종종 보게 됩니다. 물론 개인 취향이 많이 반영되어 있긴 합니다. 문서의 필요성은 중요하긴 하지만 저는 일반적으로 좀 장황하게 느껴지는 편입니다. https://www.industrialempathy.com/posts/design-docs-at-google/

Industrialempathy

고대의 머신러닝 시절에는 대규모 언어 모델(LLM)을 조정된 모델의 기반으로 사용하기 위해서는 먼저 모든 데이터를 사용해 가능한 모든 머신러닝

생성형 AI의 개발 프로세스 이해하기

커리어리 친구들, 새로운 생성형 AI 패러다임에서의 개발 프로세스는 과거와는 상당히 다른데요, 전체적인 개념을 보면 일단 생성형 AI 모델(하나 또는 여러 개)을 선택합니다. 그런 다음 프롬프트를 만지작거리고(이것을 "프롬프트 엔지니어링"이라고 하는데, 실제 엔지니어들에게는 기분 나쁜 표현), 초매개변수를 조절해서 모델이 원하는 대로 작동하도록 합니다. 그래서 생성형 AI 개발 프로세스가 어떻게 되는 지 한눈에 살펴 볼 수 있어서 이 컬럼을 추천합니다.

원문보기:
https://www.itworld.co.kr/news/337110#csidx18cbdc71a9f503494989ba2f291b511

https://www.itworld.co.kr/news/337110

커리어리 친구들, 새로운 생성형 AI 패러다임에서의 개발 프로세스는 과거와는 상당히 다른데요, 전체적인 개념을 보면 일단 생성형 AI 모델(하나 또는 여러 개)을 선택합니다. 그런 다음 프롬프트를 만지작거리고(이것을 "프롬프트 엔지니어링"이라고 하는데, 실제 엔지니어들에게는 기분 나쁜 표현), 초매개변수를 조절해서 모델이 원하는 대로 작동하도록 합니다. 그래서 생성형 AI 개발 프로세스가 어떻게 되는 지 한눈에 살펴 볼 수 있어서 이 컬럼을 추천합니다. 원문보기: https://www.itworld.co.kr/news/337110#csidx18cbdc71a9f503494989ba2f291b511 https://www.itworld.co.kr/news/337110

ITWorld Korea

<생성형 AI 개발 프로세스는?>

At Microsoft Build 2024, developers can learn how NVIDIA and Microsoft make every layer of the generative AI stack work well together.

How Developers Can Construct the Future of Generative AI at Microsoft Build 2024

커리어리 친구들, NVIDIA와 Microsoft는 Microsoft Build 2024에서 개발자를 위한 새로운 생성 AI 솔루션을 발표했습니다.

NVIDIA의 전체 스택 AI 플랫폼과 Microsoft Azure의 통합을 통해 개발자들이 더 쉽게 생성 AI 애플리케이션을 만들고 배포할 수 있습니다.

이 행사에서는 NVIDIA 부스에서 실시간 데모와 전문가 상담을 제공하며, NVIDIA Omniverse 및 기타 최신 기술을 소개합니다. 이 협력은 개발자들이 AI 기술을 더 효과적으로 활용할 수 있도록 지원합니다.

더 자세한 사항은 아래 블로그를 읽어 주십시오(https://blogs.nvidia.com/blog/microsoft-build-2024/

커리어리 친구들, NVIDIA와 Microsoft는 Microsoft Build 2024에서 개발자를 위한 새로운 생성 AI 솔루션을 발표했습니다. NVIDIA의 전체 스택 AI 플랫폼과 Microsoft Azure의 통합을 통해 개발자들이 더 쉽게 생성 AI 애플리케이션을 만들고 배포할 수 있습니다. 이 행사에서는 NVIDIA 부스에서 실시간 데모와 전문가 상담을 제공하며, NVIDIA Omniverse 및 기타 최신 기술을 소개합니다. 이 협력은 개발자들이 AI 기술을 더 효과적으로 활용할 수 있도록 지원합니다. 더 자세한 사항은 아래 블로그를 읽어 주십시오(https://blogs.nvidia.com/blog/microsoft-build-2024/

NVIDIA Blog

<혁신적인 생성 AI 솔루션 소개>

Learn more about (almost) everything announced at Google I/O 2024.

100 things we announced at I/O 2024

커리어리 친구들, Google I/O 2024 핵심 발표 내용을 한 장으로 정리해 보았습니다!

1. AI 모델 Gemini 업데이트:
* Gemini 1.5 Pro 성능 향상, 100만 토큰 컨텍스트 윈도우 지원
* Gemini 1.5 Flash: 빠르고 효율적인 경량 모델, API에서 가장 빠른 Gemini 모델
* Project Astra: AI 비서의 미래에 대한 Google의 비전
* Trillium: 6세대 TPU, 성능 및 지속가능성 향상
* 오디오 이해 기능 추가: AI Studio에서 이미지 및 오디오 추론 가능
* Gemini Nano with Multimodality: Pixel 폰에서 텍스트, 시각, 소리, 음성 언어 이해 가능

2. 생성형 AI 도구:
* Imagen 3: 고품질 이미지 생성 모델, 사실적인 이미지 생성, 텍스트 렌더링 향상
* Veo: 고품질 비디오 생성 모델, 1080p 해상도, 1분 이상의 영상 생성
* Music AI Sandbox: 새로운 악기 섹션 생성, 트랙 간 스타일 전환 등 음악 제작 도구
* VideoFX: 아이디어를 비디오 클립으로 변환하는 실험적 도구
* ImageFX: 편집 제어 기능 추가, Imagen 3 기반 사실적인 이미지 생성
* MusicFX: "DJ 모드" 추가, 생성형 AI를 사용하여 비트 믹싱

3. Gemini 앱 업데이트:
* Gemini Advanced: 100만 토큰 컨텍스트 윈도우, 1,500페이지 PDF 이해 가능
* 파일 업로드 기능: Google Drive 또는 기기에서 직접 파일 업로드
* 데이터 분석 기능: 업로드된 데이터 파일 분석 및 차트 생성
* 여행 계획 기능: 맞춤형 여행 일정 생성
* Gemini Live: 음성 기반 대화형 경험, 자연스러운 대화 지원
* Gems: 특정 요구에 맞게 사용자 지정 가능한 Gemini 버전

4. Google 검색 업데이트:
* Gemini 기반 검색 모델: 멀티 스텝 추론, 계획, 멀티모달 기능 통합
* AI Overviews: 미국 출시, 복잡한 질문에 대한 답변 제공
* 계획 기능: 식사 및 여행 계획, 맞춤 설정 기능 제공
* 비디오 이해 기능: 비디오를 사용한 질문 가능
* AI 기반 검색 결과 페이지: 새로운 아이디어 검색 시 AI가 구성한 결과 페이지 제공

5. Workspace 및 Google 포토 업데이트:
* Gmail, Docs, Drive, Slides, Sheets에서 Gemini 1.5 Pro 사이드 패널 제공
* Gmail 사이드 패널: 이메일 요약, 중요 세부 정보 및 실행 항목 제공
* Gmail 모바일 앱: 컨텍스트 기반 스마트 답장, Gmail Q&A 기능 제공
* Google 포토 Ask Photos: 특정 사진 검색, 여행 하이라이트 갤러리 생성, 캡션 작성

6. Android 업데이트:
* Gemini Nano with Multimodality: Pixel 폰에서 멀티모달 기능 지원
* Talkback 기능 향상: Gemini Nano with Multimodality 기반 접근성 기능 향상
* 사기 전화 감지 기능: Gemini Nano 기반 사기 전화 감지
* Circle to Search: 1억 대 이상의 Android 기기에서 사용 가능, 기능 확장
* Android 15 베타: Theft Detection Lock, Private space 기능 추가
* Google Play Protect: 기기 내 AI를 사용하여 사기성 앱 탐지

7. 개발자를 위한 업데이트:
* Gemini API 개발자 경진 대회: 가장 유용하고 혁신적인 AI 앱 발굴
* PaliGemma: 시각적 Q&A 및 이미지 캡션에 최적화된 비전-언어 오픈 모델
* Gemma 2: 새로운 아키텍처 기반, 270억 개 매개변수 인스턴스 포함
* Android Studio, IDX, Firebase, Colab, VSCode 등에서 Gemini 모델 지원
* Google AI Studio: 영국 및 EU를 포함한 200개 이상 국가에서 사용 가능
* Firebase Genkit 베타: 앱에 생성형 AI 경험 구축 지원
* Firebase Data Connect: Firebase에서 SQL 사용 가능

8. 책임감 있는 AI 개발:
* AI 지원 레드 티밍: AI 시스템의 약점 테스트 및 개선
* SynthID 확장: 텍스트 및 비디오 모달리티 지원
* LearnLM: 학습에 최적화된 Gemini 기반 모델, 교육 분야 파트너십 확대
* Illuminate: 지식 접근성 및 이해도 향상을 위한 실험적 도구

https://blog.google/technology/ai/google-io-2024-100-announcements/

커리어리 친구들, Google I/O 2024 핵심 발표 내용을 한 장으로 정리해 보았습니다! 1. AI 모델 Gemini 업데이트: * Gemini 1.5 Pro 성능 향상, 100만 토큰 컨텍스트 윈도우 지원 * Gemini 1.5 Flash: 빠르고 효율적인 경량 모델, API에서 가장 빠른 Gemini 모델 * Project Astra: AI 비서의 미래에 대한 Google의 비전 * Trillium: 6세대 TPU, 성능 및 지속가능성 향상 * 오디오 이해 기능 추가: AI Studio에서 이미지 및 오디오 추론 가능 * Gemini Nano with Multimodality: Pixel 폰에서 텍스트, 시각, 소리, 음성 언어 이해 가능 2. 생성형 AI 도구: * Imagen 3: 고품질 이미지 생성 모델, 사실적인 이미지 생성, 텍스트 렌더링 향상 * Veo: 고품질 비디오 생성 모델, 1080p 해상도, 1분 이상의 영상 생성 * Music AI Sandbox: 새로운 악기 섹션 생성, 트랙 간 스타일 전환 등 음악 제작 도구 * VideoFX: 아이디어를 비디오 클립으로 변환하는 실험적 도구 * ImageFX: 편집 제어 기능 추가, Imagen 3 기반 사실적인 이미지 생성 * MusicFX: "DJ 모드" 추가, 생성형 AI를 사용하여 비트 믹싱 3. Gemini 앱 업데이트: * Gemini Advanced: 100만 토큰 컨텍스트 윈도우, 1,500페이지 PDF 이해 가능 * 파일 업로드 기능: Google Drive 또는 기기에서 직접 파일 업로드 * 데이터 분석 기능: 업로드된 데이터 파일 분석 및 차트 생성 * 여행 계획 기능: 맞춤형 여행 일정 생성 * Gemini Live: 음성 기반 대화형 경험, 자연스러운 대화 지원 * Gems: 특정 요구에 맞게 사용자 지정 가능한 Gemini 버전 4. Google 검색 업데이트: * Gemini 기반 검색 모델: 멀티 스텝 추론, 계획, 멀티모달 기능 통합 * AI Overviews: 미국 출시, 복잡한 질문에 대한 답변 제공 * 계획 기능: 식사 및 여행 계획, 맞춤 설정 기능 제공 * 비디오 이해 기능: 비디오를 사용한 질문 가능 * AI 기반 검색 결과 페이지: 새로운 아이디어 검색 시 AI가 구성한 결과 페이지 제공 5. Workspace 및 Google 포토 업데이트: * Gmail, Docs, Drive, Slides, Sheets에서 Gemini 1.5 Pro 사이드 패널 제공 * Gmail 사이드 패널: 이메일 요약, 중요 세부 정보 및 실행 항목 제공 * Gmail 모바일 앱: 컨텍스트 기반 스마트 답장, Gmail Q&amp;A 기능 제공 * Google 포토 Ask Photos: 특정 사진 검색, 여행 하이라이트 갤러리 생성, 캡션 작성 6. Android 업데이트: * Gemini Nano with Multimodality: Pixel 폰에서 멀티모달 기능 지원 * Talkback 기능 향상: Gemini Nano with Multimodality 기반 접근성 기능 향상 * 사기 전화 감지 기능: Gemini Nano 기반 사기 전화 감지 * Circle to Search: 1억 대 이상의 Android 기기에서 사용 가능, 기능 확장 * Android 15 베타: Theft Detection Lock, Private space 기능 추가 * Google Play Protect: 기기 내 AI를 사용하여 사기성 앱 탐지 7. 개발자를 위한 업데이트: * Gemini API 개발자 경진 대회: 가장 유용하고 혁신적인 AI 앱 발굴 * PaliGemma: 시각적 Q&amp;A 및 이미지 캡션에 최적화된 비전-언어 오픈 모델 * Gemma 2: 새로운 아키텍처 기반, 270억 개 매개변수 인스턴스 포함 * Android Studio, IDX, Firebase, Colab, VSCode 등에서 Gemini 모델 지원 * Google AI Studio: 영국 및 EU를 포함한 200개 이상 국가에서 사용 가능 * Firebase Genkit 베타: 앱에 생성형 AI 경험 구축 지원 * Firebase Data Connect: Firebase에서 SQL 사용 가능 8. 책임감 있는 AI 개발: * AI 지원 레드 티밍: AI 시스템의 약점 테스트 및 개선 * SynthID 확장: 텍스트 및 비디오 모달리티 지원 * LearnLM: 학습에 최적화된 Gemini 기반 모델, 교육 분야 파트너십 확대 * Illuminate: 지식 접근성 및 이해도 향상을 위한 실험적 도구 https://blog.google/technology/ai/google-io-2024-100-announcements/

Google

<한 장으로 보는 구글 IO 2024>

일상에서 마주치는 수많은 문제를 심리학의 관점에서 세심하고 유쾌하게 풀어내 젊은 독자들에게 폭발적인 사랑을 받아온 신고은 작가의 저서로, 인간관계, 일, 성공, 사랑 등 무엇 하나 제대로 안되는 것 같은 이들...

잘하고 싶어서 자꾸만 애썼던 너에게

한 여행지에서 그곳에 사는 주민을 만났다. 그는 나를 부러움의 시선으로 바라봤다. “여유롭게 여행도 다니고 좋겠어요.” 반대로 나는 그를 부러워했다. “이렇게 근사한 곳에 산다니 좋겠어요.” 내가 부러워했던 삶의 주체가 나를 부러워한다는 건 아이러니한 현실이었다.

우리는 가질 수 없는 것을 아쉬워한다. 그러나 나에게도 남이 가지지 못한 무언가가 있다. 이룰 필요가 없는 목표에 애쓰기보다는 이룰 가능성이 있는 목표에 힘을 싣는 것, 그것이 나를 더 나은 사람으로 만드는 유일한 방법이다.

방어기제를 극복하려면 감정을 있는 그대로 인정해야 한다. 이 말은 감정대로 행동하라는 것이 아니다. 오히려 본심을 숨기려 할수록 통제가 어려워지고 본능적으로 행동하게 된다. 다시 말해, 감정을 인정해야 행동까지 가는 것을 막을 수 있다. 감정은 실체를 들키면 꼬리를 내리기 때문이다.

타인을 위해 내 마음을 누르는 건 진정한 행복이 될 수 없다. 타인의 행복을 바라보는 것이 내가 경험하는 행복만큼 클 수 없기 때문이다. 나를 갈아서 타인을 위하는 건 건강한 삶이 아니다. 불안을 해소하기 위한 수단일 뿐이다. 그리고 그 수단이 다시 나를 힘겹게 하니 결국은 플러스마이너스 제로다.

헌신이 습관이 되면 만족감은 떨어진다. 저울질이 시작되고 억울해진다. ‘나는 이만큼 희생하는데 걔는 왜 받기만 할까? 내가 해주듯이 알아서 해주면 안 되나?’ 돌아오지 않는 보상에 괴로움이 커진다. 결국은 상대와의 관계도 나빠지고 자신의 마음을 지키지도 못한다. 나를 위해 살지 못하는 사람은 남을 위해서도 살 수 없다. 무엇보다 중요한 것은 나 자신이다.

보라색을 칠하는 아이가 있다. 보통은 이렇게 칭찬한다. “보라색 너무 예쁘다!” 이제 아이는 매일 보라색으로만 그림을 그린다. ‘보라색=예쁘다’라는 모범답안이 생겼기 때문에 다른 답을 선택하지 못한다. 만약 “보라색을 칠했네?” 하고 만다면 어떨까? 아이는 관심만 받을 뿐 정해진 정답에 갇히지 않는다. 이제 다른 색도 집을 수 있게 된다. 그때 또 관심을 주면 된다.

“이번엔 노란색으로 칠했구나!” 어떤 행동을 해야 관심을 받는 것이 아니라, 어떤 행동을 해도 관심을 받는다는 걸 느낄 때, 선택의 결과가 아닌 ‘나’의 선택이 존중받는다고 느낀다. 그 마음은 나라는 존재 자체가 소중하다는 믿음을 심어준다. 조건 없는 인정의 시작은 존재 자체를 읽어주는 것이다. 관심을 주되 판단은 배제하는 것. 나에게도 마찬가지다.

행복해지고 싶지 않은 사람이 있을까? 우리는 모두 행복해지기 위해 산다. 문제는 때때로 우리의 행복을 남에게 맡긴다는 데 있다. ‘좋은 일이 생겼으면…’ ‘좋은 사람이 나타났으면…’ 하고 말이다. 이는 즐거운 일이 일어나지 않고, 우리를 기쁘게 해주는 사람이 없다면 결코 행복할 수 없다는 뜻이기도 하다.

그렇다면 행복을 어떻게 찾아야 할까? 행복의 주체가 ‘나’여야 한다. 내가 고민하고 내가 결정하고 내가 선택한 행동으로 행복해야 한다. 그리고 행복의 주체가 되기 위해서는 나 자신을 잘 알아야 한다.

내가 왜 불안한지, 왜 두려운지, 왜 화가 나는지 등등 자신의 감정에 담긴 이유를 제대로 이해하면 그 안에서 해결의 실마리가 보인다. 자신도 미처 몰랐던 스스로의 모습을 마주하고, 바라보고, 보듬어줄 수 있을 때만이 비로소 우리는 한 뼘 자란 ‘나’와 조우할 수 있게 된다.

자신의 모습에 100% 만족하는 사람은 없다. 당장 내다버리고 싶은 모습도 있을 것이다. 하지만 타인을 나를 정의하지 못한다. 누구보다 나를 잘 아는 것은 나다. 우리가 적극적으로 자신의 마음을 들여다보아야 하는 이유다. 내가 나의 마음을 정확히 이해할 때만이 우리는 ‘남’에게 좋은 사람이 아니라 ‘나’에게 좋은 사람이 될 수 있다.

아무렇지 않은 척, 괜찮은 척 가면을 쓰고 산다면? 상처받는 게 두려워서 도전조차 하지 않는다면? 나 하나만 참으면 된다고 생각한다면? 삶의 매 순간이 도장 깨기 같다고 느껴진다면? 타인의 평가를 최우선에 두고 살고 있다면?

지금 어떤 삶을 살고 있는가? 살 만한가, 죽지 못해 버티고 있는가. 사람들은 궁지에 몰리면 둘 중 하나를 선택한다. 떨어져 죽을 때까지 버티거나 새로운 길을 찾거나. 떨어져 죽는 것보단 새로운 길을 밟는 게 낫다. 그러나 딱 1도만큼 방향을 틀 용기도 우리에겐 부족하다.

그때 내가 나를 믿어준다면 어느 방향으로 걸어야 하는지 자연히 알게 된다. 딱 한 걸음만 발을 떼면 마음가짐이 달라지고, 마음가짐은 자신감이 되어 행동에 힘을 실어준다. 그렇게 기대는 현실에 가까워진다.

“잘하고 싶고, 잘 살고 싶은데 내 발걸음은 왜 이렇게 엉망진창일까?” 누구나 한번쯤 떠올렸을 생각이다. 사랑받고 싶고 존중받고 싶고 인정받고 싶은 마음은 굴뚝같은데 무엇 하나 신통치 않고, 나만 빼고 모두들 저만치 앞서가는 것 같아 무기력해진다.

‘나는 안되는 사람인가?’ 불안은 우울로, 상처로, 단념으로 이어진다. 인생은 마음으로 걷는 여정이다. 스스로의 마음을 읽을 줄 아는 사람과 그렇지 않은 사람은 분명히 다르다. 당장 완벽하진 않더라도 3년 후의 나, 5년 후의 나는 지금과는 전혀 다른 모습일 것이다.

인생을 후회 없이 사는 사람은 행복이 찾아오길 기다리지 않는다. 그들은 자신이 언제 미소 짓는지, 누구와 함께 있고 싶은지, 어떤 일에 뿌듯한지를 알고 그 순간을 자신의 것으로 만든다.

상처받지 않는 유일한 방법은 스스로를 할퀴던 채찍을 내려놓는 것이다. 우리는 잘 맞설 수 있고 잘 견딜 수 있고 잘 해낼 수 있는 사람이다. 이제 스스로를 상처 입히던 채찍을 내려놓고, 나에게 친절한 응원을 건네보자. 어제보다 나은 나를 발견하게 될 것이다.

한 여행지에서 그곳에 사는 주민을 만났다. 그는 나를 부러움의 시선으로 바라봤다. “여유롭게 여행도 다니고 좋겠어요.” 반대로 나는 그를 부러워했다. “이렇게 근사한 곳에 산다니 좋겠어요.” 내가 부러워했던 삶의 주체가 나를 부러워한다는 건 아이러니한 현실이었다. 우리는 가질 수 없는 것을 아쉬워한다. 그러나 나에게도 남이 가지지 못한 무언가가 있다. 이룰 필요가 없는 목표에 애쓰기보다는 이룰 가능성이 있는 목표에 힘을 싣는 것, 그것이 나를 더 나은 사람으로 만드는 유일한 방법이다. 방어기제를 극복하려면 감정을 있는 그대로 인정해야 한다. 이 말은 감정대로 행동하라는 것이 아니다. 오히려 본심을 숨기려 할수록 통제가 어려워지고 본능적으로 행동하게 된다. 다시 말해, 감정을 인정해야 행동까지 가는 것을 막을 수 있다. 감정은 실체를 들키면 꼬리를 내리기 때문이다. 타인을 위해 내 마음을 누르는 건 진정한 행복이 될 수 없다. 타인의 행복을 바라보는 것이 내가 경험하는 행복만큼 클 수 없기 때문이다. 나를 갈아서 타인을 위하는 건 건강한 삶이 아니다. 불안을 해소하기 위한 수단일 뿐이다. 그리고 그 수단이 다시 나를 힘겹게 하니 결국은 플러스마이너스 제로다. 헌신이 습관이 되면 만족감은 떨어진다. 저울질이 시작되고 억울해진다. ‘나는 이만큼 희생하는데 걔는 왜 받기만 할까? 내가 해주듯이 알아서 해주면 안 되나?’ 돌아오지 않는 보상에 괴로움이 커진다. 결국은 상대와의 관계도 나빠지고 자신의 마음을 지키지도 못한다. 나를 위해 살지 못하는 사람은 남을 위해서도 살 수 없다. 무엇보다 중요한 것은 나 자신이다. 보라색을 칠하는 아이가 있다. 보통은 이렇게 칭찬한다. “보라색 너무 예쁘다!” 이제 아이는 매일 보라색으로만 그림을 그린다. ‘보라색=예쁘다’라는 모범답안이 생겼기 때문에 다른 답을 선택하지 못한다. 만약 “보라색을 칠했네?” 하고 만다면 어떨까? 아이는 관심만 받을 뿐 정해진 정답에 갇히지 않는다. 이제 다른 색도 집을 수 있게 된다. 그때 또 관심을 주면 된다. “이번엔 노란색으로 칠했구나!” 어떤 행동을 해야 관심을 받는 것이 아니라, 어떤 행동을 해도 관심을 받는다는 걸 느낄 때, 선택의 결과가 아닌 ‘나’의 선택이 존중받는다고 느낀다. 그 마음은 나라는 존재 자체가 소중하다는 믿음을 심어준다. 조건 없는 인정의 시작은 존재 자체를 읽어주는 것이다. 관심을 주되 판단은 배제하는 것. 나에게도 마찬가지다. 행복해지고 싶지 않은 사람이 있을까? 우리는 모두 행복해지기 위해 산다. 문제는 때때로 우리의 행복을 남에게 맡긴다는 데 있다. ‘좋은 일이 생겼으면…’ ‘좋은 사람이 나타났으면…’ 하고 말이다. 이는 즐거운 일이 일어나지 않고, 우리를 기쁘게 해주는 사람이 없다면 결코 행복할 수 없다는 뜻이기도 하다. 그렇다면 행복을 어떻게 찾아야 할까? 행복의 주체가 ‘나’여야 한다. 내가 고민하고 내가 결정하고 내가 선택한 행동으로 행복해야 한다. 그리고 행복의 주체가 되기 위해서는 나 자신을 잘 알아야 한다. 내가 왜 불안한지, 왜 두려운지, 왜 화가 나는지 등등 자신의 감정에 담긴 이유를 제대로 이해하면 그 안에서 해결의 실마리가 보인다. 자신도 미처 몰랐던 스스로의 모습을 마주하고, 바라보고, 보듬어줄 수 있을 때만이 비로소 우리는 한 뼘 자란 ‘나’와 조우할 수 있게 된다. 자신의 모습에 100% 만족하는 사람은 없다. 당장 내다버리고 싶은 모습도 있을 것이다. 하지만 타인을 나를 정의하지 못한다. 누구보다 나를 잘 아는 것은 나다. 우리가 적극적으로 자신의 마음을 들여다보아야 하는 이유다. 내가 나의 마음을 정확히 이해할 때만이 우리는 ‘남’에게 좋은 사람이 아니라 ‘나’에게 좋은 사람이 될 수 있다. 아무렇지 않은 척, 괜찮은 척 가면을 쓰고 산다면? 상처받는 게 두려워서 도전조차 하지 않는다면? 나 하나만 참으면 된다고 생각한다면? 삶의 매 순간이 도장 깨기 같다고 느껴진다면? 타인의 평가를 최우선에 두고 살고 있다면? 지금 어떤 삶을 살고 있는가? 살 만한가, 죽지 못해 버티고 있는가. 사람들은 궁지에 몰리면 둘 중 하나를 선택한다. 떨어져 죽을 때까지 버티거나 새로운 길을 찾거나. 떨어져 죽는 것보단 새로운 길을 밟는 게 낫다. 그러나 딱 1도만큼 방향을 틀 용기도 우리에겐 부족하다. 그때 내가 나를 믿어준다면 어느 방향으로 걸어야 하는지 자연히 알게 된다. 딱 한 걸음만 발을 떼면 마음가짐이 달라지고, 마음가짐은 자신감이 되어 행동에 힘을 실어준다. 그렇게 기대는 현실에 가까워진다. “잘하고 싶고, 잘 살고 싶은데 내 발걸음은 왜 이렇게 엉망진창일까?” 누구나 한번쯤 떠올렸을 생각이다. 사랑받고 싶고 존중받고 싶고 인정받고 싶은 마음은 굴뚝같은데 무엇 하나 신통치 않고, 나만 빼고 모두들 저만치 앞서가는 것 같아 무기력해진다. ‘나는 안되는 사람인가?’ 불안은 우울로, 상처로, 단념으로 이어진다. 인생은 마음으로 걷는 여정이다. 스스로의 마음을 읽을 줄 아는 사람과 그렇지 않은 사람은 분명히 다르다. 당장 완벽하진 않더라도 3년 후의 나, 5년 후의 나는 지금과는 전혀 다른 모습일 것이다. 인생을 후회 없이 사는 사람은 행복이 찾아오길 기다리지 않는다. 그들은 자신이 언제 미소 짓는지, 누구와 함께 있고 싶은지, 어떤 일에 뿌듯한지를 알고 그 순간을 자신의 것으로 만든다. 상처받지 않는 유일한 방법은 스스로를 할퀴던 채찍을 내려놓는 것이다. 우리는 잘 맞설 수 있고 잘 견딜 수 있고 잘 해낼 수 있는 사람이다. 이제 스스로를 상처 입히던 채찍을 내려놓고, 나에게 친절한 응원을 건네보자. 어제보다 나은 나를 발견하게 될 것이다.

aladin

일머리가 좋다는 것은 어떤 의미일까요? 일을 잘하는 동료들을 관찰해 보니 일을 할 때 한 가지 공통점이 있었습니다. 일을 할 때 문제가 무엇인지, 진짜 문제가 무엇인지 정의하고 시작하는 습관입니다.

문제정의가 일머리의 90%입니다

일머리가 좋다는 것은 어떤 의미일까요? 일을 잘하는 동료들을 관찰해 보니 일을 할 때 한 가지 공통점이 있었습니다. 일을 할 때 문제가 무엇인지, 진짜 문제가 무엇인지 정의하고 시작하는 습관인데요. 많은 경우 요청으로 일을 시작하거든요. 요청을 받으면 무릎반사처럼 요청에 따라 일을 할 때가 많습니다. 요청한 기간에 맞춰, 요청한 태스크를 해드리는 것은 '내부 고객을 위한 서비스 제공자'라는 마인드를 길러줄 때도 있지만, 정말 문제가 무엇인지 모르고 목표가 아니라 태스크 자체에 매몰되도록 만듭니다. 항상 '문제가 무엇인가요?'라는 질문을 요청한 동료와 함께 정의하는 것부터 시작해야 합니다.

[ 큐레이터의 문장 🎒 ]

"나에게 1시간이 주어진다면, 55분 동안 문제를 찾고 5분 동안 그것을 풀 것이다" - 아인슈타인

다음 5가지 방법은 문제를 제대로 정의하기 위해서 직접 해볼 수 있는 행동 가이드입니다.

1️⃣ 직접 사실 확인하기

검색해서 답을 찾는 것으로는 부족합니다. 간접조사는 직접조사와 함께 조합할 때 힘이 있습니다. 사용자 경험이나 비즈니스 문제를 표면적인 데이터로만 정의하는 것이 아니라 직접 써보고, 직접 써본 사람을 만나보는 것이 필요합니다. UX 리서치는 문제를 정확하게 정의하기 위한 목적으로 활용되고 있습니다.

2️⃣ 문제를 정확하게 표현하기

추상적이거나 모호하게 서술한 문제는 해결할 수 없습니다. 예컨대, "전기차 배터리 성능이 너무 떨어진다"라는 문제는 해결하기 어렵습니다. "전기차 주행거리를 400km 이상으로 늘려야 한다"로 바꾸면 어떨까요? 측정할 수 있는 문제로 바꾸었고, 목표를 짚을 수 있습니다. 의견, 판단이 아니라 관찰할 수 있는 사실에서 출발해야 문제를 정확하게 정의할 수 있습니다.

3️⃣ 거꾸로 생각하기

문제를 보면 답을 구하고 싶어 집니다. 대화할 때도 비슷합니다. "이게 고민이에요"라고 말한 상대에게 무언가 도움이 되는 답을 말해주고 싶습니다. 그냥 들어주기만 해도 도움이 될 때에도 말이죠. 문제를 발견하면 바로 해결책을 찾기보다는 관점을 달리해서, "이게 왜 문제일까?"라는 질문으로 시야를 틔우는 것이 중요합니다. "전기차 주행거리가 400km 이상으로 늘려야 한다"의 진짜 문제는 '에어컨을 켠 상태로는 300km밖에 갈 수 없다'와 같이 다른 상황적 요인이 단서가 될 수 있습니다.

4️⃣ "왜" 그런지 반복해서 묻기

정의한 문제에 대해서 해결책을 정하기 전에 "왜 그럴까?"라는 질문을 반복해서 던져보는 겁니다. 5 WHYS라는 기법을 활용할 수도 있습니다. 진짜 문제는 "왜 그럴까?"라는 질문을 반복해서 던졌을 때 발견할 수 있습니다. 오티스 엘리베이터는 엘리베이터 속도에 대한 불만을 해결하려고 강력한 모터와 윤활 시스템을 만들었지만, 불만은 사그라들지 않았습니다. 본질은 엘리베이터 속도가 아니라 엘리베이터에서 느끼는 지루함이었죠. 거울을 설치하자 불만은 사그라들었습니다. 도착할 때까지 기다리는 시간이 지루해서 생긴 불만은 모터로 해결할 수 없었습니다.

5️⃣ 내가 틀릴 수 있다는 것을 의심하기

19세기 위대한 심리학자 윌리엄 제임스는 "고작 자신의 편견을 재배열할 뿐이면서 자신은 생각을 하고 있다고 믿는 사람이 한둘이 아니다"라는 말을 남겼습니다. 데이비드 롭슨의 <지능의 함정>에서는 똑똑한 사람일수록 오히려 특정한 종류의 어리석은 생각에 더 쉽게 빠져들 수 있다며 그 이유로 머리가 좋고 교육 수준이 높은 사람들은 이를테면 실수에서 교훈을 얻거나 타인의 조언을 받아들이는 성향이 상대적으로 적다는 점, 실수를 해도 제법 그럴듯한 논쟁으로 자기 논리를 정당화하는 능력이 남보다 뛰어나기 때문에 자신의 견해에 의심을 품지 않는 교조적 태도가 그 원인이라고 지적합니다. 문제정의를 제대로 하려면 적절한 의심과 겸손, 균형감각이 필요합니다.

https://www.redbusbagman.com/problems/

일머리가 좋다는 것은 어떤 의미일까요? 일을 잘하는 동료들을 관찰해 보니 일을 할 때 한 가지 공통점이 있었습니다. 일을 할 때 문제가 무엇인지, 진짜 문제가 무엇인지 정의하고 시작하는 습관인데요. 많은 경우 요청으로 일을 시작하거든요. 요청을 받으면 무릎반사처럼 요청에 따라 일을 할 때가 많습니다. 요청한 기간에 맞춰, 요청한 태스크를 해드리는 것은 '내부 고객을 위한 서비스 제공자'라는 마인드를 길러줄 때도 있지만, 정말 문제가 무엇인지 모르고 목표가 아니라 태스크 자체에 매몰되도록 만듭니다. 항상 '문제가 무엇인가요?'라는 질문을 요청한 동료와 함께 정의하는 것부터 시작해야 합니다. [ 큐레이터의 문장 🎒 ] "나에게 1시간이 주어진다면, 55분 동안 문제를 찾고 5분 동안 그것을 풀 것이다" - 아인슈타인 다음 5가지 방법은 문제를 제대로 정의하기 위해서 직접 해볼 수 있는 행동 가이드입니다. 1️⃣ 직접 사실 확인하기 검색해서 답을 찾는 것으로는 부족합니다. 간접조사는 직접조사와 함께 조합할 때 힘이 있습니다. 사용자 경험이나 비즈니스 문제를 표면적인 데이터로만 정의하는 것이 아니라 직접 써보고, 직접 써본 사람을 만나보는 것이 필요합니다. UX 리서치는 문제를 정확하게 정의하기 위한 목적으로 활용되고 있습니다. 2️⃣ 문제를 정확하게 표현하기 추상적이거나 모호하게 서술한 문제는 해결할 수 없습니다. 예컨대, "전기차 배터리 성능이 너무 떨어진다"라는 문제는 해결하기 어렵습니다. "전기차 주행거리를 400km 이상으로 늘려야 한다"로 바꾸면 어떨까요? 측정할 수 있는 문제로 바꾸었고, 목표를 짚을 수 있습니다. 의견, 판단이 아니라 관찰할 수 있는 사실에서 출발해야 문제를 정확하게 정의할 수 있습니다. 3️⃣ 거꾸로 생각하기 문제를 보면 답을 구하고 싶어 집니다. 대화할 때도 비슷합니다. "이게 고민이에요"라고 말한 상대에게 무언가 도움이 되는 답을 말해주고 싶습니다. 그냥 들어주기만 해도 도움이 될 때에도 말이죠. 문제를 발견하면 바로 해결책을 찾기보다는 관점을 달리해서, "이게 왜 문제일까?"라는 질문으로 시야를 틔우는 것이 중요합니다. "전기차 주행거리가 400km 이상으로 늘려야 한다"의 진짜 문제는 '에어컨을 켠 상태로는 300km밖에 갈 수 없다'와 같이 다른 상황적 요인이 단서가 될 수 있습니다. 4️⃣ "왜" 그런지 반복해서 묻기 정의한 문제에 대해서 해결책을 정하기 전에 "왜 그럴까?"라는 질문을 반복해서 던져보는 겁니다. 5 WHYS라는 기법을 활용할 수도 있습니다. 진짜 문제는 "왜 그럴까?"라는 질문을 반복해서 던졌을 때 발견할 수 있습니다. 오티스 엘리베이터는 엘리베이터 속도에 대한 불만을 해결하려고 강력한 모터와 윤활 시스템을 만들었지만, 불만은 사그라들지 않았습니다. 본질은 엘리베이터 속도가 아니라 엘리베이터에서 느끼는 지루함이었죠. 거울을 설치하자 불만은 사그라들었습니다. 도착할 때까지 기다리는 시간이 지루해서 생긴 불만은 모터로 해결할 수 없었습니다. 5️⃣ 내가 틀릴 수 있다는 것을 의심하기 19세기 위대한 심리학자 윌리엄 제임스는 "고작 자신의 편견을 재배열할 뿐이면서 자신은 생각을 하고 있다고 믿는 사람이 한둘이 아니다"라는 말을 남겼습니다. 데이비드 롭슨의 &lt;지능의 함정&gt;에서는 똑똑한 사람일수록 오히려 특정한 종류의 어리석은 생각에 더 쉽게 빠져들 수 있다며 그 이유로 머리가 좋고 교육 수준이 높은 사람들은 이를테면 실수에서 교훈을 얻거나 타인의 조언을 받아들이는 성향이 상대적으로 적다는 점, 실수를 해도 제법 그럴듯한 논쟁으로 자기 논리를 정당화하는 능력이 남보다 뛰어나기 때문에 자신의 견해에 의심을 품지 않는 교조적 태도가 그 원인이라고 지적합니다. 문제정의를 제대로 하려면 적절한 의심과 겸손, 균형감각이 필요합니다. https://www.redbusbagman.com/problems/

REDBUSBAGMAN | 빨간색 광역버스에 백팩을 메고 탑니다

⟪문제정의가 일머리의 90%입니다⟫

 1. 기본기 확실히 하기
 2. 학습 능력 키우기
 3. 의사 소통 잘하기
 4. 문제 정의 잘하기
 5. 태스크 완료 시간 추정 잘하기
 6. 운영을 고려한 코드 작성하기
 7. 서비스 사고 대처 능력 키우기
 8. 결과를 내는데 집중하기
 9. 영향력 갖기 (코딩 멍키)
    
    
개발자로 일을 하다보면 피할 수 없는 것이 서비스와 관련된 사고를 내는 것이다. 보통은 버그로 인해 이런 일이 발생하게 되는데 이는 사실 코드를 많이 작성하는 개발자들에게 더 많이 발생할 수 밖에 없는데 동일한 사고를 안 내겠다는 개인적인 노력과 동일한 문제가 반복되는 것이 아니라면 성장과정으로 보는 조직적인 관점이 중요하다. 이로 인한 트라우마가 생긴다면 개발자의 커리어에는 치명적인 상처가 생길 수 있다.

개인의 성향에 따라서는 내 코드로 인해 서비스 사고가 났을 때 자책을 하다못해 움츠러들 수 있는데 이 경우 코드를 완벽하게 작성해야겠다는 결론에 도달할 수 있다. 이는 개인에게도 스트레스이기도 하고 조직 관점에서도 느린 속도로 이어지기에 개인적으로도 개발자의 커리어에서 사고는 언제 내느냐의 문제라고 바라보면서 사고 발생시 복기하고 어떻게 하면 재발을 막을지 생각해보는 것이 중요하다.

하지만 그 개인이 속한 개발 조직에서 사고의 책임을 100% 개인에게 돌릴다면 개인이 움츠러 드는 것은 어쩔 수 없다. 이는 특히 기술부채를 안고 갈 수 밖에 상황에서는 더 그러하다. 그러기에 개발 조직의 관점에서는 다음을 생각해보는 것이 좋다.

 1. 사고 발생시마다 프로세스를 개선하고 테스트를 추가하는 등의 노력을 병행하는 것이 더 좋다. 사고 마다 레벨을 정해서 심각한 문제들의 경우 사후 부검 프로세스를 통해 이유를 파악하고 재발을 막기 위한 조치들을 취해야 한다.
 2. 또한 사고가 발생했을 때 얼마나 빨리 이를 감지하고 문제해결 프로세스를 시작할지 사고 대처와 관계된 역량을 키우는 것이 중요해진다. 지난 포스팅에서 이야기했던 운영을 고려한 코드를 작성하는 것이 중요해지기 시작하는데 에러 메시지를 이해하기 쉽게 하고 여기저기 로그를 자세히 남기는 것들을 이야기했었다. 어느 정도 규모가 커진 조직이라면 처음에는 백엔드 엔지니어등이 코드 배포와 운영, 모니터링을 담당할 수 있겠지만 별도의 데브옵스 조직이 필요할지 점검해보는 것이 필요할 수도 있다.
 3. 주기적으로 중요 사고에 대한 조치가 취해졌는지 어느 정도로 조치를 취할지 논의할 필요가 있다. 안 그러면 사후부검만 하고 실제 예방 조치는 취해지지 않는 문제가 발생한다. 이는 엔지니어링 리더십의 책임이기도 하다.
 4. 많은 경우 크고 작은 문제들이 고객 리포트로 초기에 발견할 수 있기에 CS팀과의 원활한 커뮤니케이션이 필요할 수 있으며 이 역시 지난 포스팅에서 이야기했었다.
 5. 대부분의 큰 사고는 데이터베이스와 연관된 경우들이 많다. 그래서 데이터베이스의 오래 걸리는 쿼리를 선제적으로 모니터링하고 문제 되는 부분을 찾아 미리 최적화하는 것이 필요하다. 또 하나 해볼 수 있는 것은 중요한 페이지나 중요 API의 실행시간 (latency) 모니터링을 해보는 것이다.
     
온라인 서비스에서 사고는 언제 일어나느냐의 문제지 피해갈 수 있는 문제는 아니다. 사고를 안 내기위해 코드를 완벽하게 작성하려고 하는 것 보다는 문제 감지와 운영이 쉬운 코드를 작성하면서 코드 배포 프로세스와 서비스 모니터링 프로세스를 강화하는 것을 병행하는 것이 더 맞는 방향이다.

<ol ><li>기본기 확실히 하기</li><li>학습 능력 키우기</li><li>의사 소통 잘하기</li><li>문제 정의 잘하기</li><li>태스크 완료 시간 추정 잘하기</li><li>운영을 고려한 코드 작성하기</li><li>서비스 사고 대처 능력 키우기</li><li>결과를 내는데 집중하기</li><li>영향력 갖기 <s>(코딩 멍키)</s> </li></ol>개발자로 일을 하다보면 피할 수 없는 것이 서비스와 관련된 사고를 내는 것이다. 보통은 버그로 인해 이런 일이 발생하게 되는데 이는 사실 코드를 많이 작성하는 개발자들에게 더 많이 발생할 수 밖에 없는데 동일한 사고를 안 내겠다는 개인적인 노력과 동일한 문제가 반복되는 것이 아니라면 성장과정으로 보는 조직적인 관점이 중요하다. 이로 인한 트라우마가 생긴다면 개발자의 커리어에는 치명적인 상처가 생길 수 있다. 개인의 성향에 따라서는 내 코드로 인해 서비스 사고가 났을 때 자책을 하다못해 움츠러들 수 있는데 이 경우 코드를 완벽하게 작성해야겠다는 결론에 도달할 수 있다. 이는 개인에게도 스트레스이기도 하고 조직 관점에서도 느린 속도로 이어지기에 개인적으로도 개발자의 커리어에서 사고는 언제 내느냐의 문제라고 바라보면서 사고 발생시 복기하고 어떻게 하면 재발을 막을지 생각해보는 것이 중요하다. 하지만 그 개인이 속한 개발 조직에서 사고의 책임을 100% 개인에게 돌릴다면 개인이 움츠러 드는 것은 어쩔 수 없다. 이는 특히 기술부채를 안고 갈 수 밖에 상황에서는 더 그러하다. 그러기에 개발 조직의 관점에서는 다음을 생각해보는 것이 좋다. <ol ><li>사고 발생시마다 프로세스를 개선하고 테스트를 추가하는 등의 노력을 병행하는 것이 더 좋다. 사고 마다 레벨을 정해서 심각한 문제들의 경우 사후 부검 프로세스를 통해 이유를 파악하고 재발을 막기 위한 조치들을 취해야 한다.</li><li>또한 사고가 발생했을 때 얼마나 빨리 이를 감지하고 문제해결 프로세스를 시작할지 사고 대처와 관계된 역량을 키우는 것이 중요해진다. 지난 포스팅에서 이야기했던 운영을 고려한 코드를 작성하는 것이 중요해지기 시작하는데 에러 메시지를 이해하기 쉽게 하고 여기저기 로그를 자세히 남기는 것들을 이야기했었다. 어느 정도 규모가 커진 조직이라면 처음에는 백엔드 엔지니어등이 코드 배포와 운영, 모니터링을 담당할 수 있겠지만 별도의 데브옵스 조직이 필요할지 점검해보는 것이 필요할 수도 있다.</li><li>주기적으로 중요 사고에 대한 조치가 취해졌는지 어느 정도로 조치를 취할지 논의할 필요가 있다. 안 그러면 사후부검만 하고 실제 예방 조치는 취해지지 않는 문제가 발생한다. 이는 엔지니어링 리더십의 책임이기도 하다.</li><li>많은 경우 크고 작은 문제들이 고객 리포트로 초기에 발견할 수 있기에 CS팀과의 원활한 커뮤니케이션이 필요할 수 있으며 이 역시 지난 포스팅에서 이야기했었다.</li><li>대부분의 큰 사고는 데이터베이스와 연관된 경우들이 많다. 그래서 데이터베이스의 오래 걸리는 쿼리를 선제적으로 모니터링하고 문제 되는 부분을 찾아 미리 최적화하는 것이 필요하다. 또 하나 해볼 수 있는 것은 중요한 페이지나 중요 API의 실행시간 (latency) 모니터링을 해보는 것이다. &nbsp;</li></ol>온라인 서비스에서 사고는 언제 일어나느냐의 문제지 피해갈 수 있는 문제는 아니다. 사고를 안 내기위해 코드를 완벽하게 작성하려고 하는 것 보다는 문제 감지와 운영이 쉬운 코드를 작성하면서 코드 배포 프로세스와 서비스 모니터링 프로세스를 강화하는 것을 병행하는 것이 더 맞는 방향이다.

좋은 개발자가 알아야하는 9가지 포인트들 - 사고 대처 능력 키우

Test UI changes and production fixes with the powerful network response overrides in Chrome DevTools. Mock response headers, files, API requests, and more wi...

Override and mock network responses #DevToolsTips

﻿서버 개발 완료가 늦어져 API의 응답이 원하는 형태로 개발이 안되는 상황이나 API의 응답을 다른 응답으로 변경하여 브라우저에서 확인하고 싶을 경우 해볼만한 방법에 대해 공유 드립니다.

저희 팀 자체 테크 톡에서 나온 내용인데요. 크롬 브라우저에서만 동작한다는 단점(?)이 있지만 응답 결과를 서버에서 다르게 변경하며 봐야할 경우 브라우저 단에서 생각보다 쉽게 변경해볼수 있는 장점이 가장 크다고 느껴졌습니다.

프론트와 백엔드를 막론하고 알고 있으면 언젠가 강력하게 도움이 될 내용으로 생각됩니다.
https://www.youtube.com/watch?v=KxjGYcHZ_uI

﻿서버 개발 완료가 늦어져 API의 응답이 원하는 형태로 개발이 안되는 상황이나 API의 응답을 다른 응답으로 변경하여 브라우저에서 확인하고 싶을 경우 해볼만한 방법에 대해 공유 드립니다. 저희 팀 자체 테크 톡에서 나온 내용인데요. 크롬 브라우저에서만 동작한다는 단점(?)이 있지만 응답 결과를 서버에서 다르게 변경하며 봐야할 경우 브라우저 단에서 생각보다 쉽게 변경해볼수 있는 장점이 가장 크다고 느껴졌습니다. 프론트와 백엔드를 막론하고 알고 있으면 언젠가 강력하게 도움이 될 내용으로 생각됩니다.https://www.youtube.com/watch?v=KxjGYcHZ_uI ﻿

YouTube

API의 응답을 프론트에서 손쉽게 변경하기

여러번의 이직을 거쳐왔지만 직장에서 동료와 직접적으로 문제가 된 적은 거의 없었다. 대부분 어느정도 의견차이가 있다고 하더라도 말도안되는 정도로 벗어나는 경우가 없기 때문에 대화로 의견타협을 할 수 있었다.

현직장에는 문제가 많다. 팀이 생긴지 2년정도밖에 안됐고 그간 거쳐간 리더들이 하나같이 잘못된 리더십을 행사하는 바람에 능력있는 사람들은 이미 다 빠져나갔다. 그러고나니 남아있던 경력만 많은 나르시스트가 감언이설과 장시간의 노동으로 테크리드 자리를 꿰찬듯 하다.

이미 한 번 철옹성을 쌓아올려 기회를 만든 이 나르시스트는 자신의 권위에 도전한다고 판단되는 모든 행위들을 권력으로 찍어누르면서 자리를 지키기위해 안간힘을 쓴다.

이들의 특징은 다음과 같다.
 1. 리더십이 아닌 자신의 직위를 내세운다
 2. 자신의 계획에 조금이라도 벗어나는 의견을 용납하지 못한다
 3. 실수를 인정하지 않는다
 4. 사과라는걸 모른다
 5. 남탓을 한다.
 6. 다른 사람의 실수를 들추며 자신을 치켜세운다.
 7. A와의 1:1 미팅에서 B를 까고 B와의 1:1 미팅에서 A를 깐다
 8. 모든 일의 공을 자신으로 돌린뒤 잡무를 팀원들에게 분배한다

이외에도 기타등등 조직에 악영향을 많이 끼친다. 어디까지나 미국 한정이지만 이것에 대응하기위해 지금까지 다음과 같은 방법을 활용하고있다.

 * 잘못된 행동이나 의사결정에 대한 정확한 기록. 일/시/상황 등을 기록한다.
 * 피드백은 되도록 매니져가 있는 상황에서 프로페셔널 한 매너를 지키며 전달한다.
 * 상대가 감정적으로 나오더라도 그것에 동요하지 않는다.
 * 인사팀과 매니져에게 기록해온 상황을 보고한다.
 * 생각이 같은 팀원을 찾아 동맹을 만든다.
 * 팀 내부도 중요하지만 외부 리더들과 좋은 관계를 유지한다.

직장에서 아무리 이해가 되지 않는 행동이나 의사결정을 지속적으로 내리는 리더를 만나더라도 준비 없이 권위에 도전하는건 위험하다. 특히나 상대적으로 직장내에서 입지가 좁다면 우선 나에대한 지지와 신뢰를 주변으로부터 얻는게 우선이다. 굴러들어온 돌이 박힌돌을 빼내려면 굴러들어오는 모멘텀과 동시에 나의 덩치를 불리는게 우선이다.

현 직장에 입사한지 1년이 지났다. 사실 이정도 되면 전직장에서는 일이 지루해져 다음 일자리를 찾기 시작했을 타이밍인데 불행 중 다행인지 이런 환경 덕분에 매일매일 새롭고 흥미로운 듯 하다. 매일이 새로운 경험이고 노하우도 쌓이는 것 같아서 어떻게보면 이런 환경에 들어온게 좋은 기회인 것 같기도 하다.

이제 슬슬 박힌돌을 빼내는 시도를 해 보려고 하고있다. 나로써도 처음하는 경험이고 여러가지 변수도 있어서 성공할 것이라는 확신은 아직 없지만, 지금까지 배운 것 들 만으로도 충분히 값진 경험을 한 것 같다.

앞으로 종종 진행상황을 업데이트 하겠다.

여러번의 이직을 거쳐왔지만 직장에서 동료와 직접적으로 문제가 된 적은 거의 없었다. 대부분 어느정도 의견차이가 있다고 하더라도 말도안되는 정도로 벗어나는 경우가 없기 때문에 대화로 의견타협을 할 수 있었다. 현직장에는 문제가 많다. 팀이 생긴지 2년정도밖에 안됐고 그간 거쳐간 리더들이 하나같이 잘못된 리더십을 행사하는 바람에 능력있는 사람들은 이미 다 빠져나갔다. 그러고나니 남아있던 경력만 많은 나르시스트가 감언이설과 장시간의 노동으로 테크리드 자리를 꿰찬듯 하다. 이미 한 번 철옹성을 쌓아올려 기회를 만든 이 나르시스트는 자신의 권위에 도전한다고 판단되는 모든 행위들을 권력으로 찍어누르면서 자리를 지키기위해 안간힘을 쓴다. 이들의 특징은 다음과 같다.<ol ><li>리더십이 아닌 자신의 직위를 내세운다</li><li>자신의 계획에 조금이라도 벗어나는 의견을 용납하지 못한다</li><li>실수를 인정하지 않는다</li><li>사과라는걸 모른다</li><li>남탓을 한다.</li><li>다른 사람의 실수를 들추며 자신을 치켜세운다.</li><li>A와의 1:1 미팅에서 B를 까고 B와의 1:1 미팅에서 A를 깐다</li><li>모든 일의 공을 자신으로 돌린뒤 잡무를 팀원들에게 분배한다</li></ol> 이외에도 기타등등 조직에 악영향을 많이 끼친다. 어디까지나 미국 한정이지만 이것에 대응하기위해 지금까지 다음과 같은 방법을 활용하고있다. <ul ><li>잘못된 행동이나 의사결정에 대한 정확한 기록. 일/시/상황 등을 기록한다.</li><li>피드백은 되도록 매니져가 있는 상황에서 프로페셔널 한 매너를 지키며 전달한다.</li><li>상대가 감정적으로 나오더라도 그것에 동요하지 않는다.</li><li>인사팀과 매니져에게 기록해온 상황을 보고한다.</li><li>생각이 같은 팀원을 찾아 동맹을 만든다.</li><li>팀 내부도 중요하지만 외부 리더들과 좋은 관계를 유지한다.</li></ul> 직장에서 아무리 이해가 되지 않는 행동이나 의사결정을 지속적으로 내리는 리더를 만나더라도 준비 없이 권위에 도전하는건 위험하다. 특히나 상대적으로 직장내에서 입지가 좁다면 우선 나에대한 지지와 신뢰를 주변으로부터 얻는게 우선이다. 굴러들어온 돌이 박힌돌을 빼내려면 굴러들어오는 모멘텀과 동시에 나의 덩치를 불리는게 우선이다. 현 직장에 입사한지 1년이 지났다. 사실 이정도 되면 전직장에서는 일이 지루해져 다음 일자리를 찾기 시작했을 타이밍인데 불행 중 다행인지 이런 환경 덕분에 매일매일 새롭고 흥미로운 듯 하다. 매일이 새로운 경험이고 노하우도 쌓이는 것 같아서 어떻게보면 이런 환경에 들어온게 좋은 기회인 것 같기도 하다. 이제 슬슬 박힌돌을 빼내는 시도를 해 보려고 하고있다. 나로써도 처음하는 경험이고 여러가지 변수도 있어서 성공할 것이라는 확신은 아직 없지만, 지금까지 배운 것 들 만으로도 충분히 값진 경험을 한 것 같다. 앞으로 종종 진행상황을 업데이트 하겠다.

직장에서 나르시스트를  상대하는 방법

몇 달 전, 반려생활에 처음 합류한 후 진행했던 첫 과제에 대한 내용을 블로그에 포스팅했더니 좋은 반응을 많이 받았습니다. 그래서 이번엔 시간을 조금 더 앞당겨, 반려생활에 합류하게 되기까지의 과정을 블로그에 적어 공유해 보고자 합니다. 반려생활에 지원할 무렵인 2023년 11월, 저는 우아한테크코스라는 부트캠프 캠퍼스에서 한창 프로그래밍 공부를 하고...

반려생활, 서버 개발자, 700대 1

반려생활에 입사하진 4개월된 승현님이 합류까지의 과정을 재미나게 적어주셨네요.

https://blog.ban-life.com/%EB%B0%98%EB%A0%A4%EC%83%9D%ED%99%9C-%EC%84%9C%EB%B2%84-%EA%B0%9C%EB%B0%9C%EC%9E%90-700%EB%8C%80-1-1aa370e64781

반려생활에 입사하진 4개월된 승현님이 합류까지의 과정을 재미나게 적어주셨네요. https://blog.ban-life.com/%EB%B0%98%EB%A0%A4%EC%83%9D%ED%99%9C-%EC%84%9C%EB%B2%84-%EA%B0%9C%EB%B0%9C%EC%9E%90-700%EB%8C%80-1-1aa370e64781

Medium

반려생활에 합류하기 위한 여정

Next.js 환경에서 개발을 하다보면 Hydration에러를 종종 만나게 되는데요. 이 에러는 서버에서 생성된 HTML과 클라이언트에서 생성되는 HTML간에 불일치가 발생할때 발생합니다.

가령 useEffect내 API호출을 한다던지, 세션이나 쿠키 같은 요인에 따라 렌더링 컴포넌트가 다를때라던지, 자바스크립트 실행 타이밍이 다를때 이 에러를 접하게 되는데요.

이 Hydration에러는 왜 발생하는 것일까요??
근본적인 원인은 렌더링을 두 번 하기 때문입니다. 서버 사이드 렌더링 후, 클라이언트 사이드에서 추가 렌더링을 하면서 데이터의 불일치가 발생하는 것인데요. 

그럼 왜 렌더링을 두 번 할까요? 언뜻 보기엔 두 번 렌더링이 비효율적인것 같아 보이는데요. 두 번 렌더링을 하게 되면 최초 초기 로딩 시 최소한의 정보만을 포함하고 있어 빠르게 렌더링이 가능합니다. 또한 검색엔진은 빠른 렌더링을 중요한 랭킹 요소로 고려하므로 SEO에도 유리 합니다. 초기 렌더링 이후에는  DOM 요소에 속성을 매칭 시키는 작업을 하는데요. 이 이벤트 리스너를 붙이는 작업은 페이지를 다시 그리지 않으므로 추가적인 렌더링 비용이 발생하지 않습니다.

따라서, Hydration은 효율적인 초기 페이지 로딩과 동적 웹 애플리케이션 기능의 균형을 맞추기 위한 과정 입니다. 다만 Hydration 에러는 개발 과정에서 다루기 까다로운 문제중 하나인데요. Next.js 에서도 에러를 줄이기 위한 방안을 지속적으로 모색하고 기술적인 접근을 제공하고 있습니다. 예를 들어 Zustand에서는 과거에 persist미들웨어를 사용할때 Hydration에러가 발생하였는데요 V3부터는 클라이언트 측에서 상태를 다시 로드하도록 하여 서버와 클라이언트 사이의 데이터 불일치 문제를 해결하였습니다. 

Hydration 과정과 이로 인해 발생할 수 있는 에러를 제대로 관리하면, 사용자 경험을 향상시키고 웹사이트의 성능을 최적화할 수 있습니다.

Next.js 환경에서 개발을 하다보면 Hydration에러를 종종 만나게 되는데요. 이 에러는 서버에서 생성된 HTML과 클라이언트에서 생성되는 HTML간에 불일치가 발생할때 발생합니다. 가령 useEffect내 API호출을 한다던지, 세션이나 쿠키 같은 요인에 따라 렌더링 컴포넌트가 다를때라던지, 자바스크립트 실행 타이밍이 다를때 이 에러를 접하게 되는데요. 이 Hydration에러는 왜 발생하는 것일까요??근본적인 원인은 렌더링을 두 번 하기 때문입니다. 서버 사이드 렌더링 후, 클라이언트 사이드에서 추가 렌더링을 하면서 데이터의 불일치가 발생하는 것인데요.&nbsp; 그럼 왜 렌더링을 두 번 할까요? 언뜻 보기엔 두 번 렌더링이 비효율적인것 같아 보이는데요. 두 번 렌더링을 하게 되면 최초 초기 로딩 시 최소한의 정보만을 포함하고 있어 빠르게 렌더링이 가능합니다. 또한 검색엔진은 빠른 렌더링을 중요한 랭킹 요소로 고려하므로 SEO에도 유리 합니다. 초기 렌더링 이후에는&nbsp; DOM 요소에 속성을 매칭 시키는 작업을 하는데요. 이 이벤트 리스너를 붙이는 작업은 페이지를 다시 그리지 않으므로 추가적인 렌더링 비용이 발생하지 않습니다. 따라서, Hydration은 효율적인 초기 페이지 로딩과 동적 웹 애플리케이션 기능의 균형을 맞추기 위한 과정 입니다. 다만 Hydration 에러는 개발 과정에서 다루기 까다로운 문제중 하나인데요. Next.js 에서도 에러를 줄이기 위한 방안을 지속적으로 모색하고 기술적인 접근을 제공하고 있습니다. 예를 들어 Zustand에서는 과거에 persist미들웨어를 사용할때 Hydration에러가 발생하였는데요 V3부터는 클라이언트 측에서 상태를 다시 로드하도록 하여 서버와 클라이언트 사이의 데이터 불일치 문제를 해결하였습니다.&nbsp; Hydration 과정과 이로 인해 발생할 수 있는 에러를 제대로 관리하면, 사용자 경험을 향상시키고 웹사이트의 성능을 최적화할 수 있습니다.

Next.js 개발 시 자주 마주치는 Hydration 에러 이해

Microsoft Word - sosp067-decandia1.doc

아래의 25개의 논문들은 현대 컴퓨팅 시스템의 기반 기술들을 소개하고 있는데요.

이러한 기술들은 대규모 서비스, 분산 시스템, 클라우드, 데이터베이스, 머신러닝 등에서 다양하게 활용되고 있다고 합니다.

이것들을 공부하면 기술 면접이나 대규모 시스템 설계 그리고 실제 리얼 월드의 문제를 해결하는데 도움을 줄거에요.

앞으로 이러한 논문들을 하나씩 소개하는 글을 작성해볼게요~ 

 1. Dynamo - Amazon’s Highly Available Key Value Store:
 * Dynamo 시스템이 Amazon의 대규모 환경에서 어떻게 신뢰성을 제공하는지, 그리고 일관성을 희생하면서 어떻게 항상 사용 가능한 경험을 지원하는지에 대해 다룹니다. 
 * https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf?utm_source=substack&utm_medium=email

 2. Google File System:
 * Google File System의 설계 및 구현에 초점을 맞추며, 이 시스템이 대규모 데이터 중심 응용 프로그램을 지원하는 분산 파일 시스템으로서 어떻게 Scalability 와 Fault Tolerance 를 제공하는지에 대해 다룹니다. 
 * https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf?utm_source=substack&utm_medium=email

 3. Scaling Memcached at Facebook:
 * Facebook 이 Memcached 를 활용하여 어떻게 전 세계에서 가장 큰 소셜 네트워크를 지원하는 분산 키-값 저장소를 구축하고 확장했는지에 대해 다룹니다. 
 * https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf

 4. BigTable:
 * Bigtable이 어떻게 구조화된 데이터를 관리하기 위해 설계되었으며, 수천 대의 commodity servers 에서 페타바이트 규모로 확장될 수 있는지에 대해 다룹니다. 
 * https://substack.com/redirect/c49ce9b7-e0ab-4f1e-8936-3efd383ba713?j=eyJ1IjoiMmNscmc3In0.K_gP_5CqaAf0cWWggPM-WMz4gPJ_QSJ7yEFtqH8EWp4

 5. Borg - Large Scale Cluster Management at Google: 
 * Borg 시스템이 수십만 대의 기계를 포함하는 여러 클러스터에서 수천 개의 다양한 응용 프로그램에서 수백만 개의 작업을 어떻게 관리하는지, 그리고 높은 자원 활용도를 달성하기 위해 어떤 기술을 사용하는지에 대해 다룹니다. 
 * https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf?utm_source=substack&utm_medium=email

 6. Cassandra:
 * Cassandra 가 어떻게 대량의 구조화된 데이터를 여러 커머디티 서버에 걸쳐 관리하면서, 단일 실패 지점 없이 높은 가용성을 제공하는 분산 스토리지 시스템이 될 수 있는지에 대해 다룹니다. 
 * https://substack.com/redirect/cad644f7-a5c8-4d78-9b37-75597bf3b689?j=eyJ1IjoiMmNscmc3In0.K_gP_5CqaAf0cWWggPM-WMz4gPJ_QSJ7yEFtqH8EWp4

 7. Attention Is All You Need: 
 * 기존의 복잡한 순환 또는 합성곱 신경망을 대체하는 새로운 신경망 구조인 Transformer 에 대해 설명하며, 이 구조가 어떻게 오직 Attention 메커니즘만을 기반으로 하여 더 빠른 학습 속도와 높은 병렬 처리 능력을 제공하는지에 대해 다룹니다. 
 * https://arxiv.org/abs/1706.03762?utm_source=substack&utm_medium=email

 8. Kafka:
 * Kafka가 어떻게 대량의 로그 데이터를 수집하고 낮은 지연시간으로 전달하는 분산 메시징 시스템인지, 그리고 기존 로그 집계기 및 메시징 시스템에서 어떤 아이디어를 도입했는지에 대해 다룹니다.
 * https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/Kafka.pdf?utm_source=substack&utm_medium=email 

 9. FoundationDB:
 * FoundationDB 가 어떻게 NoSQL의 유연성과 확장성을 ACID 트랜잭션과 결합하고 있는지, 그리고 이 시스템이 어떻게 분리된 아키텍처를 채택하여 각 서브시스템을 독립적으로 조정할 수 있게 만들었는지에 대해 다룹니다. 
 * https://www.foundationdb.org/files/fdb-paper.pdf?utm_source=substack&utm_medium=email

 10. Amazon Aurora:
 * Aurora가 어떻게 OLTP 워크로드를 위한 관계형 데이터베이스 서비스로 설계되었으며, 고성능 데이터 처리에 있어 네트워크가 중요한 제약 요소로 부상했는지에 대해 다룹니다. 
 * https://web.stanford.edu/class/cs245/readings/aurora.pdf?utm_source=substack&utm_medium=email

 11. Spanner: 
 * Spanner가 어떻게 세계적 규모로 데이터를 분산시키고, externally-consistent 을 지원하는 분산 트랜잭션을 처음으로 제공하는 시스템인지에 대해 다룹니다. 
 * https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf?utm_source=substack&utm_medium=email

 12. MapReduce:
 * MapReduce가 어떻게 대규모 데이터 세트를 처리하고 생성하는데 사용되며, 사용자가 맵 함수와 리듀스 함수를 정의하여 데이터를 자동으로 병렬 처리하는 방식에 대해 다룹니다. 
 * https://storage.googleapis.com/pub-tools-public-publication-data/pdf/16cb30b4b92fd4989b8619a61752a2387c6dd474.pdf?utm_source=substack&utm_medium=email

 13. Shard Manager:
 * Shard Manager 가 어떻게 지리적으로 분산된 애플리케이션을 위한 샤드 관리를 단순화하고, 소프트웨어 업그레이드와 같은 계획된 이벤트 동안 애플리케이션 가용성을 유지하는 기능을 제공하는지에 대해 다룹니다. 
 * https://dl.acm.org/doi/pdf/10.1145/3477132.3483546?utm_source=substack&utm_medium=email

 14. Dapper:
 * Dapper가 어떻게 낮은 오버헤드, 애플리케이션 수준의 투명성을 제공하며 대규모 시스템에서 어디에나 배포될 수 있는지에 대해 다룹니다. 
 * https://static.googleusercontent.com/media/research.google.com/en//archive/papers/dapper-2010-1.pdf?utm_source=substack&utm_medium=email

 15. Flink:
 * Apache Flink 시스템의 주요 특징과 철학을 소개하고, Flink가 실시간 분석, 연속 데이터 파이프라인, 이력 데이터 처리(배치), 반복적 알고리즘(머신러닝, 그래프 분석)을 포함한 다양한 데이터 처리 응용 프로그램을 지원하는지에 대해 다룹니다. 
 * https://www.researchgate.net/publication/308993790_Apache_Flink_Stream_and_Batch_Processing_in_a_Single_Engine

 16. A Comprehensive Survey on Vector Databases:
 * 벡터 데이터베이스에 관한 포괄적인 내용을 다룹니다. 그리고 벡터 데이터베이스가 고차원 데이터를 저장하는 방법, 전통적인 DBMS에서 다루기 어려운 데이터의 특성화 방법, 그리고 이 분야에서 발생하는 주요 도전 과제들에 대해 다룹니다. 
 * https://arxiv.org/pdf/2310.11703

 17. Zanzibar:
 * 구글의 Zanzibar 시스템에 대해 다룹니다. 그리고 Zanzibar가 어떻게 수조 개의 접근 제어 목록과 초당 수백만 개의 인증 요청을 처리하는지에 대해 다룹니다. 
 * https://storage.googleapis.com/pub-tools-public-publication-data/pdf/10683a8987dbf0c6d4edcafb9b4f05cc9de5974a.pdf?utm_source=substack&utm_medium=email

 18. Monarch: 
 * 구글의 Monarch가 어떻게 전 세계적으로 분산된 인메모리 시계열 데이터베이스로서 구글의 수십억 사용자 규모의 애플리케이션과 시스템을 모니터링하는 데 사용되는지, 그리고 이 시스템이 매초 테라바이트의 데이터를 수집하고 수백만 건의 쿼리를 처리하는 방법에 대해 다룹니다. 
 * https://storage.googleapis.com/pub-tools-public-publication-data/pdf/d84ab6c93881af998de877d0070a706de7bec6d8.pdf?utm_source=substack&utm_medium=email

 19. Thrift:
 * Thrift 소프트웨어 라이브러리와 코드 생성 도구에 대해 다룹니다. 그리고 Thrift가 어떻게 다양한 프로그래밍 언어 간의 효율적이고 신뢰할 수 있는 통신을 가능하게 하는지에 대해 다룹니다. 
 * https://thrift.apache.org/static/files/thrift-20070401.pdf?utm_source=substack&utm_medium=email

 20. Bitcoin:
 * 비트코인이 금융기관을 거치지 않고 직접적으로 온라인 지불을 가능하게 하는 순수한 Peer-to-Peer 전자화폐 시스템으로서, 어떻게 이중 지불 문제를 해결하며, 해시 기반의 작업 증명을 통해 거래를 타임스탬프하는 네트워크를 사용하는지에 대해 다룹니다. 
 * https://bitcoin.org/bitcoin.pdf?utm_source=substack&utm_medium=email

 21. WTF - Who to Follow Service at Twitter:
 * WTF가 어떻게 일일 수백만 사용자 간의 연결을 생성하는지, 그리고 공유된 관심사, 공통 연결 등을 기반으로 어떻게 사용자 추천을 수행하는지에 대해 다룹니다. 
 * https://web.stanford.edu/~rezab/papers/wtf_overview.pdf?utm_source=substack&utm_medium=email

 22. MyRocks: LSM-Tree Database Storage Engine:
 * Facebook 에서 MyRocks 엔진을 어떻게 활용하는지에 대해 다룹니다. 그리고 MyRocks가 어떻게 LSM-트리 기반의 RocksDB 위에 구축되어 MySQL의 관계형 기능을 통합했는지에 대해서도 다룹니다. 
 * https://www.vldb.org/pvldb/vol13/p3217-matsunobu.pdf?utm_source=substack&utm_medium=email

 23. GoTo Considered Harmful: 
 * https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf?utm_source=substack&utm_medium=email

 24. Raft Consensus Algorithm:
 * Raft 합의 알고리즘에 대해 다룹니다. 그리고 Raft가 어떻게 Paxos와 동등한 결과를 내면서도 더 이해하기 쉽고 실용적인 시스템 구축의 기반을 제공하는지에 대해서도 다룹니다. 
 * https://raft.github.io/raft.pdf?utm_source=substack&utm_medium=email

 25. Time Clocks and Ordering of Events:
 * 분산 시스템 내에서 이벤트의 순서를 결정하고 시간의 개념을 이해하는 방법에 대해 다룹니다. 
 * https://lamport.azurewebsites.net/pubs/time-clocks.pdf?utm_source=substack&utm_medium=email

아래의 25개의 논문들은 현대 컴퓨팅 시스템의 기반 기술들을 소개하고 있는데요. 이러한 기술들은 대규모 서비스, 분산 시스템, 클라우드, 데이터베이스, 머신러닝 등에서 다양하게 활용되고 있다고 합니다. 이것들을 공부하면 기술 면접이나 대규모 시스템 설계 그리고 실제 리얼 월드의 문제를 해결하는데 도움을 줄거에요. 앞으로 이러한 논문들을 하나씩 소개하는 글을 작성해볼게요~&nbsp; <ol ><li>Dynamo - Amazon’s Highly Available Key Value Store: </li></ol><ul ><li>Dynamo 시스템이 Amazon의 대규모 환경에서 어떻게 신뢰성을 제공하는지, 그리고 일관성을 희생하면서 어떻게 항상 사용 가능한 경험을 지원하는지에 대해 다룹니다.&nbsp;</li><li>https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="2"><li>Google File System: </li></ol><ul ><li>Google File System의 설계 및 구현에 초점을 맞추며, 이 시스템이 대규모 데이터 중심 응용 프로그램을 지원하는 분산 파일 시스템으로서 어떻게 Scalability 와 Fault Tolerance 를 제공하는지에 대해 다룹니다.&nbsp;</li><li>https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="3"><li>Scaling Memcached at Facebook: </li></ol><ul ><li>Facebook 이 Memcached 를 활용하여 어떻게 전 세계에서 가장 큰 소셜 네트워크를 지원하는 분산 키-값 저장소를 구축하고 확장했는지에 대해 다룹니다.&nbsp;</li><li>https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf</li></ul> <ol start="4"><li>BigTable: </li></ol><ul ><li>Bigtable이 어떻게 구조화된 데이터를 관리하기 위해 설계되었으며, 수천 대의 commodity servers 에서 페타바이트 규모로 확장될 수 있는지에 대해 다룹니다.&nbsp;</li><li>https://substack.com/redirect/c49ce9b7-e0ab-4f1e-8936-3efd383ba713?j=eyJ1IjoiMmNscmc3In0.K_gP_5CqaAf0cWWggPM-WMz4gPJ_QSJ7yEFtqH8EWp4</li></ul> <ol start="5"><li>Borg - Large Scale Cluster Management at Google:&nbsp; </li></ol><ul ><li>Borg 시스템이 수십만 대의 기계를 포함하는 여러 클러스터에서 수천 개의 다양한 응용 프로그램에서 수백만 개의 작업을 어떻게 관리하는지, 그리고 높은 자원 활용도를 달성하기 위해 어떤 기술을 사용하는지에 대해 다룹니다.&nbsp;</li><li>https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="6"><li>Cassandra: </li></ol><ul ><li>Cassandra 가 어떻게 대량의 구조화된 데이터를 여러 커머디티 서버에 걸쳐 관리하면서, 단일 실패 지점 없이 높은 가용성을 제공하는 분산 스토리지 시스템이 될 수 있는지에 대해 다룹니다.&nbsp;</li><li>https://substack.com/redirect/cad644f7-a5c8-4d78-9b37-75597bf3b689?j=eyJ1IjoiMmNscmc3In0.K_gP_5CqaAf0cWWggPM-WMz4gPJ_QSJ7yEFtqH8EWp4</li></ul> <ol start="7"><li>Attention Is All You Need:&nbsp;</li></ol><ul ><li>기존의 복잡한 순환 또는 합성곱 신경망을 대체하는 새로운 신경망 구조인 Transformer 에 대해 설명하며, 이 구조가 어떻게 오직 Attention 메커니즘만을 기반으로 하여 더 빠른 학습 속도와 높은 병렬 처리 능력을 제공하는지에 대해 다룹니다.&nbsp;</li><li>https://arxiv.org/abs/1706.03762?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="8"><li>Kafka: </li></ol><ul ><li>Kafka가 어떻게 대량의 로그 데이터를 수집하고 낮은 지연시간으로 전달하는 분산 메시징 시스템인지, 그리고 기존 로그 집계기 및 메시징 시스템에서 어떤 아이디어를 도입했는지에 대해 다룹니다.</li><li>https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/Kafka.pdf?utm_source=substack&amp;utm_medium=email&nbsp;</li></ul> <ol start="9"><li>FoundationDB: </li></ol><ul ><li>FoundationDB 가 어떻게 NoSQL의 유연성과 확장성을 ACID 트랜잭션과 결합하고 있는지, 그리고 이 시스템이 어떻게 분리된 아키텍처를 채택하여 각 서브시스템을 독립적으로 조정할 수 있게 만들었는지에 대해 다룹니다.&nbsp;</li><li>https://www.foundationdb.org/files/fdb-paper.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="10"><li>Amazon Aurora: </li></ol><ul ><li>Aurora가 어떻게 OLTP 워크로드를 위한 관계형 데이터베이스 서비스로 설계되었으며, 고성능 데이터 처리에 있어 네트워크가 중요한 제약 요소로 부상했는지에 대해 다룹니다.&nbsp;</li><li>https://web.stanford.edu/class/cs245/readings/aurora.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="11"><li>Spanner:&nbsp; </li></ol><ul ><li>Spanner가 어떻게 세계적 규모로 데이터를 분산시키고, externally-consistent 을 지원하는 분산 트랜잭션을 처음으로 제공하는 시스템인지에 대해 다룹니다.&nbsp;</li><li>https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="12"><li>MapReduce: </li></ol><ul ><li>MapReduce가 어떻게 대규모 데이터 세트를 처리하고 생성하는데 사용되며, 사용자가 맵 함수와 리듀스 함수를 정의하여 데이터를 자동으로 병렬 처리하는 방식에 대해 다룹니다.&nbsp;</li><li>https://storage.googleapis.com/pub-tools-public-publication-data/pdf/16cb30b4b92fd4989b8619a61752a2387c6dd474.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="13"><li>Shard Manager:</li></ol><ul ><li>Shard Manager 가 어떻게 지리적으로 분산된 애플리케이션을 위한 샤드 관리를 단순화하고, 소프트웨어 업그레이드와 같은 계획된 이벤트 동안 애플리케이션 가용성을 유지하는 기능을 제공하는지에 대해 다룹니다.&nbsp;</li><li>https://dl.acm.org/doi/pdf/10.1145/3477132.3483546?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="14"><li>Dapper: </li></ol><ul ><li>Dapper가 어떻게 낮은 오버헤드, 애플리케이션 수준의 투명성을 제공하며 대규모 시스템에서 어디에나 배포될 수 있는지에 대해 다룹니다.&nbsp;</li><li>https://static.googleusercontent.com/media/research.google.com/en//archive/papers/dapper-2010-1.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="15"><li>Flink: </li></ol><ul ><li>Apache Flink 시스템의 주요 특징과 철학을 소개하고, Flink가 실시간 분석, 연속 데이터 파이프라인, 이력 데이터 처리(배치), 반복적 알고리즘(머신러닝, 그래프 분석)을 포함한 다양한 데이터 처리 응용 프로그램을 지원하는지에 대해 다룹니다.&nbsp;</li><li>https://www.researchgate.net/publication/308993790_Apache_Flink_Stream_and_Batch_Processing_in_a_Single_Engine</li></ul> <ol start="16"><li>A Comprehensive Survey on Vector Databases: </li></ol><ul ><li>벡터 데이터베이스에 관한 포괄적인 내용을 다룹니다. 그리고 벡터 데이터베이스가 고차원 데이터를 저장하는 방법, 전통적인 DBMS에서 다루기 어려운 데이터의 특성화 방법, 그리고 이 분야에서 발생하는 주요 도전 과제들에 대해 다룹니다.&nbsp;</li><li>https://arxiv.org/pdf/2310.11703</li></ul> <ol start="17"><li>Zanzibar: </li></ol><ul ><li>구글의 Zanzibar 시스템에 대해 다룹니다. 그리고 Zanzibar가 어떻게 수조 개의 접근 제어 목록과 초당 수백만 개의 인증 요청을 처리하는지에 대해 다룹니다.&nbsp;</li><li>https://storage.googleapis.com/pub-tools-public-publication-data/pdf/10683a8987dbf0c6d4edcafb9b4f05cc9de5974a.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="18"><li>Monarch:&nbsp;</li></ol><ul ><li>구글의 Monarch가 어떻게 전 세계적으로 분산된 인메모리 시계열 데이터베이스로서 구글의 수십억 사용자 규모의 애플리케이션과 시스템을 모니터링하는 데 사용되는지, 그리고 이 시스템이 매초 테라바이트의 데이터를 수집하고 수백만 건의 쿼리를 처리하는 방법에 대해 다룹니다.&nbsp;</li><li>https://storage.googleapis.com/pub-tools-public-publication-data/pdf/d84ab6c93881af998de877d0070a706de7bec6d8.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="19"><li>Thrift: </li></ol><ul ><li>Thrift 소프트웨어 라이브러리와 코드 생성 도구에 대해 다룹니다. 그리고 Thrift가 어떻게 다양한 프로그래밍 언어 간의 효율적이고 신뢰할 수 있는 통신을 가능하게 하는지에 대해 다룹니다.&nbsp;</li><li>https://thrift.apache.org/static/files/thrift-20070401.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="20"><li>Bitcoin: </li></ol><ul ><li>비트코인이 금융기관을 거치지 않고 직접적으로 온라인 지불을 가능하게 하는 순수한 Peer-to-Peer 전자화폐 시스템으로서, 어떻게 이중 지불 문제를 해결하며, 해시 기반의 작업 증명을 통해 거래를 타임스탬프하는 네트워크를 사용하는지에 대해 다룹니다.&nbsp;</li><li>https://bitcoin.org/bitcoin.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="21"><li>WTF - Who to Follow Service at Twitter: </li></ol><ul ><li>WTF가 어떻게 일일 수백만 사용자 간의 연결을 생성하는지, 그리고 공유된 관심사, 공통 연결 등을 기반으로 어떻게 사용자 추천을 수행하는지에 대해 다룹니다.&nbsp;</li><li>https://web.stanford.edu/~rezab/papers/wtf_overview.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="22"><li>MyRocks: LSM-Tree Database Storage Engine: </li></ol><ul ><li>Facebook 에서 MyRocks 엔진을 어떻게 활용하는지에 대해 다룹니다. 그리고 MyRocks가 어떻게 LSM-트리 기반의 RocksDB 위에 구축되어 MySQL의 관계형 기능을 통합했는지에 대해서도 다룹니다.&nbsp;</li><li>https://www.vldb.org/pvldb/vol13/p3217-matsunobu.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="23"><li>GoTo Considered Harmful:&nbsp;</li></ol><ul ><li>https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="24"><li>Raft Consensus Algorithm: </li></ol><ul ><li>Raft 합의 알고리즘에 대해 다룹니다. 그리고 Raft가 어떻게 Paxos와 동등한 결과를 내면서도 더 이해하기 쉽고 실용적인 시스템 구축의 기반을 제공하는지에 대해서도 다룹니다.&nbsp;</li><li>https://raft.github.io/raft.pdf?utm_source=substack&amp;utm_medium=email</li></ul> <ol start="25"><li>Time Clocks and Ordering of Events: </li></ol><ul ><li>분산 시스템 내에서 이벤트의 순서를 결정하고 시간의 개념을 이해하는 방법에 대해 다룹니다.&nbsp;</li><li>https://lamport.azurewebsites.net/pubs/time-clocks.pdf?utm_source=substack&amp;utm_medium=email</li></ul>

allthingsdistributed.com

“컴퓨터 세계를 완전히 변화시킨 25개의 논문”

아는 사람은 많고 하는 사람은 적습니다.

정보는 넘쳐납니다. 어떻게 하면 되는지 소개하는 글과 영상이 참 많습니다. 우리는 매일 그 정보를 접합니다. 무엇을 하는 법, 무엇이 되는 법에 대한 정보를 접합니다.

얻는 정보를 토대로 시작하는 사람은 적습니다. 정보를 믿지 못하기 때문일 수도 있고 다른 일을 하고 있기 때문일 수도 있습니다. 혹은 조금 더 완벽한 시작을 준비하는 것일 수도 있죠.

일단 시작했다고 해도 끝까지 해내는 사람은 더 적습니다. 중간에 그만둬야 할 수많은 이유가 있으니까요. 시작했던 이유를 끝까지 고수하고 계속한다는 건 절대 쉽지 않습니다.

여러분이 만약 무슨 일이든 시작해서 끝까지 해냈다면, 그것만으로 충분히 대단한 사람일지도 모릅니다.

아는 사람은 많고 하는 사람은 적습니다. 정보는 넘쳐납니다. 어떻게 하면 되는지 소개하는 글과 영상이 참 많습니다. 우리는 매일 그 정보를 접합니다. 무엇을 하는 법, 무엇이 되는 법에 대한 정보를 접합니다. 얻는 정보를 토대로 시작하는 사람은 적습니다. 정보를 믿지 못하기 때문일 수도 있고 다른 일을 하고 있기 때문일 수도 있습니다. 혹은 조금 더 완벽한 시작을 준비하는 것일 수도 있죠. 일단 시작했다고 해도 끝까지 해내는 사람은 더 적습니다. 중간에 그만둬야 할 수많은 이유가 있으니까요. 시작했던 이유를 끝까지 고수하고 계속한다는 건 절대 쉽지 않습니다. 여러분이 만약 무슨 일이든 시작해서 끝까지 해냈다면, 그것만으로 충분히 대단한 사람일지도 모릅니다.

아는 사람, 하는 사람

1. Research
- ChatGPT
- YouChat
- Perplexity
- Copilot
- Gemini

2. Image
- Leap AI
- Copilot
- Segmind
- Midjourney
- Stable Diffusion

3. CopyWriting
- Rytr
- Copy AI
- Writesonic
- Adcreative AI

4. Writing
- Jasper
- HIX AI
- Jenny AI
- Textblaze

5. Website
- 10Web
- Durable
- Framer
- Style AI

6. Video
- Klap
- Opus
- Eightify
- InVideo
- HeyGen
- Runway
- ImgCreator AI
- Morphstudio .xyz

7. Meeting
- Tldv
- Otter
- Noty AI
- Fireflies

8. SEO
- VidIQ
- Seona AI
- BlogSEO
- Keywrds ai

9. Chatbot
- Droxy
- Chatbase
- Mutual info
- Chatsimple

10. Presentation
- Decktopus
- Slides AI
- Gamma AI
- Designs AI
- Beautiful AI

11. Automation
- Make
- Zapier
- Xembly
- Bardeen

12. Prompts
- FlowGPT
- Alicent AI
- PromptBox
- Promptbase
- Snack Prompt

13. UI/UX
- Figma
- Uizard
- UiMagic
- Photoshop

14. Design
- Canva
- Flair AI
- Designify
- Clipdrop
- Autodraw
- Magician design

15. Logo Generator
- Looka
- Designs AI
- Brandmark
- Stockimg AI
- Namecheap

16. Audio
- Lovo ai
- Eleven labs
- Songburst AI
- Adobe Podcast

17. Marketing
- Pencil
- Ai-Ads
- AdCopy
- Simplified
- AdCreative

18. Startup
- Tome
- Ideas AI
- Namelix
- Pitchgrade
- Validator AI

19. Productivity
- Merlin
- Tinywow
- Notion AI
- Adobe Sensei
- Personal AI

20. Social media management
- Tapilo
- Typefully
- Hypefury
- TweetHunter

 * Source: https://twitter.com/HeyAbhishekk/status/1788778562897563965

1. Research- ChatGPT- YouChat- Perplexity- Copilot- Gemini 2. Image- Leap AI- Copilot- Segmind- Midjourney- Stable Diffusion 3. CopyWriting- Rytr- Copy AI- Writesonic- Adcreative AI 4. Writing- Jasper- HIX AI- Jenny AI- Textblaze 5. Website- 10Web- Durable- Framer- Style AI 6. Video- Klap- Opus- Eightify- InVideo- HeyGen- Runway- ImgCreator AI- Morphstudio .xyz 7. Meeting- Tldv- Otter- Noty AI- Fireflies 8. SEO- VidIQ- Seona AI- BlogSEO- Keywrds ai 9. Chatbot- Droxy- Chatbase- Mutual info- Chatsimple 10. Presentation- Decktopus- Slides AI- Gamma AI- Designs AI- Beautiful AI 11. Automation- Make- Zapier- Xembly- Bardeen 12. Prompts- FlowGPT- Alicent AI- PromptBox- Promptbase- Snack Prompt 13. UI/UX- Figma- Uizard- UiMagic- Photoshop 14. Design- Canva- Flair AI- Designify- Clipdrop- Autodraw- Magician design 15. Logo Generator- Looka- Designs AI- Brandmark- Stockimg AI- Namecheap 16. Audio- Lovo ai- Eleven labs- Songburst AI- Adobe Podcast 17. Marketing- Pencil- Ai-Ads- AdCopy- Simplified- AdCreative 18. Startup- Tome- Ideas AI- Namelix- Pitchgrade- Validator AI 19. Productivity- Merlin- Tinywow- Notion AI- Adobe Sensei- Personal AI 20. Social media management- Tapilo- Typefully- Hypefury- TweetHunter <ul ><li>Source: https://twitter.com/HeyAbhishekk/status/1788778562897563965</li></ul>

X (formerly Twitter)

20가지 작업 대체를 위한 100가지 AI 도구

To answer that, I would like to say that, mastering these do's and don'ts while writing code isn't just about impressing your peers (though that's a nice bonus). It's about writing code that's easier...

15 + 11 Mistakes Every Java Developer MUST avoid TODAY

1. Nulls와 Optionals
Bad Practice: 메서드에서 바로 null을 리턴하는 건 NPE를 유발할 수 있습니다.
public String getString() {
	return null;
}

Good Practice: null에 대한 명확한 핸들링과 에러 방지를 위해 Optional을 사용합니다.
public Optional<String> getString() {
	return Optional.empty();
}

 
2. String.valueOf()로 String 변환
Bad Practice: + 연산자를 사용해 문자열을 합칩니다.
double d = 3.14525;
String s = "" + d;

Good Practice: 내장 메서드를 활용합니다.
double d = 3.14245;
String s = String.valueOf(d);

 
3. array를 복사할 때 Arrays.copyOf() 
Bad Practice: 정석적으로 array를 복사합니다.
int[] sourceArray = {1,2,3,4,5};
int[] targetArray = new int[sourceArray.length];
for (int i = 0; i< sourceArray.length; i++) {
	targetArray[i] = sourceArray[i];
}

Good Practice: Arrays.copyOf() 메서드를 사용합니다.
int[] sourceArray = {1,2,3,4,5};
int[] targetArray = Arrays.copyOf(sourceArray, sourceArray.length);

 
4.  컬렉션이 비어있는지 체크하기 위해 isEmpty()
Bad Practice: length()나 size()로 string이나 컬렉션이 비어있는지 체크합니다.
String text = "Hello, World!";
if(text.length() == 0) {
	// Do something
}

Good Practice: isEmpty()로 string이나 컬렉션이 비어있는지 체크합니다.
String text = "Hello, World!";
if(text.isEmpty()) {
	// Do something
}

 
5. Concurrent Modification Exception 방지
Bad Practice: 리스트를 순회하고 있는 동안 요소를 제거하여 ConcurrentModificationException을 일으킵니다.
List<String> words = new ArrayList<>();
words.add("A");
words.add("B");
words.add("C");

for(String word : words) {
	if (word.equals("A")) {
 	words.remove(word);
 }
}

Good Practice: iterator remove 메서드나 removeIf() 메서드를 사용합니다. 
List<String> words = new ArrayList<>();
words.add("A");
words.add("B");
words.add("C");

Iterator<String> iterator = words.iterator();
while (iterator.hasNext()) {
 String word = iterator.next();
 if (word.equals("A")) {
 iterator.remove(); // Use iterator's remove method to safely remove elements
 }
}

System.out.println(words); // Output: [B, C]

 
6. 정규표현식 사전 컴파일
Bad Practice: 런타임 시에 정규표현식을 컴파일합니다.
String text = "Hello, World!";
if(text.matches("Hello.*")) {
	System.out.println("Matches!");
}
String replaced = text.replaceAll("\\s", "");

Good Practice: 정규표현식을 사전컴파일하고 재사용합니다.
final Pattern PATTERN1 = Pattern.compile("Hello.*");
final Pattern PATTERN2 = Pattern.compile("\\s");

String text = "Hello, World!";
if(PATTERN1.matcher(text).matches()) {
	System.out.println("Matches!");
}
String replaced = PATTERN2.matcher(text).replaceAll("");

 
번역: [https://ducktopia.tistory.com/124]
원문

1. Nulls와 OptionalsBad Practice: 메서드에서 바로 null을 리턴하는 건 NPE를 유발할 수 있습니다.<pre ><code class="language-java">public String getString() {
	return null;
}</code></pre>Good Practice: null에 대한 명확한 핸들링과 에러 방지를 위해 Optional을 사용합니다.<pre ><code class="language-java">public Optional&lt;String&gt; getString() {
	return Optional.empty();
}</code></pre>&nbsp;2. String.valueOf()로 String 변환Bad Practice: + 연산자를 사용해 문자열을 합칩니다.<pre ><code class="language-java">double d = 3.14525;
String s = "" + d;</code></pre>Good Practice: 내장 메서드를 활용합니다.<pre ><code class="language-java">double d = 3.14245;
String s = String.valueOf(d);</code></pre>&nbsp;3. array를 복사할 때 Arrays.copyOf()&nbsp;Bad Practice: 정석적으로 array를 복사합니다.<pre ><code class="language-java">int[] sourceArray = {1,2,3,4,5};
int[] targetArray = new int[sourceArray.length];
for (int i = 0; i&lt; sourceArray.length; i++) {
	targetArray[i] = sourceArray[i];
}</code></pre>Good Practice: Arrays.copyOf() 메서드를 사용합니다.<pre ><code class="language-java">int[] sourceArray = {1,2,3,4,5};
int[] targetArray = Arrays.copyOf(sourceArray, sourceArray.length);</code></pre>&nbsp;4.&nbsp; 컬렉션이 비어있는지 체크하기 위해 isEmpty()Bad Practice: length()나 size()로 string이나 컬렉션이 비어있는지 체크합니다.<pre ><code class="language-java">String text = "Hello, World!";
if(text.length() == 0) {
	// Do something
}</code></pre>Good Practice: isEmpty()로 string이나 컬렉션이 비어있는지 체크합니다.<pre ><code class="language-java">String text = "Hello, World!";
if(text.isEmpty()) {
	// Do something
}</code></pre>&nbsp;5. Concurrent Modification Exception 방지Bad Practice: 리스트를 순회하고 있는 동안 요소를 제거하여 ConcurrentModificationException을 일으킵니다.<pre ><code class="language-java">List&lt;String&gt; words = new ArrayList&lt;&gt;();
words.add("A");
words.add("B");
words.add("C");

for(String word : words) {
	if (word.equals("A")) {
 	words.remove(word);
 }
}</code></pre>Good Practice: iterator remove 메서드나 removeIf() 메서드를 사용합니다.&nbsp;<pre ><code class="language-java">List&lt;String&gt; words = new ArrayList&lt;&gt;();
words.add("A");
words.add("B");
words.add("C");

Iterator&lt;String&gt; iterator = words.iterator();
while (iterator.hasNext()) {
 String word = iterator.next();
 if (word.equals("A")) {
 iterator.remove(); // Use iterator's remove method to safely remove elements
 }
}

System.out.println(words); // Output: [B, C]</code></pre>&nbsp;6. 정규표현식 사전 컴파일Bad Practice: 런타임 시에 정규표현식을 컴파일합니다.<pre ><code class="language-java">String text = "Hello, World!";
if(text.matches("Hello.*")) {
	System.out.println("Matches!");
}
String replaced = text.replaceAll("\\s", "");</code></pre>Good Practice: 정규표현식을 사전컴파일하고 재사용합니다.<pre ><code class="language-java">final Pattern PATTERN1 = Pattern.compile("Hello.*");
final Pattern PATTERN2 = Pattern.compile("\\s");

String text = "Hello, World!";
if(PATTERN1.matcher(text).matches()) {
	System.out.println("Matches!");
}
String replaced = PATTERN2.matcher(text).replaceAll("");</code></pre>&nbsp;번역: [https://ducktopia.tistory.com/124]원문

🕊️ [Medium] 자바 개발자가 피해야 하는 11가지 실수 (

영문/국문 모두! 이력서 작성은 오늘로 끝낸다! 💪수천개의 이력서를 검토한 세 분의 이력서 전문가에게 배우는, 실패할 수 없는 이력서의 모든 것! 성공할 수 없는 이력서 작성을 위해 더커유가 전문가 세분을 모시고 이력서 특집 라이브를 진행합니다! 🙌 마치 이력서 첨삭을 받듯, ...

[더커유 라이브] 이직 성공하는 이력서 작성법!

[2024.03.21 목 오후 9시 KST] 오후 10시부터가 제 파트 시작일거 같아요~ 하지만 해당 특강은 꼭 9시부터 시청해주셔야 더 많이 얻어갈 수 있는 생방이에요 ㅎㅎ 유튜브 라이브로 진행이 되기 때문에 아래에 링크 타고 들어가서 "알림 받기" 설정해주시면 됩니다.

그리고 "나는 글로벌 인재다! 🫡" 하는 분들은 더커유 유튜브 채널 모르고 계셨다면 구독과 알림 설정 필수입니다. ㅎㅎ 이런 유익한 채널 귀하잖아요~

제 파트에 대해 간단히 말씀드리자면, 현장에서 영문 이력서를 첨삭하면서 여러 꿀팁 대방출 할 예정이에요. 혹시나 늦은 저녁 시간에 육아로 분주한 분이라도 이어폰 한쪽으로만 꽂고 참야하셔도 좋을거 같아요. Q&A 세션도 진행되다보니 생방으로 참여하는게 최고 같네요!

그러면 여러분 3/21 저녁에 생방으로 만나요! 🤗

참고로 저는 광고비나 사례비를 받지 않고 진행하는 방송이라는 점 참고해주세요. 더 많은 분들이 좋은 커리어 만들 수 있도록 열심히 이런 좋은 기회로 참여하는겁니다.

여기 출연하는 분들 모두 너무 귀하네요.
🙌 Logan Yoon & Joshua Ro & 이상학

https://www.youtube.com/live/X8KVtuQ06OE?si=0AlDCNTxZu_3PfKE

[2024.03.21 목 오후 9시 KST] 오후 10시부터가 제 파트 시작일거 같아요~ 하지만 해당 특강은 꼭 9시부터 시청해주셔야 더 많이 얻어갈 수 있는 생방이에요 ㅎㅎ 유튜브 라이브로 진행이 되기 때문에 아래에 링크 타고 들어가서 "알림 받기" 설정해주시면 됩니다. 그리고 "나는 글로벌 인재다! 🫡" 하는 분들은 더커유 유튜브 채널 모르고 계셨다면 구독과 알림 설정 필수입니다. ㅎㅎ 이런 유익한 채널 귀하잖아요~ 제 파트에 대해 간단히 말씀드리자면, 현장에서 영문 이력서를 첨삭하면서 여러 꿀팁 대방출 할 예정이에요. 혹시나 늦은 저녁 시간에 육아로 분주한 분이라도 이어폰 한쪽으로만 꽂고 참야하셔도 좋을거 같아요. Q&amp;A 세션도 진행되다보니 생방으로 참여하는게 최고 같네요! 그러면 여러분 3/21 저녁에 생방으로 만나요! 🤗 참고로 저는 광고비나 사례비를 받지 않고 진행하는 방송이라는 점 참고해주세요. 더 많은 분들이 좋은 커리어 만들 수 있도록 열심히 이런 좋은 기회로 참여하는겁니다. 여기 출연하는 분들 모두 너무 귀하네요.🙌 Logan Yoon &amp; Joshua Ro &amp; 이상학 https://www.youtube.com/live/X8KVtuQ06OE?si=0AlDCNTxZu_3PfKE

글로벌 인재를 위한 이력서 작성법

Contributor

Creative Arts Company (Musical, Play, Concert, Talk Show, and etc.); Started from scratch to create musicals and plays / Planning, sub-directing, marketing / Led the first overseas premiere show of an act at The Edinburgh Festival Fringe (세계3대 축제)

Production Manager

Handled marketing and sales for the sole distributor of ‘The Cheesecake Factory Bakery’ in Korea / Handled retail sales and closed supply contracts / Handled main operations for pop-up stores; Main Department Stores (Over 9 locations) / Product Marketing; Research and making manuals / Involved in serious trade issues

Sales and Marketing, Associate Manager

2019.06 - 2021.01 링크드인 오프/라이브 강의
2021.05 - 현재 링크드인 온라인 강의 (탈잉 VOD)

성공적인 경력 이직을 위한 링크드인 LinkedIn 활용법 (온라인 VOD)

Lecturer

러닝스푼즈 / 비즈니스 파트너로 자리잡는 리크루터 필수 과정
: 핵심인재 발굴과 영입
보이지 않던 핵심인재를 발굴하고 영입하는 리크루팅 노하우

의료 / 헬스케어

현재, HRBP & 채용 파트장
인사 팀장 - HRM, HRD (한국 HQ, 미국/독일 지사)
HRBP & 채용 팀장

채용 파트장

Full Life Cycle Recruiter / 채용, 인사, 총무
'최고의 동료'가 진짜 복지인 회사. 1조 가치 기업 무조건 되는 회사.
두달반이 육개월 같았다 #네카라쿠배당토월

리크루터

#1 Search Firm in Korea, Unico (1984' ~ Present) https://bit.ly/2xqDpav
*Team Leader, Manager of ICT & FutureTech (I&F)

[채용 - Hiring]
▶ Currently focusing on positions for B2B Tech, Smart Factory, E-commerce, Fintech, Healthcare, Entertainment, F&B, Edu-Tech, Cloud, AI, NGO, ESG sectors
▶ Hunting talents within trending industries & emerging technologies
▶ Specialized in directly sourcing & communicating with talents all over the world

팀장 (헤드헌터)

경영정보AI비즈니스학과

Esther Kang

블로그(모바일)

링크드인

리브스메드, 생명을 살리는 압도적 기술력

"한국인들은 너무 교포스럽다고 하고
교포 커뮤니티에서는 너무 한국인이라고 하는"

#ENTJ
직접 두 발로 뛰는 Social Network Creator
#스타트업 #끊임없이배우기 #네트워킹 #독서 #디지털마케팅

글로벌 인재를 위한 이력서 작성법

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필