"백문이 불여일타"라는 말이 있습니다. 백 번 듣는 것보다 한 번 직접 해보는 것이 낫다는 뜻인데요. 개발 공부에서도 실습이 중요하지만, 무작정 코드를 따라 치는 것은 비효율적입니다.단순 타이핑은 기계적인 반복일 뿐, 생각할 시간이 부족합니다. 타이핑을 하면서도 뇌는 적극적으로 학습하지 않아 코드를 이해하는 듯한 착각에 빠지기 쉽습니다. 따라서, 단순 따라 치기에서 벗어나 더 효과적인 학습 방법을 찾아야 하는데요

✅ 효율적인 개발 공부법
1. 요구사항 정리
코드를 작성하기 전에,
 * "이 코드가 해결해야 할 문제는 무엇인가?"
 * "어떤 입력을 받고, 어떤 출력을 만들어야 하는가?"
이런식으로 요구사항을 명확하게 정리하면 불필요한 시행착오를 줄일 수 있습니다.

2. 플로우 차트 & 도식화를 활용
코드의 실행 흐름을 시각적으로 표현하면 이해가 쉬워집니다.
 * 플로우 차트(Flowchart) : 코드의 동작 흐름을 한눈에 파악 가능
 * 시퀀스 다이어그램(Sequence Diagram) : 여러 요소가 어떻게 상호작용하는지 표현
도식화의 가장 큰 장점은 "메타인지" 입니다. 내가 무엇을 알고, 무엇을 모르는지 메타인지가 향상됩니다.

3. 코드 변형 & 리팩토링
 * "이 부분을 다르게 하면 어떤 결과가 나올까?"
 * "이 기능을 다른 방식으로 구현할 수 있을까?"
코드를 직접 수정하고 테스트하면서 학습하면 진짜 실력이 됩니다. 단순 실행에서 벗어나 깊이 있는 학습이 가능합니다.

결론
따라서 요구사항 정리 → 플로우 차트 작성 → 코드 변경 및 & 리팩토링 의 학습법을 추천합니다. 이 과정을 통해 단순 타이핑이 아니라 문제를 해결하는 사고 과정을 활성화 할 수 있습니다. 그리고 메타인지(내가 제대로 이해하고 있는지 점검하는 과정)를 거쳐 장기 기억에 남게 됩니다.
혹시나 무작정 따라 치는 학습법을 하고 계셨다면, 스스로 사고하며 학습하는 방식으로 바꿔 보시기를 추천드립니다 :)

"백문이 불여일타"라는 말이 있습니다. 백 번 듣는 것보다 한 번 직접 해보는 것이 낫다는 뜻인데요. 개발 공부에서도 실습이 중요하지만, 무작정 코드를 따라 치는 것은 비효율적입니다.단순 타이핑은 기계적인 반복일 뿐, 생각할 시간이 부족합니다. 타이핑을 하면서도 뇌는 적극적으로 학습하지 않아 코드를 이해하는 듯한 착각에 빠지기 쉽습니다. 따라서, 단순 따라 치기에서 벗어나 더 효과적인 학습 방법을 찾아야 하는데요 ✅ 효율적인 개발 공부법1. 요구사항 정리코드를 작성하기 전에,<ul ><li>"이 코드가 해결해야 할 문제는 무엇인가?"</li><li>"어떤 입력을 받고, 어떤 출력을 만들어야 하는가?"</li></ul>이런식으로 요구사항을 명확하게 정리하면 불필요한 시행착오를 줄일 수 있습니다. 2. 플로우 차트 &amp; 도식화를 활용코드의 실행 흐름을 시각적으로 표현하면 이해가 쉬워집니다.<ul ><li>플로우 차트(Flowchart) : 코드의 동작 흐름을 한눈에 파악 가능</li><li>시퀀스 다이어그램(Sequence Diagram) : 여러 요소가 어떻게 상호작용하는지 표현</li></ul>도식화의 가장 큰 장점은 "메타인지" 입니다. 내가 무엇을 알고, 무엇을 모르는지 메타인지가 향상됩니다. 3. 코드 변형 &amp; 리팩토링<ul ><li>"이 부분을 다르게 하면 어떤 결과가 나올까?"</li><li>"이 기능을 다른 방식으로 구현할 수 있을까?"</li></ul>코드를 직접 수정하고 테스트하면서 학습하면 진짜 실력이 됩니다. 단순 실행에서 벗어나 깊이 있는 학습이 가능합니다. 결론따라서 요구사항 정리 → 플로우 차트 작성 → 코드 변경 및 &amp; 리팩토링 의 학습법을 추천합니다. 이 과정을 통해 단순 타이핑이 아니라 문제를 해결하는 사고 과정을 활성화 할 수 있습니다. 그리고 메타인지(내가 제대로 이해하고 있는지 점검하는 과정)를 거쳐 장기 기억에 남게 됩니다.혹시나 무작정 따라 치는 학습법을 하고 계셨다면, 스스로 사고하며 학습하는 방식으로 바꿔 보시기를 추천드립니다 :)

개발 공부법: 코드를 무작정 따라 치지 마세요.

[번역] 환경변수에 시크릿 값을 저장하지 않고 사용하는 더 나은 방법

오늘은 두나무의 조영제님이 번역해주신 글입니다.

우리가 자바스크립트로 프론트엔드나 백엔드 작업을 할 때는 환경 변수 관리를 위해 .env 파일을 사용하는 경우가 많습니다. 개발을 시작할 때 대부분 이렇게 관리하는 모습을 보았고, 아무래도 이 글에서 언급하는 것처럼 그렇게 하는 것이 편하기 때문일 것입니다.
이 글은 크게 두 가지를 다루고 있습니다. 첫 번째는 환경 변수에 시크릿 값을 저장하는 것이 왜 위험한지, 다양한 실제 사례를 통해 설명해줍니다. 두 번째는 시크릿 값을 안전하게 사용하는 다양한 방법에 대해 소개합니다. 이 글이 여러분이 운영하는 서비스의 보안 강화에 도움이 되길 바랍니다.

참고로 글 내에는 없지만 도플러 라는 서비스도 개인적으로 좋게 봤습니다!

글 링크: https://bit.ly/3CCk08b

오늘은 두나무의 조영제님이 번역해주신 글입니다. 우리가 자바스크립트로 프론트엔드나 백엔드 작업을 할 때는 환경 변수 관리를 위해 .env 파일을 사용하는 경우가 많습니다. 개발을 시작할 때 대부분 이렇게 관리하는 모습을 보았고, 아무래도 이 글에서 언급하는 것처럼 그렇게 하는 것이 편하기 때문일 것입니다.이 글은 크게 두 가지를 다루고 있습니다. 첫 번째는 환경 변수에 시크릿 값을 저장하는 것이 왜 위험한지, 다양한 실제 사례를 통해 설명해줍니다. 두 번째는 시크릿 값을 안전하게 사용하는 다양한 방법에 대해 소개합니다. 이 글이 여러분이 운영하는 서비스의 보안 강화에 도움이 되길 바랍니다. 참고로 글 내에는 없지만 도플러 라는 서비스도 개인적으로 좋게 봤습니다! 글 링크: https://bit.ly/3CCk08b

App Store

환경변수에 시크릿 값을 저장하지 않고 사용하는 더 나은 방법

ComfyDeploy 대시보드를 Next.js에서 순수한 리액트로 마이그레이션했습니다.

(번역) 꼭 Next.js일 필요는 없습니다

오늘은 라인플러스의 김찬희님이 번역해주신 글입니다.

현재 가장 널리 사용 되는 프레임워크 중 하나는 단연 Next.js일 것입니다. Next.js는 리액트를 사용해 웹 애플리케이션을 구축할 수 있게 해주는 다양한 기능들을 제공하는 강력한 프레임워크 입니다. 다양한 기능과 편리함 때문에 정말 많이 사용 되고 있으며, 때문에 프로젝트를 시작할 때 가장 우선적으로 고려되는 도구이기도 합니다.

널리 쓰이는 만큼 많은 분들이 이미 사용하고 계시기 때문에 관성적으로 Next.js를 사용하게 되기도 합니다. 그런데 사실 Next.js로 개발하지 않았어도 되었지 않을까요? Next.js는 분명 굉장히 좋은 프레임워크 이지만, 여러분도 알고 계시듯 마법의 은 탄환 같은 것은 없기 때문에 모든 상황에서 좋지는 않습니다.

이 글은 Next.js에서 리액트로 마이그레이션 하게 된 과정과 결과를 상세히 다루고 있습니다. 저자가 어떤 문제를 겪었고, Next.js를 걷어 내었을 때 어떤 결과를 얻었는지 살펴보며 Next.js 였어야 했을까? 하는 고민을 해보시는 것은 어떨 까요? 이런 고민은 앞으로의 보다 많은 선택지를 가질 수 있도록 시야를 넓혀주는 데 도움이 될 것이라 생각합니다.

글 링크 : https://velog.io/@superlipbalm/you-dont-need-nextjs

오늘은 라인플러스의 김찬희님이 번역해주신 글입니다. 현재 가장 널리 사용 되는 프레임워크 중 하나는 단연 Next.js일 것입니다. Next.js는 리액트를 사용해 웹 애플리케이션을 구축할 수 있게 해주는 다양한 기능들을 제공하는 강력한 프레임워크 입니다. 다양한 기능과 편리함 때문에 정말 많이 사용 되고 있으며, 때문에 프로젝트를 시작할 때 가장 우선적으로 고려되는 도구이기도 합니다. 널리 쓰이는 만큼 많은 분들이 이미 사용하고 계시기 때문에 관성적으로 Next.js를 사용하게 되기도 합니다. 그런데 사실 Next.js로 개발하지 않았어도 되었지 않을까요? Next.js는 분명 굉장히 좋은 프레임워크 이지만, 여러분도 알고 계시듯 마법의 은 탄환 같은 것은 없기 때문에 모든 상황에서 좋지는 않습니다. 이 글은 Next.js에서 리액트로 마이그레이션 하게 된 과정과 결과를 상세히 다루고 있습니다. 저자가 어떤 문제를 겪었고, Next.js를 걷어 내었을 때 어떤 결과를 얻었는지 살펴보며 Next.js 였어야 했을까? 하는 고민을 해보시는 것은 어떨 까요? 이런 고민은 앞으로의 보다 많은 선택지를 가질 수 있도록 시야를 넓혀주는 데 도움이 될 것이라 생각합니다. 글 링크 : https://velog.io/@superlipbalm/you-dont-need-nextjs

velog.io

꼭 Next.js일 필요는 없습니다

‘실험이라고 생각하기’

완벽하지 않은 완성품을 세상에 내놓을 때 실험이라고 생각해보세요. 일종의 테스트이자 점검인 거죠.

글도 코드도 너무 오래 다듬기보다 얼른 세상에 내놓고 반응을 보며 다음을 준비하는 게 나은 경우가 많더라고요.

‘실험이라고 생각하기’ 완벽하지 않은 완성품을 세상에 내놓을 때 실험이라고 생각해보세요. 일종의 테스트이자 점검인 거죠. 글도 코드도 너무 오래 다듬기보다 얼른 세상에 내놓고 반응을 보며 다음을 준비하는 게 나은 경우가 많더라고요.

완벽주의에서 벗어나는 법

쓰신 분은 대부분 글을 짧고 쉽게 써서 특히 주니어 분들은 오해할 수도 있을 것 같은데요.

주어진 개발은 언제나 나에겐 완전에 가깝도록 최선의 노력을 다해 구현하고 테스트해 배포하는 습관을 들여야 합니다. 

장인정신.

시간과 기회를 위해 실험하고 희생해야 하는 건 코드, 품질 수준이 아니라 기능, 서비스의 크기, 깊이 입니다.

그것 또한 상당 부분 기술 부채로 돌아오기도 하죠.

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

 - YouTube

현재 Nextjs 에서는
Dynamic 렌더링을 할지 혹은 Static 렌더링을 할지에 대해
페이지 단위로만 결정할 수 있단 사실 알고계셨나요??
(자식 컴포넌트 중에서 하나라도 Dynamic 이면
해당 페이지 전체를 Dynamic 으로 간주)

이러한 한계를 갖게된 배경에 대해
렌더링 방식의 발전 역사부터 쭉 살펴보았습니다.

그럼 오늘도 각자의 자리에서 함께 공부하는 모든 분들 화이팅입니다 :)

https://youtu.be/dBRFHwH9imo

현재 Nextjs 에서는Dynamic 렌더링을 할지 혹은 Static 렌더링을 할지에 대해페이지 단위로만 결정할 수 있단 사실 알고계셨나요??(자식 컴포넌트 중에서 하나라도 Dynamic 이면해당 페이지 전체를 Dynamic 으로 간주) 이러한 한계를 갖게된 배경에 대해렌더링 방식의 발전 역사부터 쭉 살펴보았습니다. 그럼 오늘도 각자의 자리에서 함께 공부하는 모든 분들 화이팅입니다 :) https://youtu.be/dBRFHwH9imo

youtu.be

Nextjs 렌더링 방식이 페이지 단위로만 결정된다?!

단순함에 대한 탐구는 실제로 웹 개발을 단순하게 만들지 못했습니다.

(번역) 자바스크립트 프레임워크 - 2025년을 향해

오늘은 라인플러스의 황세현님이 번역해주신 글입니다.

이 글에서는 2024년을 돌아보며 웹 개발의 변화와 기술적 복잡성에 대한 저자의 깊은 통찰이 담겨 있습니다. 저자는 기술의 단순함을 추구하는 과정에서 오히려 새로운 복잡성이 발생하는 역설을 지적하며, 서버 중심 아키텍처의 변화, 컴파일러의 역할, AI 기반 개발 도구의 발전 등 앞으로의 중요한 흐름을 분석합니다.

또한, 2025년에는 큰 기술적 도약보다는 현재의 복잡성을 이해하고 해결책을 모색하는 해가 될 것이라고 예상하며, 단순함을 추구하는 과정에서 발생하는 새로운 복잡성에 대해 성찰해야 한다고 강조합니다. 2025년 웹 개발의 흐름을 제대로 파악하고 싶다면, 이 글을 통해 한 번 성찰해 보는 건 어떨까요?

글 링크 : https://velog.io/@sehyunny/js-frameworks-heading-into-2025

오늘은 라인플러스의 황세현님이 번역해주신 글입니다. 이 글에서는 2024년을 돌아보며 웹 개발의 변화와 기술적 복잡성에 대한 저자의 깊은 통찰이 담겨 있습니다. 저자는 기술의 단순함을 추구하는 과정에서 오히려 새로운 복잡성이 발생하는 역설을 지적하며, 서버 중심 아키텍처의 변화, 컴파일러의 역할, AI 기반 개발 도구의 발전 등 앞으로의 중요한 흐름을 분석합니다. 또한, 2025년에는 큰 기술적 도약보다는 현재의 복잡성을 이해하고 해결책을 모색하는 해가 될 것이라고 예상하며, 단순함을 추구하는 과정에서 발생하는 새로운 복잡성에 대해 성찰해야 한다고 강조합니다. 2025년 웹 개발의 흐름을 제대로 파악하고 싶다면, 이 글을 통해 한 번 성찰해 보는 건 어떨까요? 글 링크 : https://velog.io/@sehyunny/js-frameworks-heading-into-2025

자바스크립트 프레임워크 - 2025년을 향해

테스트를 작성하다 보면 여러 테스트에 걸쳐서 반복되는 로직이 생기기 마련인데요. 이러한 공통 로직을 모든 테스트마다 중복해서 작성하면 개발 생산성이 떨이지고 유지보수가 힘들어집니다.

이번 포스팅에서는 Vitest를 이용해서 테스트 전이나 후에 항상 실행되야 하는 로직을 효과적으로 실행하는 방법에 대해서 알아보겠습니다.

📺 동영상: https://youtu.be/0fV30sUDAXE
📝 게시물: https://www.daleseo.com/vitest-before-after/

차세대 테스팅 프레임워크로 각광받고 있는 Vitest를 학습하시는 분들께 아래 게시물도 추천드리겠습니다.

📕 Vitest 처음 시작하기: https://careerly.co.kr/comments/115949
📗 Vitest 결과 매칭: https://careerly.co.kr/comments/116437
📘 Vitest 그룹화: https://careerly.co.kr/comments/116659

테스트를 작성하다 보면 여러 테스트에 걸쳐서 반복되는 로직이 생기기 마련인데요. 이러한 공통 로직을 모든 테스트마다 중복해서 작성하면 개발 생산성이 떨이지고 유지보수가 힘들어집니다. 이번 포스팅에서는 Vitest를 이용해서 테스트 전이나 후에 항상 실행되야 하는 로직을 효과적으로 실행하는 방법에 대해서 알아보겠습니다. 📺 동영상: https://youtu.be/0fV30sUDAXE📝 게시물: https://www.daleseo.com/vitest-before-after/ 차세대 테스팅 프레임워크로 각광받고 있는 Vitest를 학습하시는 분들께 아래 게시물도 추천드리겠습니다. 📕 Vitest 처음 시작하기: https://careerly.co.kr/comments/115949📗 Vitest 결과 매칭: https://careerly.co.kr/comments/116437📘 Vitest 그룹화: https://careerly.co.kr/comments/116659

Vitest 테스트 전/후 처리하기

우아한형제들 멘토단 꿀팁 모음

Udemy X 우아한형제들 커리어 성장 멘토링

udemy에 올라간 강의 중 우아한형제들 구성원이 만든 강의가 모여있답니다.
테크니컬라이팅, 커뮤니케이션, 매크로, 프로덕트 관리 노하우 등 다양한 강의가 준비되어있으니 살펴보셔요.

덤으로 제 강의도 있어요 🥳

https://meta-bifrost.vercel.app/BBs5sSF0AQP211KN39Pp

udemy에 올라간 강의 중 우아한형제들 구성원이 만든 강의가 모여있답니다.테크니컬라이팅, 커뮤니케이션, 매크로, 프로덕트 관리 노하우 등 다양한 강의가 준비되어있으니 살펴보셔요. 덤으로 제 강의도 있어요 🥳 https://meta-bifrost.vercel.app/BBs5sSF0AQP211KN39Pp

meta-bifrost.vercel.app

강의 완강하면 커피챗☕ 기회가 생겨요!

Feat. Excel, Python, R, SQL

텍스트(String) 데이터를
날짜 시간(Datetime) 데이터로 변환하는 일은
데이터 분석 및 엔지니어링에서 매우 자주 사용하는 작업 중 하나입니다.

아래 리스트의 다양한 데이터 도구를 사용하여
변환하는 방법에 대해 정리해보았습니다.

- Excel
- Python
- R
- SQL

우리는 모든 구문(Syntax)들을 정확히 암기할 필요는 없습니다.
대신 각 방법이 어떻게 작동하는지 이해하고,
필요할 때 효과적으로 사용할 수 있도록 하는 것이 중요합니다.

Feat. Excel, Python, R, SQL 텍스트(String) 데이터를 날짜 시간(Datetime) 데이터로 변환하는 일은 데이터 분석 및 엔지니어링에서 매우 자주 사용하는 작업 중 하나입니다. 아래 리스트의 다양한 데이터 도구를 사용하여 변환하는 방법에 대해 정리해보았습니다. - Excel - Python - R - SQL 우리는 모든 구문(Syntax)들을 정확히 암기할 필요는 없습니다. 대신 각 방법이 어떻게 작동하는지 이해하고, 필요할 때 효과적으로 사용할 수 있도록 하는 것이 중요합니다.

"2025.02.05."를 실제 날짜로 변환하는 함수들

알고리즘 입문자를 위한 달레의 친절한 안내서

Spiral Matrix | 알고달레

코딩 테스트를 준비하시는 분들을 위해서 일주일에 한 번씩 문제 풀이를 해드리고 있습니다. 이번 시간에는 LeetCode의 54번째 문제인 Spiral Matrix를 풀어보겠습니다.

📺 동영상: https://youtu.be/F56WDTUJ1GM
📝 설명/코드: https://www.algodale.com/problems/spiral-matrix/

코딩 테스트를 준비하시는 분들을 위해서 일주일에 한 번씩 문제 풀이를 해드리고 있습니다. 이번 시간에는 LeetCode의 54번째 문제인 Spiral Matrix를 풀어보겠습니다. 📺 동영상: https://youtu.be/F56WDTUJ1GM📝 설명/코드: https://www.algodale.com/problems/spiral-matrix/

알고달레

리트코드 54. Spiral Matrix 파이썬 풀이

As an engineering manager I’ve had the privilege of promoting engineers on my team and offering people their first role in tech. It’s one…

From Hired!… to Fired! Avoid these 2 Developer Career Death Traps

이번 글에서는 사람들이 해고되는 가장 흔한 두 가지 이유와 이를 피하는 방법에 대해 살펴보겠습니다.

1단계: 목표를 명확히 설정하기
개발자가 해고되는 가장 일반적인 이유는 기대치 불일치 때문입니다.
 * 90일 계획 없음
 * 매니저 피드백 없음
 * 본인은 잘하고 있다고 생각하지만 팀원들은 답답해함
 * 그리고 갑작스러운 해고 통보
본인에게는 '갑자기'일지 모르지만, 팀원들에게는 그렇지 않습니다.
대부분의 매니저는 일부러 피드백을 주지 않는 것이 아닙니다. 사람들은 본능적으로 갈등을 피하려 합니다.

그러므로 첫 출근 날부터 팀 리드나 매니저와 실질적인 목표를 설정하는 것이 중요합니다.
특히, 첫 1~2개월 동안 성공의 기준을 정리해야 합니다. 만약 매니저가 명확한 계획을 제공하지 않는다면, 스스로 계획을 세워 공유해야 합니다.

예를 들어, 주니어 개발자라면 다음과 같이 설정할 수 있습니다.
 * 1~30일
   * 로컬 환경에서 모든 레포지토리를 실행
   * 코드 리뷰 및 배포 프로세스 이해
   * 적어도 2개의 작은 기능을 프로덕션에 배포
 * 30~60일
   * 온콜(On-call) 로테이션 참여
   * 주요 장애 대응 프로세스 학습
   * 소프트웨어 개발 라이프사이클 이해
   * 작은 버그를 혼자 해결
 * 60~90일
   * 중급 난이도의 기능 개발 및 배포
   * 기술적 논의에 기여
이렇게 하면 '눈치 게임'을 할 필요 없이, 본인의 성장 수준을 명확히 파악할 수 있습니다.

2단계: 본인의 성과를 알리기
일부 조직에서는 매니저가 모든 엔지니어와 직접 소통하지 않습니다.
그 결과, 관리자는 본인을 잘못된 기준으로 평가할 수 있습니다.
예를 들어, 코드 라인 수나 버그 수정 개수 같은 무의미한 지표로 평가받을 수도 있습니다.

그렇다면 어떻게 해야 할까요?

👉 본인의 성과를 자연스럽게 알리는 방법을 배워야 합니다. "자랑"하지 말고, "교육"해야 합니다.
 * 중요한 문제를 해결했나요?
   → 해결 방법을 문서화하고, 간단한 발표를 통해 공유하기
 * 새로운 기능을 출시했나요?
   → 다음 회의에서 직접 데모를 진행하기
마지막으로, 본인이 한 모든 중요한 작업을 기록해 두는 것이 중요합니다.

이렇게 하면 연말 평가 때 본인의 가치를 쉽게 증명할 수 있습니다. 이제 당신은 "그 사람 누구였더라?"가 아니라 "그 팀에서 중요한 엔지니어"로 기억될 것입니다.

당신의 성공을 바랍니다
이 글을 읽고 있다면, 아마 개발자로서 커리어를 시작한 지 얼마 되지 않았을 것입니다.

저는 수많은 실수를 했지만, 다행히도 해고당하지 않았습니다. 하지만 이번에 다룬 두 가지 교훈을 배우기까지 4년이 걸렸습니다.

제 목표는 단순히 해고를 피하는 것이 아닙니다.

기술적으로 성장하고, 회사 내에서 돋보이며, 만약 해고당하더라도 빠르게 새로운 기회를 잡을 수 있는 개발자가 되는 것입니다.

첫 취업이 끝은 아닙니다. 진짜 중요한 것은 그 이후입니다.

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

이번 글에서는 사람들이 해고되는 가장 흔한 두 가지 이유와 이를 피하는 방법에 대해 살펴보겠습니다. 1단계: 목표를 명확히 설정하기개발자가 해고되는 가장 일반적인 이유는 기대치 불일치 때문입니다.<ul><li>90일 계획 없음</li><li>매니저 피드백 없음</li><li>본인은 잘하고 있다고 생각하지만 팀원들은 답답해함</li><li>그리고 갑작스러운 해고 통보</li></ul>본인에게는 '갑자기'일지 모르지만, 팀원들에게는 그렇지 않습니다.대부분의 매니저는 일부러 피드백을 주지 않는 것이 아닙니다. 사람들은 본능적으로 갈등을 피하려 합니다. 그러므로 첫 출근 날부터 팀 리드나 매니저와 실질적인 목표를 설정하는 것이 중요합니다.특히, 첫 1~2개월 동안 성공의 기준을 정리해야 합니다. 만약 매니저가 명확한 계획을 제공하지 않는다면, 스스로 계획을 세워 공유해야 합니다. 예를 들어, 주니어 개발자라면 다음과 같이 설정할 수 있습니다.<ul><li>1~30일<ul><li>로컬 환경에서 모든 레포지토리를 실행</li><li>코드 리뷰 및 배포 프로세스 이해</li><li>적어도 2개의 작은 기능을 프로덕션에 배포</li></ul></li><li>30~60일<ul><li>온콜(On-call) 로테이션 참여</li><li>주요 장애 대응 프로세스 학습</li><li>소프트웨어 개발 라이프사이클 이해</li><li>작은 버그를 혼자 해결</li></ul></li><li>60~90일<ul><li>중급 난이도의 기능 개발 및 배포</li><li>기술적 논의에 기여</li></ul></li></ul>이렇게 하면 '눈치 게임'을 할 필요 없이, 본인의 성장 수준을 명확히 파악할 수 있습니다. 2단계: 본인의 성과를 알리기일부 조직에서는 매니저가 모든 엔지니어와 직접 소통하지 않습니다. 그 결과, 관리자는 본인을 잘못된 기준으로 평가할 수 있습니다. 예를 들어, 코드 라인 수나 버그 수정 개수 같은 무의미한 지표로 평가받을 수도 있습니다. 그렇다면 어떻게 해야 할까요? 👉 본인의 성과를 자연스럽게 알리는 방법을 배워야 합니다. "자랑"하지 말고, "교육"해야 합니다.<ul><li>중요한 문제를 해결했나요? → 해결 방법을 문서화하고, 간단한 발표를 통해 공유하기</li><li>새로운 기능을 출시했나요? → 다음 회의에서 직접 데모를 진행하기</li></ul>마지막으로, 본인이 한 모든 중요한 작업을 기록해 두는 것이 중요합니다. 이렇게 하면 연말 평가 때 본인의 가치를 쉽게 증명할 수 있습니다. 이제 당신은 "그 사람 누구였더라?"가 아니라 "그 팀에서 중요한 엔지니어"로 기억될 것입니다. 당신의 성공을 바랍니다이 글을 읽고 있다면, 아마 개발자로서 커리어를 시작한 지 얼마 되지 않았을 것입니다. 저는 수많은 실수를 했지만, 다행히도 해고당하지 않았습니다. 하지만 이번에 다룬 두 가지 교훈을 배우기까지 4년이 걸렸습니다. 제 목표는 단순히 해고를 피하는 것이 아닙니다. 기술적으로 성장하고, 회사 내에서 돋보이며, 만약 해고당하더라도 빠르게 새로운 기회를 잡을 수 있는 개발자가 되는 것입니다. 첫 취업이 끝은 아닙니다. 진짜 중요한 것은 그 이후입니다. 번역: [https://ducktopia.tistory.com/m/144]원문:

Medium

[Medium] 개발자로서 살아남기: 해고를 피하는 두 가지 방법

JYK 매니지먼트 | 현대의 디지털 제품과 서비스는 작은 아이디어에서 시작해 수백만 사용자에게 사랑받는 모습으로 성장합니다. 이를 가능하게 하는 핵심은 확장성 있는 시스템 설계입니다. 이 강의에서는 소규모에서 대규모 시스템으로 성장할 수 있는 설계 원리와 실천 방안을 배울

확장성 있는 시스템 설계하기 강의 | JYK 매니지먼트 - 인프런

작년 말, 고려대에서 시스템 설계에 대해 특강을 진행했다. 정말 재미있고 유익했으며, 도움이 되었다며 가능한 온라인 강의로 출시를 해줬으면 좋겠다는 피드백을 받았었다. 당시에는 여유가 없어 시도해보겠다고 답하고, 한동안 바빠져서 챙기지 못했다. 얼마 전부터 여유가 나서 자료를 정비하고, AI 서비스의 도움을 받아 제작해서 출시했다.

맨땅에서 시작해 백만 사용자가 이용하는 대규모 서비스를 구축하려면 가용성, 성능, 확장성 등을 고려한 시스템 설계가 필수다. 이 강의는 '#POTD(Photo of the Day)'이라는 가상 프로젝트를 통해 최소 기능 제품에서 시작하여 글로벌 규모로 확장하는 과정에서 발생하는 다양한 문제와 해결책을 구체적으로 다룬다.

작은 규모에서는 놓치기 쉬운 트래픽 분산, 서버 확장, 데이터베이스 복제, 검색 엔진 및 메시지 큐 연동, CDN과 멀티 데이터 센터 활용 등 대규모 서비스 운영 시 직면하는 핵심 문제를 단계별로 살펴본다. 수평 확장 환경에서 애플리케이션 수준의 설계 고민과 함께 캐싱 등 성능 최적화 필수 기술을 배우고, 머신러닝 기반 개인 맞춤 추천 시스템 구현 아이디어도 소개하고 있다.

프로그래밍 언어 및 기본적인 CS 지식을 갖춘 분이라면, 사례 중심의 설명을 통해 확장성 있는 시스템 설계를 처음부터 끝까지 이해하는 좋은 시작점이 될 것이다.

https://inf.run/TczsG

작년 말, 고려대에서 시스템 설계에 대해 특강을 진행했다. 정말 재미있고 유익했으며, 도움이 되었다며 가능한 온라인 강의로 출시를 해줬으면 좋겠다는 피드백을 받았었다. 당시에는 여유가 없어 시도해보겠다고 답하고, 한동안 바빠져서 챙기지 못했다. 얼마 전부터 여유가 나서 자료를 정비하고, AI 서비스의 도움을 받아 제작해서 출시했다. 맨땅에서 시작해 백만 사용자가 이용하는 대규모 서비스를 구축하려면 가용성, 성능, 확장성 등을 고려한 시스템 설계가 필수다. 이 강의는 '#POTD(Photo of the Day)'이라는 가상 프로젝트를 통해 최소 기능 제품에서 시작하여 글로벌 규모로 확장하는 과정에서 발생하는 다양한 문제와 해결책을 구체적으로 다룬다. 작은 규모에서는 놓치기 쉬운 트래픽 분산, 서버 확장, 데이터베이스 복제, 검색 엔진 및 메시지 큐 연동, CDN과 멀티 데이터 센터 활용 등 대규모 서비스 운영 시 직면하는 핵심 문제를 단계별로 살펴본다. 수평 확장 환경에서 애플리케이션 수준의 설계 고민과 함께 캐싱 등 성능 최적화 필수 기술을 배우고, 머신러닝 기반 개인 맞춤 추천 시스템 구현 아이디어도 소개하고 있다. 프로그래밍 언어 및 기본적인 CS 지식을 갖춘 분이라면, 사례 중심의 설명을 통해 확장성 있는 시스템 설계를 처음부터 끝까지 이해하는 좋은 시작점이 될 것이다. https://inf.run/TczsG

인프런

확장성 있는 시스템 설계하기

숫자로 보는 책 경매 서비스 회고

Cursor로 한시간 반만에 만든 책 경매 서비스 - Blog by Jason Kang

지난주에 올렸던 책 경매사이트 회고글입니다.

이걸 만들려고 결심한 건, 알라딘 중고서점에 팔려다가 RealMySQL 8.0이 3천원이길래, "이 좋은책을 3천원에 판다는건 말이 안된다" 라는 생각에 시작했어요.

이 글은 “누구나 Cursor를 활용하면 한시간안에 앱을 개발할 수 있다”는 내용은 아닙니다. 저는 플러터에 contribution 이력이 있을 정도로 플러터가 익숙하기 때문에 LLM을 어떻게 활용할지 잘 알아서 빠른 시간내에 개발이 가능했다고 생각합니다.

지난 5일간 전세계 8개국에서 700명 가까이 찾아주신 서비스 회고를 확인해주세요 😂

https://jasonkang14.github.io/llm/building-an-auction-service-to-sell-books-with-cursor

지난주에 올렸던 책 경매사이트 회고글입니다. 이걸 만들려고 결심한 건, 알라딘 중고서점에 팔려다가 RealMySQL 8.0이 3천원이길래, "이 좋은책을 3천원에 판다는건 말이 안된다" 라는 생각에 시작했어요. 이 글은 “누구나 Cursor를 활용하면 한시간안에 앱을 개발할 수 있다”는 내용은 아닙니다. 저는 플러터에 contribution 이력이 있을 정도로 플러터가 익숙하기 때문에 LLM을 어떻게 활용할지 잘 알아서 빠른 시간내에 개발이 가능했다고 생각합니다. 지난 5일간 전세계 8개국에서 700명 가까이 찾아주신 서비스 회고를 확인해주세요 😂 https://jasonkang14.github.io/llm/building-an-auction-service-to-sell-books-with-cursor

jasonkang14.github.io

한시간 반만에 Cursor로 만든 개발서적 경매서비스 후기

Claude가 GPT나 Gemini 등에 비해 코딩에 여전히 더 적합하다는 경험담이 많은데요.

제가 지속적으로 써 보고 느낀바도 역시 그렇습니다. 특히 웹 코딩 쪽에서 좀 더 두각을 나타내는 편으로 보이는데, Claude 서비스에 Web App을 만드는 기능을 만들면서 그쪽으로 데이터를 좀 더 집중한게 아닌게 싶습니다.

그러나, 함정이 있습니다.

Claude가 잘 하는 부분은 복잡해보이는 문제도 실제로는 단순한 부분입니다. 간단하게 말하자면, 빈칸을 채우는 것을 잘하는 것이었습니다.

그런데 조금은 생각을 해야하는, 이를테면 메모리 문제나 동시성 처리같은 부분, 혹은 수학적인 알고리즘의 구현 등은 Claude나 4o 같은 일반 생성 모델 보다는 Reasoning 모델들이 더 잘 하는 것을 확인했습니다.

즉, 말 그대로 생각없이 채워넣기 수준의 코딩은 Claude가 더 잘 하는 편이고, 대개 많은 경우가 새로운 문제나 어려운 문제를 푸는 것이 아니라 단순 구현이 많기 때문에 대부분의 경우 Claude가 더 잘 한다고 느끼는 것 입니다.

이를 확인하고나니 폰 노이만이 프로그래밍, 코딩을 지적 능력이 거의 필요하지 않은 사무적인 일이라고 했던 말이 다시금 떠오르더군요.

사실 지금 회사에서 하는 일도, 많은 부분을 이미 생각은 니가 하렴 노가다는 인간이(내가) 할께..수준으로 일을 하고 있기도 합니다.

아무튼, 당장은 AI를 그 필요에 맞게 선택해서 쓰는데에 이 경험이 유용하겠지만, 앞으로 우리가 해야 할 일이 무엇인지 조금 더 진지하게 생각해 볼 필요가 있지 않을까 싶네요.

Claude가 GPT나 Gemini 등에 비해 코딩에 여전히 더 적합하다는 경험담이 많은데요. 제가 지속적으로 써 보고 느낀바도 역시 그렇습니다. 특히 웹 코딩 쪽에서 좀 더 두각을 나타내는 편으로 보이는데, Claude 서비스에 Web App을 만드는 기능을 만들면서 그쪽으로 데이터를 좀 더 집중한게 아닌게 싶습니다. 그러나, 함정이 있습니다. Claude가 잘 하는 부분은 복잡해보이는 문제도 실제로는 단순한 부분입니다. 간단하게 말하자면, 빈칸을 채우는 것을 잘하는 것이었습니다. 그런데 조금은 생각을 해야하는, 이를테면 메모리 문제나 동시성 처리같은 부분, 혹은 수학적인 알고리즘의 구현 등은 Claude나 4o 같은 일반 생성 모델 보다는 Reasoning 모델들이 더 잘 하는 것을 확인했습니다. 즉, 말 그대로 생각없이 채워넣기 수준의 코딩은 Claude가 더 잘 하는 편이고, 대개 많은 경우가 새로운 문제나 어려운 문제를 푸는 것이 아니라 단순 구현이 많기 때문에 대부분의 경우 Claude가 더 잘 한다고 느끼는 것 입니다. 이를 확인하고나니 폰 노이만이 프로그래밍, 코딩을 지적 능력이 거의 필요하지 않은 사무적인 일이라고 했던 말이 다시금 떠오르더군요. 사실 지금 회사에서 하는 일도, 많은 부분을 이미 생각은 니가 하렴 노가다는 인간이(내가) 할께..수준으로 일을 하고 있기도 합니다. 아무튼, 당장은 AI를 그 필요에 맞게 선택해서 쓰는데에 이 경험이 유용하겠지만, 앞으로 우리가 해야 할 일이 무엇인지 조금 더 진지하게 생각해 볼 필요가 있지 않을까 싶네요.

Claude가 GPT나 Gemini 등에 비해 코딩에 여전히 더 

Availability is critical to the user experience...

5 Strategies for High-Availability Systems

고가용성(high availability, HA)의 사전적 정의는 서버, 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질을 말합니다. 예컨대, 어떤 일이 있어도(IDC가 정전이 나도, 로직이 잘못되어 무한 루프에 빠져도) 운영하는 서비스의 장애를 사용자가 못 느끼도록 하는 상황을 말하는데요. 서비스의 복잡도와 사용자의 규모가 점점 늘어남에 따라 고가용성은 더욱 중요해지는 것 같습니다. 간혹, 기능 개발에만 신경 쓰며 "구현"만 하고 그다음은 생각 안 하는 경우가 있는데 이 글에서 이야기하는 다섯 가지 전략 측면이라도 살펴보면 좋을 것 같아 공유합니다.
1. 로드 밸런싱(Load Balancing, LB)
2. 격리를 통한 데이터 복제(Data Redundancy
3. 장애 조치(Failover)
4. 오토 스케일링(Auto scailing)
5. Rate Limiting(호출 제한)

각자 구현의 방식은 상황이나 환경에 따라 달라질 수는 있겠지만 개념을 숙지하고 있다가 서비스를 출시하거나 운영하는 상황에서 적용해 봐도 좋을 것 같네요.

https://newsletter.systemdesigncodex.com/p/5-strategies-for-high-availability

고가용성(high&nbsp;availability,&nbsp;HA)의 사전적 정의는&nbsp;서버,&nbsp;네트워크,&nbsp;프로그램&nbsp;등의&nbsp;정보&nbsp;시스템이&nbsp;상당히&nbsp;오랜&nbsp;기간&nbsp;동안&nbsp;지속적으로&nbsp;정상&nbsp;운영이&nbsp;가능한&nbsp;성질을&nbsp;말합니다. 예컨대, 어떤 일이 있어도(IDC가 정전이 나도, 로직이 잘못되어 무한 루프에 빠져도) 운영하는 서비스의 장애를 사용자가 못 느끼도록 하는 상황을 말하는데요. 서비스의 복잡도와 사용자의 규모가 점점 늘어남에 따라 고가용성은 더욱 중요해지는 것 같습니다. 간혹, 기능 개발에만 신경 쓰며 "구현"만 하고 그다음은 생각 안 하는 경우가 있는데 이 글에서 이야기하는 다섯 가지 전략 측면이라도 살펴보면 좋을 것 같아 공유합니다.1. 로드 밸런싱(Load Balancing, LB)2. 격리를 통한 데이터 복제(Data Redundancy3. 장애 조치(Failover)4. 오토 스케일링(Auto scailing)5. Rate Limiting(호출 제한) 각자 구현의 방식은 상황이나 환경에 따라 달라질 수는 있겠지만 개념을 숙지하고 있다가 서비스를 출시하거나 운영하는 상황에서 적용해 봐도 좋을 것 같네요. https://newsletter.systemdesigncodex.com/p/5-strategies-for-high-availability﻿

newsletter.systemdesigncodex.com

고가용성 시스템을 위한 5가지 전략

책 『리액트 훅을 활용한 마이크로 상태 관리』 를 읽고 작성한 서평입니다.

리액트 훅을 활용한 마이크로 상태 관리 - 재그지그의 개발 블로그

- 책 『리액트 훅을 활용한 마이크로 상태 관리』 를 읽고 작성한 서평입니다.

---

올해 첫 책을 읽었습니다. 원래 작년에 읽으려 했지만 미뤄둔 책이라, 이번 설 연휴를 계기로 완독하고 후기를 남겨보려고 합니다.

사실 이 책을 읽게 된 이유는 회사에서 스터디 목적으로 구매한 책이었는데, 정작 바쁘다는 이유로 스터디를 하지는 못했기 때문입니다. 사놓은 책만 덩그러니 남겨져 있어서, 개인적으로 공부하기 위해 읽게 되었습니다.

이 책을 보고 흥미를 느낀 부분은 크게 두 가지였는데요. 첫 번째는 책 제목에서 이야기하는 마이크로 상태 관리 라는 개념이 저에게는 생소하게 느껴져서 그 의미가 궁금했고, 두 번째로는 Zustand와 Jotai처럼 유명한 상태 관리 라이브러리를 깊이 다루는 내용이 포함되어 있다는 점이었습니다. 사실 저는 아직까지 두 라이브러리를 들어보기만 했지 직접 사용해본 경험은 없어서 그 둘의 차이점을 알고 싶었기 때문입니다.

저와 비슷한 고민을 하시는 분들도 계실 것 같아, 이번 포스트에서 이 책의 주요 내용을 소개하고 인상 깊었던 부분을 공유하려고 합니다.

https://wormwlrm.github.io/2025/02/02/Micro-State-Management-with-React-Hooks.html

- 책 『리액트 훅을 활용한 마이크로 상태 관리』 를 읽고 작성한 서평입니다. --- 올해 첫 책을 읽었습니다. 원래 작년에 읽으려 했지만 미뤄둔 책이라, 이번 설 연휴를 계기로 완독하고 후기를 남겨보려고 합니다. 사실 이 책을 읽게 된 이유는 회사에서 스터디 목적으로 구매한 책이었는데, 정작 바쁘다는 이유로 스터디를 하지는 못했기 때문입니다. 사놓은 책만 덩그러니 남겨져 있어서, 개인적으로 공부하기 위해 읽게 되었습니다. 이 책을 보고 흥미를 느낀 부분은 크게 두 가지였는데요. 첫 번째는 책 제목에서 이야기하는&nbsp;마이크로 상태 관리&nbsp;라는 개념이 저에게는 생소하게 느껴져서 그 의미가 궁금했고, 두 번째로는 Zustand와 Jotai처럼 유명한 상태 관리 라이브러리를 깊이 다루는 내용이 포함되어 있다는 점이었습니다. 사실 저는 아직까지 두 라이브러리를 들어보기만 했지 직접 사용해본 경험은 없어서 그 둘의 차이점을 알고 싶었기 때문입니다. 저와 비슷한 고민을 하시는 분들도 계실 것 같아, 이번 포스트에서 이 책의 주요 내용을 소개하고 인상 깊었던 부분을 공유하려고 합니다. https://wormwlrm.github.io/2025/02/02/Micro-State-Management-with-React-Hooks.html

재그지그의 개발 블로그

🎤 리액트 훅을 활용한 마이크로 상태 관리

에이든든님이
이직 과정에서 공고 확인이 불편하여 코파일럿으로 이를 손쉽게 필터링하는 크롬 익스텐션을 만든 이야기입니다

역시 필요는 발명의 어머니네요
https://aydenden.medium.com/%EC%BD%94%ED%8C%8C%EC%9D%BC%EB%9F%BF%EA%B3%BC-%ED%95%A8%EA%BB%98%ED%95%9C-%EC%9D%B4%EC%A7%81-%EA%B3%BC%EC%A0%95-6529e9c753c2

에이든든님이 이직 과정에서 공고 확인이 불편하여 코파일럿으로 이를 손쉽게 필터링하는 크롬 익스텐션을 만든 이야기입니다 역시 필요는 발명의 어머니네요https://aydenden.medium.com/%EC%BD%94%ED%8C%8C%EC%9D%BC%EB%9F%BF%EA%B3%BC-%ED%95%A8%EA%BB%98%ED%95%9C-%EC%9D%B4%EC%A7%81-%EA%B3%BC%EC%A0%95-6529e9c753c2

필요는 발명의 어머니(이직할 때 코파일럿쓴 사례)

원문 : Goodbye SASS 👋, welcome back native CSS thumbnail Sass는 로컬에 설치되는 강력한 전처리기로 자리 잡으며 지난 10년 동안 제 프로젝트의 핵심을 이루었습니다. 이는 확장 가능하고 안정적인 CSS 패키지를 효율적으로 구성할 수 있게 해 주었습니다. 지금도 Sass는 굉장히 강력한 도구라고 생각합니다. 하지만 2024년에 접어들면서 CSS가 급속도로 발전하고 있다는 것은 부인할 수 없는 사실입니다. 한때 Sass에만 존재하던 기능들이 이제는 CSS…

(번역) 잘 가 SASS 👋, 다시 만나 반가워 네이티브 CSS

오늘은 42dot의 유경상님이 번역해주신 글입니다.

Sass는 오랫동안 CSS 전처리기로서 많은 개발자들에게 사랑받아 왔지만, 이 글에서 저자는 CSS의 발전으로 인해 Sass의 필요성이 줄어들고 있다고 말하고 있습니다. 네이티브 CSS에 추가된 변수, 중첩, 컨테이너 쿼리 등 강력한 기능들이 어떻게 Sass의 기능을 대체할 수 있는지 살펴보고, 과연 Sass를 충분히 대체할 수 있을지에 대해 생각해보는 기회가 되시길 바랍니다 :)

> https://ykss.netlify.app/translation/goodbye_sass_welcome_back_native_css/

오늘은 42dot의 유경상님이 번역해주신 글입니다. Sass는 오랫동안 CSS 전처리기로서 많은 개발자들에게 사랑받아 왔지만, 이 글에서 저자는 CSS의 발전으로 인해 Sass의 필요성이 줄어들고 있다고 말하고 있습니다. 네이티브 CSS에 추가된 변수, 중첩, 컨테이너 쿼리 등 강력한 기능들이 어떻게 Sass의 기능을 대체할 수 있는지 살펴보고, 과연 Sass를 충분히 대체할 수 있을지에 대해 생각해보는 기회가 되시길 바랍니다 :) &gt; https://ykss.netlify.app/translation/goodbye_sass_welcome_back_native_css/

ykss.netlify.app

잘 가 SASS 👋, 다시 만나 반가워 네이티브 CSS

출처: https://blog.axlight.com/posts/you-might-not-need-react-query-for-jotai/ Jotai 개발이 시작되었을 떄(v1이 출시되기 전), Jotai의 목표는 간단했습니다. 큰 상태 객체를 사용하는 useState와 useContext에서 종종 문제가 되었던 리렌더링을 최적화 하는 것이었습니다. 또한 Redux에 의해 대중화되어 널리 사용되고 있는 selector 함수를 사용하고 싶지 않았습니다. 초

[번역] Jotai에 React Query가 필요하지 않을 수도 있습니다

오늘 소개해드릴 글은 라인플러스의 김은빈님이 번역해주신 글입니다. Jotai를 만든 Daishi Kato의 글로 Jotai를 위한 데이터 페칭 API는 무엇일지 찾아가는 여정을 담은 짧은 글입니다. 명확한 결론을 짓는 글은 아니지만 가볍게 읽으며 `jotai/query` 패키지를 만든 목적이 무엇이었는지, Jotai로의 데이터 페칭은 무엇이 가능하고 무엇이 불가한지 등을 엿볼 수 있습니다.

직원

undefined

퍼블리셔 직무로 개발 현업을 경험 후, 현재 프론트개발 업무를 맡아 진행하고 있습니다, 
속도는 더디지만🙊 차근차근 원리를 이해하며 습득하는 과정을 좋아합니다,
타입스크립트를 좋아하며👍🏻, 리액트🍭와 바닐라 스크립트🥤을 공부하고 있습니다

NHN Edu 프론트엔드 개발자

최인혁

프론트엔드 개발자

인수

Jotai에 React Query가 필요하지 않을 수도 있습니다

Official Account를 개발하고 있습니다.

프런트엔드 개발자

프론트엔드 업무 인턴십을 수행했습니다. React를 이용해 설문조사 폼을 만드는 과제를 수행했습니다. 

프런트엔드 인턴쉽

TOAST UI 오픈소스 메인테이닝 업무를 수행했습니다.

JSP 기반의 환경에서 웹 페이지 퍼블리싱 업무를 주로 수행했습니다. jQuery와 HTML, CSS를 사용해 개발했습니다.

퍼블리셔 및 프런트엔드 개발자

컴퓨터 정보공학과

한정(Jung Han)

링크드인

블로그

효율적이게 일하는 것을 중요하게 여기며 팀에 도움이 되는 활동에 관심이 많습니다. 
Korean FE Article이란 프런트엔드 아티클 번역 활동을 운영하고 있습니다.
최근에는 AI를 통한 업무 효율을 높이는데 관심이 많습니다.

Jotai에 React Query가 필요하지 않을 수도 있습니다

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필