들어가며프로젝트를 시작하면 공통 UI를 설계하더라도, 보통은 해당 프로젝트 내에서만 제한적으로 사용하는 경우가 많았습니다. 이번에는 저는 공통 컴포넌트를 별도 패키지로 만들어 배포하고, 다른 서비스에서 설치해 사용하는 구조로 진행하게 되었습니다.그 과정에서 package.json을 단순히 “패키지 목록과 실행 스크립트를 관리하는 파일”로만 알고 있다가 실제로 어떤 역할을 하는지 살펴보게 되어 소개하고자 합니다.1. PeerDependenciesdependencies와 devDependencies는 프로젝트 환경 세팅 시 설치해야 하는 항목들이라 익숙한 개념입니다. 하지만 peerDependencies는 npm init 시 기본적으로 생성되지 않기 때문에 상대적으로 생소할 수 있어, 함께 비교해 보았습니다..

들어가며React 공식 블로그나 Next.js App Router 중심의 흐름을 보면 최근 React 생태계는 서버 중심 렌더링 구조를 적극적으로 활용하는 방향으로 변화하고 있는 것 같습니다. Server Components, Streaming UI, Server Actions 같은 개념들의 등장 이후, 기존에 익숙했던 CSR(Client Side Rendering) 중심의 개발 방식이 Server Components 기반 구조와 공존하는 방향으로 흐르는 추세인 것 같습니다. 이런 흐름은 React 19 이후에 좀 더 명확해졌는데요, 근래의 React 동향에 대해서 정리해 보았습니다. 서버 중심 구조로 변화하는 ReactServer Components 중심으로 변화해온 흐름React 공식 블로그를 보면 ..

들어가며지난 편에서 검색엔진과 AI 크롤러가 우리 사이트를 어떻게 발견하는지를 다뤘어요. robots.txt, sitemap, canonical, 리다이렉트, AI 크롤러 허용까지 — 결국 "크롤러가 페이지에 안정적으로 닿을 수 있는가"가 핵심이었죠.이번 편에서는 그 다음 단계 이야기예요. 크롤러가 페이지에 도착했어요. 그다음엔 뭘 볼까요?검색엔진이든 AI든, 페이지에 도착한 이후에는 콘텐츠의 구조를 읽어요. 제목이 뭔지, 주제가 뭔지, 어떤 질문에 답하고 있는지, 정보가 어떤 단위로 나뉘어 있는지. 이 구조가 명확한 페이지는 검색 결과에서도, AI 답변에서도 선택받을 가능성이 높아요.이번 편에서는 "AI가 인용하고 싶어지는 페이지"가 어떤 구조적 특성을 가지고 있는지, 프론트엔드 개발자가 실제로 챙길 ..

들어가며지난 편에서 프론트엔드 개발자가 왜 SEO를 챙겨야 하는지, 그리고 GEO라는 새로운 관점이 왜 필요해졌는지 이야기했어요. 이번 편에서는 좀 더 실전적인 이야기를 해볼게요.검색엔진이 우리 사이트를 검색 결과에 보여주려면, 먼저 우리 사이트를 발견해야 하잖아요. 근데 이 "발견"이라는 과정이 생각보다 단순하지 않더라고요. SEO/GEO 분석 서비스를 만들면서 수많은 사이트를 들여다봤는데, 콘텐츠는 멀쩡한데 크롤러가 아예 접근을 못 하는 경우가 의외로 많았어요. 대기업 사이트에서도요.이번 편에서는 검색엔진 크롤러가 우리 사이트를 발견하고 색인하는 과정을 프론트엔드 개발자 관점에서 풀어볼게요.크롤링 → 인덱싱 → 랭킹, 이 흐름부터 잡자검색엔진이 검색 결과를 보여주기까지는 크게 세 단계를 거쳐요.크롤링..

들어가며OpenAI의 엔지니어링 팀이 5개월 동안 약 100만 줄의 프로덕션 코드를 만들었다. 놀라운 건 규모가 아니다. 수동으로 작성한 소스코드가 단 한 줄도 없다는 점이다.소수의 엔지니어가 Codex 에이전트에게 작업을 지시하고, PR을 검토하고, CI 파이프라인을 관리했을 뿐이다. 애플리케이션 로직, 문서, CI 설정, 모니터링 설정까지 전부 AI 에이전트가 만들었다. 이 실험에서 OpenAI가 얻은 가장 중요한 교훈은 이것이다:"어려운 건 AI 에이전트가 아니다. 에이전트가 일할 환경(harness)이 어렵다." 이 환경을 설계하는 분야가 바로 하네스 엔지니어링(Harness Engineering)이다. 하네스 엔지니어링이란?비유로 이해하기"하네스(harness)"는 말에게 씌우는 마구(馬具)다...

들어가며AI 코딩 에이전트에게 "로그인 폼 만들어줘"라고 했더니, 있지도 않는 props를 쓰고, import 경로를 틀리고, 프로젝트 테마와 전혀 안 맞는 결과물이 나온 경험이 있나요?shadcn/ui가 더 확실하고 사용하기 쉽게 shadcn/cli v4로 업데이트 되었어요. shadcn/ui가 AI 시대에 주목받는 이유shadcn/ui는 이미 주목을 많이 받았던 UI 프레임워크이지만 AI시대가 되며 더더욱 많이 주목받고 활용되고 있습니다.일반적인 컴포넌트 라이브러리와 다르죠. npm에서 패키지를 설치하는 방식이 아니라, 컴포넌트 코드를 직접 프로젝트에 복사하는 구조입니다.npx shadcn@latest add button# → src/components/ui/button.tsx 파일이 생성됨 이 "코..

들어가며저는 마크업과 프론트엔드 작업을 하고 있어서 파이썬을 사용할 일이 없었습니다. 그러다 팀 과제를 하면서 제가 작성한 코드가 제대로 동작하는지 테스트해보고 싶어졌고, 방법을 찾다가 파이썬을 알게 되었습니다. 처음엔 낯선 언어여서 AI의 도움을 받아 코드를 작성하고 테스트를 해봤는데 결과를 바로바로 확인할 수 있어서 정말 편하더라고요. 그러면서 파이썬이 궁금해져서 알아보기 시작했습니다.작업하면서 저처럼 스쳐 지나가듯 파이썬을 경험해 보신 분들이나, 저처럼 아예 몰랐던 분들께 조금이나마 도움이 될까 싶어 공부한 내용을 정리해봤습니다.(참고로 저는 "100 Days of Code: The Complete Python Pro Bootcamp"라는 강의를 듣고 있습니다.) 파이썬 설치하기코드를 작성하려면 먼..

들어가며GEONIQ(SEO/GEO(AI Engine Optimization)를 분석해주는 서비스) 개발에 저도 같이 참여하게 되었는데 프론트엔드는 Next.js의 App Router, 백엔드는 FastAPI로 구성되어 있어 프론트엔드에서 백엔드 API를 호출할 일이 많았습니다.처음에는 프론트엔드에서 백엔드를 직접 호출하는 단순한 구조로 시작했지만, 개발을 진행하면서 CORS 문제라든지, 작업 환경에 따라 URL이 각각 바뀌는 것에 의해 필연적으로 ”중간에 서버인 Proxy 서버 ”가 필요해 졌습니다. 이 글은 Next.js API Routes를 활용해 API 프록시 레이어를 만들게 된 과정과, 만들고 나서 느낀 점을 이야기해 보려고 합니다프론트엔드가 백엔드를 직접 호출하면 안 되나?실제로 많은 프로젝트가..

들어가며개발 생태계의 변화가 무섭습니다.이제는 단순한 '도구의 진화'를 넘어섰죠.AI 에이전트가 코드를 짜는 수준을 넘어 직접 PR을 올리고 작업을 수행하는 모습을 보며, 바이브 코딩을 곁들인 대'딸깍'의 시대가 된 것 같아요.이제 개발자가 고민해야 하는 것은 "어떻게 코드를 짤 것인가"가 아니라 "어떤 문제를 정의하고, AI가 내놓은 답을 어떻게 검증할 것인가"라는 본질적인 질문에 대한 답일거에요. 좁아진 취업문요즘 시장은 기묘한 양극화를 보이고 있습니다. 하버드 연구에 따르면 AI 도입 이후 주니어 채용은 약 10% 감소한 반면, 시니어 수요는 여전하다고 해요. "가르쳐야 하는 신입보다 AI 에이전트가 가성비 좋다"는 냉혹한 논리가 현장을 지배하기 시작한 것 같아요.이제는 문턱이 매우 높아졌어요.이제..

들어가며그동안 접근성에 관련하여 체크리스트와 적용 사례 그리고, 자가진단을 공유하였습니다.웹 표준을 준수하고, 논리적인 마크업과 기능 구현을 하게 된다면 대부분의 접근성 관련한 항목은 신경쓰지 않아도 될 정도로 지켜지게 되는데요. 그럼에도 불구하고 작업 중 실수도 발생할 수 있고 미처 신경쓰지 못하는 부분도 있기 마련입니다.더불어 현재 진행하고 있는 프로젝트는 매년 접근성 인증마크를 갱신하고 있긴 하나 굉장히 오래되고 규모가 큰 사이트로서 아무리 기존에 잘 운영해왔던 사이트라 하여도 문제가 되는 부분은 많을거라 생각이 되었습니다.이번에 프로젝트를 이끌며, 25년도 접근성 인증마크 갱신을 진행 하면서 경험한 실무에서의 주의할 점과 좀 더 신경써야 할 부분을 정리해 보았습니다. role="tab" 사용 시 ..

들어가며2025년 팀 스터디로 장비 관리용 웹 사이트를 만들어, 그 위에 테스트를 붙여보자는 방향으로 진행되었는데 상반기에 개인 사정으로 자리를 비우게 되어, 팀에서 진행한 테스트 코드 학습에 참여하지 못하여 뒤늦게 Playwright에 대해 알게 되었습니다.이 글은 Playwright를 처음 사용해 보며 느낀 점과, 실제로 어떻게 동작하는지에 대해 정리한 기록입니다.PlaywrightPlaywright는 웹 애플리케이션을 실제 사용자처럼 테스트할 수 있는 E2E(End-to-End) 테스트 도구입니다. 브라우저를 직접 실행해서 클릭, 입력, 페이지 이동 같은 동작을 자동화하고, 그 결과를 검증합니다.왜 playwright를 선택하게 되었을 까하고 고민해보니 “사용자가 이 화면에서 이 버튼을 누르면, 다..

들어가며UI 개발을 하다 보면 누구나 한번은 겪는 문제가 있습니다.분명히 똑같은 수치와 CSS를 이용해서 구현했는데 왜 구현된 결과물이 피그마와 달라 보이는 걸까? 어렴풋이 어떤 이유일 거라고 짐작만 하던 이 차이점을 이번에 맘먹고 한번 찾아보았습니다. 원인을 알아보자1. 픽셀 렌더링의 차이피그마는 본래의 목적이 디자인 툴이기 때문에 canvas 환경에서 ‘논리적 픽셀’(벡터 기반 렌더링 방식)을 기준으로 표시합니다.반면에 웹브라우저는 디스플레이 DPI / PPI / Device Pixel Ratio(DPR) 등을 고려한 ‘물리적 픽셀’로 렌더링 됩니다. 이 과정에서 보정이 일어나 미세한 오차가 발생할 수 있습니다. 일부 상황에 대해서 표로 요약하면 다음과 같습니다.상황피그마 표현 방식웹브라우저 표현..