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 프론트엔드 뉴스 한 방에 몰아보기

Next.js 15.1 introduces React 19 stable support, improved error debugging, new experimental authorization APIs, and more.

Next.js 15.1

Next.js 15.1이 출시되었습니다. Next.js 15가 나온지 얼마 되지 않은 것 같은데, 역시 Vercel 답게, 꽤 빠른 후속 업그레이드가 이뤄졌네요. 이번 업데이트의 주요 내용은 대략 다음과 같습니다.

React 19 정식 지원
React 19가 안정화(Stable) 버전으로 출시됨에 따라 Next.js에서도 이를 공식적으로 지원하게 되었습니다. 이제 앱 라우터(App Router)와 페이지 라우터(Pages Router) 모두에서 정식 React 19를 활용할 수 있습니다.

에러 디버깅 환경 개선
터미널, 브라우저, 디버거 모두에서 오류 원인을 더 명확히 확인할 수 있도록 개선되었습니다.

ignoreList
를 사용해 외부 종속성 스택 프레임을 기본적으로 숨김 처리하여 애플리케이션 코드 중심으로 문제를 파악할 수 있습니다. 이전에는 서드파티 라이브러리까지 모두 표시되어 디버깅이 다소 번거러운 측면이 있었는데요. 이제는 필요한 경우
“Show ignored frames”
를 통해 외부 종속성 스택 프레임을 확인할 수 있습니다.

forbidden(), unauthorized() API 실험적 도입
403(Forbidden)과 401(Unauthorized) 에러 처리를 선언적으로 할 수 있는 새로운 API가 추가되었습니다.
 * forbidden()
   : 403 에러 처리 (forbidden.tsx를 통해 UI 커스터마이징 가능)
 * unauthorized()
   : 401 에러 처리 (unauthorized.tsx를 통해 UI 커스터마이징 가능)
해당 기능은 실험적이므로 사용하려면
next.config.ts
에서
experimental.authInterrupts: true
를 활성화해야 합니다. 앞으로 인증/인가 오류를 좀 더 선언적으로 관리할 수 있을것 같습니다.
if (userRole !== 'admin') {
  forbidden(); // 403 에러 발생 및 커스텀 UI 표시
}

이번 업데이트로 인해 직관적인 디버깅 및 코드 가시성이 한층 개선될것으로 보이네요 :)

https://nextjs.org/blog/next-15-1

Next.js 15.1이 출시되었습니다. Next.js 15가 나온지 얼마 되지 않은 것 같은데, 역시 Vercel 답게, 꽤 빠른 후속 업그레이드가 이뤄졌네요. 이번 업데이트의 주요 내용은 대략 다음과 같습니다. React 19 정식 지원 React 19가 안정화(Stable) 버전으로 출시됨에 따라 Next.js에서도 이를 공식적으로 지원하게 되었습니다. 이제 앱 라우터(App Router)와 페이지 라우터(Pages Router) 모두에서 정식 React 19를 활용할 수 있습니다. 에러 디버깅 환경 개선 터미널, 브라우저, 디버거 모두에서 오류 원인을 더 명확히 확인할 수 있도록 개선되었습니다. <code >ignoreList</code>를 사용해 외부 종속성 스택 프레임을 기본적으로 숨김 처리하여 애플리케이션 코드 중심으로 문제를 파악할 수 있습니다. 이전에는 서드파티 라이브러리까지 모두 표시되어 디버깅이 다소 번거러운 측면이 있었는데요. 이제는 필요한 경우 <code >“Show ignored frames”</code>를 통해 외부 종속성 스택 프레임을 확인할 수 있습니다. forbidden(), unauthorized() API 실험적 도입 403(Forbidden)과 401(Unauthorized) 에러 처리를 선언적으로 할 수 있는 새로운 API가 추가되었습니다.<ul ><li><code >forbidden()</code>: 403 에러 처리 (forbidden.tsx를 통해 UI 커스터마이징 가능)</li><li><code >unauthorized()</code>: 401 에러 처리 (unauthorized.tsx를 통해 UI 커스터마이징 가능)</li></ul>해당 기능은 실험적이므로 사용하려면 <code >next.config.ts</code>에서 <code >experimental.authInterrupts: true</code>를 활성화해야 합니다. 앞으로 인증/인가 오류를 좀 더 선언적으로 관리할 수 있을것 같습니다.<pre ><code>if (userRole !== 'admin') {
 forbidden(); // 403 에러 발생 및 커스텀 UI 표시
}</code></pre> 이번 업데이트로 인해 직관적인 디버깅 및 코드 가시성이 한층 개선될것으로 보이네요 :) https://nextjs.org/blog/next-15-1

nextjs.org

Next.js 15.1 출시: React 19 정식 지원

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에 웹사이트 배포하기

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

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

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 시대, 개발자 로드맵: 코더에서 아키텍트로

단순 코딩만 하는 개발자가 언제  필요한 적이 있었던가요? 학력에 경력에 맨날 따지더만 이력서 내봐야 죄다 서류에서 탈락 시키더만 알고보니 단순 코딩하는 인력이었어요? 그럼 저는 단순 코딩 복사 붙여넣기 조차 시킬 수 없는 인간이였단 얘기입니까

어디선가 많이 본 UI를 구현해야 했어요. 알고 보니 옆 팀에서 사용하고 있는 구성이었죠.

우선 복사하고 붙여 넣었어요. 하나씩 저희 코드에 맞게 다듬었어요. 뺄 건 빼고 넣을 건 넣고.

문득 그런 생각이 들었어요. 잘 옮기는 것도 기술이구나. 뭘 빼야 할지, 뭘 더해야 할지 아는 것도 능력이구나.

복붙도 기술이에요. 중요한 능력이에요.

어디선가 많이 본 UI를 구현해야 했어요. 알고 보니 옆 팀에서 사용하고 있는 구성이었죠. 우선 복사하고 붙여 넣었어요. 하나씩 저희 코드에 맞게 다듬었어요. 뺄 건 빼고 넣을 건 넣고. 문득 그런 생각이 들었어요. 잘 옮기는 것도 기술이구나. 뭘 빼야 할지, 뭘 더해야 할지 아는 것도 능력이구나. 복붙도 기술이에요. 중요한 능력이에요.

복붙도 기술이에요

지난봄, 길을 걷다 마주한 벚꽃을 보며 감탄했어요. 벚꽃이 최고인 줄 알았죠.

늦가을에 같은 길을 지나는데 커다란 은행나무가 있었어요. 아름다움에 다시 한번 감탄했어요.

은행나무도 5월쯤 꽃을 피운대요. 화려하지 않아서 잘 몰랐던 거죠. 대신 가을에 아름답게 물든 잎으로 주목받아요.

우리는 모두 벚꽃처럼 빠르고 화려하게 인정받고 싶어 해요.

하지만 은행나무처럼 묵묵히 자신만의 방식으로 자라나는 것도 멋진 일이에요. 조용히 쌓아온 내공과 신뢰는 시간이 지나야 비로소 진가를 드러내요.

모두가 벚꽃이 될 필요는 없어요. 각자의 계절에서 각자의 방식으로 인정받을 수 있으니까요.

지난봄, 길을 걷다 마주한 벚꽃을 보며 감탄했어요. 벚꽃이 최고인 줄 알았죠. 늦가을에 같은 길을 지나는데 커다란 은행나무가 있었어요. 아름다움에 다시 한번 감탄했어요. 은행나무도 5월쯤 꽃을 피운대요. 화려하지 않아서 잘 몰랐던 거죠. 대신 가을에 아름답게 물든 잎으로 주목받아요. 우리는 모두 벚꽃처럼 빠르고 화려하게 인정받고 싶어 해요. 하지만 은행나무처럼 묵묵히 자신만의 방식으로 자라나는 것도 멋진 일이에요. 조용히 쌓아온 내공과 신뢰는 시간이 지나야 비로소 진가를 드러내요. 모두가 벚꽃이 될 필요는 없어요. 각자의 계절에서 각자의 방식으로 인정받을 수 있으니까요.

벚꽃과 커리어

The 2024 edition of the annual survey about the latest trends in the JavaScript ecosystem.

State of JavaScript 2024

올 한해는 어떤 어떤 새로운게 나오나? 순위가 바뀌나? 하면서 지켜보던 재미가 있던 state of js 였는데, 이번에는 사실 큰 기대가 되지 않았습니다. 예상과는 별로 다르지 않은 결과가 나올것 같았고 들여다 봤지만 역시나네요. 이제 프론트엔드 씬은 확실히 Hype는 끝나고 안정화 추세에 와있습니다.

1
설문조사 현재 가장 많이 쓰이고 있는 프론트엔드 기술스택은 다음과 같습니다.
그리고 여러분들도 이미 알고 있지 않을까 생각이 되네요.

Typescript
React, Next, Vite,
Testing library, Jest,
Playwright, pnpm,
React Native, Electron
express, Nest

2
전반적으로 모든 2024 주류 라이브러리들(Webpack, React, Vite, Jest, Next.js, Svelte) 의 만족도에 대한 평가가 모두 불만족으로 꺽이고 있는게 재밌는 포인트이네요.
그래서 상대적으로 Vue, Angaulr의 관심도가 올라간게 재밌긴 한데 대세에는 영향은 없지 않을까 생각합니다.

Svelte와 SvelteKit도 다소 불만족으로 꺽이는 모양입니다.
React와의 대척점을 만들어주지 못했고, 주류 패러다임과 결이 같아지면서 아쉬운 행보입니다.

3
주목해보고 관심을 끄는 것은 Astro정도 이네요.
SSG를 사용해도 되는 프로젝트라면 Astro는 매우 좋은 선택지라고 생각합니다.
또한 다양한 프레임워크를 어쩔 수 없이 써야 하거나,
Vue, Angaulr등을 유지하면서 React로 갈아타는 브릿지 역할도 잘 수행할 수 있다 생각합니다.
성능도 편의성도 개념도 월등하게 좋은 녀석이니 추천합니다.

4
자바스크립트의 일부 새로운 기능들이 생겼으나 유의미하게 변한다 싶은 것은 없습니다.
이제 Javascript보다 Typescript로 개발한다는 사람이 더 많고
100% Typescript라는 비율이 압도적으로 높네요.
이렇게 된지는 꽤 오래되었지만 처음부터 Typescript가 기본 언어다 생각하고 배우시면 되겠습니다.

더 궁금하신 분들을 설문조사의 결과를 보면서 살펴보세요.
재미난 인사이트나 의견이 있다면 공유해주세요. 고맙습니다.

https://2024.stateofjs.com/ko-KR/

올 한해는 어떤 어떤 새로운게 나오나? 순위가 바뀌나? 하면서 지켜보던 재미가 있던 state of js 였는데, 이번에는 사실 큰 기대가 되지 않았습니다. 예상과는 별로 다르지 않은 결과가 나올것 같았고 들여다 봤지만 역시나네요. 이제 프론트엔드 씬은 확실히 Hype는 끝나고 안정화 추세에 와있습니다. 1설문조사 현재 가장 많이 쓰이고 있는 프론트엔드 기술스택은 다음과 같습니다.그리고 여러분들도 이미 알고 있지 않을까 생각이 되네요. TypescriptReact, Next, Vite, Testing library, Jest, Playwright, pnpm, React Native, Electronexpress, Nest 2전반적으로 모든 2024 주류 라이브러리들(Webpack, React, Vite, Jest, Next.js, Svelte) 의 만족도에 대한 평가가 모두 불만족으로 꺽이고 있는게 재밌는 포인트이네요.그래서 상대적으로 Vue, Angaulr의 관심도가 올라간게 재밌긴 한데 대세에는 영향은 없지 않을까 생각합니다. Svelte와 SvelteKit도 다소 불만족으로 꺽이는 모양입니다. React와의 대척점을 만들어주지 못했고, 주류 패러다임과 결이 같아지면서 아쉬운 행보입니다. 3주목해보고 관심을 끄는 것은 Astro정도 이네요. SSG를 사용해도 되는 프로젝트라면 Astro는 매우 좋은 선택지라고 생각합니다.또한 다양한 프레임워크를 어쩔 수 없이 써야 하거나,Vue, Angaulr등을 유지하면서 React로 갈아타는 브릿지 역할도 잘 수행할 수 있다 생각합니다.성능도 편의성도 개념도 월등하게 좋은 녀석이니 추천합니다. 4자바스크립트의 일부 새로운 기능들이 생겼으나 유의미하게 변한다 싶은 것은 없습니다. 이제 Javascript보다 Typescript로 개발한다는 사람이 더 많고100% Typescript라는 비율이 압도적으로 높네요.이렇게 된지는 꽤 오래되었지만 처음부터 Typescript가 기본 언어다 생각하고 배우시면 되겠습니다. 더 궁금하신 분들을 설문조사의 결과를 보면서 살펴보세요.재미난 인사이트나 의견이 있다면 공유해주세요. 고맙습니다. https://2024.stateofjs.com/ko-KR/

2024.stateofjs.com

프론트엔드 기술 스택 설문 state of js 2024 결과가 나왔네요

Rust for Windows. Contribute to microsoft/windows-rs development by creating an account on GitHub.

GitHub - microsoft/windows-rs: Rust for Windows

Windows Rust는 Microsoft가 개발한 오픈 소스 라이브러리로, Rust 프로그래밍 언어에서 Windows API를 간편하게 활용할 수 있게 해줍니다.

Rust의 안전성과 성능을 극대화할 수 있는 인터페이스를 제공하며, 복잡한 API 호출을 자동으로 생성해줍니다. 단 몇 줄의 설정만으로 Windows API에 접근할 수 있고, 다양한 애플리케이션—데스크톱 프로그램, 시스템 유틸리티, 게임 개발 등에 활용할 수 있습니다.

이제 Windows API를 C++ 말고도 사용할 수 있게 되었네요!

https://github.com/microsoft/windows-rs

Windows Rust는 Microsoft가 개발한 오픈 소스 라이브러리로, Rust 프로그래밍 언어에서 Windows API를 간편하게 활용할 수 있게 해줍니다. Rust의 안전성과 성능을 극대화할 수 있는 인터페이스를 제공하며, 복잡한 API 호출을 자동으로 생성해줍니다. 단 몇 줄의 설정만으로 Windows API에 접근할 수 있고, 다양한 애플리케이션—데스크톱 프로그램, 시스템 유틸리티, 게임 개발 등에 활용할 수 있습니다. 이제 Windows API를 C++ 말고도 사용할 수 있게 되었네요! https://github.com/microsoft/windows-rs

GitHub

Windows Rust: Windows API를 Rust로 간편하게 사용

이 글은... '이름 들으면 알 정도의' 스타트업이 아니라, 그 아래에서 성공하기 위해 고군분투하고 있는 작은 스타트업 주니어에 대한 글이다. 그리고 그 안에서 고군분투했던 내가 어떤 실패를 겪었는지, 무엇을 느꼈는지에 대해 적어보고자 한다. 초기 스타트업이라고 불리는 곳에 '지원해볼까? 말까?'하고 있는, 혹은 다니고 있는 주니어들에게 도움이 되지 않을까

13화 스타트업에서 성장한다는 주니어의 착각

거의 5년이 지나가는 글이지만, 몇 달에 한번씩 우연히 이 글을 볼 때 마다 매번 내용이 좋다고 생각하는 글입니다. 주니어로 한정짓기보다는 그냥 직장인로써 회사 업무를 진행하며 성장하고 있다고 느껴질때, 과연 실제로 그 업무가 시장에서 인정받는 성장 인지 판단해봐야 한다는 교훈을 주는 글입니다.

주니어가 스타트업에 채용되어 입사했다면 대개 그 스타트업은 성장한다.
조직 내부에 있으면 외부에 있을 때보다 훨씬 성공이 크게 다가온다. 매출이 1억에서 2억으로 뛰었을 때, 고무적인 성장을 이뤄낸 것에 대해 다 같이 자축하고 동기 부여된다. 특히 주니어로서 많은 권한과 책임을 안고 시도한 일들이 어떤 성과를 냈을 때 당연히 기분이 좋을 수 밖에 없다.

하지만 나와 회사의 위대함은 어디까지나 은밀하게 위대했다
어떤 모임에 나가 무슨 스타트업이라 이야기해도 아무도 모르고, 연 매출 100억 회사가 되었다고 열심히 이야기하더라도 그들입장에서는 그냥 똑같은 스타트업이었을뿐이다.
결국 대기업에 비해 보여지는건 그냥 작은 스타트업 일뿐이었다.

회사의 성장은 나의 성장이라고 믿었다.
실제로 회사가 성장하는 만큼 나도 꽤나 성장했다. 작은 비즈니스라도 쉬운일이 아니고, 실력이 있어야만 가능한 일이라는 것을 배웠다. 하지만 주변에 아무나 잡고 이야기해봐도 '그래?'가 끝이였고, 메이저 스타트업 출신의 다른 동료분들의 비해 주늑 드는 나 자신을 발견하게 되었다.

여기서 나의 착각은 '회사의 성장이 곧 나의 성장' 이라는 것만 믿었다는 것이다.
현업에 치여 매일 실무들을 쳐내다 보니 작은 성장들이 너무나 크게 보였고, 정작 '나의 성장' 에는 소홀했다. 커리어 개발의 기준을 '시장'에 두어야 하는데 단지 그 '회사' 안에서만 두었던 것이다. 그러니 시장에 나갔을 때 이야기할만한 '나의 성장'이 적을 수 밖에 없었다.

시장의 기준에서 통용될 수 있는 성장의 근거를 만들어야한다.
그 근거가 조직 내부의 관점에 머물러 있으면 작은 성공도 커보이고, 시장의 관점에서 인정받는 성장을 놓치게 된다. 주인의식을 갖고 몰입하는 건 좋지만 언제나 '시장'의 관점을 견지하고 있어야 한다. 개인 커리어 관점에서 말이다.

회사의 성장과 회사 안에서 나의 성장은 실체보다 더 크게보인다.
이에 매몰되지 않도록 항상 '시장'의 관점에서 사고하고 판단할 수 있게끔 유관업계 현직자들과 네트워킹 해야하고, 시장의 관점으로 나 자신의 성장을 판단해야한다.
단순히 회사의 성장에 기대지 않도록 나만의 포트폴리오를 만들어가야 하고, 단순히 숫자나 성과 위주가 아닌, 숫자의 크기와 상관없이 적용 가능한 '문제 해결 방법론과 의사결정 히스토리' 를 중심으로 기록하는게 좋다.

논리와 근거가 있어도 쉽게 무너진다.
조직 안에서는 서로간의 신뢰가 있기 때문에 논리와 근거를 바탕으로 이야기했을 때 상대방을 설득해낼 수 있지만, 외부로 나가면 논리와 근거보다 직급과 나이, 출신이 실제로 더 힘이 있었던것 같다. 그러니까 단순히 스타트업에서 '해봤다'는 것만으로는 부족하고, 나의 전문성을 입증할 수 있을 만한 근거를 일하는 동안 끊임없이 모아야 한다. 구직 시장에서 먹힐 수 있는, 공신력 있는 근거들을 쌓아두지 않으면 씨알도 먹히지 않는다.

하고 싶은 일이나 성장이라는 허울 좋은 가치만 쫒는 동안 해야 하는일과 생존을 놓쳤다.
주말 없이 바쁘게 살고 있으니 퇴근 후 조금은 워라벨을 즐겨야 한다고 생각하고 쉬기도했다. 회사도 성장하고 있고 그 안에서 나도 누구보다 바쁘게, 어디서 해볼 수 없는 다양한 일들을 경험하며 성장하고 있으니까 괜찮다고 안일하게 생각했다. 내 경험이 재산이 될 거라고 생각했고 일에 대한 관점과 논리적인 생각이 경쟁력이 될 거라고 생각했으나 실제로는 인정받기 어려웠다.

거의 5년이 지나가는 글이지만, 몇 달에 한번씩 우연히 이 글을 볼 때 마다 매번 내용이 좋다고 생각하는 글입니다. 주니어로 한정짓기보다는 그냥 직장인로써 회사 업무를 진행하며 성장하고 있다고 느껴질때, 과연 실제로 그 업무가 시장에서 인정받는 성장 인지 판단해봐야 한다는 교훈을 주는 글입니다. 주니어가 스타트업에 채용되어 입사했다면 대개 그 스타트업은 성장한다.조직 내부에 있으면 외부에 있을 때보다 훨씬 성공이 크게 다가온다. 매출이 1억에서 2억으로 뛰었을 때, 고무적인 성장을 이뤄낸 것에 대해 다 같이 자축하고 동기 부여된다. 특히 주니어로서 많은 권한과 책임을 안고 시도한 일들이 어떤 성과를 냈을 때 당연히 기분이 좋을 수 밖에 없다. 하지만 나와 회사의 위대함은 어디까지나 은밀하게 위대했다어떤 모임에 나가 무슨 스타트업이라 이야기해도 아무도 모르고, 연 매출 100억 회사가 되었다고 열심히 이야기하더라도 그들입장에서는 그냥 똑같은 스타트업이었을뿐이다.결국 대기업에 비해 보여지는건 그냥 작은 스타트업 일뿐이었다. 회사의 성장은 나의 성장이라고 믿었다.실제로 회사가 성장하는 만큼 나도 꽤나 성장했다. 작은 비즈니스라도 쉬운일이 아니고, 실력이 있어야만 가능한 일이라는 것을 배웠다. 하지만 주변에 아무나 잡고 이야기해봐도 '그래?'가 끝이였고, 메이저 스타트업 출신의 다른 동료분들의 비해 주늑 드는 나 자신을 발견하게 되었다. 여기서 나의 착각은 '회사의 성장이 곧 나의 성장' 이라는 것만 믿었다는 것이다.현업에 치여 매일 실무들을 쳐내다 보니 작은 성장들이 너무나 크게 보였고, 정작 '나의 성장' 에는 소홀했다. 커리어 개발의 기준을 '시장'에 두어야 하는데 단지 그 '회사' 안에서만 두었던 것이다. 그러니 시장에 나갔을 때 이야기할만한 '나의 성장'이 적을 수 밖에 없었다. 시장의 기준에서 통용될 수 있는 성장의 근거를 만들어야한다.그 근거가 조직 내부의 관점에 머물러 있으면 작은 성공도 커보이고, 시장의 관점에서 인정받는 성장을 놓치게 된다. 주인의식을 갖고 몰입하는 건 좋지만 언제나 '시장'의 관점을 견지하고 있어야 한다. 개인 커리어 관점에서 말이다. 회사의 성장과 회사 안에서 나의 성장은 실체보다 더 크게보인다.이에 매몰되지 않도록 항상 '시장'의 관점에서 사고하고 판단할 수 있게끔 유관업계 현직자들과 네트워킹 해야하고, 시장의 관점으로 나 자신의 성장을 판단해야한다.단순히 회사의 성장에 기대지 않도록 나만의 포트폴리오를 만들어가야 하고, 단순히 숫자나 성과 위주가 아닌, 숫자의 크기와 상관없이 적용 가능한 '문제 해결 방법론과 의사결정 히스토리' 를 중심으로 기록하는게 좋다. 논리와 근거가 있어도 쉽게 무너진다.조직 안에서는 서로간의 신뢰가 있기 때문에 논리와 근거를 바탕으로 이야기했을 때 상대방을 설득해낼 수 있지만, 외부로 나가면 논리와 근거보다 직급과 나이, 출신이 실제로 더 힘이 있었던것 같다. 그러니까 단순히 스타트업에서 '해봤다'는 것만으로는 부족하고, 나의 전문성을 입증할 수 있을 만한 근거를 일하는 동안 끊임없이 모아야 한다. 구직 시장에서 먹힐 수 있는, 공신력 있는 근거들을 쌓아두지 않으면 씨알도 먹히지 않는다. 하고 싶은 일이나 성장이라는 허울 좋은 가치만 쫒는 동안 해야 하는일과 생존을 놓쳤다.주말 없이 바쁘게 살고 있으니 퇴근 후 조금은 워라벨을 즐겨야 한다고 생각하고 쉬기도했다. 회사도 성장하고 있고 그 안에서 나도 누구보다 바쁘게, 어디서 해볼 수 없는 다양한 일들을 경험하며 성장하고 있으니까 괜찮다고 안일하게 생각했다. 내 경험이 재산이 될 거라고 생각했고 일에 대한 관점과 논리적인 생각이 경쟁력이 될 거라고 생각했으나 실제로는 인정받기 어려웠다.

Brunch Story

스타트업에서 성장한다는 주니어의 착각

구글 코딩 가이드라인을 보면 코드 가독성(Readability)을 강조한다. 코딩 주짓수 하지 말고 읽기 쉬운 코드를 작성하라는 건데 그래야 다른 개발자들 뿐만 아니라 본인이 본인의 코드를 나중에 볼 때 도움이 된다. 기본적으로 실리콘밸리에서는 개발자들의 이직이 워낙 잦기 때문에 유지 보수의 중요성에 대한 전반적인 인식이 더 있지 않나 싶다. 좋은 코드가 갖는 여러가지 원칙이 있겠지만 아래와 같은 것들을 들어볼 수 있을 듯 하다.

 1. 유지 보수성
    * 코드가 단순할수록 이해하기 쉽고, 수정하거나 확장할 때 실수를 줄일 수 있다.
    * 코드 리뷰, 디버깅, 팀 협업에서 단순한 코드는 더 효율적이다.
 2. 복잡성의 비용
    * 불필요하게 복잡한 코드는 버그를 유발하기 쉽고, 기능을 추가하거나 수정할 때 전체 시스템을 망칠 위험이 커진다
    * 가독성이 떨어지면 개발자는 코드 이해에 더 많은 시간을 소비한다.
 3. KISS 원칙
    * "Keep It Simple, Stupid"라는 원칙은 소프트웨어 설계에서 중요한 가이드라인으로, 과도한 설계나 복잡한 논리를 피하고 간단한 해결책을 찾는 것을 권장한다.
 4. YAGNI 원칙
    * "You Aren’t Gonna Need It"이라는 원칙은 필요하지 않은 기능을 미리 작성하지 말라는 뜻으로, 불필요한 코드 생성을 막는 데 초점이 맞춘다.
 5. DRY 원칙
    * "Don't Repeat Yourself"라는 원칙은 비슷한 코드를 copy-and-paste 형태로 반복하지 말고 함수나 클래스의 형태로 모듈화하는 걸 이야기한다. 그래야 유지보수가 쉬워진다.

경험상 정말 잘 하는 개발자는 코드를 양산하기 보다는 불필요한 코드를 줄이고 단순화하는 특성(빼기의 미학)이 있다. 하지만 대부분의 개발자들은 코드를 양산하는데 집중을 하기 쉬운데 일반적으로 우리는 가산 편향에 빠져 있기 때문이다. 즉 문제 해결을 하려면 뭔가를 새로 추가해야 한다고 생각하기 쉽다는 거다.

잘 하지 못하는 개발자가 코드를 양산하는 이유는 다음과 같다. 잘 하는 프로덕트 매니저와 같이 일을 한다면 아래 이슈 중의 몇 가지는 피할 수 있다.

 1. 기능주의 사고방식
    * "많은 기능 = 좋은 코드"라는 착각에 빠져, 기능 추가에만 집중하는 경우가 많다.
 2. 단순화 기술 부족
    * 복잡한 문제를 단순화하는 기술과 경험이 부족하면, 더 많은 코드로 문제를 해결하려는 경향이 생긴다.
 3. 과잉 설계 (Overengineering)
    * 모든 가능성을 고려해서 너무 많은 구조와 패턴을 적용하려다 보면, 실제로 필요하지 않은 코드가 양산되며 이는 유지보수 문제로 이어진다.

더하기가 아닌 빼기의 미학에 대해 생각해보자. 스티브 잡스는 무언가를 더 추가하려는 유혹에 저항하는 것이야말로 훌륭한 디자인과 혁신의 핵심이라고 말했다. 진정으로 중요한 것에 집중하기 위해 불필요한 것들을 과감히 제거해야 한다는 거다. 스티브 잡스의 아래 문구로 글을 마무리하고자 한다.

"I'm as proud of many of the things we haven't done as the things we have done. Innovation is saying no to a thousand things."

구글 코딩 가이드라인을 보면 코드 가독성(Readability)을 강조한다. 코딩 주짓수 하지 말고 읽기 쉬운 코드를 작성하라는 건데 그래야 다른 개발자들 뿐만 아니라 본인이 본인의 코드를 나중에 볼 때 도움이 된다. 기본적으로 실리콘밸리에서는 개발자들의 이직이 워낙 잦기 때문에 유지 보수의 중요성에 대한 전반적인 인식이 더 있지 않나 싶다. 좋은 코드가 갖는 여러가지 원칙이 있겠지만 아래와 같은 것들을 들어볼 수 있을 듯 하다. <ol ><li>유지 보수성<ul ><li>코드가 단순할수록 이해하기 쉽고, 수정하거나 확장할 때 실수를 줄일 수 있다.</li><li>코드 리뷰, 디버깅, 팀 협업에서 단순한 코드는 더 효율적이다.</li></ul></li><li>복잡성의 비용<ul ><li>불필요하게 복잡한 코드는 버그를 유발하기 쉽고, 기능을 추가하거나 수정할 때 전체 시스템을 망칠 위험이 커진다</li><li>가독성이 떨어지면 개발자는 코드 이해에 더 많은 시간을 소비한다.</li></ul></li><li>KISS 원칙<ul ><li>"Keep It Simple, Stupid"라는 원칙은 소프트웨어 설계에서 중요한 가이드라인으로, 과도한 설계나 복잡한 논리를 피하고 간단한 해결책을 찾는 것을 권장한다.</li></ul></li><li>YAGNI 원칙<ul ><li>"You Aren’t Gonna Need It"이라는 원칙은 필요하지 않은 기능을 미리 작성하지 말라는 뜻으로, 불필요한 코드 생성을 막는 데 초점이 맞춘다.</li></ul></li><li>DRY 원칙<ul ><li>"Don't Repeat Yourself"라는 원칙은 비슷한 코드를 copy-and-paste 형태로 반복하지 말고 함수나 클래스의 형태로 모듈화하는 걸 이야기한다. 그래야 유지보수가 쉬워진다.</li></ul></li></ol> 경험상 정말 잘 하는 개발자는 코드를 양산하기 보다는 불필요한 코드를 줄이고 단순화하는 특성(빼기의 미학)이 있다. 하지만 대부분의 개발자들은 코드를 양산하는데 집중을 하기 쉬운데 일반적으로 우리는 가산 편향에 빠져 있기 때문이다. 즉 문제 해결을 하려면 뭔가를 새로 추가해야 한다고 생각하기 쉽다는 거다. 잘 하지 못하는 개발자가 코드를 양산하는 이유는 다음과 같다. 잘 하는 프로덕트 매니저와 같이 일을 한다면 아래 이슈 중의 몇 가지는 피할 수 있다. <ol ><li>기능주의 사고방식<ul ><li>"많은 기능 = 좋은 코드"라는 착각에 빠져, 기능 추가에만 집중하는 경우가 많다.</li></ul></li><li>단순화 기술 부족<ul ><li>복잡한 문제를 단순화하는 기술과 경험이 부족하면, 더 많은 코드로 문제를 해결하려는 경향이 생긴다.</li></ul></li><li>과잉 설계 (Overengineering)<ul ><li>모든 가능성을 고려해서 너무 많은 구조와 패턴을 적용하려다 보면, 실제로 필요하지 않은 코드가 양산되며 이는 유지보수 문제로 이어진다.</li></ul></li></ol> 더하기가 아닌 빼기의 미학에 대해 생각해보자. 스티브 잡스는 무언가를 더 추가하려는 유혹에 저항하는 것이야말로 훌륭한 디자인과 혁신의 핵심이라고 말했다. 진정으로 중요한 것에 집중하기 위해 불필요한 것들을 과감히 제거해야 한다는 거다. 스티브 잡스의 아래 문구로 글을 마무리하고자 한다. "I'm as proud of many of the things we haven't done as the things we have done. Innovation is saying no to a thousand things."

코드 가독성과 빼기의 미학

군대에 다녀와서 컴퓨터 공부를 처음 시작할 때 어떻게 해야 할지를 몰랐습니다.

다시 공부한다면 탑다운 방식으로

군대에 다녀와서 컴퓨터 공부를 처음 시작할 때 어떻게 해야 할지를 몰랐습니다.
에라 모르겠다. 처음부터 차근차근 해보자. 010101 부터.

C언어도 아니고 모리스 마노 교수의 디지털 논리와 컴퓨터 설계를 읽기 시작했습니다.
부울 연산이 뭔지, NAND 게이트가 뭔지부터 시작했던 것입니다.

그리고 C언어도 공부하고 자료구조와 알고리즘도 공부하고…
컴퓨터 구조, 운영체제, 네트워킹, 데이터베이스.
그렇게 차근 차근 공부했습니다.

지금 생각하면 좋은 방법이었는지 의문이 듭니다.
그냥 간단한 웹 개발 같은 걸로 시작했으면 어땠을까?
코딩을 잘하고 싶으면 코딩을 많이 해봐야지.
그러다 궁금한 게 생기면 하나씩 파고들어가는 탑다운 방식으로.

실제로 이렇게 공부한 친구들을 회사에서 많이 만났습니다.
운영체제 내부는 거의 아는 게 없지만…
앱 개발이나 서버 개발은 저보다 훨씬 잘했습니다.

이런 걸 보면서 난 그동안 뭘 한 거지? 하는 자괴감이 들곤 했습니다.

다시 대학생으로 돌아간다면 탑다운 방식으로 공부해 보고 싶습니다.
기술이 금세 바뀌어 버리니까.
요즘 새로운 기술을 공부할 때는 저도 이렇게 탑다운 방식으로 하는 것 같기도 합니다.
모르는 게 생기면 ChatGPT에게 물어보면서 점점 깊이 내려가는 식으로.

이렇게 공부할 때는 주의할 점도 있습니다.
조금 어려워진다 싶으면 ‘이딴 건 몰라도 돼’ 하는 마음이 올라온다는 것입니다.
이런 마음만 잘 다스릴 수 있으면… 탑다운 어프로치도 좋은 학습 전략인 것 같습니다.

https://jeho.page/essay/2024/12/10/top-down-approach.html

군대에 다녀와서 컴퓨터 공부를 처음 시작할 때 어떻게 해야 할지를 몰랐습니다. 에라 모르겠다. 처음부터 차근차근 해보자. 010101 부터. C언어도 아니고 모리스 마노 교수의 디지털 논리와 컴퓨터 설계를 읽기 시작했습니다. 부울 연산이 뭔지, NAND 게이트가 뭔지부터 시작했던 것입니다. 그리고 C언어도 공부하고 자료구조와 알고리즘도 공부하고… 컴퓨터 구조, 운영체제, 네트워킹, 데이터베이스. 그렇게 차근 차근 공부했습니다. 지금 생각하면 좋은 방법이었는지 의문이 듭니다. 그냥 간단한 웹 개발 같은 걸로 시작했으면 어땠을까?코딩을 잘하고 싶으면 코딩을 많이 해봐야지. 그러다 궁금한 게 생기면 하나씩 파고들어가는 탑다운 방식으로. 실제로 이렇게 공부한 친구들을 회사에서 많이 만났습니다. 운영체제 내부는 거의 아는 게 없지만… 앱 개발이나 서버 개발은 저보다 훨씬 잘했습니다. 이런 걸 보면서 난 그동안 뭘 한 거지? 하는 자괴감이 들곤 했습니다. 다시 대학생으로 돌아간다면 탑다운 방식으로 공부해 보고 싶습니다. 기술이 금세 바뀌어 버리니까. 요즘 새로운 기술을 공부할 때는 저도 이렇게 탑다운 방식으로 하는 것 같기도 합니다. 모르는 게 생기면 ChatGPT에게 물어보면서 점점 깊이 내려가는 식으로. 이렇게 공부할 때는 주의할 점도 있습니다. 조금 어려워진다 싶으면 ‘이딴 건 몰라도 돼’ 하는 마음이 올라온다는 것입니다. 이런 마음만 잘 다스릴 수 있으면… 탑다운 어프로치도 좋은 학습 전략인 것 같습니다. https://jeho.page/essay/2024/12/10/top-down-approach.html

K리그 프로그래머

차세대 자바스크립트 런타임이자 올인원 개발 키트인 Bun에 대한 국내 첫 기술서인 헬로 Bun을 이제 eBook으로도 만나 보실 수 있습니다!

사실 eBook 출간은 아이러니하게도 저자인 제가 제일 손꼽아 기다렸는데요 😅 해외에 있어서 정적 저는 종이 책을 손에 아직 쥐어보지 못했거든요 😭 선편으로 부쳤다는데 캐나다 우체국이 현재 파업 중이라서 언제 도착할지 모르겠습니다 ㅋㅋ

저처럼 종이 책을 읽기 어려운 분들께 eBook이 좋은 대안이 되었으면 좋겠네요! 많은 관심 부탁드립니다 🙏

📕 YES24: https://www.yes24.com/Product/Goods/134021042
📗 교보문고: https://product.kyobobook.co.kr/detail/S000214450265
📘 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ISBN=9791193926710

차세대 자바스크립트 런타임이자 올인원 개발 키트인 Bun에 대한 국내 첫 기술서인 헬로 Bun을 이제 eBook으로도 만나 보실 수 있습니다! 사실 eBook 출간은 아이러니하게도 저자인 제가 제일 손꼽아 기다렸는데요 😅 해외에 있어서 정적 저는 종이 책을 손에 아직 쥐어보지 못했거든요 😭 선편으로 부쳤다는데 캐나다 우체국이 현재 파업 중이라서 언제 도착할지 모르겠습니다 ㅋㅋ 저처럼 종이 책을 읽기 어려운 분들께 eBook이 좋은 대안이 되었으면 좋겠네요! 많은 관심 부탁드립니다 🙏 📕 YES24: https://www.yes24.com/Product/Goods/134021042 📗 교보문고: https://product.kyobobook.co.kr/detail/S000214450265 📘 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ISBN=9791193926710

헬로 Bun 🥟 eBook 출간 소식 📨

1
명심하라. 설득은, 설득이 필요한 순간에 꺼내들면 대부분 실패한다.

2
설득이 필요하지 않은 순간에 설득을 차곡차곡 쌓아놓으면, 언젠가 그것이 꼭 필요해질 때가 온다.

3
설득을 쌓아놓았다가 설득이 필요한 순간에 꺼내 쓰기만 하면 된다.

4
당신을 팔아야 할 때도 마찬가지다.

5
누군가에게 간절히 당신을 팔아야 할 때는, 아무리 영업을 잘해도 당신은 팔려나가지 않는다.

6
평소에 더 많은 사람들의 장바구니에 당신이 담겨 있어야 한다.

7
그러다가 당신이 간절히 필요해질 때 그들은 마침내 구매 버튼을 누른다.

#싸우지않고이기는기술

1 명심하라. 설득은, 설득이 필요한 순간에 꺼내들면 대부분 실패한다. ​ ​2 설득이 필요하지 않은 순간에 설득을 차곡차곡 쌓아놓으면, 언젠가 그것이 꼭 필요해질 때가 온다. ​ ​3 설득을 쌓아놓았다가 설득이 필요한 순간에 꺼내 쓰기만 하면 된다. ​ ​4 당신을 팔아야 할 때도 마찬가지다. ​ ​5 누군가에게 간절히 당신을 팔아야 할 때는, 아무리 영업을 잘해도 당신은 팔려나가지 않는다. ​ ​6 평소에 더 많은 사람들의 장바구니에 당신이 담겨 있어야 한다. ​ ​7 그러다가 당신이 간절히 필요해질 때 그들은 마침내 구매 버튼을 누른다. #싸우지않고이기는기술

< 당신을 팔고 싶다면, 평소에 장바구니에 담겨라 >

지금 AI와 코딩하는 일에 대한 의견은 약간 그런거 같다. 게임 업계에서 자동사냥이 시작되었던 때, 자동사냥에 대한 업계인들의 반응.

처음 자동사냥이 시작되었을 때, 그게 게임이냐라거나 핵 쓰는거나 다름없다 막 그랬지만, 결국 자동사냥 게임은 많은 일반인(?)들의 선택에 의해 게임 장르의 한 축이 되었다.

게임의 특성은 여러가지가 있지만, 수집 욕구가 큰 축을 차지하는데 자동사냥은 그걸 쉽게 만들어 준 것. 업계 고인물이나 골수 게이머들은 인정하지 않았지만, 결과적으로 더 많은 사람들이 게임을 즐길 수 있게 됨으로써 게임의 저변이 넓어졌다.

프로그래밍, 코딩도 마찬가지로, 코딩의 즐거움과 유용함에는 여러가지가 있지만 그중 가장 큰 축은 소프트웨어적으로 작동하는 무언가를 창작해내는 것에 있는데, 이를 쉽게 이룰 수 있게 해 준 것.

고인물들에게는 쓰레기 코드만 양산되는거 아니냐 싶겠지만, 결과적으로 더 많은 사람들이 소프트웨어를 만들 수 있게 됨으로써 저변이 넓어질 것으로 생각된다.

그리고 이건 생성형 AI로 혁신되는 거의 모든 업계에 해당되는 말이지 않을까 싶다.

지금 AI와 코딩하는 일에 대한 의견은 약간 그런거 같다. 게임 업계에서 자동사냥이 시작되었던 때, 자동사냥에 대한 업계인들의 반응. 처음 자동사냥이 시작되었을 때, 그게 게임이냐라거나 핵 쓰는거나 다름없다 막 그랬지만, 결국 자동사냥 게임은 많은 일반인(?)들의 선택에 의해 게임 장르의 한 축이 되었다. 게임의 특성은 여러가지가 있지만, 수집 욕구가 큰 축을 차지하는데 자동사냥은 그걸 쉽게 만들어 준 것. 업계 고인물이나 골수 게이머들은 인정하지 않았지만, 결과적으로 더 많은 사람들이 게임을 즐길 수 있게 됨으로써 게임의 저변이 넓어졌다. 프로그래밍, 코딩도 마찬가지로, 코딩의 즐거움과 유용함에는 여러가지가 있지만 그중 가장 큰 축은 소프트웨어적으로 작동하는 무언가를 창작해내는 것에 있는데, 이를 쉽게 이룰 수 있게 해 준 것. 고인물들에게는 쓰레기 코드만 양산되는거 아니냐 싶겠지만, 결과적으로 더 많은 사람들이 소프트웨어를 만들 수 있게 됨으로써 저변이 넓어질 것으로 생각된다. 그리고 이건 생성형 AI로 혁신되는 거의 모든 업계에 해당되는 말이지 않을까 싶다.

지금 AI와 코딩하는 일에 대한 의견은 약간 그런거 같다. 게임 

직장에서 처음으로 데이터 분석 프로젝트를 시작하게 된 당신.

바로 데이터 분석에 뛰어들기 전,
아래의 체크리스트를 먼저 확인해보세요.

당신의 데이터 분석이 더욱 가치있어질 거에요.

직장에서 처음으로 데이터 분석 프로젝트를 시작하게 된 당신. 바로 데이터 분석에 뛰어들기 전,아래의 체크리스트를 먼저 확인해보세요. 당신의 데이터 분석이 더욱 가치있어질 거에요.

데이터 분석 전 체크해야 하는 체크리스트 6가지

[Leadership] 유능한 직원은 떠나고 무능한 상사만 남는 이유

‘어떻게 저렇게 무능한 사람이 임원 자리에 앉아있는 걸까?’ 직장생활의 풀리지 않는 미스터리다. 회사 뿐 아니라 정부, 종교단체, 학교 등 근무지에 상관없이 그리고 시대와 동서양 문화권을 막론하고 보편적인 현상이다. 유능한 직원은 떠나고 무능한 상사만 남는 이유는 무엇일까.

1969년 미국의 교육학자 로런스 피터와 레이먼드 헐은 정치, 법률, 교육, 산업 등 모든 조직에서 시간이 지날수록 무능한 관리자들이 넘쳐나는 현상을 발견했다. 이를 ‘피터의 법칙(Peter Principle)’이라고 하는데 ‘승진 후 새로운 업무를 수행할 때 과거보다 일 처리 능력이 떨어지는 것은 자연스러운 현상’이라는 주장이다.

예를 들어 보자. 업무 성과가 탁월한 김 대리는 팀장으로 특진했다. 그러나 기쁨도 잠시 ‘아직도 빛나는 유능한 실무능력’이 문제가 된다. 자신의 뛰어난 실무능력을 팀원들에게 효율적으로 전수하면서 팀원들을 격려하고 동기부여를 하는 동시에 리더로서 해야 할 일에 전념해야 하지만, 특진까지 했으니 짧은 시간에 뛰어난 실적을 보여 자신의 능력을 입증하려 한다.

그러나 생각보다 좋은 결과가 나오지 않으니 팀원들을 격려하기보다는, 자신에 비해 업무능력이 떨어지는 팀원들을 비난하며 질책한다. 결국 자신이 직접 나서 실적을 채우려 실무까지 처리한다.

권한 위임을 하는 것에 대해서는 불안을 느낀다. 통제와 관리, 신뢰와 위임 사이에서 끊임없이 갈등만 한다. 팀장 본연의 업무가 무엇인지 깨닫지도 못한 상황에서 무엇을 어떻게 해야 할지 답답하기만 하다. 팀원들은 팀장이 자기들을 믿지 못해 실무적인 일까지 나서서 한다는 생각에 의욕을 잃어가고, 그러는 사이에 팀 내에서는 웃음소리가 사라져 버린다.

켈리 슈 예일대 경영대학원 교수는 높은 성과를 인정받아 승진한 관리자들이 리더로서 새로운 업무도 잘 수행하는지 알아보기 위해 131개 기업을 분석했다. 조사 결과는 피터의 법칙을 그대로 보여주었다. 주로 1등 영업사원 출신 관리자들의 실적이 최하위에 머물렀다.

이에 대해 켈리 슈는 “최고의 엔지니어가 창업한다고 해서 반드시 최고의 경영자가 되는 것은 아니며, 이는 최고의 엔지니어가 되는 것과 엔지니어를 잘 관리하는 리더가 되는 것은 다른 역량이기 때문”이라고 설명했다. 즉 리더는 성과를 내는 추진력 뿐만 아니라 팀원을 독려하고 시너지를 만드는 관리 능력이 매우 중요하다는 것이다.

조직의 리더는 대부분 실무능력이 뛰어난 사람들이다. 성과가 뛰어난 사람이 승진하는 것은 공정하다고 인식되기 때문이다. 여기에는 실무를 잘하면 자신의 담당 업무뿐 아니라 부하직원의 교육과 관리 등 리더의 역할도 잘 해낼 거라는 기대가 포함되어 있다.

그러나 실제로 리더의 과거 업무 성과는 리더십과 직접적인 연관성이 없다. 과거의 직무 수행능력을 승진 후의 직책에 필요한 능력과 같은 것으로 생각하는 판단의 오류는 승진할수록 되레 무능해지는 상사들을 만드는 아이러니를 낳는다.

그런데 피터의 법칙이 경고하는 진짜 위험은 ‘유능한 직원들이 조직을 떠나게 된다’라는 사실이다. 무능해진 상사들에게 자리를 지키는 것은 가장 중요한 문제다. 이들의 눈에 창의적 사고로 새로운 도전을 시도하는 유능한 직원은 질서를 어지럽히는 존재일 뿐이다.

따라서 창의적이고 도전적인 인재들은 오히려 승진에서 제외되기 쉽고 결국 스스로 버티지 못하고 떠나게 된다. 피터의 법칙이 관료적 조직에서 더욱 강하게 나타나는 건 바로 이런 속성 때문이다.

미국의 만화 <딜버트(Dilbert)>는 65개국 2000여 개의 신문에 연재된 세계적인 콘텐츠다. 엔지니어 딜버트의 직장생활을 그린 3~4컷의 만화는 경영진의 무능과 상사의 횡포, 권위주의적 계층구조를 신랄하게 풍자하는 내용으로 선풍적인 인기를 끌었다.

열광한 독자들은 작가 스콧 애덤스에게 자신들의 직장생활 이야기를 보냈는데 이는 고스란히 만화의 소재로 활용되었다. 작가는 열렬한 반응에 힘입어 독자들을 대상으로 ‘어떤 관행이 직원들을 가장 화나게 하는가’라는 설문조사를 했다. 가장 많은 표를 얻은 것은 ‘경영진으로 승진한 멍청이’였다.

이 내용은 만화 <딜버트의 법칙>으로 출간됐고 100만 부 이상이 팔렸다. 여기서 ‘무능력하고 비효율적인 직원일수록 경쟁 단계를 거치지 않고 곧바로 승진하는 현상’을 뜻하는 딜버트의 법칙이 탄생했다.

딜버트의 법칙이 작용하는 조직은 변화를 두려워하고 현실에 안주하려는 경향이 강하다. 혁신을 외치지만 혁신을 시도하지 않는다. 이런 풍토에 어울리는 사람이 바로 무능한 사람이다. 만화에서는 무능하지만 승진하고 싶은 사람들에게 “상사에게 잘 보이면 그만이고 너무 열심히 일하면 오히려 곤란하다”라고 조언한다.

피터의 법칙은 조직이 리더의 자질을 제대로 평가하지 않을 때 무능한 리더가 조직을 가득 채운다고 경고한다. 무능해진 리더들은 자신의 결점을 보완하고 리더로서 필요한 자질과 지식을 습득하기보다는 조직에 딜버트의 법칙을 만연하게 만든다.

무능한 상사들은 일에 대한 열정을 가진 직원이 오히려 껄끄럽다. 그래서 의도적으로 똑똑하지 않은 직원을 승진시켜 옆에 두는 최고경영자도 실제 현실에서 존재한다. 무능한 사람이 고위직으로 승진하는 꽤 흔한 이유다. 만년 저성과 조직은 이렇게 만들어진다.

‘어떻게 저렇게 무능한 사람이 임원 자리에 앉아있는 걸까?’ 직장생활의 풀리지 않는 미스터리다. 회사 뿐 아니라 정부, 종교단체, 학교 등 근무지에 상관없이 그리고 시대와 동서양 문화권을 막론하고 보편적인 현상이다. 유능한 직원은 떠나고 무능한 상사만 남는 이유는 무엇일까. 1969년 미국의 교육학자 로런스 피터와 레이먼드 헐은 정치, 법률, 교육, 산업 등 모든 조직에서 시간이 지날수록 무능한 관리자들이 넘쳐나는 현상을 발견했다. 이를 ‘피터의 법칙(Peter Principle)’이라고 하는데 ‘승진 후 새로운 업무를 수행할 때 과거보다 일 처리 능력이 떨어지는 것은 자연스러운 현상’이라는 주장이다. 예를 들어 보자. 업무 성과가 탁월한 김 대리는 팀장으로 특진했다. 그러나 기쁨도 잠시 ‘아직도 빛나는 유능한 실무능력’이 문제가 된다. 자신의 뛰어난 실무능력을 팀원들에게 효율적으로 전수하면서 팀원들을 격려하고 동기부여를 하는 동시에 리더로서 해야 할 일에 전념해야 하지만, 특진까지 했으니 짧은 시간에 뛰어난 실적을 보여 자신의 능력을 입증하려 한다. 그러나 생각보다 좋은 결과가 나오지 않으니 팀원들을 격려하기보다는, 자신에 비해 업무능력이 떨어지는 팀원들을 비난하며 질책한다. 결국 자신이 직접 나서 실적을 채우려 실무까지 처리한다. 권한 위임을 하는 것에 대해서는 불안을 느낀다. 통제와 관리, 신뢰와 위임 사이에서 끊임없이 갈등만 한다. 팀장 본연의 업무가 무엇인지 깨닫지도 못한 상황에서 무엇을 어떻게 해야 할지 답답하기만 하다. 팀원들은 팀장이 자기들을 믿지 못해 실무적인 일까지 나서서 한다는 생각에 의욕을 잃어가고, 그러는 사이에 팀 내에서는 웃음소리가 사라져 버린다. 켈리 슈 예일대 경영대학원 교수는 높은 성과를 인정받아 승진한 관리자들이 리더로서 새로운 업무도 잘 수행하는지 알아보기 위해 131개 기업을 분석했다. 조사 결과는 피터의 법칙을 그대로 보여주었다. 주로 1등 영업사원 출신 관리자들의 실적이 최하위에 머물렀다. 이에 대해 켈리 슈는 “최고의 엔지니어가 창업한다고 해서 반드시 최고의 경영자가 되는 것은 아니며, 이는 최고의 엔지니어가 되는 것과 엔지니어를 잘 관리하는 리더가 되는 것은 다른 역량이기 때문”이라고 설명했다. 즉 리더는 성과를 내는 추진력 뿐만 아니라 팀원을 독려하고 시너지를 만드는 관리 능력이 매우 중요하다는 것이다. 조직의 리더는 대부분 실무능력이 뛰어난 사람들이다. 성과가 뛰어난 사람이 승진하는 것은 공정하다고 인식되기 때문이다. 여기에는 실무를 잘하면 자신의 담당 업무뿐 아니라 부하직원의 교육과 관리 등 리더의 역할도 잘 해낼 거라는 기대가 포함되어 있다. 그러나 실제로 리더의 과거 업무 성과는 리더십과 직접적인 연관성이 없다. 과거의 직무 수행능력을 승진 후의 직책에 필요한 능력과 같은 것으로 생각하는 판단의 오류는 승진할수록 되레 무능해지는 상사들을 만드는 아이러니를 낳는다. 그런데 피터의 법칙이 경고하는 진짜 위험은 ‘유능한 직원들이 조직을 떠나게 된다’라는 사실이다. 무능해진 상사들에게 자리를 지키는 것은 가장 중요한 문제다. 이들의 눈에 창의적 사고로 새로운 도전을 시도하는 유능한 직원은 질서를 어지럽히는 존재일 뿐이다. 따라서 창의적이고 도전적인 인재들은 오히려 승진에서 제외되기 쉽고 결국 스스로 버티지 못하고 떠나게 된다. 피터의 법칙이 관료적 조직에서 더욱 강하게 나타나는 건 바로 이런 속성 때문이다. 미국의 만화 &lt;딜버트(Dilbert)&gt;는 65개국 2000여 개의 신문에 연재된 세계적인 콘텐츠다. 엔지니어 딜버트의 직장생활을 그린 3~4컷의 만화는 경영진의 무능과 상사의 횡포, 권위주의적 계층구조를 신랄하게 풍자하는 내용으로 선풍적인 인기를 끌었다. 열광한 독자들은 작가 스콧 애덤스에게 자신들의 직장생활 이야기를 보냈는데 이는 고스란히 만화의 소재로 활용되었다. 작가는 열렬한 반응에 힘입어 독자들을 대상으로 ‘어떤 관행이 직원들을 가장 화나게 하는가’라는 설문조사를 했다. 가장 많은 표를 얻은 것은 ‘경영진으로 승진한 멍청이’였다. 이 내용은 만화 &lt;딜버트의 법칙&gt;으로 출간됐고 100만 부 이상이 팔렸다. 여기서 ‘무능력하고 비효율적인 직원일수록 경쟁 단계를 거치지 않고 곧바로 승진하는 현상’을 뜻하는 딜버트의 법칙이 탄생했다. 딜버트의 법칙이 작용하는 조직은 변화를 두려워하고 현실에 안주하려는 경향이 강하다. 혁신을 외치지만 혁신을 시도하지 않는다. 이런 풍토에 어울리는 사람이 바로 무능한 사람이다. 만화에서는 무능하지만 승진하고 싶은 사람들에게 “상사에게 잘 보이면 그만이고 너무 열심히 일하면 오히려 곤란하다”라고 조언한다. 피터의 법칙은 조직이 리더의 자질을 제대로 평가하지 않을 때 무능한 리더가 조직을 가득 채운다고 경고한다. 무능해진 리더들은 자신의 결점을 보완하고 리더로서 필요한 자질과 지식을 습득하기보다는 조직에 딜버트의 법칙을 만연하게 만든다. 무능한 상사들은 일에 대한 열정을 가진 직원이 오히려 껄끄럽다. 그래서 의도적으로 똑똑하지 않은 직원을 승진시켜 옆에 두는 최고경영자도 실제 현실에서 존재한다. 무능한 사람이 고위직으로 승진하는 꽤 흔한 이유다. 만년 저성과 조직은 이렇게 만들어진다.

www.chiefexe.com

‘어떻게 저렇게 무능한 사람이 임원 자리에 앉아있는 걸까?’ 직장

가장 많이 여쭤보시는 질문 중 하나입니다. 채용 담당자 시절과 현재 코칭을 많이 하며 느낀 제 기준입니다.

👉 총 45-55p 사이
👉 서비스 3~4개
👉 프로젝트 6~7개, 장당 7-8p
👉 프로젝트 = 서비스 아님
👉 서비스 하나당 n개의 프로젝트가 나올 수 있음
👉 한 프로젝트 구성
- 프로젝트 배경 > 문제인식 및 정의 > 가설 > 솔루션 > 결과해석 > 레슨런
👉 문제 해결력을 잘 보여줄 수 있는 중요도 순서로 배치: 최신순 아니어도 됨, 같은 서비스가 붙어 있지 않아도 됨
👉 JD상 필요시 장표 후반에 Appendix 추가 후 BX, 개발, 그래픽 관련 작업들 추가

가장 많이 여쭤보시는 질문 중 하나입니다. 채용 담당자 시절과 현재 코칭을 많이 하며 느낀 제 기준입니다. 👉 총 45-55p 사이👉 서비스 3~4개👉 프로젝트 6~7개, 장당 7-8p👉 프로젝트 = 서비스 아님👉 서비스 하나당 n개의 프로젝트가 나올 수 있음👉 한 프로젝트 구성- 프로젝트 배경 &gt; 문제인식 및 정의 &gt; 가설 &gt; 솔루션 &gt; 결과해석 &gt; 레슨런👉 문제 해결력을 잘 보여줄 수 있는 중요도 순서로 배치: 최신순 아니어도 됨, 같은 서비스가 붙어 있지 않아도 됨👉 JD상 필요시 장표 후반에 Appendix 추가 후 BX, 개발, 그래픽 관련 작업들 추가

✋적당한 문제 해결 포트폴리오 장수는?

Findings in our latest study show that the quality of code written with GitHub Copilot is significantly more functional, readable, reliable, maintainable, and concise.

Does GitHub Copilot improve code quality? Here’s what the data says

GitHub에서 Copilot의 효과를 파악하기 위해 실험을 했습니다.

5년 이상의 개발자 202명을 모집 후 절반은 GitHub Copilot을 쓰고 절반은 AI도구를 일체 사용하지 않은 채 웹 서버의 API 엔드포인트를 작성하도록 한 뒤 준비된 단위 테스트의 통과 여부와 전문가 검토를 통해서 코드를 평가했습니다.

연구 결과에 따르면 GitHub Copilot을 사용한 코드가 단위테스트를 통과할 가능성이 56% 더 높았고 가독성은 1~3% 좋고 유지보수 면에서도 쉬운것으로 평가 받았다고 합니다.

https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/

GitHub에서 Copilot의 효과를 파악하기 위해 실험을 했습니다. 5년 이상의 개발자 202명을 모집 후 절반은 GitHub Copilot을 쓰고 절반은 AI도구를 일체 사용하지 않은 채 웹 서버의 API 엔드포인트를 작성하도록 한 뒤 준비된 단위 테스트의 통과 여부와 전문가 검토를 통해서 코드를 평가했습니다. 연구 결과에 따르면 GitHub Copilot을 사용한 코드가 단위테스트를 통과할 가능성이 56% 더 높았고 가독성은 1~3% 좋고 유지보수 면에서도 쉬운것으로 평가 받았다고 합니다. https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/

The GitHub Blog

GitHub에서 Copilot의 효과를 파악하기 위해 실험을 했습

Generate interactive flashcards from your notes using models from OpenAI (ChatGPT), Google (Gemini), Ollama (local LLMs), and more. Or manually create your own to use with the quiz UI. - ECuiDev/ob...

GitHub - ECuiDev/obsidian-quiz-generator: Generate interactive flashcards from your notes using models from OpenAI (ChatGPT), Google (Gemini), Ollama (local LLMs), and more. Or manually create your own to use with the quiz UI.

노트에 열심히 적어놓고 나중에 보면 무슨 내용인지 기억이 안 날 때가 많습니다. 복습 용도로 AI가 퀴즈를 내주면 좋겠다고 생각했었는데, 구글링하다가 찾은 Quiz Generator 플러그인이 제가 딱 생각한 역할을 하는 플러그인이여서 소개드립니다.

이 플러그인은 여러분이 작성한 노트나 폴더를 넣으면 알아서 맞춤형 퀴즈를 만들어줍니다. 거의 모든 주요 AI 제공업체의 모델을 지원하는데요, OpenAI, Google, Anthropic, Perplexity, Mistral, Cohere, Ollama 등이 포함돼 있습니다. 다국어도 지원하는데 그 중 한국어도 사용 가능합니다.

설치는 옵시디언 커뮤니티 플러그인에서 Quiz Generator를 검색해서 설치하시고, 설정에 들어가 Provider와 API Key를 입력하고 저장하면 됩니다. 경험상 Provider는 OpenAI로 설정해서 사용하는 걸 추천드립니다. Claude 3.5도 써봤는데 일부 기능이 잘 안 되더라구요.
설정이 끝나면 왼쪽 사이드바에 뇌 모양 아이콘이 생기는데, 이걸 클릭해서 원하는 노트나 폴더를 선택하고 하단의 퀴즈 생성 버튼을 누르면 잠시 후에 퀴즈를 만들어줍니다.

최근에 HTTP 관련 노트로 퀴즈를 만들어봤는데요, 당시엔 완벽하게 공부했다고 생각했지만 퀴즈를 풀어보니 절반 이상을 틀리더라구요. 복습의 중요성을 다시 한 번 깨달았습니다ㅎ 그 때부터 이 플러그인으로 옛날 노트들의 퀴즈를 만들어서 풀어보고 있는데 확실히 도움이 많이 되는 것 같아요.

플러그인 깃허브 링크는 아래에 있습니다. 링크에 데모 동영상도 있으니 써보기 전에 한 번 느낌을 보시고 설치해 보시는 것도 좋습니다.

https://github.com/ECuiDev/obsidian-quiz-generator

노트에 열심히 적어놓고 나중에 보면 무슨 내용인지 기억이 안 날 때가 많습니다. 복습 용도로 AI가 퀴즈를 내주면 좋겠다고 생각했었는데, 구글링하다가 찾은 Quiz Generator 플러그인이 제가 딱 생각한 역할을 하는 플러그인이여서 소개드립니다. 이 플러그인은 여러분이 작성한 노트나 폴더를 넣으면 알아서 맞춤형 퀴즈를 만들어줍니다. 거의 모든 주요 AI 제공업체의 모델을 지원하는데요, OpenAI, Google, Anthropic, Perplexity, Mistral, Cohere, Ollama 등이 포함돼 있습니다. 다국어도 지원하는데 그 중 한국어도 사용 가능합니다. 설치는 옵시디언 커뮤니티 플러그인에서 Quiz Generator를 검색해서 설치하시고, 설정에 들어가 Provider와 API Key를 입력하고 저장하면 됩니다. 경험상 Provider는 OpenAI로 설정해서 사용하는 걸 추천드립니다. Claude 3.5도 써봤는데 일부 기능이 잘 안 되더라구요.설정이 끝나면 왼쪽 사이드바에 뇌 모양 아이콘이 생기는데, 이걸 클릭해서 원하는 노트나 폴더를 선택하고 하단의 퀴즈 생성 버튼을 누르면 잠시 후에 퀴즈를 만들어줍니다. 최근에 HTTP 관련 노트로 퀴즈를 만들어봤는데요, 당시엔 완벽하게 공부했다고 생각했지만 퀴즈를 풀어보니 절반 이상을 틀리더라구요. 복습의 중요성을 다시 한 번 깨달았습니다ㅎ 그 때부터 이 플러그인으로 옛날 노트들의 퀴즈를 만들어서 풀어보고 있는데 확실히 도움이 많이 되는 것 같아요. 플러그인 깃허브 링크는 아래에 있습니다. 링크에 데모 동영상도 있으니 써보기 전에 한 번 느낌을 보시고 설치해 보시는 것도&nbsp;좋습니다. https://github.com/ECuiDev/obsidian-quiz-generator

한국경영원인재개발원 spring fullstack

양정연

농협중앙회 사업기획, 서비스 개발

염경선

농협중앙회와 농협경제지주에서 중장기 전략, 디지털 혁신, 조직 등을 담당하였습니다.
현재는 신사업 서비스 기획, 개발, 투자 등을 담당하고 있습니다.

아티스시스템 백엔드 개발자

AI로 맞춤형 퀴즈를 만들어주는 옵시디언 플러그인

- 아기상어 키즈 월드 앱 어드민, 웹뷰 페이지 프론트엔드 개발 리딩
- Collavate, Jira를 대체하는 백오피스 개발
- 핑크퐁 통합 회원 인증 서비스 개발

프론트엔드 개발자

- B마트, 배민스토어, 배민 주문 도메인 개발
- 전국별미 프론트엔드 리뷰 기능 개발


컴퓨터공학과

김하림

블로그

깃허브

UX와 DX 개선을 좋아하는 FE 개발자입니다. 오픈소스에 종종 기여하고 있습니다.
#개발자 #프론트엔드 #소프트웨어엔지니어

AI로 맞춤형 퀴즈를 만들어주는 옵시디언 플러그인

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필