이 글에서는 리액트로 만든 웹의 핵심 웹 바이탈 지표, 특히 INP를 개선하는 몇 가지 최적화 기술을 살펴봅니다.

[번역] 리액트에서 INP를 효과적으로 최적화하는 5가지 팁

오늘은 네이버의 안샛별님이 번역해주신 글입니다.

프런트엔드 개발자가 주의를 기울여야 하는 웹 바이탈 지표들이 여럿 있습니다. 그중 INP는 사용자의 상호작용에 대한 전반적인 응답성을 나타내는 지표입니다. 클릭, 모달, 입력 등이 많아질수록 이 INP 지표는 사용자의 이탈률에 유의미한 관계가 있습니다. 이 글에서는 리액트 웹에서 INP를 효과적으로 최적화하는 방법을 5가지 설명합니다. 여러분의 웹에 적용 가능할지 확인해보세요!

글 링크: https://velog.io/@typo/5-tips-to-effectively-optimize-inp

오늘은 네이버의 안샛별님이 번역해주신 글입니다. 프런트엔드 개발자가 주의를 기울여야 하는 웹 바이탈 지표들이 여럿 있습니다. 그중 INP는 사용자의 상호작용에 대한 전반적인 응답성을 나타내는 지표입니다. 클릭, 모달, 입력 등이 많아질수록 이 INP 지표는 사용자의 이탈률에 유의미한 관계가 있습니다. 이 글에서는 리액트 웹에서 INP를 효과적으로 최적화하는 방법을 5가지 설명합니다. 여러분의 웹에 적용 가능할지 확인해보세요! 글 링크: https://velog.io/@typo/5-tips-to-effectively-optimize-inp

velog.io

리액트에서 INP를 효과적으로 최적화하는 5가지 팁

여러분 안녕하세요. 헬로 Bun의 저자 달레입니다.

오늘 차세대 자바스크립트 런타임 Bun v1.2가 출시되었습니다. 여러가지 업데이트가 있었지만 가장 놀라웠던 부분은 이제 Bun에서 PostgreSQL과 Amazon S3를 별다른 라이브러리 없이 그냥 바로 사용할 수 있다는 점입니다. 그냥 단순 지원되는 정도가 아니라 성능 측면에서 기존 라이브러리를 압살하네요. 예전부터 SQLite는 지원하고 있었고, 추후 MySQL까지 지원한다고 하는데요. 런타임 수준에서 앞으로 도대체 어디까지 가능할지 기대됩니다.

뿐만 아니라 패키지 설치 속도가 한층 더 빨라졌습니다. 지금도 미친듯이 빨라서 더 이상은 빨라질 수가 없다고 생각했는데 정말 대단한 것 같습니다. 패키지 잠금 파일의 형식이 다른 패키지 매니저들처럼 Json으로 바뀐 부분도 반가운 소식입니다. 또한 프론트엔드 개발이 쉽도록 특별한 설정 없이도 내장 번들러를 통해서 HTML 파일을 마치 일반 자바스크립트 모듈 불러오듯이 불러올 수 있다고 하네요.

자세한 업데이트 내용은 아래의 공식 자료를 참고하시기 바랍니다.

📺 동영상: https://youtu.be/uSzffuqfJQk
📝 포스팅: https://bun.sh/blog/bun-v1.2

여러분 안녕하세요. 헬로 Bun의 저자 달레입니다. 오늘 차세대 자바스크립트 런타임 Bun v1.2가 출시되었습니다. 여러가지 업데이트가 있었지만 가장 놀라웠던 부분은 이제 Bun에서 PostgreSQL과 Amazon S3를 별다른 라이브러리 없이 그냥 바로 사용할 수 있다는 점입니다. 그냥 단순 지원되는 정도가 아니라 성능 측면에서 기존 라이브러리를 압살하네요. 예전부터 SQLite는 지원하고 있었고, 추후 MySQL까지 지원한다고 하는데요. 런타임 수준에서 앞으로 도대체 어디까지 가능할지 기대됩니다. 뿐만 아니라 패키지 설치 속도가 한층 더 빨라졌습니다. 지금도 미친듯이 빨라서 더 이상은 빨라질 수가 없다고 생각했는데 정말 대단한 것 같습니다. 패키지 잠금 파일의 형식이 다른 패키지 매니저들처럼 Json으로 바뀐 부분도 반가운 소식입니다. 또한 프론트엔드 개발이 쉽도록 특별한 설정 없이도 내장 번들러를 통해서 HTML 파일을 마치 일반 자바스크립트 모듈 불러오듯이 불러올 수 있다고 하네요. 자세한 업데이트 내용은 아래의 공식 자료를 참고하시기 바랍니다. 📺 동영상: https://youtu.be/uSzffuqfJQk 📝 포스팅: https://bun.sh/blog/bun-v1.2

🥟 Bun v1.2 출시 소식 😍

깨알 광고 🙈 전국 온오프라인 서점에 "헬로 Bun" 절찰리 판매중! 😁
https://careerly.co.kr/comments/111998

프론트엔드 일타강사로 유명한 이정환님을 모시고 인터뷰를 진행했어요. 이번 편에선 정환님이 만들고 계신 한입 커뮤니티와 2025년 계획에 대해 들어봤어요.

아래 링크에서 자세한 이야기를 확인해보세요!

https://youtu.be/UkSHIIzMs2Q?si=S7sIDSNXMk0Y0eI-

프론트엔드 일타강사로 유명한 이정환님을 모시고 인터뷰를 진행했어요. 이번 편에선 정환님이 만들고 계신 한입 커뮤니티와 2025년 계획에 대해 들어봤어요. 아래 링크에서 자세한 이야기를 확인해보세요! https://youtu.be/UkSHIIzMs2Q?si=S7sIDSNXMk0Y0eI-

주니어 개발자를 위한 커뮤니티는 없나요?

The fastest online video converter, powered by WebCodecs. No upload required, no watermarks, no limits.

Remotion Convert - Fast video conversion in the browser

웹브라우저만으로 비디오 컨버트되니 편하네요
보통의 무료 프로그램과 다르게 광고없어서 너무 편안하네요

https://www.remotion.dev/convert

웹브라우저만으로 비디오 컨버트되니 편하네요보통의 무료 프로그램과 다르게 광고없어서 너무 편안하네요 https://www.remotion.dev/convert

www.remotion.dev

No 광고, 오직 로컬! 비디오 컨버트

연말정산 굳이 왜 회사에서 해주는건지 잘 모르겠다. 옛날엔 필요했겠지만, 지금은.

이제는 정상적인 회사나 직장인이라면 대부분 수입이 국가전산에 기록되고, 지출도 주로 카드를 사용하기 때문에, 대부분은 간소화 사이트에서 내려받은 그대로 신고가 되어서 굳이 회사가 중간에 있을 필요가 없지 않나?

기타 소득이나 지출이 있는 경우는 어차피 5월 종합소득세 기간에 각자 해야하고, 개인정보가 회사로 들어가는 것도 좀 껄끄럽기도하고.

세금에 대한 이해도를 높이기 위해서라도 직접 하는게 좋지 않나 싶음.

연말정산 굳이 왜 회사에서 해주는건지 잘 모르겠다. 옛날엔 필요했겠지만, 지금은. 이제는 정상적인 회사나 직장인이라면 대부분 수입이 국가전산에 기록되고, 지출도 주로 카드를 사용하기 때문에, 대부분은 간소화 사이트에서 내려받은 그대로 신고가 되어서 굳이 회사가 중간에 있을 필요가 없지 않나? 기타 소득이나 지출이 있는 경우는 어차피 5월 종합소득세 기간에 각자 해야하고, 개인정보가 회사로 들어가는 것도 좀 껄끄럽기도하고. 세금에 대한 이해도를 높이기 위해서라도 직접 하는게 좋지 않나 싶음.

아무래도 돈에 관련된 부분이니 꼼꼼하게 따져봐야 되는데 그걸 하기 힘든 직장인도 있다보니 그래서 회사가 분담해주지 않나 생각합니다.

Test tearing and branching in React concurrent rendering - dai-shi/will-this-react-global-state-work-in-concurrent-rendering

GitHub - dai-shi/will-this-react-global-state-work-in-concurrent-rendering: Test tearing and branching in React concurrent rendering

React 18에서 도입된 동시 렌더링(Concurrent Rendering)은 UI 업데이트 시 렌더링이 “중단되거나(branch), 뒤로 미뤄지거나(defer), 쪼개져(time slicing)” 여러 단계로 일어날 수 있도록 해줍니다. 그런데 이 구조가 전역 상태 관리 라이브러리와 함께 동작할 때, 이론적으로 “tearing”(상태가 일시적으로 어긋나는 현상)이 발생할 가능성이 있습니다.

소개할 레포는 Zustand, Jotai 등 유명 상태 관리 라이브러리 저자가 만든 저장소로, 여러 React 상태 관리 라이브러리들을 대상으로 다양한 상황에서 실험했을 때 동시 렌더링에서 tearing이 발생하는지 테스트 결과를 정리해둔 곳입니다.

테스트 결과, Jotai는 모든 테스트를 통과해 동시 렌더링 대응이 우수하고, Zustand는 외부 스토어 설계 특성상 일부 제한이 있지만 실무에서 감수 할만한 수준인 것 같습니다.
React Query처럼 서버 상태 관리 라이브러리도 테스트에 포함되어 있는데, 일부 케이스에서 tearing이 발생하는 점을 확인할 수 있었습니다.

자세한 내용은 저장소 링크를 확인해 주세요.

https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering

React 18에서 도입된 동시 렌더링(Concurrent Rendering)은 UI 업데이트 시 렌더링이 “중단되거나(branch), 뒤로 미뤄지거나(defer), 쪼개져(time slicing)” 여러 단계로 일어날 수 있도록 해줍니다. 그런데 이 구조가 전역 상태 관리 라이브러리와 함께 동작할 때, 이론적으로 “tearing”(상태가 일시적으로 어긋나는 현상)이 발생할 가능성이 있습니다. 소개할 레포는 Zustand, Jotai 등 유명 상태 관리 라이브러리 저자가 만든 저장소로, 여러 React 상태 관리 라이브러리들을 대상으로 다양한 상황에서 실험했을 때 동시 렌더링에서 tearing이 발생하는지 테스트 결과를 정리해둔 곳입니다. 테스트 결과, Jotai는 모든 테스트를 통과해 동시 렌더링 대응이 우수하고, Zustand는 외부 스토어 설계 특성상 일부 제한이 있지만 실무에서 감수 할만한 수준인 것 같습니다.React Query처럼 서버 상태 관리 라이브러리도 테스트에 포함되어 있는데, 일부 케이스에서 tearing이 발생하는 점을 확인할 수 있었습니다. 자세한 내용은 저장소 링크를 확인해 주세요. https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering

GitHub

상태 관리 라이브러리가 동시 렌더링 환경에서 잘 동작할까 궁금할 때

🗞️ OpenAI의 샘 알트먼이 1월 30일에 미국 정부 관리들을 위한 비공개 브리핑을 예약했다고 합니다.

OpenAI의 내부 소식통에 따르면 PhD 수준의 슈퍼 에이전트에 큰 돌파구가 올 것이라고 하며, OpenAI 직원들은 최근의 발전이 매우 흥분되지만, 겁이 나기도 한다고 말했다고 하는데요.

며칠 전 메타의 저커버그가 AI 엔지니어가 미드 레벨급으로 올라감에 따라 직원을 대거 해고한다고 했던 것도 있고.. 빅테크들에서는 내부적으로 뭔가 큰 진보를 경험하고 있는걸까요?

저는 AI의 발전을 대체로 긍정적으로 보는 사람이긴 합니다만, 뭔가.. 이정도 반응은 좀 무섭기도 하네요. 🤨🧐🤔😕

🗞️ OpenAI의 샘 알트먼이 1월 30일에 미국 정부 관리들을 위한 비공개 브리핑을 예약했다고 합니다. OpenAI의 내부 소식통에 따르면 PhD 수준의 슈퍼 에이전트에 큰 돌파구가 올 것이라고 하며, OpenAI 직원들은 최근의 발전이 매우 흥분되지만, 겁이 나기도 한다고 말했다고 하는데요. 며칠 전 메타의 저커버그가 AI 엔지니어가 미드 레벨급으로 올라감에 따라 직원을 대거 해고한다고 했던 것도 있고.. 빅테크들에서는 내부적으로 뭔가 큰 진보를 경험하고 있는걸까요? 저는 AI의 발전을 대체로 긍정적으로 보는 사람이긴 합니다만, 뭔가.. 이정도 반응은 좀 무섭기도 하네요. 🤨🧐🤔😕

인문학 책에 추천사를 쓰는 날이 다 오다니.. 아직 1월도 안지났지만, 과장안하고 이 책이 이미 제겐 올 해의 책이 될 것 같습니다. 정말 강력히 추천합니다. 선물용으로도 좋게 표지도 정말 예쁘게 나왔네요.

- 추천사 일부 -

이 책의 주제들은 인생이라는 복잡한 소프트웨어 속 오류 메시지를 하나하나 짚어가는 디버거(Debugger) 같 았다. 이 책이 100권 읽기 프로젝트의 첫 번째 책이었으면 좋았겠다는 생각을 했다. 나아가 스무 살 때 읽었다면 정말 좋았겠다고도 생각했다. 하지만 지금 읽어도 충분히 좋다.

100권의 자기계발서보다 이 책 한 권이 100배는 유익하다.

—

교보문고: https://product.kyobobook.co.kr/detail/S000215554421

예스24: https://m.yes24.com/Goods/Detail/141380817

알라딘: https://www.aladin.co.kr/m/mproduct.aspx?ItemId=355864678

인문학 책에 추천사를 쓰는 날이 다 오다니.. 아직 1월도 안지났지만, 과장안하고 이 책이 이미 제겐 올 해의 책이 될 것 같습니다. 정말 강력히 추천합니다. 선물용으로도 좋게 표지도 정말 예쁘게 나왔네요. - 추천사 일부 - 이 책의 주제들은 인생이라는 복잡한 소프트웨어 속 오류 메시지를 하나하나 짚어가는 디버거(Debugger) 같 았다. 이 책이 100권 읽기 프로젝트의 첫 번째 책이었으면 좋았겠다는 생각을 했다. 나아가 스무 살 때 읽었다면 정말 좋았겠다고도 생각했다. 하지만 지금 읽어도 충분히 좋다. 100권의 자기계발서보다 이 책 한 권이 100배는 유익하다. — 교보문고: https://product.kyobobook.co.kr/detail/S000215554421 예스24: https://m.yes24.com/Goods/Detail/141380817 알라딘: https://www.aladin.co.kr/m/mproduct.aspx?ItemId=355864678

📚 스무 살에 알았더라면 좋았을 철학의 위로

Introduction Jotai is developed to solve an extra re-render issue with React Context. A major challenge in its development has been the support of both Suspense and Concurrent rendering. Otherwise, it would have been a simpler implementation and its implementation would closely resemble that of any observable-like libraries.
As of writing, Jotai is fully compatible with Suspense and Concurrent rendering with some exceptions. There’s a repo to evaluate some details.

Why useSyncExternalStore Is Not Used in Jotai

상태 관리 라이브러리인 Zustand, Jotai, Valtio의 저자가 쓴 글 중 흥미로운 글이 있어 소개드립니다. 이 글에서는 React 18에서 제공하는
useSyncExternalStore
를 왜 Jotai가 사용하지 않았는지에 대해서 자세히 설명하고 있습니다.

결론적으로, Jotai는 React의 동시 렌더링(Concurrent Rendering) 기능과 최대한 매끄럽게 호환되도록 하기 위해
useSyncExternalStore
대신
useState
를 모델로 한 자체적인 Atom 기반 상태 관리 방식을 채택했습니다.

반면,
useSyncExternalStore
를 사용하는 Zustand의 경우, 동시 렌더링(ex:
useTransition
)을 사용할 때 UI 이슈(예:
isPending
대신
Suspense
의 fallback UI가 표시됨)가 존재합니다.

이는 Zustand가 React 컴포넌트와는 별개로 독립된 스토어로 동작하도록 설계되었기 때문에, 완벽한 동시 렌더링 연동이 어렵기 때문입니다. 외부 스토어로 설계된 특성 상 어느 정도의 임시적인 UI 불일치(temporary tearing) 가능성은 감안하는 것입니다. (역시 은총알은 없네요)
결국, Zustand는 외부 스토어 접근 방식을 그대로 유지하는 대신 약간의 동시 렌더링 이슈를 감수하는 편이고, Jotai는 React 내부 상태(
useState
) 모델을 따르면서
useTransition
같은 동시 렌더링 기능을 더욱 안정적으로 지원하는 쪽을 택했다는 점이 핵심입니다. (서로가 trade-off인 관계)

자세한 내용은 원문 블로그를 확인해 보세요.

https://blog.axlight.com/posts/why-use-sync-external-store-is-not-used-in-jotai/

상태 관리 라이브러리인 Zustand, Jotai, Valtio의 저자가 쓴 글 중 흥미로운 글이 있어 소개드립니다. 이 글에서는 React 18에서 제공하는 <code >useSyncExternalStore</code>를 왜 Jotai가 사용하지 않았는지에 대해서 자세히 설명하고 있습니다. 결론적으로, Jotai는 React의 동시 렌더링(Concurrent Rendering) 기능과 최대한 매끄럽게 호환되도록 하기 위해 <code >useSyncExternalStore</code> 대신 <code >useState</code>를 모델로 한 자체적인 Atom 기반 상태 관리 방식을 채택했습니다. 반면, <code >useSyncExternalStore</code>를 사용하는 Zustand의 경우, 동시 렌더링(ex: <code >useTransition</code>)을 사용할 때 UI 이슈(예: <code >isPending</code> 대신 <code >Suspense</code>의 fallback UI가 표시됨)가 존재합니다. 이는 Zustand가 React 컴포넌트와는 별개로 독립된 스토어로 동작하도록 설계되었기 때문에, 완벽한 동시 렌더링 연동이 어렵기 때문입니다. 외부 스토어로 설계된 특성 상 어느 정도의 임시적인 UI 불일치(temporary tearing) 가능성은 감안하는 것입니다. (역시 은총알은 없네요)결국, Zustand는 외부 스토어 접근 방식을 그대로 유지하는 대신 약간의 동시 렌더링 이슈를 감수하는 편이고, Jotai는 React 내부 상태(<code >useState</code>) 모델을 따르면서 <code >useTransition</code> 같은 동시 렌더링 기능을 더욱 안정적으로 지원하는 쪽을 택했다는 점이 핵심입니다. (서로가 trade-off인 관계) 자세한 내용은 원문 블로그를 확인해 보세요. https://blog.axlight.com/posts/why-use-sync-external-store-is-not-used-in-jotai/

Daishi Kato's blog

왜 Jotai는 useSyncExternalStore를 사용하지 않았을까

최근 FBI와 CISA가 발표한 '제품 보안 나쁜 사례' 문서를 살펴봤습니다.
이 가이드라인은 소프트웨어 제조업체들이 피해야 할 13가지 주요 보안 위험 사례를 제시하고 있는데요, 특히 중요 인프라나 국가 핵심 기능과 관련된 소프트웨어에 초점을 맞추고 있습니다.

주요 내용을 크게 세 가지 카테고리로 나누어 설명하고 있습니다.

 1. 제품 속성: 메모리 안전성이 검증되지 않은 C/C++ 사용 지양, SQL/명령어 인젝션 취약점 방지, 기본 패스워드 사용 금지
 2. 보안 기능: 다중인증(MFA) 의무 지원, 침입 증거 수집을 위한 로깅 기능 구현
 3. 조직 프로세스: CVE 적시 발행, 취약점 공개 정책(VDP) 수립, 제품 지원 기간 명확한 커뮤니케이션

이 가이드라인은 강제성은 없지만, 현대 소프트웨어 개발에서 반드시 고려해야 할 보안 요소들을 잘 정리하고 있습니다. 개발자분들에게 일독을 추천드립니다.

https://www.ic3.gov/CSA/2025/250117.pdf

최근 FBI와 CISA가 발표한 '제품 보안 나쁜 사례' 문서를 살펴봤습니다.이 가이드라인은 소프트웨어 제조업체들이 피해야 할 13가지 주요 보안 위험 사례를 제시하고 있는데요, 특히 중요 인프라나 국가 핵심 기능과 관련된 소프트웨어에 초점을 맞추고 있습니다. 주요 내용을 크게 세 가지 카테고리로 나누어 설명하고 있습니다. <ol ><li>제품 속성: 메모리 안전성이 검증되지 않은 C/C++ 사용 지양, SQL/명령어 인젝션 취약점 방지, 기본 패스워드 사용 금지</li><li>보안 기능: 다중인증(MFA) 의무 지원, 침입 증거 수집을 위한 로깅 기능 구현</li><li>조직 프로세스: CVE 적시 발행, 취약점 공개 정책(VDP) 수립, 제품 지원 기간 명확한 커뮤니케이션</li></ol> 이 가이드라인은 강제성은 없지만, 현대 소프트웨어 개발에서 반드시 고려해야 할 보안 요소들을 잘 정리하고 있습니다. 개발자분들에게 일독을 추천드립니다. https://www.ic3.gov/CSA/2025/250117.pdf

FBI & CISA의 '제품 보안 나쁜 사례' 가이드라인 살펴보기

변경하기 쉬운 프론트엔드 코드를 위한 지침서

Frontend Fundamentals

토스에서 프론트엔드 코드를 위한 지침서를 공개했습니다.

https://frontend-fundamentals.com

GitHub를 통해 공개된 문서를 기반으로 하고 있는 웹사이트입니다. 아직 기여 가이드는 만들어지지 않았네요.

하지만 GitHub Discussions 페이지에서 의견을 교류할 수 있다고 합니다.

토스에서 프론트엔드 코드를 위한 지침서를 공개했습니다. https://frontend-fundamentals.com GitHub를 통해 공개된 문서를 기반으로 하고 있는 웹사이트입니다. 아직 기여 가이드는 만들어지지 않았네요. 하지만 GitHub Discussions 페이지에서 의견을 교류할 수 있다고 합니다.

frontend-fundamentals.com

[1] 해야 할일 리스트 만들기 > [2] 우선 순위 정하기 > [3] 정해진 시간 안에 수행하기 > [4] 피드백 과정 거치기

시간이 지날수록, 시간은 금이라는 말이 점점 실감이 납니다.
무엇을 제대로 한것도 없는데 벌써 2025년 1월의 중반을 지나고 있으니 말입니다.

올해 4월에 대학원 졸업과 취업 준비라는 큰 이벤트를 앞둔 저에게도 앞으로 해나가야 할 다양한 숙제들과 프로젝트를 생각하고 나면 벌써부터 마음이 무거워지고 한숨이 절로 납니다.

하지만, 이대로 그냥 한숨만 쉬면 포기하고 있을 수는 없죠. 우리의 앞길에 놓인 중요한 프로젝트들을 성공적으로 수행하기 위해 제가 작년부터 사용하고 있는 방법을 공유해보려 합니다.

저는 매일 약 4-5개의 투두 리스트(To-do List)를 만들고 그 리스트를 하루 동안 수행하고 있습니다. 그리고 작년까지 약 70개의 해야 할 업무 및 일정들을 큰 문제없이 잘 처리해왔습니다.

그럼 첫번째 단계인 [1] 해야 할일 정하기 부터 이야기해 볼까요?

[1] 해야 할일 정하기

매일 여러분들은 해야 할 일들 리스트를 의식적으로 만들고 수행하고 있나요?
해야 할일이 정해진 삶이란 단조롭고 기계적이라고 느낄수도 모르겠습니다.
하지만 실제로 투두 리스트를 만들고 나면, 마음이 생각보다 편해지는 걸 느낄 수 있습니다.

특히 저처럼 하고 싶은 것들이 많은 욕심쟁이들에게는
하루하루가 매일 다른 일들을 벌려놓고 흐지부지 끝나는 경우들이 많습니다.

이 때 우리가 그날 해야 하는 일들을 정하는 것이 도움이 될 수 있습니다.
이 때의 포인트는 리스트는 5개가 넘어가면 안된다는 점입니다.

여러분들이 5개 이상의 리스트를 만드는 순간,
그 때부터 여러분들의 하루는 롤러코스터가 될 가능성이 매우 높습니다.

하루 정도는 괜찮지만, 매일 그런 삶을 살고 싶지는 않으시겠죠? 해야 할일 리스트를 만들어보세요. 사소한 것이라도 좋습니다, 만들면서 여러분들은 깨닫게 될거에요.

우리가 하루 동안 정말 어떤 일들을 하고 있는지를 말이죠.

다음 편에서 [2] 우선 순위 정하기에 대해 이야기 해볼게요 :)

[1] 해야 할일 리스트 만들기 &gt; [2] 우선 순위 정하기 &gt; [3] 정해진 시간 안에 수행하기 &gt; [4] 피드백 과정 거치기 시간이 지날수록, 시간은 금이라는 말이 점점 실감이 납니다. 무엇을 제대로 한것도 없는데 벌써 2025년 1월의 중반을 지나고 있으니 말입니다. 올해 4월에 대학원 졸업과 취업 준비라는 큰 이벤트를 앞둔 저에게도 앞으로 해나가야 할 다양한 숙제들과 프로젝트를 생각하고 나면 벌써부터 마음이 무거워지고 한숨이 절로 납니다. 하지만, 이대로 그냥 한숨만 쉬면 포기하고 있을 수는 없죠. 우리의 앞길에 놓인 중요한 프로젝트들을 성공적으로 수행하기 위해 제가 작년부터 사용하고 있는 방법을 공유해보려 합니다. 저는 매일 약 4-5개의 투두 리스트(To-do List)를 만들고 그 리스트를 하루 동안 수행하고 있습니다. 그리고 작년까지 약 70개의 해야 할 업무 및 일정들을 큰 문제없이 잘 처리해왔습니다. 그럼 첫번째 단계인 [1] 해야 할일 정하기 부터 이야기해 볼까요? [1] 해야 할일 정하기 매일 여러분들은 해야 할 일들 리스트를 의식적으로 만들고 수행하고 있나요? 해야 할일이 정해진 삶이란 단조롭고 기계적이라고 느낄수도 모르겠습니다. 하지만 실제로 투두 리스트를 만들고 나면, 마음이 생각보다 편해지는 걸 느낄 수 있습니다. 특히 저처럼 하고 싶은 것들이 많은 욕심쟁이들에게는 하루하루가 매일 다른 일들을 벌려놓고 흐지부지 끝나는 경우들이 많습니다. 이 때 우리가 그날 해야 하는 일들을 정하는 것이 도움이 될 수 있습니다. 이 때의 포인트는 리스트는 5개가 넘어가면 안된다는 점입니다. 여러분들이 5개 이상의 리스트를 만드는 순간, 그 때부터 여러분들의 하루는 롤러코스터가 될 가능성이 매우 높습니다. 하루 정도는 괜찮지만, 매일 그런 삶을 살고 싶지는 않으시겠죠? 해야 할일 리스트를 만들어보세요. 사소한 것이라도 좋습니다, 만들면서 여러분들은 깨닫게 될거에요. 우리가 하루 동안 정말 어떤 일들을 하고 있는지를 말이죠. 다음 편에서 [2] 우선 순위 정하기에 대해 이야기 해볼게요 :)

성공적인 프로젝트 관리의 4단계 프로세스

스크리닝, 코딩, 시스템 디자인, Behavioral 인터뷰, 팀 매칭, 오퍼

Meta SWE 면접 합격 후기

요즘 채용이 조심스럽게 되살아나고 있고 메타도 채용을 많이 하고 있는거 같습니다. 

블라인드 앱 보면 주위 개발자 25%가 메타 면접을 보고 있는거 같다는 글도 보이는데요. 저도 메타 인터뷰 관련해서 DM을 많이 받았습니다. 특히 다른 회사에는 없는 '팀 매칭' 단계에 대해서 질문이 많았는데 이 부분 포함해서 좀 더 상세히 글로 정리했습니다.

https://www.nyprogrammer.com/p/meta-swe-interview

요즘 채용이 조심스럽게 되살아나고 있고 메타도 채용을 많이 하고 있는거 같습니다.&nbsp; 블라인드 앱 보면 주위 개발자 25%가 메타 면접을 보고 있는거 같다는 글도 보이는데요. 저도 메타 인터뷰 관련해서 DM을 많이 받았습니다. 특히 다른 회사에는 없는 '팀 매칭' 단계에 대해서 질문이 많았는데 이 부분 포함해서 좀 더 상세히 글로 정리했습니다. https://www.nyprogrammer.com/p/meta-swe-interview

www.nyprogrammer.com

“혼자서 앱을 개발해 나간다는 게 쉬운 작업이 아닌데, 혹시 스터디나 모임도 활용하셨는지 궁금합니다.”
“활용하지 않습니다.”

스터디그룹에 참여해 보지 않았던 것은 아닙니다.
20대에는 무슨 스터디만 한다 하면 어떻게든 시간을 내서 참여했습니다.

내가 발표할 시간이 되면 스트레스받아 가면서 시간에 쫓겨 자료를 만들고…
남들 발표 시간에는 편안한 마음으로 듣기도 하고…
스터디에 많이 참여하니 항상 바쁘게 쪼개서 시간을 썼는데, 그에 비해 배움은 크지 않은 것 같았습니다.
이상하다. 마치 헛공부만 하고 있는 느낌이랄까…?
이런 경험이 반복되면서 스터디에 참여하는 것을 점점 주저하게 됐습니다.

스터디 그룹에 참여하면 누가 떠먹여 주지 않을까 하는 생각이 그렇게 만들었던 건 아닐까?
어차피 공부는 누가 떠먹여 주는 것이 아니라 내가 해야 하는 것인데.

가만히 생각해 보면 제대로 학습했다는 느낌이 들었던 순간은 언제나 제 책상 앞이었습니다.
혼자 끙끙대면서 스스로에게 질문하고 답하는 시간을 더 많이 갖고 싶습니다.

“혼자서 앱을 개발해 나간다는 게 쉬운 작업이 아닌데, 혹시 스터디나 모임도 활용하셨는지 궁금합니다.”“활용하지 않습니다.” 스터디그룹에 참여해 보지 않았던 것은 아닙니다.20대에는 무슨 스터디만 한다 하면 어떻게든 시간을 내서 참여했습니다. 내가 발표할 시간이 되면 스트레스받아 가면서 시간에 쫓겨 자료를 만들고…남들 발표 시간에는 편안한 마음으로 듣기도 하고…스터디에 많이 참여하니 항상 바쁘게 쪼개서 시간을 썼는데, 그에 비해 배움은 크지 않은 것 같았습니다.이상하다. 마치 헛공부만 하고 있는 느낌이랄까…?이런 경험이 반복되면서 스터디에 참여하는 것을 점점 주저하게 됐습니다. 스터디 그룹에 참여하면 누가 떠먹여 주지 않을까 하는 생각이 그렇게 만들었던 건 아닐까?어차피 공부는 누가 떠먹여 주는 것이 아니라 내가 해야 하는 것인데. 가만히 생각해 보면 제대로 학습했다는 느낌이 들었던 순간은 언제나 제 책상 앞이었습니다.혼자 끙끙대면서 스스로에게 질문하고 답하는 시간을 더 많이 갖고 싶습니다.

스터디 그룹에 참여하지 않는 이유

우연히 보게 된 유투브(링크는 댓글 참고)인데 서울대내에서 어떤 학생들이 학점이 좋은지 그리고 공통적인 학습방법이 있는지 찾아보려는 연구에 관한 이야기이다. 뭔가 도움이되는 흥미로운 결과를 기대하고 시작한 이 연구는 기대와는 완전히 다르게 진행되었다.

학점을 좋게 받는 학생들의 공통점은 질문을 하거나 본인의 생각을 가지려고 하는게 아니라 주입식으로 교수님의 강의를 달달 외운 경우였다. 교수님의 의견에 동의하지 않는 경우 시험 문제에서 본인의 의견을 그래도 주장하겠냐는 질문에 다들 점수를 잘 받기 위해서 교수님의 생각을 적겠다고 답을 했다.

동일한 연구자가 미국 미시간 대학의 학생들을 대상으로 조사를 해보니 강의시간에 교수님의 이야기를 그대로 적는 사람들은 거의 없었고 대부분 흥미로운 부분이나 자기의 생각을 필기했다고 답했고 교수님 강의 필기와 학점 간에 별다른 상관관계가 없었다. 또한 인터뷰에 응한 모든 학생들이 교수님의 의견과 본인의 의견이 다른 경우 그래도 본인의 의견을 적겠다고 했다.
영상 중 아래 문장들이 참 슬프게 다가왔다.

"질문왕 승현이는 이제 더 이상 질문을 하지 않습니다"
"너는 어떠한 생각도 가져서는 안되고 네 생각이 아무리 좋아도 교수님과 다르면 버려야 되고 교수님의 말씀을 단 한마디도 빼놓지 않고 적어야 하고 이게 서울대학교의 교육이라고 과연 이야기할 수 있을까?"

두 학교 학생들은 모두 열심히 하지만 방향이 다르며 (수용적 vs. 비판적) 결국 학점이란 게임의 룰이 다르다보니 결국 학생들의 성향까지 변화시킨다. 정답을 찾으라는 교육과 아닌 교육의 차이점이다.

이 유튜브 비디오는 대학생으로 국한해서 연구를 했지만 개발자를 대상으로 해도 크게 다를지 않을 것 같다. 사람의 능력은 한국이나 미국이나 크게 다르다고 생각하지 않는다. 질문을 꺼리는 환경과 장려하는 환경, 순응하기를 원하는 환경과 비판을 허용하는 환경, 환경의 차이가 사람의 성장에 차이를 가져온다.

우연히 보게 된 유투브(링크는 댓글 참고)인데 서울대내에서 어떤 학생들이 학점이 좋은지 그리고 공통적인 학습방법이 있는지 찾아보려는 연구에 관한 이야기이다. 뭔가 도움이되는 흥미로운 결과를 기대하고 시작한 이 연구는 기대와는 완전히 다르게 진행되었다. 학점을 좋게 받는 학생들의 공통점은 질문을 하거나 본인의 생각을 가지려고 하는게 아니라 주입식으로 교수님의 강의를 달달 외운 경우였다. 교수님의 의견에 동의하지 않는 경우 시험 문제에서 본인의 의견을 그래도 주장하겠냐는 질문에 다들 점수를 잘 받기 위해서 교수님의 생각을 적겠다고 답을 했다. 동일한 연구자가 미국 미시간 대학의 학생들을 대상으로 조사를 해보니 강의시간에 교수님의 이야기를 그대로 적는 사람들은 거의 없었고 대부분 흥미로운 부분이나 자기의 생각을 필기했다고 답했고 교수님 강의 필기와 학점 간에 별다른 상관관계가 없었다. 또한 인터뷰에 응한 모든 학생들이 교수님의 의견과 본인의 의견이 다른 경우 그래도 본인의 의견을 적겠다고 했다.영상 중 아래 문장들이 참 슬프게 다가왔다. "질문왕 승현이는 이제 더 이상 질문을 하지 않습니다""너는 어떠한 생각도 가져서는 안되고 네 생각이 아무리 좋아도 교수님과 다르면 버려야 되고 교수님의 말씀을 단 한마디도 빼놓지 않고 적어야 하고 이게 서울대학교의 교육이라고 과연 이야기할 수 있을까?" 두 학교 학생들은 모두 열심히 하지만 방향이 다르며 (수용적 vs. 비판적) 결국 학점이란 게임의 룰이 다르다보니 결국 학생들의 성향까지 변화시킨다. 정답을 찾으라는 교육과 아닌 교육의 차이점이다. 이 유튜브 비디오는 대학생으로 국한해서 연구를 했지만 개발자를 대상으로 해도 크게 다를지 않을 것 같다. 사람의 능력은 한국이나 미국이나 크게 다르다고 생각하지 않는다. 질문을 꺼리는 환경과 장려하는 환경, 순응하기를 원하는 환경과 비판을 허용하는 환경, 환경의 차이가 사람의 성장에 차이를 가져온다.

서울대안에서는 누가 A+를 받을까?

원문: https://frontendatscale.com/issues/17

(번역) 프런트엔드 아키텍처 시각화하기

오늘은 12월 이진우님이 공유해주신 2024 프론트엔드 뉴스 한 방에 몰아 보기 글에서 알게 된 C4 모델을 활용해 아키텍처를 시각화하는 방법에 대한 글을 번역해 봤습니다. C4 모델은 소프트웨어 시스템을 다양한 추상화 수준(시스템 컨텍스트, 컨테이너, 컴포넌트, 코드)에서 시각화하는 방법론으로 다양한 분야에서 사용하고 있는데요. 이 글에서는 저자가 프런트엔드 계층을 추상화 수준에 맞춰 정리하고 시각화하는 방법에 대해 이야기하고 있습니다. 도움이 되셨으면 좋겠습니다. 😃

링크: https://bit.ly/3WdXidn

오늘은 12월 이진우님이 공유해주신 2024 프론트엔드 뉴스 한 방에 몰아 보기 글에서 알게 된 C4 모델을 활용해 아키텍처를 시각화하는 방법에 대한 글을 번역해 봤습니다. C4 모델은 소프트웨어 시스템을 다양한 추상화 수준(시스템 컨텍스트, 컨테이너, 컴포넌트, 코드)에서 시각화하는 방법론으로 다양한 분야에서 사용하고 있는데요. 이 글에서는 저자가 프런트엔드 계층을 추상화 수준에 맞춰 정리하고 시각화하는 방법에 대해 이야기하고 있습니다. 도움이 되셨으면 좋겠습니다. 😃 링크: https://bit.ly/3WdXidn

bit.ly

프런트엔드 아키텍처 시각화하기

Guidelines for easily modifiable frontend code

https://frontend-fundamentals.com/

"프론트엔드에서 '좋은 코드'란 '변경하기 쉬운 코드'"라는 기준점을 제시하면서, 가독성, 예측 가능성, 응집도, 결합도 4가지 기준을 바탕으로 좋은 코드를 작성하는 전략에 대해서 소개하는 문서입니다.

읽어보니 이론적인 내용 보다는 전반적으로 실무에서 사용할 법한 코드 예시를 중점으로 소개하고 있어서 이해하기가 쉬웠습니다.

코드 리뷰할 때 참고 문서로 활용하기도 좋을 것 같습니다.

https://frontend-fundamentals.com/ "프론트엔드에서 '좋은 코드'란 '변경하기 쉬운 코드'"라는 기준점을 제시하면서, 가독성, 예측 가능성, 응집도, 결합도 4가지 기준을 바탕으로 좋은 코드를 작성하는 전략에 대해서 소개하는 문서입니다. 읽어보니 이론적인 내용 보다는 전반적으로 실무에서 사용할 법한 코드 예시를 중점으로 소개하고 있어서 이해하기가 쉬웠습니다. 코드 리뷰할 때 참고 문서로 활용하기도 좋을 것 같습니다.

토스에서 만든 FE 코드 지침서

원고지 글자수를 쉽게 계산하세요. 원고지 매수 자동 계산, 글자수 세기, A4 용지 변환까지 한번에 해결하는 무료 원고지 계산기입니다.

원고지 계산기 - 글자수 세기, 원고지 매수 자동 변환

"마케터 -> 개발자"로 살다가,
24년 2월에 퇴사를 했습니다.

그 후 완전 새로운 일을 시작했는데요. 다음과 같습니다.

1. 고시원 2개 인수(1개는 24년 12월에 매도했습니다)
2. 파티룸 창업 후 운영중(네이버지도에 "건대 오아시" 검색!)
3. 일은 아니지만 "결혼"

-

비교적 시간이 많아져서(위 사업은 자동사냥이 되버림)
올해는 해보고 싶은 것(하고 있는 것)도 자연스레 많아졌습니다.
아래와 같이요!

1. 단편 소설 1개 쓰기(꾸준히 글 쓰는중)
2. 일본인과 대화하기(학원 다니고 있음)
3. 트레이딩 공부해서 10일 연속 수익 내보기(강의 듣고 있음)

-

무튼, 글을 쓰면서 문학상도 한번 넣어보고 싶어서 봤는데,
대부분 문학상이 원고지 200자 기준 N매 따위의 조건이 있더라고요..!

전(?)개발자긴 했지만 안 쓰니 까먹어서..
cursor의 도움으로 하루이틀만에 급하게 "원고지계산기"라는 앱을 만들었습니다.
다크모드는 대응 안됐는데, 이대로도 괜찮아서(?) 쓰려고 합니다.
무튼 cursor가 뚝딱해주는 거 보고 개발하기 쉬워졌다(?) 생각이 들었네요.

"마케터 -&gt; 개발자"로 살다가, 24년 2월에 퇴사를 했습니다. 그 후 완전 새로운 일을 시작했는데요. 다음과 같습니다. 1. 고시원 2개 인수(1개는 24년 12월에 매도했습니다) 2. 파티룸 창업 후 운영중(네이버지도에 "건대 오아시" 검색!) 3. 일은 아니지만 "결혼" - 비교적 시간이 많아져서(위 사업은 자동사냥이 되버림) 올해는 해보고 싶은 것(하고 있는 것)도 자연스레 많아졌습니다. 아래와 같이요! 1. 단편 소설 1개 쓰기(꾸준히 글 쓰는중) 2. 일본인과 대화하기(학원 다니고 있음) 3. 트레이딩 공부해서 10일 연속 수익 내보기(강의 듣고 있음) - 무튼, 글을 쓰면서 문학상도 한번 넣어보고 싶어서 봤는데, 대부분 문학상이 원고지 200자 기준 N매 따위의 조건이 있더라고요..! 전(?)개발자긴 했지만 안 쓰니 까먹어서.. cursor의 도움으로 하루이틀만에 급하게 "원고지계산기"라는 앱을 만들었습니다. 다크모드는 대응 안됐는데, 이대로도 괜찮아서(?) 쓰려고 합니다.무튼 cursor가 뚝딱해주는 거 보고 개발하기 쉬워졌다(?) 생각이 들었네요.

www.xn--989a2bt9ciz7b65g7qe.kr

💠 cursor로 하루이틀만에 간단한 앱 만든 이야기

React로 단일 페이지 애플리케이션(SPA)을 개발하고 Spring Boot를 통해 배포하는 과정에서, 사용자들이 특정 페이지로 이동한 후 새로고침을 하면 404 오류가 발생하는 경우가 있습니다. 이는 React와 Spring Boot가 라우팅을 처리하는 방식의 차이에서 비롯된 문제로, 많은 개발자가 마주하는 흔한 이슈입니다.
 
문제 상황: 새로고침 시 404 오류 발생
React 애플리케이션에서 BrowserRouter를 사용하여 클라이언트 사이드 라우팅(Client-Side Routing)을 처리할 때, 새로고침 시 다음과 같은 404 오류가 발생할 수 있습니다.
GET https://example.com/purchased-product 404 (Not Found)

이 상황은 브라우저가 /purchased-product 경로에 대한 요청을 서버로 보냈지만, Spring Boot 서버가 해당 경로를 처리하는 방법을 알지 못해 404 Not Found를 반환했기 때문에 발생합니다.
 
React는 클라이언트에서 모든 라우팅을 처리하도록 설계되었으나, 브라우저는 새로고침하거나 직접 URL을 입력했을 때 서버에 요청을 보내는 기본 동작을 따릅니다. 따라서 Spring Boot 서버가 이러한 요청을 적절히 처리하지 않으면 위와 같은 문제가 발생합니다.
 
문제 원인: React와 Spring Boot 라우팅 처리 방식의 차이
[React의 클라이언트 사이드 라우팅]
React에서 BrowserRouter는 브라우저의 주소(URL)를 변경하지만 실제로 서버에 요청을 보내지 않습니다. 대신, 클라이언트 측에서 라우팅이 이루어지며, 경로에 매핑된 React 컴포넌트를 렌더링합니다.
 * URL 변경은 브라우저 주소창에서만 이루어집니다.
 * React 내부에서 지정된 컴포넌트가 로드됩니다.
 
[브라우저의 기본 동작]
반면, 브라우저에서 새로고침하거나 URL을 직접 입력하면 해당 경로에 대한 요청을 서버로 보냅니다.
 * 서버는 경로에 대해 정의된 처리가 없는 경우, 404 Not Found를 반환합니다.
 * 이는 서버가 클라이언트 사이드 라우팅 경로에 대해 무지한 상태이기 때문입니다.
 
React와 브라우저의 동작 차이를 이해했으니, 이제 이를 해결하기 위한 Spring Boot 설정 방법을 살펴보겠습니다.
 
해결 방법: Spring Boot에서 React 경로 처리하기
Spring Boot 서버가 React 애플리케이션의 모든 경로를 처리하도록 설정하면, 브라우저가 서버로 보내는 모든 요청에 대해 React의 index.html 파일을 반환할 수 있습니다. 이렇게 하면 브라우저는 React 애플리케이션을 다시 로드하고, 클라이언트 측에서 올바른 경로를 렌더링할 수 있습니다.
 
[구현 방법]
Spring Boot에서 React 라우팅을 처리하기 위한 WebController를 다음과 같이 작성할 수 있습니다.
import org.springframework.boot.web.servlet.error.ErrorController;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
public class WebController implements ErrorController {

    @GetMapping({
        "/purchased-product"
    })
    public String index() {
        // Spring Boot가 React의 index.html 파일을 반환하도록 설정
        // index.html은 /resources/static 또는 /resources/public에 위치
        return "index.html";
    }
}

 위 코드는 React 애플리케이션의 경로를 명시적으로 나열하고, 해당 경로에 대한 요청이 들어오면 index.html을 반환하도록 설정합니다. 이렇게 하면 React의 라우터가 클라이언트 측에서 경로를 처리할 수 있는 환경을 제공하게 됩니다.
 
결론
Spring Boot와 React를 통합할 때, 클라이언트 사이드 라우팅으로 인해 발생하는 새로고침 404 오류는 React와 브라우저의 기본 동작 차이에서 발생합니다. 서버에서 React의 모든 경로를 처리하도록 설정함으로써 문제를 쉽게 해결할 수 있습니다.

React로 단일 페이지 애플리케이션(SPA)을 개발하고 Spring Boot를 통해 배포하는 과정에서, 사용자들이 특정 페이지로 이동한 후 새로고침을 하면 404 오류가 발생하는 경우가 있습니다. 이는 React와 Spring Boot가 라우팅을 처리하는 방식의 차이에서 비롯된 문제로, 많은 개발자가 마주하는 흔한 이슈입니다.&nbsp;문제 상황: 새로고침 시 404 오류 발생React 애플리케이션에서 BrowserRouter를 사용하여 클라이언트 사이드 라우팅(Client-Side Routing)을 처리할 때, 새로고침 시 다음과 같은 404 오류가 발생할 수 있습니다.<pre ><code class="language-bash">GET https://example.com/purchased-product 404 (Not Found)</code></pre>이 상황은 브라우저가 /purchased-product 경로에 대한 요청을 서버로 보냈지만, Spring Boot 서버가 해당 경로를 처리하는 방법을 알지 못해 404 Not Found를 반환했기 때문에 발생합니다.&nbsp;React는 클라이언트에서 모든 라우팅을 처리하도록 설계되었으나, 브라우저는 새로고침하거나 직접 URL을 입력했을 때 서버에 요청을 보내는 기본 동작을 따릅니다. 따라서 Spring Boot 서버가 이러한 요청을 적절히 처리하지 않으면 위와 같은 문제가 발생합니다.&nbsp;문제 원인: React와 Spring Boot 라우팅 처리 방식의 차이[React의 클라이언트 사이드 라우팅]React에서 BrowserRouter는 브라우저의 주소(URL)를 변경하지만 실제로 서버에 요청을 보내지 않습니다. 대신, 클라이언트 측에서 라우팅이 이루어지며, 경로에 매핑된 React 컴포넌트를 렌더링합니다.<ul ><li>URL 변경은 브라우저 주소창에서만 이루어집니다.</li><li>React 내부에서 지정된 컴포넌트가 로드됩니다.</li></ul>&nbsp;[브라우저의 기본 동작]반면, 브라우저에서 새로고침하거나 URL을 직접 입력하면 해당 경로에 대한 요청을 서버로 보냅니다.<ul ><li>서버는 경로에 대해 정의된 처리가 없는 경우, 404 Not Found를 반환합니다.</li><li>이는 서버가 클라이언트 사이드 라우팅 경로에 대해 무지한 상태이기 때문입니다.</li></ul>&nbsp;React와 브라우저의 동작 차이를 이해했으니, 이제 이를 해결하기 위한 Spring Boot 설정 방법을 살펴보겠습니다.&nbsp;해결 방법: Spring Boot에서 React 경로 처리하기Spring Boot 서버가 React 애플리케이션의 모든 경로를 처리하도록 설정하면, 브라우저가 서버로 보내는 모든 요청에 대해 React의 index.html 파일을 반환할 수 있습니다. 이렇게 하면 브라우저는 React 애플리케이션을 다시 로드하고, 클라이언트 측에서 올바른 경로를 렌더링할 수 있습니다.&nbsp;[구현 방법]Spring Boot에서 React 라우팅을 처리하기 위한 WebController를 다음과 같이 작성할 수 있습니다.<pre ><code class="language-java">import org.springframework.boot.web.servlet.error.ErrorController;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
public class WebController implements ErrorController {

 @GetMapping({
 "/purchased-product"
 })
 public String index() {
 // Spring Boot가 React의 index.html 파일을 반환하도록 설정
 // index.html은 /resources/static 또는 /resources/public에 위치
 return "index.html";
 }
}</code></pre>&nbsp;위 코드는 React 애플리케이션의 경로를 명시적으로 나열하고, 해당 경로에 대한 요청이 들어오면 index.html을 반환하도록 설정합니다. 이렇게 하면 React의 라우터가 클라이언트 측에서 경로를 처리할 수 있는 환경을 제공하게 됩니다.&nbsp;결론Spring Boot와 React를 통합할 때, 클라이언트 사이드 라우팅으로 인해 발생하는 새로고침 404 오류는 React와 브라우저의 기본 동작 차이에서 발생합니다. 서버에서 React의 모든 경로를 처리하도록 설정함으로써 문제를 쉽게 해결할 수 있습니다.

🕊️ Spring Boot&React에서 새로 고침 404 오류 

1
반대해야 하는 상황에 직면했을 때 대응 매뉴얼을 만들었다.

2
첫째, 상대 의견을 부정하지 않고 인정해 준다.

3
둘째, 공통점을 찾는다.

4
셋째, 내 의견을 피력하기 위한 자락을 만들어둔다. “이렇게 말씀드려 죄송합니다만”

5
넷째, 반대 의사를 표명한다. 이유와 근거, 대안을 포함해 말해야 한다.

#강원국의어른답게말합니다

1 반대해야 하는 상황에 직면했을 때 대응 매뉴얼을 만들었다. ​ ​2 첫째, 상대 의견을 부정하지 않고 인정해 준다. ​ ​3 둘째, 공통점을 찾는다. ​ ​4 셋째, 내 의견을 피력하기 위한 자락을 만들어둔다. “이렇게 말씀드려 죄송합니다만” ​ ​5 넷째, 반대 의사를 표명한다. 이유와 근거, 대안을 포함해 말해야 한다. #강원국의어른답게말합니다

< 매너 있게 반대하는 4단계 >

최근 템플스테이를 다녀오면서 2025년에는 커리어리에서 얻는 수익을 기부하기로 결정했습니다.
현재 저는 커리어리 큐레이터로 활동하며 소정의 지원금을 받고 있는데요. 비록 크지는 않지만, 앞으로 이 수익 전액을 기부 단체에 전달하려고 합니다.

우리 사회가 조금이라도 더 따뜻해지기를 바라는 마음으로 이런 결정을 내렸는데요. 2025년에도 다른 개발자분들에게 도움이 될만한 더욱 의미 있는 글을 써내려갈 수 있도록 노력하겠습니다.

최근 템플스테이를 다녀오면서 2025년에는 커리어리에서 얻는 수익을 기부하기로 결정했습니다.현재 저는 커리어리 큐레이터로 활동하며 소정의 지원금을 받고 있는데요. 비록 크지는 않지만, 앞으로 이 수익 전액을 기부 단체에 전달하려고 합니다. 우리 사회가 조금이라도 더 따뜻해지기를 바라는 마음으로 이런 결정을 내렸는데요. 2025년에도 다른 개발자분들에게 도움이 될만한 더욱 의미 있는 글을 써내려갈 수 있도록 노력하겠습니다.

2025년에는 Careerly뿐만 아니라 https://incredibox-game.io/home 회사도 이를 따라 공유 정신을 확산하고 더욱 지속 가능한 기술 커뮤니티를 개발하는 데 도움이 되기를 바랍니다.

F-lab MBA

Patrick

신입

프론트엔드 개발자

yeomkyeorae

안녕하세요 시나브로 성장하길 꿈꾸는 개발자입니다!
#개발자 #프론트엔드 #커뮤니케이션 #Web #Algorithm #끊임없이배우기 #네트워킹 #도전적인

야놀자 Culture & Grow 매니저

최경은

약 9년간 HRD 컨설턴트로 스타벅스, 현대기아자동차, SK, 삼성 등 다양한 대기업의 교육 과정 콘텐츠를 개발하고, 조직개발 활동을 추진해왔습니다. 
현재는 IT회사 '야놀자'에서 Culture & Grow 담당자로 일하며 구성원들의 행복과 성장을 지원하고 있습니다.

2025년 다짐. 커리어리 수익 기부

플랫폼

html

javascript

프리랜서

시니어 프론트엔드 개발자

우아한형제들 주문웹프론트개발팀 주문 도메인 (배민스토어, 전국별미)
배달의민족 앱 내 전국별미 서비스 웹뷰 작업
배민상회, 배민문방구, 배민포스, 배민아카데미

프론트개발자

컴퓨터과학과

김의중

AWS Certified Cloud Practitioner

패스트캠퍼스 '내 생에 마지막 JavaScript' 강의

상위1%개발자들의 멘토링 - Frontend 멘토

패스트캠퍼스 에서 자바스크립트 강의를 만들었어요.
상위1%개발자 멘토링 멘토와 블로그 글을 쓰고 있어요.
bohaesoju@gmail.com

2025년 다짐. 커리어리 수익 기부

댓글 1

비슷한 게시물

주간 인기 TOP 10

추천 프로필