 This article revisits the State of Node.js performance, focusing on comparing versions 20 through 22. Providing how Node.js has evolved over the past year.

State of Node.js Performance 2024

새로 LTS가 된 Node.js의 22와 20의 성능 차이를 분석한 글입니다.

현재 상황에서의 비교이고 이후에도 22에 추가되는 커밋이 20으로도 다시 백포트될 가능성이 있기 때문에 나중에 비교해보면 성능 차이가 달라질 수 있습니다. 실제로 event.target의 경우 20이 18보다 200%정도 빨라졌지만 20의 수정사항이 18로도 백포트되었기 때문에 현재 22의 18에 비해서 55% 빠른 것으로 나타납니다. 이는 22의 성능이 안좋아진 것이 아니라 18이 빨라졌기 때문입니다.

Assert, Buffer, FileSystem, Path, Stream 등 Node.js API의 속도 차이를 비교해서 볼 수 있고 이 글에서 정리되지 않은 기능은 성능이 거의 비슷하다고 판단해도 됩니다.

https://nodesource.com/blog/State-of-Nodejs-Performance-2024

새로 LTS가 된 Node.js의 22와 20의 성능 차이를 분석한 글입니다. 현재 상황에서의 비교이고 이후에도 22에 추가되는 커밋이 20으로도 다시 백포트될 가능성이 있기 때문에 나중에 비교해보면 성능 차이가 달라질 수 있습니다. 실제로 event.target의 경우 20이 18보다 200%정도 빨라졌지만 20의 수정사항이 18로도 백포트되었기 때문에 현재 22의 18에 비해서 55% 빠른 것으로 나타납니다. 이는 22의 성능이 안좋아진 것이 아니라 18이 빨라졌기 때문입니다. Assert, Buffer, FileSystem, Path, Stream 등 Node.js API의 속도 차이를 비교해서 볼 수 있고 이 글에서 정리되지 않은 기능은 성능이 거의 비슷하다고 판단해도 됩니다. https://nodesource.com/blog/State-of-Nodejs-Performance-2024

The NodeSource Blog - Node.js Tutorials, Guides, and Updates

“연차가 얼만데 이것도 몰라요?”

이런 말 들을까 봐 아는 척할 때가 있어요.

부디 연차가 더 쌓이기 전에 모른다고 말하세요. 지금 인정하고 배우는 편이 나아요.

시간의 무게는 갈수록 무겁고 부담스러워져요. 연차가 쌓일수록 모른다고 말하기 어려워요.

지금이 모른다고 말하기 가장 쉬울 때예요.

“연차가 얼만데 이것도 몰라요?” 이런 말 들을까 봐 아는 척할 때가 있어요. 부디 연차가 더 쌓이기 전에 모른다고 말하세요. 지금 인정하고 배우는 편이 나아요. 시간의 무게는 갈수록 무겁고 부담스러워져요. 연차가 쌓일수록 모른다고 말하기 어려워요. 지금이 모른다고 말하기 가장 쉬울 때예요.

아는 척하지 않고 모른다고 말했을 때, 이를 이해하고 가르치는 일을 무겁거나 부담스러워하지 않고 쉽게 풀어가는 회사와 사회의 문화도 중요한 것 같아요.

주말이 너무 길어요. 출근하고 싶어요.

개발자 1년 차에 제가 했던 말이에요. 망언이죠.

당시엔 일하는 게 유일한 놀이였어요. 주말은 지루했어요. 친구들이랑 만나는 시간도 아까웠어요.

회사에 있는 게 가장 좋았죠. 일과 회사를 애정했어요.

조금씩 알게 됐어요. 과했다는 걸. 애정을 둬야 할 곳은 내 주변 사람이라는 걸 깨달았어요.

그 후론 주말을 잘 활용하려고 해요. 친구들과 시간을 보내고 관계의 밀도를 높이는 데 써요.

이젠 알아요. 주말은 너무 짧아요.

주말이 너무 길어요. 출근하고 싶어요. 개발자 1년 차에 제가 했던 말이에요. 망언이죠. 당시엔 일하는 게 유일한 놀이였어요. 주말은 지루했어요. 친구들이랑 만나는 시간도 아까웠어요. 회사에 있는 게 가장 좋았죠. 일과 회사를 애정했어요. 조금씩 알게 됐어요. 과했다는 걸. 애정을 둬야 할 곳은 내 주변 사람이라는 걸 깨달았어요. 그 후론 주말을 잘 활용하려고 해요. 친구들과 시간을 보내고 관계의 밀도를 높이는 데 써요. 이젠 알아요. 주말은 너무 짧아요.

코드를 짜맞추는 재미. 그 재미를 안다는 게 너무 감사한 순간들이 있어요.

일이 쏟아질 땐 스트레스 받고 힘들죠. 그런데 와중에도 개발 그 자체는 정말 재밌다는 생각이 들어요.

요구사항을 내 손으로 완성했을 때 주는 쾌감이 있어요. 기능 하나가 동작하는 걸 보면 뿌듯해요.

완성한 기능을 혼자만 써봐도 기분 좋아요. 심지어 누가 그걸 써주면? 더할 나위 없죠.

개발자는 정말 좋은 직업이에요.

코드를 짜맞추는 재미. 그 재미를 안다는 게 너무 감사한 순간들이 있어요. 일이 쏟아질 땐 스트레스 받고 힘들죠. 그런데 와중에도 개발 그 자체는 정말 재밌다는 생각이 들어요. 요구사항을 내 손으로 완성했을 때 주는 쾌감이 있어요. 기능 하나가 동작하는 걸 보면 뿌듯해요. 완성한 기능을 혼자만 써봐도 기분 좋아요. 심지어 누가 그걸 써주면? 더할 나위 없죠. 개발자는 정말 좋은 직업이에요.

매년 이맘때면 연락이 와요. 회사는 어떤지, 하는 일은 마음에 드는지 안부를 묻죠. 헤드헌터예요.

이직 생각이 없더라도 헤드헌터와 알고 지내는 건 제법 괜찮은 선택이에요. '정보의 비대칭성'을 해소할 수 있으니까요.

구체적으론 세 가지 좋은 점이 있었어요.

1. 채용 시장의 분위기를 파악할 수 있어요
2. 서류 전형에 대한 부담이 낮아져요
3. 연봉 계약도 혼자 하는 것보단 유리해져요

여러분이 생각하는 헤드헌터를 알고 지내면 좋은 이유는 무엇인가요? 혹시 단점도 있었나요?

매년 이맘때면 연락이 와요. 회사는 어떤지, 하는 일은 마음에 드는지 안부를 묻죠. 헤드헌터예요. 이직 생각이 없더라도 헤드헌터와 알고 지내는 건 제법 괜찮은 선택이에요. '정보의 비대칭성'을 해소할 수 있으니까요. 구체적으론 세 가지 좋은 점이 있었어요. 1. 채용 시장의 분위기를 파악할 수 있어요2. 서류 전형에 대한 부담이 낮아져요3. 연봉 계약도 혼자 하는 것보단 유리해져요 여러분이 생각하는 헤드헌터를 알고 지내면 좋은 이유는 무엇인가요? 혹시 단점도 있었나요?&nbsp;

헤드헌터와 알고 지내면 좋은 점

전 헤드헌터라는 존재를 본적이 없어요,,,,ㅎㅎ

최근의 AI와 로봇의 발전을 보면, 기술의 발전은 인재…가 아니라 기술의 한계를 돌파할 수 있는 수준의, 한계점이 넘는 막대한 돈을 밀도있게(빠르고 집중적으로) 투입(태우는)하는데 있는 것 같다. 갈수록 더 할 것 같고. 로켓이나 양자 컴퓨터 같은 건 말 할 것도 없으니.

최근의 AI와 로봇의 발전을 보면, 기술의 발전은 인재…가 아니라 기술의 한계를 돌파할 수 있는 수준의, 한계점이 넘는 막대한 돈을 밀도있게(빠르고 집중적으로) 투입(태우는)하는데 있는 것 같다. 갈수록 더 할 것 같고. 로켓이나 양자 컴퓨터 같은 건 말 할 것도 없으니.

그래서 아직 자율주행도 상용화 못 하고 있나요

WEBNORI

AI로 작성한 AI활용 개발방법론 을 작성시도해보았습니다.
작성하고 나니~ 현실가능성 없는 소리같기도 하지만 특정한 상황의 특정팀에게는 도움될수도 있을것 같은 말들을 하는것같습니다.
아직 성공 기업사례가 없는 편이라~ AI를 단순하게 코드생성에만 사용하는것이아니라 AI를 활용한 업그레이드된 개발방법론이 지속 등장하지 않을까? 예상해봅니다.

https://wiki.webnori.com/pages/viewpage.action?pageId=93946961

AI로 작성한 AI활용 개발방법론 을 작성시도해보았습니다.작성하고 나니~ 현실가능성 없는 소리같기도 하지만 특정한 상황의 특정팀에게는 도움될수도 있을것 같은 말들을 하는것같습니다.아직 성공 기업사례가 없는 편이라~ AI를 단순하게 코드생성에만 사용하는것이아니라 AI를 활용한 업그레이드된 개발방법론이 지속 등장하지 않을까? 예상해봅니다. https://wiki.webnori.com/pages/viewpage.action?pageId=93946961

wiki.webnori.com

우리의 수준과 AI활용 개발방법론 도입

기회가 닿아 2년 동안 초기 창업가나 초기 스타트업 종사자를 1,500명가량 만났다. 1:1 대면 코칭한 기업도 있고, 심사를 했던 기업도 있고, 말 한마디 안 나누고 강의만 했던 적도 있다. 나도 초기 스타트업에 다니기도 했다. 덕분에 많은 팀 상황을 관찰할 기회가 있었다. 보고 느낀 점들을 풀어볼까 한다.   OKR이나 Agile이나 뭐나 말이 많다. 

초기 스타트업의 5가지 조직 체계

과거에 실리콘밸리의 조직문화를 벤치마킹해 시도 해 본 한국 스타트업들이 많았습니다.
물론 성공적으로 안착하여 지금까지 잘 활용하고 있는 스타트업도 많겠지만, 실패했던 스타트업들은 어떤 부분을 놓치고 있었는지에 대해 설명해주신 글이 있어 공유드립니다.
글을 작성해주신 분께서는 다섯가지의 항목이 기본적으로 잡혀있어야 하고, 이중에 하나라도 문제가 생길 경우 다른 모든 곳에 영향을 미치니 이 부분부터 기본적으로 점검하는게 중요하다고 합니다.

채용
 * 핵심 역량을 외주 맡기지 않는다.
사업에 꼭 필요한 역량은 팀 내부에 있어야 한다는 점을 인지하고 있어야 합니다.
 * 동기부여 수준이 높은 사람을 뽑는다.
동기부여는 남이 해줄 수 없기에 회사는 동기 부여 수준이 높은 직원들의 사기를 깎아내리는 제도와 문제 상황을 해결하는 것에만 집중해야합니다. 즐겁게 일하게 만드는 건 못하더라도 일에만 집중 할 수 있게 만드는 건 회사가 할 수 있습니다.

평가와 보상
 * 엄격한 개인 성과 평가는 독이 될 수 있다.
성과를 칼같이 측정하고 평가하려 들면 사람이 위축될 수 밖에 없습니다. 정형화된 직무와 경직된 회사에서나 성과를 평가하기 쉽지, 스타트업이 성과 평가에 목숨을 걸고 있으면 불필요한 에너지만 낭비합니다.
 * 무엇을 보상할 것인가
보상은 회사에서 중요하게 생각하는 가치가 무엇인지를 드러냅니다. 대체로 성과에 따라 팀 단위로 보상하고, 실력과 조직 기여도에 따라 개인 단위로 연봉을 책정하는 게 업계 흐름인 것 같습니다.

팀 체제와 R&R
 * 미션 중심 조직 / 기능 중심 조직 / 하이브리드 조직
팀이 커질수록 사일로 현상이나 갈등이 생기기 쉽기에 팀 구성을 어떻게 만드냐에 따라 조직 건정성과 지속가능성이 좌우됩니다. 구조와 체계를 명문화하고 선언하고 반복적으로 강조하고 제도적인 업무 방법론을 만들어야 행동이 바뀐다는 점을 중요하게 생각하세요.
 * 명확한 R&R
무엇보다 각자 어떤 사업에서 무슨 과업을 맡는 건지가 명확해야 합니다. 초기 스타트업은 R&R이 불명확하지만, 그 상태가 계속 지속되어서는 안됩니다. 각자 자신의 역할은 명확히 있지만 얼마든지 다른 사람의 업무 영역에도 함께할 수 있도록 협업을 장려해야 합니다.

의사소통 구조
 * 업무 보고/공유를 누구나 쉽게 파악할 수 있도록 만든다
어떤 정보가 있고, 정보에 접근할 수 있는 권한이 어떻게 나뉘어 있고, 정보가 쉽게 이해할 수 있도록 가공되어 있는지가 중요합니다. 회사 안의 Task 현황을 파악한다는 건 회사의 벨류체인을 파악하는 것과 같고, 업무 진행 현황은 모든 구성원이 알 수 있어야 합니다.
자신이 어떤 일에 기여하는지 눈으로 계속 확인할 수 있어야 능동적으로 일하게 됩니다.
 * 정기 회의 / 상시 회의를 효과적으로 한다.
 * 업무 커뮤니케이션 툴을 활용한다.
 * 의사소통 협업 원칙을 만든다.
공통의 원칙을 선언하는 건 행동의 기준 근거를 마련해주는 행위라는 점을 인지하고 협업 원칙을 만들어 반복적으로 이야기해야합니다.

의사결정권
 * 초기엔 마이크로 매니징하더라도 차차 권한을 위임한다.
실무자가 바로바로 의사결정해줘야 빠르게 성장할 수 있다는 점을 인지하고 의식적으로 마이크로 매니징을 줄이고 대표는 경영을 해야합니다.
 * 의사결정 과정에 실무자를 참여시킨다.
실무자들은 프로젝트에 참여하지도 않았던 대표가 결과물을 갈아엎을때 권한 위임을 침해당했다고 느낍니다. 현업에서 권한이 제대로 위임되었는지 점검하려면 의사결정이 진행되는 과정을 관찰하고 실무자가 의사결정의 과정에 제대로 참여했다고 느끼게 하세요.
 * 결정된 사항을 대표/팀장 마음대로 번복하지 않는다.

과거에 실리콘밸리의 조직문화를 벤치마킹해 시도 해 본 한국 스타트업들이 많았습니다. 물론 성공적으로 안착하여 지금까지 잘 활용하고 있는 스타트업도 많겠지만, 실패했던 스타트업들은 어떤 부분을 놓치고 있었는지에 대해 설명해주신 글이 있어 공유드립니다.글을 작성해주신 분께서는 다섯가지의 항목이 기본적으로 잡혀있어야 하고, 이중에 하나라도 문제가 생길 경우 다른 모든 곳에 영향을 미치니 이 부분부터 기본적으로 점검하는게 중요하다고 합니다. 채용<ul ><li>핵심 역량을 외주 맡기지 않는다.</li></ul>사업에 꼭 필요한 역량은 팀 내부에 있어야 한다는 점을 인지하고 있어야 합니다.<ul ><li>동기부여 수준이 높은 사람을 뽑는다.</li></ul>동기부여는 남이 해줄 수 없기에 회사는 동기 부여 수준이 높은 직원들의 사기를 깎아내리는 제도와 문제 상황을 해결하는 것에만 집중해야합니다. 즐겁게 일하게 만드는 건 못하더라도 일에만 집중 할 수 있게 만드는 건 회사가 할 수 있습니다. 평가와 보상<ul ><li>엄격한 개인 성과 평가는 독이 될 수 있다.</li></ul>성과를 칼같이 측정하고 평가하려 들면 사람이 위축될 수 밖에 없습니다. 정형화된 직무와 경직된 회사에서나 성과를 평가하기 쉽지, 스타트업이 성과 평가에 목숨을 걸고 있으면 불필요한 에너지만 낭비합니다.<ul ><li>무엇을 보상할 것인가</li></ul>보상은 회사에서 중요하게 생각하는 가치가 무엇인지를 드러냅니다. 대체로 성과에 따라 팀 단위로 보상하고, 실력과 조직 기여도에 따라 개인 단위로 연봉을 책정하는 게 업계 흐름인 것 같습니다. 팀 체제와 R&amp;R<ul ><li>미션 중심 조직 / 기능 중심 조직 / 하이브리드 조직</li></ul>팀이 커질수록 사일로 현상이나 갈등이 생기기 쉽기에 팀 구성을 어떻게 만드냐에 따라 조직 건정성과 지속가능성이 좌우됩니다. 구조와 체계를 명문화하고 선언하고 반복적으로 강조하고 제도적인 업무 방법론을 만들어야 행동이 바뀐다는 점을 중요하게 생각하세요.<ul ><li>명확한 R&amp;R</li></ul>무엇보다 각자 어떤 사업에서 무슨 과업을 맡는 건지가 명확해야 합니다. 초기 스타트업은 R&amp;R이 불명확하지만, 그 상태가 계속 지속되어서는 안됩니다. 각자 자신의 역할은 명확히 있지만 얼마든지 다른 사람의 업무 영역에도 함께할 수 있도록 협업을 장려해야 합니다. 의사소통 구조<ul ><li>업무 보고/공유를 누구나 쉽게 파악할 수 있도록 만든다</li></ul>어떤 정보가 있고, 정보에 접근할 수 있는 권한이 어떻게 나뉘어 있고, 정보가 쉽게 이해할 수 있도록 가공되어 있는지가 중요합니다. 회사 안의 Task 현황을 파악한다는 건 회사의 벨류체인을 파악하는 것과 같고, 업무 진행 현황은 모든 구성원이 알 수 있어야 합니다.자신이 어떤 일에 기여하는지 눈으로 계속 확인할 수 있어야 능동적으로 일하게 됩니다.<ul ><li>정기 회의 / 상시 회의를 효과적으로 한다.</li><li>업무 커뮤니케이션 툴을 활용한다.</li><li>의사소통 협업 원칙을 만든다.</li></ul>공통의 원칙을 선언하는 건 행동의 기준 근거를 마련해주는 행위라는 점을 인지하고 협업 원칙을 만들어 반복적으로 이야기해야합니다. 의사결정권<ul ><li>초기엔 마이크로 매니징하더라도 차차 권한을 위임한다.</li></ul>실무자가 바로바로 의사결정해줘야 빠르게 성장할 수 있다는 점을 인지하고 의식적으로 마이크로 매니징을 줄이고 대표는 경영을 해야합니다.<ul ><li>의사결정 과정에 실무자를 참여시킨다.</li></ul>실무자들은 프로젝트에 참여하지도 않았던 대표가 결과물을 갈아엎을때 권한 위임을 침해당했다고 느낍니다. 현업에서 권한이 제대로 위임되었는지 점검하려면 의사결정이 진행되는 과정을 관찰하고 실무자가 의사결정의 과정에 제대로 참여했다고 느끼게 하세요.<ul ><li>결정된 사항을 대표/팀장 마음대로 번복하지 않는다.</li></ul>

Brunch Story

코드에서 if는 가능성을 의미해요. if를 로직 깊이 숨기는 건 복잡성을 늘리는 일이에요.

그래서 if는 최대한 밖으로 꺼내야 해요. 초반에 가능성을 줄이면 뒤에선 코드가 단순해져요.

개인의 목표도 마찬가지예요. 가능성을 줄여야 해요.

물론 기회라는 이름의 가능성이 열리는 건 좋은 일이에요. 하지만 기회는 때론 우릴 혼란스럽게 해요.

목표를 정했다면 일정 기간 가능성을 차단하고 밀어붙이세요. 가능성에 잡아먹히지 마세요.

코드에서 if는 가능성을 의미해요. if를 로직 깊이 숨기는 건 복잡성을 늘리는 일이에요. 그래서 if는 최대한 밖으로 꺼내야 해요. 초반에 가능성을 줄이면 뒤에선 코드가 단순해져요. 개인의 목표도 마찬가지예요. 가능성을 줄여야 해요. 물론 기회라는 이름의 가능성이 열리는 건 좋은 일이에요. 하지만 기회는 때론 우릴 혼란스럽게 해요. 목표를 정했다면 일정 기간 가능성을 차단하고 밀어붙이세요. 가능성에 잡아먹히지 마세요.&nbsp;

가능성에 잡아먹히지 마세요

System 1, 2 사고를 간단하게 말하면 지식의 탐색과 논리의 탐색으로 나눈다고 할 수 있는데, LLM도 마찬가지로 Base model로 결과를 출력하는 것은 지식의 탐색이고 Reasoning model로 추론하는 것은 논리의 탐색으로 볼 수 있으며, 이는 고정된 가중치 내에서의 탐색과 가중치들의 변화(정확한 의미는 아님)를 탐색하는 것으로 나타낼 수 있겠다. 가중치는 결과를 출력하며 변화시킬 수(지식간의 연결 변화) 있는데, 고정된 가중치를 현재의 바둑판의 형세라 한다면, 변화하는 가중치를 탐색하는 건 바둑판의 형세 변화를 탐색하는 것과 같다고 할 수 있겠다. 따라서 새로운 문제에 대한 Reasoning model의 Test time compute는 필수적인 연산일 것이다. (“은하수를..안내서”에서 궁극의 질문에 답하기 위해 지구 컴퓨터가 1천만년동안 깊이 생각했다는 이야기가 다시 다가온다) 따라서 관건은 한 번 Reasoning model로 추론한 논리에 대해서는 과정과 결과를 스스로 즉시 학습하여, 다음번엔 논리의 탐색이 아니라 지식의 탐색으로 사용할 수 있는가가 아닐까 싶다.

System 1, 2 사고를 간단하게 말하면 지식의 탐색과 논리의 탐색으로 나눈다고 할 수 있는데, LLM도 마찬가지로 Base model로 결과를 출력하는 것은 지식의 탐색이고 Reasoning model로 추론하는 것은 논리의 탐색으로 볼 수 있으며, 이는 고정된 가중치 내에서의 탐색과 가중치들의 변화(정확한 의미는 아님)를 탐색하는 것으로 나타낼 수 있겠다. 가중치는 결과를 출력하며 변화시킬 수(지식간의 연결 변화) 있는데, 고정된 가중치를 현재의 바둑판의 형세라 한다면, 변화하는 가중치를 탐색하는 건 바둑판의 형세 변화를 탐색하는 것과 같다고 할 수 있겠다. 따라서 새로운 문제에 대한 Reasoning model의 Test time compute는 필수적인 연산일 것이다. (“은하수를..안내서”에서 궁극의 질문에 답하기 위해 지구 컴퓨터가 1천만년동안 깊이 생각했다는 이야기가 다시 다가온다) 따라서 관건은 한 번 Reasoning model로 추론한 논리에 대해서는 과정과 결과를 스스로 즉시 학습하여, 다음번엔 논리의 탐색이 아니라 지식의 탐색으로 사용할 수 있는가가 아닐까 싶다.

베이지안 추론 가지고 추론 모델이라고 하면서 소설 쓰시는 듯 대체 어디까지를 추론의 정의에 포함시켜야 하는지 현재 일치된 견해도 없는 듯 한데 통일된 만족할만한 합의도 없는 상태에서 그저 인공지능이니 머신러닝이니 떠드는 건 공해에 지나지 않습니다

구글 HR 수석 부사장이 말하는 이력서 작성 노하우 중 XYZ 법칙이 있습니다.

X - 주요 업무 내용
Y - 수치적으로 표현 가능한 성과 및 결과물
Z - 업무를 수행하기 위한 도구 및 스킬

이 3가지를 조합하여 자신이
어떤 업무를 통해 회사에 어떤 혜택을 주었는지를
정량적으로 표현해보세요.

이력서를 작성할 때, 당신의 주요 목표는
내 모든 경력에 대해 자세히 서술하는 것이 아닙니다.

가장 중요한 목표는 바로 이력서를 읽는 사람의 눈에 띄는 것입니다.

구글 HR 수석 부사장이 말하는 이력서 작성 노하우 중 XYZ 법칙이 있습니다. X - 주요 업무 내용 Y - 수치적으로 표현 가능한 성과 및 결과물 Z - 업무를 수행하기 위한 도구 및 스킬 이 3가지를 조합하여 자신이 어떤 업무를 통해 회사에 어떤 혜택을 주었는지를 정량적으로 표현해보세요. 이력서를 작성할 때, 당신의 주요 목표는 내 모든 경력에 대해 자세히 서술하는 것이 아닙니다. 가장 중요한 목표는 바로 이력서를 읽는 사람의 눈에 띄는 것입니다.

아마존 출신 엔지니어가 알려주는 이력서 작성 팁

2024 프론트엔드 뉴스 한 방에 몰아 보기

2024 프론트엔드 뉴스 한 방에 몰아 보기 : NHN Cloud Meetup

벌써 12월 중순을 지나고 있는데요.
1년 동안 있었던 주요 프런트엔드 관련 핵심 소식을 깔끔하게 정리해 주신 정말 좋은 글을 발행해 주셔서 소개해 드립니다.
이렇게 보니 생각보다 많은 소식이 있었다고 느껴지는데요. 처음 보는 소식이 있으시다면 관련 글의 링크가 명시되어 있으니 읽어보면서 한 해를 마무리해 보시는 건 어떤가요?

https://meetup.nhncloud.com/posts/390

벌써 12월 중순을 지나고 있는데요.1년 동안 있었던 주요 프런트엔드 관련 핵심 소식을 깔끔하게 정리해 주신 정말 좋은 글을 발행해 주셔서 소개해 드립니다.이렇게 보니 생각보다 많은 소식이 있었다고 느껴지는데요. 처음 보는 소식이 있으시다면 관련 글의 링크가 명시되어 있으니 읽어보면서 한 해를 마무리해 보시는 건 어떤가요? https://meetup.nhncloud.com/posts/390

NHN Cloud Meetup

2024 프론트엔드 뉴스 한 방에 몰아보기

GitHub Pages는 깃허브 저장소에 올려놓은 웹 프로젝트를 최소한의 노력으로 호스팅할 수 있는 서비스입니다. 깃허브에서 거의 초창기부터 무료로 제공하고 있는데 은근히 모르시는 분들이 많아서 개인적으로 아쉬웠던 완전 혜자 기능인데요. 백엔드 서버나 데이터베이스를 필요로 하지 않는 단순한 웹사이트를 호스팅하는데 아주 적합합니다.

📺 동영상: https://youtu.be/rd1C-LFz8fU
📝 포스팅: https://www.daleseo.com/github-pages/

사실 요즘 Netlify나 Vercel과 같은 훌륭한 호스팅 플랫폼이 워낙 많지만 제대로 사용하려면 해당 서비스를 공부를 해야 한다는 부담이 있죠. 하지만 GitHub Pages를 활용하면 이러한 학습 곡선을 최소화하면서 아주 쉽게 웹사이트를 배포할 수 있습니다.

GitHub Pages는 깃허브 계정이 있는 누구나 사용할 수 있으며, 기본적으로
github.io
서브 도메인을 제공해주며 별도로 구매한 커스텀 도메인도 연결할 수 있습니다. GitHub Pages를 통해 배포된 웹사이트는 깃허브의 빠르고 안정적인 글로벌 CDN의 혜택을 누릴 수 있다는 것도 큰 매력입니다.

월간 방문자가 10만명이 넘는 제 블로그도 GitHub Pages로 호스팅하고 있는데 아주 만족하며 쓰고 있어요 😎👍 깃허브에 코드 저장소를 가지고 계시다면 배포 과정이 정말 간편해서 꼭 써보시라고 추천드리고 싶습니다!

GitHub Pages는 깃허브 저장소에 올려놓은 웹 프로젝트를 최소한의 노력으로 호스팅할 수 있는 서비스입니다. 깃허브에서 거의 초창기부터 무료로 제공하고 있는데 은근히 모르시는 분들이 많아서 개인적으로 아쉬웠던 완전 혜자 기능인데요. 백엔드 서버나 데이터베이스를 필요로 하지 않는 단순한 웹사이트를 호스팅하는데 아주 적합합니다. 📺 동영상: https://youtu.be/rd1C-LFz8fU📝 포스팅: https://www.daleseo.com/github-pages/ 사실 요즘 Netlify나 Vercel과 같은 훌륭한 호스팅 플랫폼이 워낙 많지만 제대로 사용하려면 해당 서비스를 공부를 해야 한다는 부담이 있죠. 하지만 GitHub Pages를 활용하면 이러한 학습 곡선을 최소화하면서 아주 쉽게 웹사이트를 배포할 수 있습니다. GitHub Pages는 깃허브 계정이 있는 누구나 사용할 수 있으며, 기본적으로 <code >github.io</code> 서브 도메인을 제공해주며 별도로 구매한 커스텀 도메인도 연결할 수 있습니다. GitHub Pages를 통해 배포된 웹사이트는 깃허브의 빠르고 안정적인 글로벌 CDN의 혜택을 누릴 수 있다는 것도 큰 매력입니다. 월간 방문자가 10만명이 넘는 제 블로그도 GitHub Pages로 호스팅하고 있는데 아주 만족하며 쓰고 있어요 😎👍 깃허브에 코드 저장소를 가지고 계시다면 배포 과정이 정말 간편해서 꼭 써보시라고 추천드리고 싶습니다!

GitHub Pages에 웹사이트 배포하기

GPT와 같은 생성형 AI가 출시된 이후, 글쓰기, 번역, 고객 서비스와 같은 직종에서는 약 16%에서 30%의 직업 감소가 관찰되었습니다. 이는 AI가 이러한 업무를 빠르고 정확하게 처리할 수 있기 때문인데요. 하지만 기술 관련 직종(비디오 편집 및 제작: 39% 증가, 백엔드, 프론트 5% 증가)은 오히려 성장세를 보이고 있습니다. 이처럼 개발 분야는 전체적으로 성장세를 보이고 있는데요.
하지만 이러한 변화가 모든 개발자에게 동일한 영향을 미치는 것은 아닙니다.

단순 코딩의 감소와 개발자에 대한 새로운 요구
AI의 발전으로 인해 단순 반복적인 코딩 작업은 더 쉬워졌습니다. 따라서 이러한 작업만을 수행하는 개발자에 대한 수요는 점차 줄어들 것으로 전망됩니다. 이제는 단순한 코딩 기술을 넘어 다음과 같은 능력이 요구됩니다:

새로운 개발자 수요 전망
GPT와 같은 언어 모델은 코드 작성과 구현에서 뛰어난 성능을 발휘합니다. 하지만 미래를 예측하거나 시스템 전반을 최적화하는 창의적인 아이디어 제안에는 여전히 한계가 존재합니다.
이는 고급 엔지니어링 인력에 대한 수요가 증가할 것임을 의미하는데요. 기업 입장에서는 더 효율적이고 최적화된 시스템을 설계하려면 높은 기술력과 창의적인 사고를 갖춘 개발자가 반드시 필요하기 때문입니다. 따라서 미래의 개발자는 다음과 같은 역량이 필요할것으로 예상됩니다.

미래 개발자에게 필요한 역량
 * 기술적 깊이
   * 웹 기술 전반에 대한 깊은 이해
   * 시스템 아키텍처 설계 능력
   * 성능 최적화 역량
 * 비즈니스 통찰력
   * 기술과 비즈니스의 연계성 이해
   * 전략적 의사결정 능력
 * 지속적 학습
   * 새로운 기술 트렌드 파악
   * AI 도구의 효과적 활용 능력

결론
AI 시대의 개발자는 단순히 코드를 작성하는 기술자에서 벗어나, 더 높은 수준의 기술력과 통찰력이 요구됩니다. AI를 보완적 도구로 활용하면서, 시스템 전반을 설계하고 최적화 할 수 있는 역량이 중요해지고 있습니다. 이제부터 나무만 보는 개발자가 아닌, 숲 전체를 조망하며 전체적인 구조와 방향성을 설계할 수 있는 역량이 요구될 것으로 보입니다.

GPT와 같은 생성형 AI가 출시된 이후, 글쓰기, 번역, 고객 서비스와 같은 직종에서는 약 16%에서 30%의 직업 감소가 관찰되었습니다. 이는 AI가 이러한 업무를 빠르고 정확하게 처리할 수 있기 때문인데요. 하지만 기술 관련 직종(비디오 편집 및 제작: 39% 증가, 백엔드, 프론트 5% 증가)은 오히려 성장세를 보이고 있습니다. 이처럼 개발 분야는 전체적으로 성장세를 보이고 있는데요. 하지만 이러한 변화가 모든 개발자에게 동일한 영향을 미치는 것은 아닙니다. 단순 코딩의 감소와 개발자에 대한 새로운 요구AI의 발전으로 인해 단순 반복적인 코딩 작업은 더 쉬워졌습니다. 따라서 이러한 작업만을 수행하는 개발자에 대한 수요는 점차 줄어들 것으로 전망됩니다. 이제는 단순한 코딩 기술을 넘어 다음과 같은 능력이 요구됩니다: 새로운 개발자 수요 전망GPT와 같은 언어 모델은 코드 작성과 구현에서 뛰어난 성능을 발휘합니다. 하지만 미래를 예측하거나 시스템 전반을 최적화하는 창의적인 아이디어 제안에는 여전히 한계가 존재합니다. 이는 고급 엔지니어링 인력에 대한 수요가 증가할 것임을 의미하는데요. 기업 입장에서는 더 효율적이고 최적화된 시스템을 설계하려면 높은 기술력과 창의적인 사고를 갖춘 개발자가 반드시 필요하기 때문입니다. 따라서 미래의 개발자는 다음과 같은 역량이 필요할것으로 예상됩니다. 미래 개발자에게 필요한 역량<ul ><li>기술적 깊이<ul ><li>웹 기술 전반에 대한 깊은 이해</li><li>시스템 아키텍처 설계 능력</li><li>성능 최적화 역량</li></ul></li><li>비즈니스 통찰력<ul ><li>기술과 비즈니스의 연계성 이해</li><li>전략적 의사결정 능력</li></ul></li><li>지속적 학습<ul ><li>새로운 기술 트렌드 파악</li><li>AI 도구의 효과적 활용 능력</li></ul></li></ul> 결론 AI 시대의 개발자는 단순히 코드를 작성하는 기술자에서 벗어나, 더 높은 수준의 기술력과 통찰력이 요구됩니다. AI를 보완적 도구로 활용하면서, 시스템 전반을 설계하고 최적화 할 수 있는 역량이 중요해지고 있습니다. 이제부터 나무만 보는 개발자가 아닌, 숲 전체를 조망하며 전체적인 구조와 방향성을 설계할 수 있는 역량이 요구될 것으로 보입니다.

AI 시대, 개발자 로드맵: 코더에서 아키텍트로

“연차가 얼만데 이것도 몰라요?”

이런 말 들을까 봐 아는 척할

리더를 위한 멘탈 수업 (4) ▶저성과자 팀원과 일하는 방법, 팀원도 리콜이 되나요? 중견 기업에서 전산 업무를 담당하고 있는 40대 팀장입니다. 저는 요즘 팀원 때문에 골머리를 썩고 있습니다. 문제가 되고 있는 팀

저성과자 바꾸는 '열린 질문'과 '수시 피드백'

✅팀원 때문에 골머리를 썩고 있습니다. 문제가 되는 팀원은 업무 역량을 포함해 일을 처리하고 소통하는 방식에 문제가 많은 편입니다. 기회가 있을 때마다 충분한 피드백을 줬지만 아무런 변화가 없습니다.

독한 마음을 먹고 “매번 업무 처리가 늦어져 우리 팀 성과에 문제가 되고 있습니다. 어떻게 생각하세요?”라고 말한 적도 있습니다. 정작 본인은 왜 그런 평가를 받아야 하는지 납득하지 못하겠다며 억울하다는 태도를 보이더라고요. 자신은 주어진 일을 빠짐없이 처리했기 때문에 문제가 없다는 것입니다.

이런 상황들이 되풀이되고 업무 정체가 심해져 다른 팀원의 불만도 쌓여가고 있습니다. 팀을 이끌어가는 리더로서 팀원들에게 제 할 일을 하지 못한 것 같아 마음이 무겁습니다. 성과가 낮은 팀원은 어떻게 이끌어야 할까요?

1️⃣‘열린 질문’ 통해 천천히 변화 기다려야
윤대현 교수의 솔루션(서울대병원 정신건강의학과 교수)

변화는 누구에게나 어렵습니다. 그 이유는 무엇일까요? 묘하고 신비로운 인간의 ‘마음’ 때문입니다. 사연자분이 팀원과 일대일 대화를 나눌 때, 사실은 네 명의 객체가 이야기를 나누고 있습니다.

팀장과 팀원 외에도 팀장의 마음과 팀원의 마음도 함께 대화에 참여하는 것이죠. 그런데 사람의 언어와 마음의 언어는 서로 다른 모습을 갖고 있습니다. 사람은 논리적 언어를 사용하지만 마음은 은유적 언어를 사용하기 때문에 머리로는 이해를 했는데도 마음은 반대일 수 있습니다.

우리는 먼저 상대방의 행동을 긍정적으로 변화시키는 것이 얼마나 어려운 것인지 이해하고 인정해야 합니다. 그러니 사연자분이 최선을 다해 코칭했다고 해서 팀원이 바뀔 거라고 기대하지 마십시오. 팀원이 바뀌지 않았다고 과도한 자기비판을 할 필요도 없습니다. 지나치게 부정적인 자기 인식은 리더에게 추천할 만한 덕목이 아니니까요.

효과적인 소통을 위해 쉽게 사용할 수 있는 방법으로는 ‘직면적 소통’이 있습니다. 말 그대로 상대방 잘못을 직접 지적해 자신의 문제를 직면하게 하는 것이죠. “이번에도 마감을 못 지켰네요. 이러다가 우리 팀 실적이 꼴찌겠어요!” 같은 직설적인 말이 직면적 소통입니다.

이 방법은 상대의 마음에 불편함과 부끄러움을 만들고 그 부정적인 감정을 이용해 행동의 변화를 유발합니다. 다만 반복할수록 효과가 떨어지는 문제가 발생합니다. 또한 저항 심리가 작용해 동기부여는 커녕 있던 동기마저 없앨 수 있습니다.

동기부여를 통해 팀원의 행동을 변화시키고 싶다면 직면적 소통보다는 ‘열린 질문’을 해야 합니다. 열린 질문이란 일방적 지시가 아닌 의견을 묻는 것입니다.

“어제 지시한 프로젝트는 다 마쳤나요?” “오늘도 지각이네요. 또 늦잠 잤나요?”가 닫힌 질문이라면, “프로젝트 기획하는 데 어려움은 없나요?” “아침에 일어나는 게 힘든가요? 자꾸 지각하는 이유가 뭘까요?”는 열린 질문입니다.

열린 질문에는 리더의 일방적인 주장이나 지시가 담겨 있지 않아서 팀원에게 저항감을 주지 않습니다. 그래서 마음이 좀 더 쉽게 열립니다.

프로젝트의 어려움을 물어보면, 그간 느꼈던 어려움을 이야기하면서 스스로 자연스럽게 문제를 인식하게 됩니다. 스스로 문제를 인식했기 때문에 해결 방안에 관한 이야기를 나눌 때도 더 능동적으로 대화할 수 있습니다.

리더가 열린 질문에 익숙하지 않은 이유는 변화가 빨리 일어나길 바라는 조급함과 불안감 때문입니다. 하지만 어떤 변화든 하루아침에 일어날 수는 없습니다. 더구나 자신이 아닌 다른 누군가를 변화시키는 일이라면 더욱더 기다림이 필요합니다.

2️⃣그는 왜 피드백이 통하지 않을까
장은지 대표의 솔루션(이머징리더십인터벤션즈 대표)

인간에게는 자신을 다른 사람보다 우월하다고 생각하는 본성이 있습니다. 이로 인해 많은 사람이 “나 정도면 평균 이상이지”라고 믿습니다. 이것이 ‘평균 이상 효과(better-than-average effect)’입니다.

이렇게 자신의 역량과 성과를 후하게 평가하는 심리적 경향으로, 팀원들은 리더가 자신에 대해 낮은 평가를 했을 때 잘 받아들이지 못하는 경우가 많습니다. 실제 모 대기업을 대상으로 조사한 결과 직원의 70% 이상과 임원의 90% 이상이 자신의 성과를 ‘평균 이상’으로 평가했습니다.

저성과자가 있다면 리더는 피드백을 통해 변화를 유도하고 성과를 높이도록 도와야 합니다. 하지만 저성과자 대다수는 아무리 피드백을 주고 코칭을 해도 잘 변하지 않기 때문에 리더에게 큰 부담으로 작용합니다.

사연자 분 같은 상황에서도 당사자는 아무 문제가 없다고 생각하는 동상이몽이 발생하기도 합니다. 이런 경우에는 팀장의 인식이 아닌 팀원의 인식을 기반으로 피드백이 이뤄져야 하는데, 이것을 아는 리더는 많지 않습니다.

저성과자 문제는 대부분 자기 인식의 결여에서 비롯됩니다. 그렇기 때문에 자신에 대한 평가가 부당하다고 생각하죠. 따라서 리더는 먼저 팀원이 자신의 문제점을 정확하게 인식할 수 있도록 돕고, 그 문제가 무엇인지에 따라 피드백을 해야 합니다.

구성원에게 평가가 공정하다는 인상을 주려면 ‘객관적인 평가’와 ‘지속적인 피드백’을 잘 활용해야 합니다. 주기적인 피드백을 통해 객관적이고 투명하게 소통함으로써 당사자가 본인의 저성과를 인정하고 받아들일 수 있게 해야 합니다.

이걸 잘하는 회사가 넷플릭스입니다. 넷플릭스 리더들은 “경쟁사로 가겠다고 하는 팀원 중 최우선으로 붙잡아야 할 사람은 누구인가?”라는 질문으로 팀원들을 수시로 평가합니다. 그리고 이 질문에서 반복적으로 제외되는 사람은 빠르게 해고됩니다. 잔혹할 만큼 냉정한 문화죠.

넷플릭스에 입사했을 정도의 인재들이라면 ‘나 정도면 평균 이상이지’라고 생각할텐데, 냉혹한 평가를 군말 없이 받아들이는 이유는 무엇일까요? 바로 수시로 이뤄지는 리더의 평가와 피드백 덕분입니다.

자기 역량을 과대평가하는 저성과자가 정확한 자기 인식을 할 수 있도록 도우려면 무엇보다 객관적 평가를 토대로 한 효과적인 피드백이 중요합니다. 저성과자에게 하는 피드백은 필요할 때마다 수시로 이뤄져야 하며, 스스로 문제점을 정확하게 인식할 수 있도록 객관적이면서 구체적이어야 효과가 있습니다.

✅팀원 때문에 골머리를 썩고 있습니다. 문제가 되는 팀원은 업무 역량을 포함해 일을 처리하고 소통하는 방식에 문제가 많은 편입니다. 기회가 있을 때마다 충분한 피드백을 줬지만 아무런 변화가 없습니다. 독한 마음을 먹고 “매번 업무 처리가 늦어져 우리 팀 성과에 문제가 되고 있습니다. 어떻게 생각하세요?”라고 말한 적도 있습니다. 정작 본인은 왜 그런 평가를 받아야 하는지 납득하지 못하겠다며 억울하다는 태도를 보이더라고요. 자신은 주어진 일을 빠짐없이 처리했기 때문에 문제가 없다는 것입니다. 이런 상황들이 되풀이되고 업무 정체가 심해져 다른 팀원의 불만도 쌓여가고 있습니다. 팀을 이끌어가는 리더로서 팀원들에게 제 할 일을 하지 못한 것 같아 마음이 무겁습니다. 성과가 낮은 팀원은 어떻게 이끌어야 할까요? 1️⃣‘열린 질문’ 통해 천천히 변화 기다려야윤대현 교수의 솔루션(서울대병원 정신건강의학과 교수) 변화는 누구에게나 어렵습니다. 그 이유는 무엇일까요? 묘하고 신비로운 인간의 ‘마음’ 때문입니다. 사연자분이 팀원과 일대일 대화를 나눌 때, 사실은 네 명의 객체가 이야기를 나누고 있습니다. 팀장과 팀원 외에도 팀장의 마음과 팀원의 마음도 함께 대화에 참여하는 것이죠. 그런데 사람의 언어와 마음의 언어는 서로 다른 모습을 갖고 있습니다. 사람은 논리적 언어를 사용하지만 마음은 은유적 언어를 사용하기 때문에 머리로는 이해를 했는데도 마음은 반대일 수 있습니다. 우리는 먼저 상대방의 행동을 긍정적으로 변화시키는 것이 얼마나 어려운 것인지 이해하고 인정해야 합니다. 그러니 사연자분이 최선을 다해 코칭했다고 해서 팀원이 바뀔 거라고 기대하지 마십시오. 팀원이 바뀌지 않았다고 과도한 자기비판을 할 필요도 없습니다. 지나치게 부정적인 자기 인식은 리더에게 추천할 만한 덕목이 아니니까요. 효과적인 소통을 위해 쉽게 사용할 수 있는 방법으로는 ‘직면적 소통’이 있습니다. 말 그대로 상대방 잘못을 직접 지적해 자신의 문제를 직면하게 하는 것이죠. “이번에도 마감을 못 지켰네요. 이러다가 우리 팀 실적이 꼴찌겠어요!” 같은 직설적인 말이 직면적 소통입니다. 이 방법은 상대의 마음에 불편함과 부끄러움을 만들고 그 부정적인 감정을 이용해 행동의 변화를 유발합니다. 다만 반복할수록 효과가 떨어지는 문제가 발생합니다. 또한 저항 심리가 작용해 동기부여는 커녕 있던 동기마저 없앨 수 있습니다. 동기부여를 통해 팀원의 행동을 변화시키고 싶다면 직면적 소통보다는 ‘열린 질문’을 해야 합니다. 열린 질문이란 일방적 지시가 아닌 의견을 묻는 것입니다. “어제 지시한 프로젝트는 다 마쳤나요?” “오늘도 지각이네요. 또 늦잠 잤나요?”가 닫힌 질문이라면, “프로젝트 기획하는 데 어려움은 없나요?” “아침에 일어나는 게 힘든가요? 자꾸 지각하는 이유가 뭘까요?”는 열린 질문입니다. 열린 질문에는 리더의 일방적인 주장이나 지시가 담겨 있지 않아서 팀원에게 저항감을 주지 않습니다. 그래서 마음이 좀 더 쉽게 열립니다. 프로젝트의 어려움을 물어보면, 그간 느꼈던 어려움을 이야기하면서 스스로 자연스럽게 문제를 인식하게 됩니다. 스스로 문제를 인식했기 때문에 해결 방안에 관한 이야기를 나눌 때도 더 능동적으로 대화할 수 있습니다. 리더가 열린 질문에 익숙하지 않은 이유는 변화가 빨리 일어나길 바라는 조급함과 불안감 때문입니다. 하지만 어떤 변화든 하루아침에 일어날 수는 없습니다. 더구나 자신이 아닌 다른 누군가를 변화시키는 일이라면 더욱더 기다림이 필요합니다. 2️⃣그는 왜 피드백이 통하지 않을까장은지 대표의 솔루션(이머징리더십인터벤션즈 대표) 인간에게는 자신을 다른 사람보다 우월하다고 생각하는 본성이 있습니다. 이로 인해 많은 사람이 “나 정도면 평균 이상이지”라고 믿습니다. 이것이 ‘평균 이상 효과(better-than-average effect)’입니다. 이렇게 자신의 역량과 성과를 후하게 평가하는 심리적 경향으로, 팀원들은 리더가 자신에 대해 낮은 평가를 했을 때 잘 받아들이지 못하는 경우가 많습니다. 실제 모 대기업을 대상으로 조사한 결과 직원의 70% 이상과 임원의 90% 이상이 자신의 성과를 ‘평균 이상’으로 평가했습니다. 저성과자가 있다면 리더는 피드백을 통해 변화를 유도하고 성과를 높이도록 도와야 합니다. 하지만 저성과자 대다수는 아무리 피드백을 주고 코칭을 해도 잘 변하지 않기 때문에 리더에게 큰 부담으로 작용합니다. 사연자 분 같은 상황에서도 당사자는 아무 문제가 없다고 생각하는 동상이몽이 발생하기도 합니다. 이런 경우에는 팀장의 인식이 아닌 팀원의 인식을 기반으로 피드백이 이뤄져야 하는데, 이것을 아는 리더는 많지 않습니다. 저성과자 문제는 대부분 자기 인식의 결여에서 비롯됩니다. 그렇기 때문에 자신에 대한 평가가 부당하다고 생각하죠. 따라서 리더는 먼저 팀원이 자신의 문제점을 정확하게 인식할 수 있도록 돕고, 그 문제가 무엇인지에 따라 피드백을 해야 합니다. 구성원에게 평가가 공정하다는 인상을 주려면 ‘객관적인 평가’와 ‘지속적인 피드백’을 잘 활용해야 합니다. 주기적인 피드백을 통해 객관적이고 투명하게 소통함으로써 당사자가 본인의 저성과를 인정하고 받아들일 수 있게 해야 합니다. 이걸 잘하는 회사가 넷플릭스입니다. 넷플릭스 리더들은 “경쟁사로 가겠다고 하는 팀원 중 최우선으로 붙잡아야 할 사람은 누구인가?”라는 질문으로 팀원들을 수시로 평가합니다. 그리고 이 질문에서 반복적으로 제외되는 사람은 빠르게 해고됩니다. 잔혹할 만큼 냉정한 문화죠. 넷플릭스에 입사했을 정도의 인재들이라면 ‘나 정도면 평균 이상이지’라고 생각할텐데, 냉혹한 평가를 군말 없이 받아들이는 이유는 무엇일까요? 바로 수시로 이뤄지는 리더의 평가와 피드백 덕분입니다. 자기 역량을 과대평가하는 저성과자가 정확한 자기 인식을 할 수 있도록 도우려면 무엇보다 객관적 평가를 토대로 한 효과적인 피드백이 중요합니다. 저성과자에게 하는 피드백은 필요할 때마다 수시로 이뤄져야 하며, 스스로 문제점을 정확하게 인식할 수 있도록 객관적이면서 구체적이어야 효과가 있습니다.

n.news.naver.com

✅팀원 때문에 골머리를 썩고 있습니다. 문제가 되는 팀원은 업무 

”상사도 관리해야 합니다“ | 오늘 이야기할 주제는 ‘어퍼 매니지먼트(Upper Management)’입니다. 이 용어는 해외에서는 익숙하지만, 국내에서는 아직 생소합니다. 어퍼 매니지먼트란 말 그대로 상사를 어떻게 효과적으로 관리할 것인지에 대한 개념입니다. 보통 매니지먼트라고 하면 팀원이나 조직을 관리하는 것을 떠올리지만 여기서는 반대로 상사와의 관계를 주도적으로 이끌어가는 방법에 

04. 당신은 상사를 어떻게 관리하고 있나요?

개인 커리어를 발전시키기 위해서 보통 새로운 서비스를 성공적으로 런칭하거나, 여러 프로젝트를 동시에 관리하거나, 팀을 이끄는 리더십 등 다양한 방법이 있습니다. 하지만 무엇보다도 직급이 올라가게 되면 상사와의 소통과 협력이 더욱 중요합니다.
이때 필요한 어퍼매니지먼트에 대한 개념을 설명해주신 글이 있어 공유드립니다.

어퍼 매니지먼트란
상사를 어떻게 효과적으로 관리할 것인지에 대한 개념이고, 상사와의 관계를 주도적으로 이끌어가는 방법에 초점을 맞춥니다.
많은 사람들이 상사는 나를 평가하고 관리하는 존재로만 생각하지만, 상사를 효과적으로 관리하고 내가 원하는 방향으로 관계를 이끌어나가는 것이야말로 커리어의 큰 변화를 가져올 수 있습니다.
상사에게 내 업무를 알리고, 필요할 때 도움을 요청하며, 내 성과를 명확히 전달하는 것이 어퍼 매니지먼트의 핵심입니다.

매커니즘 설정의 중요성
상사와의 정기적인 미팅을 잡는 것은 능사가 아닙니다. 프로젝트가 잘 진행되고 있고 상사의 도움이 필요하지 않다면 미팅을 과감히 취소하는 것도 하나의 전략입니다.
내가 전달하고자 하는 핵심이 무엇인지 고민하고, 무작정 미팅을 잡는 것이 아닌 상사의 시간을 효율적으로 사용하는 것이 중요합니다.
보고는 단순히 칭찬을 받기 위한 것이 아닌 프로젝트의 성공을 위해 필요한 지원을 얻고 결정을 함께 내리기 위한 것입니다. 그렇기에 반드시 필요한 정보만 간결히 전달하고 필요한 도움을 구체적으로 요청해야 합니다.

문제를 감추지 말고 사실에 기반해 보고하라
문제가 발생 했을 때 감추지 않고, 사실에 기반에 균형 잡힌 내용을 보고하는 것이 중요합니다
저는 상사들에게 잘한 점만 강조하기보다 어려운 부분과 해결이 필요한 문제들을 솔직하게 공유했습니다.
문제 보고 시 단순히 "도와주세요"가 아닌 지금까지 어떤 방식으로 문제를 해결하려고 노력했는지 그리고 우리가 고려한 여러 대안을 함께 제시하는 것이 중요합니다
상사에게 모든 결정을 떠넘기려고 하는게 아닌 우리가 제안한 해결책에 대한 동의를 구하거나 보완점을 확인하는것이 좋습니다.

약속과 시간을 철저히 지켜라
여기서 말하는 시간은 프로젝트의 마감 기한 뿐만 아닌 회의록 작성, 추가 자료 제공 등 모든 약속을 포함합니다. 상사가 재촉하지 않는다고 해서 몇 번 약속을 어기게 되면 신뢰를 잃기 쉽습니다. 저는 프로젝트를 진행하면서 회의가 끝난 직후 즉시 회의록을 작성해 공유했고, 모든 팀원들도 각자의 일정과 약속을 철저히 지켰습니다. 이러한 철저한 태도는 상사의 신뢰를 얻는 데 큰 도움이 됩니다.

어퍼 매니지먼트의 핵심은
신뢰를 얻는 것입니다. 상사의 시간을 소중히 여기고, 꾸준히 성실한 모습을 보여준다면 자연스럽게 신뢰를 쌓을 수 있습니다. 이러한 자세는 상사뿐만 아니라 동료나 타 부서와의 협업에서도 큰 도움이됩니다.

개인 커리어를 발전시키기 위해서 보통 새로운 서비스를 성공적으로 런칭하거나, 여러 프로젝트를 동시에 관리하거나, 팀을 이끄는 리더십 등 다양한 방법이 있습니다. 하지만 무엇보다도 직급이 올라가게 되면 상사와의 소통과 협력이 더욱 중요합니다.이때 필요한 어퍼매니지먼트에 대한 개념을 설명해주신 글이 있어 공유드립니다. 어퍼 매니지먼트란상사를 어떻게 효과적으로 관리할 것인지에 대한 개념이고, 상사와의 관계를 주도적으로 이끌어가는 방법에 초점을 맞춥니다. 많은 사람들이 상사는 나를 평가하고 관리하는 존재로만 생각하지만, 상사를 효과적으로 관리하고 내가 원하는 방향으로 관계를 이끌어나가는 것이야말로 커리어의 큰 변화를 가져올 수 있습니다. 상사에게 내 업무를 알리고, 필요할 때 도움을 요청하며, 내 성과를 명확히 전달하는 것이 어퍼 매니지먼트의 핵심입니다. 매커니즘 설정의 중요성 상사와의 정기적인 미팅을 잡는 것은 능사가 아닙니다. 프로젝트가 잘 진행되고 있고 상사의 도움이 필요하지 않다면 미팅을 과감히 취소하는 것도 하나의 전략입니다.내가 전달하고자 하는 핵심이 무엇인지 고민하고, 무작정 미팅을 잡는 것이 아닌 상사의 시간을 효율적으로 사용하는 것이 중요합니다.보고는 단순히 칭찬을 받기 위한 것이 아닌 프로젝트의 성공을 위해 필요한 지원을 얻고 결정을 함께 내리기 위한 것입니다. 그렇기에 반드시 필요한 정보만 간결히 전달하고 필요한 도움을 구체적으로 요청해야 합니다. 문제를 감추지 말고 사실에 기반해 보고하라문제가 발생 했을 때 감추지 않고, 사실에 기반에 균형 잡힌 내용을 보고하는 것이 중요합니다저는 상사들에게 잘한 점만 강조하기보다 어려운 부분과 해결이 필요한 문제들을 솔직하게 공유했습니다.문제 보고 시 단순히 "도와주세요"가 아닌 지금까지 어떤 방식으로 문제를 해결하려고 노력했는지 그리고 우리가 고려한 여러 대안을 함께 제시하는 것이 중요합니다 상사에게 모든 결정을 떠넘기려고 하는게 아닌 우리가 제안한 해결책에 대한 동의를 구하거나 보완점을 확인하는것이 좋습니다. 약속과 시간을 철저히 지켜라여기서 말하는 시간은 프로젝트의 마감 기한 뿐만 아닌 회의록 작성, 추가 자료 제공 등 모든 약속을 포함합니다. 상사가 재촉하지 않는다고 해서 몇 번 약속을 어기게 되면 신뢰를 잃기 쉽습니다. 저는 프로젝트를 진행하면서 회의가 끝난 직후 즉시 회의록을 작성해 공유했고, 모든 팀원들도 각자의 일정과 약속을 철저히 지켰습니다. 이러한 철저한 태도는 상사의 신뢰를 얻는 데 큰 도움이 됩니다. 어퍼 매니지먼트의 핵심은 신뢰를 얻는 것입니다. 상사의 시간을 소중히 여기고, 꾸준히 성실한 모습을 보여준다면 자연스럽게 신뢰를 쌓을 수 있습니다. 이러한 자세는 상사뿐만 아니라 동료나 타 부서와의 협업에서도 큰 도움이됩니다.

당신은 상사를 어떻게 관리하고 있나요?

Software engineers shared their favorite IDEs with GenAI features on social media. The most-mentioned one by a comfortable margin was Cursor. WindSurf and Zed also seem to be getting traction at the expense of Visual Studio, and JetBrains.

Which IDEs do software engineers love, and why?

예전에는 IntelliJ 혹은 VSCode로 천하통일이었던 것 같은데, 최근 AI 기능 통합된 새로운 도구들이 속속 나타나면서 개발자들에게는 더 즐거운 IDE 선택지들이 생긴 것 같습니다.

 * Cursor: 2022년에 설립되어 2023년 3월 첫 버전을 출시한 AI 기반 IDE로, 특히 'Composer'라는 기능이 주목받고 있습니다. 이 기능은 여러 파일에 걸쳐 지시사항을 수행. "다른 경쟁사 제품을 사용해봐도 Cursor가 더 나은 결과를 제공한다"는 찬사도 받음.
 * Windsurf: Codeium에서 최근 출시한 AI 코드 에디터로, AI와의 협업 흐름을 개선하고 디버깅 시 유용하다는 평가를 받고 있습니다. 'Cascade'라는 기능은 여러 파일에 걸쳐 협업할 수 있는 에이전트형 챗봇으로, 'write code'와 'chat' 모드를 지원하며 터미널 명령도 실행할 수 있습니다.
 * Zed: 협업과 AI 기능을 갖춘 차세대 코드 에디터로, 빠른 속도와 사용자 친화적인 인터페이스를 제공합니다.
 * Neovim with Copilot: Vim 기반의 텍스트 에디터인 Neovim에 GitHub Copilot을 통합하여 AI 기반 코드 보완 기능을 활용할 수 있습니다.
 * Supermaven: VS Code나 JetBrains IDE와 같은 환경에서 작동하는 AI 완성 유틸리티로, 코드 작성 시 효율성을 높여줍니다.

 * 무료 도구 (기본 사용량 한정):
   * Zed: 초기 출시 기간 동안 Anthropic과의 파트너십을 통해 무료로 제공
   * Cursor: 2주간의 무료 체험 기간 제공
   * Windsurf: 개인 무료 플랜 제공
   * v0 by Vercel: 개인 무료 플랜 제공
   * Replit AI Agent: 스타터 플랜 제공
   * Cody: 무료 플랜 제공
   * Bolt.new: 추수감사절 기간 동안 200만 개의 무료 토큰 제공
   * JetBrains AI: 7일간의 무료
 * 유료 도구 ($10-20/월):
   * Cody: Pro 플랜 월 $9
   * GitHub Copilot: 개인 플랜 월 $10
   * JetBrains AI: Pro 플랜 월 $10
   * Replit AI Agent: Core 플랜 월 $15
   * Stackblitz: Pro 플랜 월 $18
   * Cursor: Pro 플랜 월 $20
   * v0 by Vercel: 월 $20
     
     
   
   

https://blog.pragmaticengineer.com/ide-that-software-engineers-love

예전에는 IntelliJ 혹은 VSCode로 천하통일이었던 것 같은데, 최근 AI 기능 통합된 새로운 도구들이 속속 나타나면서 개발자들에게는 더 즐거운 IDE 선택지들이 생긴 것 같습니다. <ul ><li>Cursor: 2022년에 설립되어 2023년 3월 첫 버전을 출시한 AI 기반 IDE로, 특히 'Composer'라는 기능이 주목받고 있습니다. 이 기능은 여러 파일에 걸쳐 지시사항을 수행. "다른 경쟁사 제품을 사용해봐도 Cursor가 더 나은 결과를 제공한다"는 찬사도 받음. </li><li>Windsurf: Codeium에서 최근 출시한 AI 코드 에디터로, AI와의 협업 흐름을 개선하고 디버깅 시 유용하다는 평가를 받고 있습니다. 'Cascade'라는 기능은 여러 파일에 걸쳐 협업할 수 있는 에이전트형 챗봇으로, 'write code'와 'chat' 모드를 지원하며 터미널 명령도 실행할 수 있습니다.</li><li>Zed: 협업과 AI 기능을 갖춘 차세대 코드 에디터로, 빠른 속도와 사용자 친화적인 인터페이스를 제공합니다.</li><li>Neovim with Copilot: Vim 기반의 텍스트 에디터인 Neovim에 GitHub Copilot을 통합하여 AI 기반 코드 보완 기능을 활용할 수 있습니다.</li><li>Supermaven: VS Code나 JetBrains IDE와 같은 환경에서 작동하는 AI 완성 유틸리티로, 코드 작성 시 효율성을 높여줍니다.</li></ul> <ul ><li>무료 도구 (기본 사용량 한정):<ul ><li>Zed: 초기 출시 기간 동안 Anthropic과의 파트너십을 통해 무료로 제공</li><li>Cursor: 2주간의 무료 체험 기간 제공</li><li>Windsurf: 개인 무료 플랜 제공</li><li>v0 by Vercel: 개인 무료 플랜 제공</li><li>Replit AI Agent: 스타터 플랜 제공</li><li>Cody: 무료 플랜 제공</li><li>Bolt.new: 추수감사절 기간 동안 200만 개의 무료 토큰 제공</li><li>JetBrains AI: 7일간의 무료</li></ul></li><li>유료 도구 ($10-20/월):<ul ><li>Cody: Pro 플랜 월 $9</li><li>GitHub Copilot: 개인 플랜 월 $10</li><li>JetBrains AI: Pro 플랜 월 $10</li><li>Replit AI Agent: Core 플랜 월 $15</li><li>Stackblitz: Pro 플랜 월 $18</li><li>Cursor: Pro 플랜 월 $20</li><li>v0 by Vercel: 월 $20 </li></ul> </li></ul> https://blog.pragmaticengineer.com/ide-that-software-engineers-love

The Pragmatic Engineer

요즘 IDE

Llama 모델이란?먼저, Llama 모델에 대해 간단히 소개하겠습니다.   Llama(Large Language Model Meta AI)는 Meta AI에서 개발한 대규모 언어 모델입니다. OpenAI의 GPT 시리즈와 마찬가지로 트랜스포머 아키텍처를 기반으로 하며, 다양한 크기와 성능을 제공합니다. 이 포스팅에서 다룰 Llama-3.2-1B-Instruction 모델은 약 10억 개의 파라미터를 가진 모델로, sLLM에 해당하는 아주 작은 파라미터를 가지고 있지만, 특정 태스크에서는 뛰어난 성능을 보여주는 모델입니다.한국어 QA 튜닝 방법한국어 QA 시스템의 발전은 국내 AI 산업에서 매우 중요한 부분을 차지합니다. 검색 엔진, 고객 서비스 챗봇, 교육용 AI 등 다양한 분야에서 활용될 수 있기 때..

Llama-3.2-1B-Instruction 모델 파인튜닝하기

최근에 Llama 모델을 파인튜닝 해서 모델의 성능을 높여야하는 과제가 있어서,
다양한 자료를 찾아보았습니다.

그런데 대부분의 경우 잘 실행되지 않았고, 알 수 없는 에러로 저를 고생시키기만 했습니다.
그러다가 아래 링크에 있는 내용들을 보고 성공했습니다.

그리고 이를 바탕으로 해서 Llama-70B 모델도 파인튜닝을 할 수 있는 코드를 작성하기도 했습니다.

파인튜닝에 관심있는 분에게 추천드립니다.

https://naakjii.tistory.com/138

최근에 Llama 모델을 파인튜닝 해서 모델의 성능을 높여야하는 과제가 있어서, 다양한 자료를 찾아보았습니다. 그런데 대부분의 경우 잘 실행되지 않았고, 알 수 없는 에러로 저를 고생시키기만 했습니다. 그러다가 아래 링크에 있는 내용들을 보고 성공했습니다. 그리고 이를 바탕으로 해서 Llama-70B 모델도 파인튜닝을 할 수 있는 코드를 작성하기도 했습니다. 파인튜닝에 관심있는 분에게 추천드립니다. https://naakjii.tistory.com/138

NJSUNG BLOG

Llama 를 파인튜닝 해보자.

전문가를 위한 파이썬 | 파이썬의 잠재력을 끌어올리는 프로그래밍 기법다른 언어에서 배운 패턴을 파이썬에 억지로 맞추지 말자. 파이썬의 단순함은 생산성을 빠르게 높여주지만, 그 단순함에 취해 언어가 제공하는 다양……

전문가를 위한 파이썬 | 루시아누 하말류 - 교보문고

저는 파이썬이라는 언어를 매우 좋아합니다.
깔끔하고 알기 쉬운 문법, 친절한 문서, 따뜻한 커뮤니티가 있기 때문입니다.

그런데 쉬운언어라는 선입견들이 있어서,
입문자 단계에서 중급자로 올라가기 위해서는 다양한 노력들을 해야합니다.

파이썬 관련해서 책을 30권정도는 봤는데, 그중에 단 1권만 추천한다면
단연코 '전문가를 위한 파이썬'을 추천합니다.

프로토콜, 메타프로그램, 제너레이터등의 주제를 다루고 있습니다.
조금 어려운 주제 일 수 있지만, 중급자 이상으로 올라가려면 파이썬의 동작방식을 잘 이해해야 될 것입니다.

이 책으로 같이 스터디하시면 아마도 실력이 한단계 더 향상 될것이라 생각합니다 .
https://product.kyobobook.co.kr/detail/S000214847242

저는 파이썬이라는 언어를 매우 좋아합니다. 깔끔하고 알기 쉬운 문법, 친절한 문서, 따뜻한 커뮤니티가 있기 때문입니다. 그런데 쉬운언어라는 선입견들이 있어서, 입문자 단계에서 중급자로 올라가기 위해서는 다양한 노력들을 해야합니다. 파이썬 관련해서 책을 30권정도는 봤는데, 그중에 단 1권만 추천한다면 단연코 '전문가를 위한 파이썬'을 추천합니다. 프로토콜, 메타프로그램, 제너레이터등의 주제를 다루고 있습니다. 조금 어려운 주제 일 수 있지만, 중급자 이상으로 올라가려면 파이썬의 동작방식을 잘 이해해야 될 것입니다. 이 책으로 같이 스터디하시면 아마도 실력이 한단계 더 향상 될것이라 생각합니다 .https://product.kyobobook.co.kr/detail/S000214847242

product.kyobobook.co.kr

중급자를 위한 파이썬 책을 단 한권만 추천한다면?

지금까지 내가 헥사고날 아키텍처를 설계해 보며 배운 점을 정리해 봤다.📌 서론지금까지 3번 정도 헥사고날 아키텍처를 적용시켜서 프로젝트를 만들어봤다. 첫 번째 설계에서는 왜 port 같은 것을 사용해서 이렇게 복잡하고 어렵게 설계하는 거지? 이런 생각이 많이 들었다. 원리를 이해하지 못하고 단순히 이게 좋다니까 해봐야겠다! 이런 생각을 하면서 개발을 진행했었던 것 같다.

[Spring] 헥사고날 아키텍처

스프링에 헥사고날 아키텍처를 적용시킨 프로젝트를 진행하며 배운점들을 정리해봤습니다. (주니어 개발자의 회고록입니다!)

잘못된 부분도 있을것이고 보충할 내용도 있을것이라고 생각합니다. 언제든지 조언 부탁드립니다. 🙏🙏

블로그 내용은 대략 이렇게 구성되어 있습니다.

 1. 헥사고날 아키텍처의 구조
 2. 도메인 영역
 3. 서비스 영역
 4. 어댑터 in
 5. 어댑터 out
 6. 배운점

감사합니다 :)

https://curiousjinan.tistory.com/entry/spring-hexagonal-architecture

스프링에 헥사고날 아키텍처를 적용시킨 프로젝트를 진행하며 배운점들을 정리해봤습니다. (주니어 개발자의 회고록입니다!) 잘못된 부분도 있을것이고 보충할 내용도 있을것이라고 생각합니다. 언제든지 조언 부탁드립니다. 🙏🙏 블로그 내용은 대략 이렇게 구성되어 있습니다. <ol><li>헥사고날 아키텍처의 구조</li><li>도메인 영역</li><li>서비스 영역</li><li>어댑터 in</li><li>어댑터 out</li><li>배운점</li></ol> 감사합니다 :) https://curiousjinan.tistory.com/entry/spring-hexagonal-architecture

오늘도 개발중입니다

헥사고날 아키텍처를 통해 배운점

플랫폼

교육 / 에듀테크

apache kafka

SpringBoot

Java

Docker

Redis

AWS ECS

AWS RDS(with MySQL)

Jira

차세대 기업교육 플랫폼을 msa 프로젝트로 개발하고 있습니다.


헥사고날 아키텍처를 통해 배운점

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필