TypeScript 기술 블로그 최신 글

사진 속 별자리 찾기: 7년 걸린 Plate Solver 만들기

1. 들어가며 안녕하세요, 버즈빌에서 Frontend 개발자로 일하고 있는 Brice입니다. 기술 이야기로 딱딱한 이곳 테크 블로그에서, 조금은 낭만적인 이야기를 해 보려고 합니다. 여러분은 별을 얼마나 자주 보시나요? <figure style="margin:2rem 0;" <div style="position:relative;padding-bottom:c…

미리캔버스의 편집 로직을 책임지는 웹 에디터 팀 엔진 개발자들

미리캔버스에서 도형을 옮기고, 글자를 고치고, 방금 한 작업을 한 번에 되돌리는 순간. 우리는 이 움직임을 당연하게 여기죠. 그런데 이 매끄러움이 저절로 만들어지는 게 아니라면요? 화면 뒤에는 복잡한 로직과 정교한 성능 최적화를 위해 애쓰는 엔진 개발자들이 있습니다. 미리디의 웹 에디터 팀이 바로 그들이에요. 사용자가 미리캔버스에서 도형과 텍스트를 자유롭게 다뤄 원하는 디자인을 완성할 수 있도록, 편집 기능이 ‘실제로 작동하게’ 만드는 핵심 로직을 설계하죠. 미리디의 엔진 개발자는 ‘기능을 만드는 개발자’로 출발해, 점차 ‘구조를 설계하는 개발자’로 성장합니다. 지금부터 웹 에디터 엔진 개발을 맡고 있는 백동열, 김예지, 이은지 님의 이야기를 들려드릴게요. 미리캔버스의 편집 화면을 움직이는 사람들 Q. 안녕하세요! 먼저 세 분이 각자 어떤 일을 하고 계신지, 간단한 자기소개부터 부탁드려요. 동열님: 안녕하세요. 미리디에서 웹 에디터 엔진 개발을 맡고 있는 백동열이에요. 지금은 미리캔버스 2.0 프로젝트와 함께 프레젠테이션의 새로운 방식을 만드는 일에 참여하고 있어요. AI가 사용자를 도와서 빠르고 만족스럽게 프레젠테이션을 만들 수 있는 환경을 함께 만들어가고 있어요. 예지님: 안녕하세요, 저도 웹 에디터 엔진 개발을 맡고 있는 김예지예요. 미리디에 합류한 지는 3개월쯤 됐어요. 저는 원래 미리캔버스와 비즈하우스를 쓰던 사용자였는데, 다양한 창작물이 만들어지는 과정을 지켜보다가 저도 이 서비스에 직접 기여해보고 싶어서 합류하게 됐어요. 은지님: 안녕하세요. 웹 에디터 엔진 개발자 이은지예요. 저는 애니메이션이나 공유 뷰어, 슬라이드쇼처럼 재생과 관련된 기능을 주로 개발하고 있어요. 원래 프론트엔드 팀에 있다가 중간에 웹 에디터 팀으로 옮겨왔는데, 정신없이 일하다 보니 벌써 이 팀에서 지낸 지도 1년이 지났네요. Q. ‘웹 에디터 엔진 개발자’라는 이름이 아직 낯선 분들도 많을 것 같아요. 정확히 어떤 일을 하는 직무인지 조금 더 풀어서 설명해 주실 수 있을까요? 예지님: ‘엔진’이라는 말이 무언가를 움직이게 하는 동력이잖아요. 저희는 그 이름처럼 사용자가 미리캔버스에서 편집을 매끄럽게 할 수 있도록 핵심 기능과 내부 로직을 만드는 사람들이에요. 그래서 다루는 범위가 꽤 넓어요. 디자인 페이지에 들어갔을 때 문서를 불러오는 것부터, 도형이나 텍스트를 더하고 지우고 복사하고 붙여넣는 기능, 방금 한 동작을 되돌리거나 다시 실행하는 기능, 바뀐 내용을 썸네일에 반영하는 기능까지 맡고 있어요. 여기에 성능 최적화나 동시 편집처럼 조금 더 까다로운 기술 문제를 푸는 것도 저희 몫이에요. 동열님: 덧붙이자면, 제가 지금 집중하는 프로젝트에서는 사용자의 의도를 정확히 읽어서 가장 잘 맞는 디자인을 제안하는 엔진을 만들고 있어요. 단순히 화면을 그리는 걸 넘어서, 복잡한 비즈니스 로직과 AI 모델을 하나로 잘 엮는 작업이거든요. 그래서 이 직무를 한마디로 정리하면, ‘사용자가 조작한 대로 지연 없이, 정확하게 반응하는 편집 경험’을 만들기 위해 실제로 작동하는 핵심 로직을 설계하고 구현하는 소프트웨어 엔지니어라고 할 수 있어요. 미리캔버스는 생각보다 훨씬 복잡한 구조로 만들어져 있었어요 Q. 사용자 경험을 위한 로직을 직접 설계한다니 매력적으로 들려요. 그만큼 처음엔 만만치 않았을 것 같은데, 입사 초기에 낯설거나 어렵게 느꼈던 부분은 없으셨어요? 동열님: 가장 낯설었던 건 미리캔버스의 구조였어요. 편집 영역과 템플릿, 요소 패널이 각각 독립된 작은 서비스로 나뉘어 있는 MFA(Micro Frontend Architecture) 구조였거든요. 각 기능이 서로 정해진 방식으로 명령을 주고받고, 객체지향 설계와 함수형 프로그래밍이 적절히 섞여 있는 꽤 복잡한 구조였어요. 사실 처음엔 ‘이 작은 편집 화면 하나에 로직이 들어봤자 얼마나 들어있겠어’라고 가볍게 생각했어요. 그런데 그 생각이 틀렸다는 걸 깨닫는 데는 얼마 걸리지 않더라고요. 은지님: 저는 모듈이 역할에 따라 나뉘어 있는 구조가 조금 낯설었어요. 예를 들어 디자인 편집기의

앱 리뷰 자동화 일주일만에 만들기

3년 동안 쌓이기만 하던 원티드 앱 리뷰에 다시 답글을 달기 시작했다. 원티드 Android, iOS 앱 리뷰는 거의 3년째 방치되어 있었습니다. 조직 개편이 진행되는 동안 누가 담당자인지 모호해졌습니다. 다들 언젠가 해야 한다고는 생각했지만 막상 누구 일도 아닌 상태로 시간이 흘렀 버렸습니다. 그러던 중 iOS개발자였던 찬주님이 슬랙에 위와 같은 아이디어를 올렸고, Android도 동일한 상황이라 이번에 앱 개발자 두 명(Android, iOS)이 직접 이 일을 정리해 보기로 했습니다. 일주일 동안 만든 건 이런 사이트 입니다. 하는 일은 단순합니다. 1시간마다 App Store와 Google Play에서 새 리뷰를 가져온다. 새 리뷰를 Slack 채널에 올리고, AI가 쓴 답글 초안을 스레드에 단다. 사람이 초안을 읽고 승인 이모지를 누르면 스토어에 답글이 올라간다. 버그 제보나 기능 제안이면 이모지 하나로 Jira 이슈를 만든다. Web에서는 리뷰를 걸러 보고, 답글을 고쳐서 게시하고, 통계를 본다. AI가 답글을 쓰긴 하지만 사람이 확인하지 않은 답글은 절대 올라가지 않습니다. 스토어 답글은 한 번 게시하면 사용자에게 바로 전달되기 때문에 이것만큼은 처음부터 정해 두고 시작했습니다. 스펙은 화면을 보면서 정했다 이 프로젝트에는 기획자도 디자이너도 없었습니다. 일단 스펙 문서부터 작성했지만 문서만으로는 자연스럽게 소통하기 힘들었습니다. 그래서 스펙을 Claude에게 보여 주고 이렇게 부탁했습니다. [문서]의 기능을 만들 건데, Claude Design에게 시킬 프롬프트를 작성해 줘. 프롬프트를 Claude Design에 넣자 리뷰 목록, 상세, 게시 확인, 통계, 배치 상태 화면까지 초안이 한 번에 나왔습니다. 여기서부터는 화면을 같이 보면서 바로바로 피드백을 주고받을 수 있었습니다. “통계에 Jira 이슈 수도 넣자”, “목록에서는 답글 게시 전 초안을 숨기자”, “게시 버튼 앞에 내용을 끝까지 확인했다는 체크를 두자” 같은 이야기가 화면 위에서 나왔고, 그렇게 정한 내용을 스펙으로 옮겼습니다. 글로만 논의할 땐 나오지 않던 피드백들이 자연스럽게 쏟아져 나왔습니다. Montage 디자인 시스템도 큰 역할을 했습니다. Claude Design에 원티드 디자인 시스템인 Montage를 연결해 두었더니 첫 초안부터 기존 원티드 서비스와 같은 버튼, 색, 글꼴로 나왔습니다. 웹 화면도 사내 표준 스택(Next.js + Montage)을 따랐기 때문에 목업을 코드로 옮길 때 같은 컴포넌트를 그대로 가져다 쓸 수 있었습니다. 디자이너 없이 만든 화면인데 어색하지 않은 건 Montage 덕분입니다. 사내 도구를 이어 붙여서 만들었다 Backyard: 웹 프론트, API 서버, DB Backyard는 원티드랩 사내 구성원들을 위한 샌드박스 실행 환경입니다. Kubernetes(이하 k8s) 위에서 돌아가고, 프로젝트를 하나 만들면 그 프로젝트만 쓰는 공간이 생깁니다. 그 안에서 웹 프론트엔드, 백엔드 API 서버, MySQL DB를 켜고 끌 수 있고, 필요하면 Redis와 S3 저장소도 붙일 수 있습니다. 각 구성 요소는 컨테이너로 뜨고, k8s 배포 설정, 서비스, 도메인 연결은 Backyard가 대신 만듭니다. Backyard가 MCP를 제공해주기 때문에 개발자는 k8s 설정 파일을 쓸 필요 없이 자연어로 “이 프로젝트에 프론트, 백엔드, DB를 켜줘.” 라고만 말해도 알아서 세팅해 줍니다. 배포는 도커 이미지를 올리는 것으로 끝납니다. 프로젝트 전용 레지스트리에 latest 태그로 이미지를 push하면, Backyard가 이를 감지해 실행 중인 컨테이너를 새 이미지로 차례로 교체합니다. 이 또한 자연어로 “Backyard로 배포해줘"라고만 말하면 됩니다. 덕분에 서버 신청이나 DB 발급을 기다릴 필요가 없었고, 킥오프 당일에 백엔드와 DB가 이미 떠 있었습니다. Ennoia: AI 에이전트 Ennoia는 원티드에서 운영하는 AI 에이전트 플랫폼으로, 에이전트를 자연어로 쉽게 만들 수 있습니다. 여기에 에이전트를 만들

2026년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)

2016년부터 매년 이어 오던 "JavaScript의 동향" 연재는 2020년을 마지막으로 한동안 쉬었습니다. 그사이 6년이 지났고, 그 6년 동안 ECMAScript 명세는 여섯 번 개정되었습니다. 2020년 글을 쓸 때 Stage 2였던 Temporal은 9년에 걸친 논의 끝에 Stage 4에 올랐고, 이제 Chrome과 Firefox, Node.js에서 플래그 없이 쓸 수 있습니다. 달라진 것은 명세만이 아닙니다. 2020년에는 상상하기 어려웠던 방식으로 코드를 쓰는 사람이 늘었습니다. AI 코딩 도구가 코드의 상당 부분을 작성하고, 사람이 방향을 정하면 AI 에이전트가 브라우저 엔진의 JavaScript 엔진 코드를 다른 언어로 옮기는 일까지 생겼습니다. 2025년 GitHub Octoverse에서 TypeScript가 처음으로 가장 많이 쓰인 언어 1위에 올랐고, GitHub은 그 배경으로 AI를 꼽았습니다. 이번 연재는 다음 네 편으로 구성됩니다. 1편: JavaScript(ECMAScript) 2편: 브라우저 밖의 JavaScript 3편: WebAssembly 4편: 라이브러리와 프레임워크 직전 회차인 2020년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)에서는 ECMAScript 2020, 2021과 당시 진행 중이던 제안들을 살펴보았습니다. 해마다 발표되는 명세는 'ECMAScript 2026'처럼 연도를 붙여 부르고, 줄여서 'ES2026'이라고도 씁니다. 이 글에서는 먼저 2020년 이후 6년의 공백을 정리하고, 2020년 글에서 소개한 제안들이 어떤 결말을 맞았는지 확인합니다. 이어서 TC39 프로세스의 변화, 2026년 6월 승인된 ECMAScript 2026과 2027년 명세에 포함될 기능, 브라우저와 임베디드 엔진의 현황, JavaScript 상표권 분쟁, TypeScript 7을 살펴봅니다. 마지막으로 AI 코딩 도구가 JavaScript와 TypeScript를 쓰는 방식, 그리고 표준을 만드는 방식에 어떤 영향을 주고 있는지 정리합니다. 이 글의 내용은 2026년 10월을 기준으로 작성되었습니다. 글을 읽는 시점에 따라 글의 내용과 사실이 다를 수 있습니다. 2020년 이후 6년 2020년 글은 swyx의 The Third Age of JavaScript를 인용하며 2020년 이후를 JavaScript의 세 번째 주기로 보았습니다. 이 주기에서는 레거시를 정리하고 도구가 만든 레이어를 걷어 내는 일이 일어날 것이라고 했습니다. 구체적으로는 세 가지를 예상했습니다. CommonJS, AMD 같은 비표준 모듈이 ESM으로 전환될 것입니다. JavaScript 도구가 반드시 JavaScript로 작성될 필요는 없다는 흐름이 강해질 것입니다. TypeScript와 JavaScript가 서로 영향을 주며 함께 발전할 것입니다. 6년이 지난 지금 세 가지 모두 예상한 방향으로 진행되었습니다. 다만 속도와 모습은 예상과 달랐습니다. ESM 전환은 생각보다 오래 걸렸습니다. 전환을 가로막던 가장 큰 장벽은 CommonJS 코드에서 ESM 패키지를 require()로 불러올 수 없다는 점이었고, 이 문제는 2024년 말이 되어서야 Node.js의 require(esm) 지원으로 풀렸습니다(참고: Node.js 22.12.0 (LTS)). 인기 npm 패키지의 모듈 형식을 정기적으로 집계하는 wooorm/npm-esm-vs-cjs 데이터에 따르면, ESM을 제공하는(ESM 전용이거나 ESM과 CommonJS를 함께 제공하는) 패키지 비율은 2021년 8월 7.8%에서 2024년 11월 25.9%, 2026년 6월 38.0%로 늘었습니다. 다만 2025년 12월부터 집계 대상 목록의 출처가 바뀌어 그 이전 수치와 바로 비교하기는 어렵습니다. Anthony Fu(Vue, Vite, Nuxt 코어 팀원이자 Vitest, Slidev, UnoCSS 제작자)는 2024년 말 수치를 근거로 새 패키지는 ESM 전용으로 내자고 제안하기도 했습니다(참고: Move on to ESM

여기어때 해외투어 프론트엔드 구축기록

글. 박수봉(Henby) / 서비스웹개발팀 안녕하세요. 서비스웹개발팀 헨비입니다. 9월 7일, 여기어때 해외투어 서비스를 오픈했습니다. 프론트엔드 담당 개발자는 두 명이었고, 웹과 앱 웹뷰를 하나의 코드베이스로 개발했습니다. 저는 웹 카테고리홈·상품 상세·주문서·예약내역·해외투어용 채팅을 맡았고, 검색바·헤더·푸터·예약내역 탭·찜 탭·회원탈퇴처럼 여러 서비스가 함께 쓰는 공통 화면도 담당했습니다. 3월 13일에 빈 앱을 만들고 9월 7일에 오픈까지 총 25주였습니다. 이 글은 그 25주 동안 어떤 것을 만들었고 어떤 판단을 했는지 정리한 기록입니다. 세 번의 신규 서비스, 개발 범위는 넓어지고 처리는 빨라졌습니다 여기어때에서 신규 서비스 프론트를 맡은 건 이번이 세 번째입니다. 2024년 가을 해외숙소 비회원 예약, 2025년 봄 패키지여행, 그리고 이번 해외투어까지입니다. 세 프로젝트를 같은 기준으로 비교해 보니 한 가지 흐름이 보였습니다. 저의 담당 범위는 점점 넓어지고 깊어졌습니다. 첫 번째 프로젝트에서는 주문서·예약완료·예약내역·조회 흐름을, 두 번째에서는 웹 PDP·홈 검색·채팅을 맡았습니다. 이번에는 웹과 앱을 합쳐 여덟 개 영역을 담당했고, 웹과 웹뷰를 동시에 개발했습니다. 반면 작업해야 할 레포 수는 줄었습니다. 첫 번째 프로젝트에서는 세 개, 두 번째에서는 두 개의 레포를 오갔지만, 이번에는 모노레포 하나와 채팅 레포 하나로 작업했습니다. QA 티켓은 77건, 55건, 280건으로 늘었지만 3일 내 처리율은 48%, 62%, 81%로 높아졌습니다. 범위와 티켓 수는 늘었지만 처리 속도는 빨라졌습니다. 그 변화를 만든 작업을 정리해 봤습니다. 모노레포에서 두 번째 서비스를 올렸습니다 해외투어는 모노레포에 올라간 두 번째 서비스였습니다. 첫 번째 서비스인 항공팀은 웹·모바일웹·웹뷰를 하나의 코드베이스로 운영할 기반을 이미 만들어 둔 상태였습니다. 구축 과정은 같은 팀 에릭이 쓴 “항공 프론트엔드 구축기” 열 편에 자세히 정리돼 있습니다. [링크] 저는 그 기반을 활용했습니다. 웹 레이아웃의 Provider 스택은 항공 레이아웃을 따라 3월 말에 구성했습니다. 현재 구조는 다음과 같습니다. <PlatformProvider value={{ platform: 'web', isWebAccess: true }}> <AppInitializer runtimeEnv={process.env.NEXT_PUBLIC_ENV} /> <AuthProvider initialUser={user}> <GtmTrackingProvider> <LoadingSpinnerProvider> <DialogProvider> <SnackbarProvider>{children}</SnackbarProvider> </DialogProvider> </LoadingSpinnerProvider> </GtmTrackingProvider> </AuthProvider> </PlatformProvider> 플랫폼 판정, 앱 초기화, 인증, 계측, 로딩, 다이얼로그, 스낵바의 순서는 항공과 같습니다. 앱 레이아웃은 첫 줄의 platform 값만 다릅니다. 앱과 웹의 로그인 분기, 브라우저 뒤로가기와 안드로이드 백키를 함께 처리하는 모달 구조, 팀 공통 디자인 시스템 YDS도 그대로 활용했습니다. 개발자 두 명이 화면 서른일곱 개를 만들어야 하는 상황에서 기반을 새로 만들기보다, 먼저 개발중인 항공에서 이미 검증한 구조를 재사용하는 편이 합리적이었습니다. 대신 서비스에만 필요한 구현으로 남지 않도록, 재사용 가능한 기능은 공유 패키지에 추가했습니다. 25주 동안 공유 패키지에 182건을 커밋했고 컴포넌트 파일 50개를 새로 만들었습니다. 이미지 전체 보기 모달을 공통화하고, 결제수단 UI를 패키지로 분리했으며, 화면에 묶여 있던 찜 API는 앱 공용으로 옮겼습니다. 공유 패키지를 수정하면 항공에 영향을 줄 수 있습니다. 그래서 서비스 브랜치는 master에서만 분기하고, 공유 패키지 변경은 서비스 브랜치 안에서 격리한 뒤 master 머지를 통해서만 다른 서비스에

Swift 6 어때요? (2): executor, job, hop_to_executor

런타임 소스 좀 읽어 봤습니다

슈퍼 마리오, 2026 3D 로고 리프레쉬

닌텐도가 공식 슈퍼 마리오 웹사이트에 새로운 로고를 적용했습니다. 여러 색을 조합한 글자와 익숙한 형태는 유지하면서, 글자 표면과 가장자리에 입체감을 더했습니다. 멀리서 보면 기존 로고와 같은 슈퍼 마리오 글자지만, 가까이서 보면 평면 그래픽보다 두께가 있는 물체에 가깝습니다. 가장 큰 변화는 글자의 테두리입니다. 기존 로고에서 형태를 또렷하게 구분하던 검은 윤곽선 대신 회색 경사면이 들어갔습니다. 글자의 앞면에는 밝은 […] Source

허미어스 웹사이트, 엔진의 열기에 일렁이는 글자

미국 항공 스타트업 허미어스가 새 브랜드와 웹사이트를 공개했습니다. 작업은 디자인 스튜디오 HAUS가 맡았습니다. 허미어스는 고속 항공기 개발을 목표로 하는 기업입니다. 새 디자인은 이 회사의 핵심 문장인 “Building Fast Planes, Fast”를 중심으로 구성됐습니다. 프로젝트는 기존 브랜드를 다듬는 방식으로 진행됐습니다. HAUS는 허미어스의 날개 심벌을 다시 그렸고, 새 워드마크와 타입 시스템을 만들었습니다. 기존 심벌의 네 개 깃털은 네 […] Source

Shadcn/ui, AI에 쓰기 좋은 오픈 코드 디자인 시스템

shadcn/ui는 웹 서비스를 만들 때 쓰는 화면 구성 도구입니다. 버튼, 입력창, 메뉴, 표, 알림창 같은 기본 부품을 제공합니다. 다만 일반적인 컴포넌트 라이브러리와 방식이 다릅니다. 패키지를 설치해 불러오는 구조가 아니라, 필요한 컴포넌트의 코드를 프로젝트 안으로 가져와 직접 수정해 쓰는 방식입니다. 공식 문서는 shadcn/ui를 “컴포넌트 라이브러리가 아니라, 자신의 컴포넌트 라이브러리를 만드는 방법”이라고 설명합니다. 개발자는 버튼의 색, 크기, […] Source

전체 데이터를 브라우저에 두는 광고 대시보드 만들기

서버가 하던 필터링·정렬·검색·페이지네이션을 브라우저로 옮겼더니, 속도뿐 아니라 손대지 못하던 문제 네 개가 같이 풀렸습니다.

FE News 26년 7월 소식을 전해드립니다.

주요소식 26년 6월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. TypeScript 7.0 RC Go로 재작성된 네이티브 컴파일러를 탑재한 TypeScript 7.0의 릴리스 후보(RC)가 공개되었다. 기존 타입 체크 로직과 구조를 그대로 유지한 채 포팅해 6.0보다 약 10배 빠르며, Bloomberg, Figma, Google, Slack, Vercel 등 여러 기업의 팀과 프리릴리스 빌드를 테스트해 왔다. 향후 한 달 내 정식 릴리스될 예정으로, 대규모 코드베이스에서 타입 체크와 빌드 속도로 고생해 온 팀이라면 미리 검증해 볼 가치가 있다. Ship the policy, not the code 프런트엔드와 백엔드처럼 별도로 배포되는 두 시스템에 동일한 비즈니스 규칙을 구현할 때 발생하는 코드 중복과 불일치 문제를 다룬다. 백엔드가 "allowedActions": ["CANCEL"] 같은 결정값을 내려보내거나, CASL이나 JSON Schema 같은 표준 형식으로 정책 자체를 데이터로 직렬화해 전송하는 방안을 제시한다. 마이크로서비스나 BFF 구조에서 규칙 일관성을 고민하는 개발자에게 실용적인 관점을 제공한다. Getting started with loops Claude Code 팀이 코딩 에이전트에게 프롬프트를 반복 입력하는 대신 "루프를 설계"하는 접근을 정리한 글이다. 트리거 방식과 종료 기준에 따라 턴 기반, 목표 기반, 시간 기반, 프로액티브 4가지 유형으로 분류하고, 검증 절차를 스킬(SKILL.md)로 인코딩해 자가 검증 능력을 높이는 방법을 소개한다. 명확한 종료 기준 설정과 대규모 실행 전 파일럿 테스트 등 토큰 사용량 관리 팁도 함께 제안한다. React Doctor AI 에이전트가 작성한 React 코드의 품질 문제를 자동으로 잡아내는 도구다. 상태 관리, 이펙트, 성능, 아키텍처, 보안, 접근성 전반을 검사하며 Next.js, Vite, TanStack, React Native, Expo 등 대부분의 React 환경을 지원한다. Claude Code, Cursor, Codex 같은 AI 에이전트와 연동되고, GitHub Actions를 통한 PR 자동 리뷰도 가능하다. vercel/eve Vercel이 공개한 파일시스템 기반의 지속형(persistent) AI 에이전트 프레임워크다. 시스템 프롬프트는 instructions.md, 도구는 tools/, 온디맨드 절차는 skills/ 디렉터리에 두는 식으로 에이전트의 구성 요소를 코드가 아닌 디렉터리 구조로 관리해 검사와 확장이 쉽다. 마크다운과 타입 정의된 함수만으로 에이전트를 구성하는 접근은 코드 중심 프레임워크 대비 낮은 진입 장벽을 제공한다. >> FE News 26년 7월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기

게임 회사에서 클라이언트 프로그래머가 하는 일

게임 회사에서 클라이언트 프로그래머가 하는 일을 게임 업데이트 루틴과 함께 소개합니다.

프론트엔드 개발자를 위한 5가지 스크롤 복구 시나리오와 실전 코드 팁

안녕하세요! 올리브영 프론트엔드 개발자 hee 입니다‍ 여러분은 혹시 사용자가 이전에 보던 화면 그대로 다시 보여주려다 예상치 못한 스크롤 위치 때문에 당황했던 경험이 있으신가요? SPA 환경에서 '스크롤 복구(Scroll Restoration…

딜리버리 프로덕트 개발팀의 개발 문화 - 주니어 디버깅 스터디

주니어 개발자의 성장을 목표로 진행한 에러 디버깅 스터디 과정을 소개합니다.

AOP와 MDC로 구현하는 보급형 APM - 인터페이스 이력 관리부터 호출 추적까지

타입스크립트스럽게 성능과 생산성 두 마리 토끼 모두 잡기

최고의 자동완성 플러그인 타입스크립트를 사용하여 개발자를 속이고 코드를 최적화한 경험을 공유합니다.

개발 파트 소개 - 3. 모바일 앱 개발 파트 (React Native)

인프랩 채용 공고 안녕하세요. 저희 인프랩 개발팀은 현재 백엔드, 프론트엔드, 모바일 앱, 데브옵스 파트로 나뉘어져 있습니다. 각각의 개발 파트가 어떻게 일 하는지, 어떤 사람과 함께 하고 싶어하는지 등을 소개드리려 합니다. 세 번째로 모바일 앱 개발 파트를 소개드리겠습니다. 인프랩팀이 새롭게 모바일 앱 개발 파트를 구성하게 되었습니다. 그동안은 웹 프론트엔드 개발자분들이 처음 앱을 출시하고, 웹 서비스를 메인으로 하면서 하면서 앱을 운영해왔는데요. [서비스] 모바일 앱 각 스토어에서 공개 중지 안내 그래서 인프런의 앱 서비스를 새롭게 개편하기로 결정하고, 이에 맞춰 React Native 기반의 모바일 앱 개발을 전담할 개발팀을 구성하게 되었습니다. 앞서 언급했듯이 인프랩 팀에는 그동안 모바일 앱 전담팀이 없었습니다. 그러다보니 제로에서 시작하는 개발팀에 대한 걱정과 우려로 다음과 같은 궁금증이 생깁니다. 코드리뷰는 하고 있는걸까? 서비스 기능 개발하기에 바빠서 각개전투 하는건 아닐까? 테스트 코드를 작성하고 있을까? 리팩토링 / 생산성 향상 등에 관심이 있을까? 성장을 위한 피드백 문화가 있을까? 구성원의 성장을 위해 회사에서는 어떤 지원을 해줄까? 개발자의 성장에 있어 가장 중요한건 개인의 노력인데요. 그렇다면 회사에서 해줄 수 있는 것은 무엇일까요? 제 생각에는 그 사람이 성장할 수 있는 좋은 재료와 환경을 제공해주는 것이 아닐까 싶습니다. 인프랩의 모바일 앱 (React Native) 개발 파트를 소개드리려고 합니다. 이런 환경이라면 좋은 개발자로 성장할 수 있지 않을까 생각해보는 시간이 되셨으면 합니다. 직군 소개 현재 인프랩 모바일 앱 개발 파트는 총 2명의 개발자로 이루어져있습니다. 모바일 앱 개발자는 프로덕트 조직인 셀 (Cell) 과 프론트엔드 파트 (Part) 에 속합니다. 셀 (Cell) 에서는 PM, 디자이너와 함께 모여 일하며 셀에서 맡은 제품을 개선하고 문제를 해결하고 있습니다. 프론트엔드 파트 (Part) 에서는 매주 정기적으로 모여 각 셀에서 발생했던 장애에 대한 공유나 좀 더 일을 잘하기 위한 방법, 기술적인 공유 등을 하는 시간을 가지고 있습니다. 스프린트 회고, 프로젝트 회고, 분기 회고, 반기 회고 등 다양한 회고를 기반으로 항상 더 나은 방식으로 문제를 해결하기 위한 개선을 진행합니다. 인프랩의 모바일 (React Native) 개발자는 다양한 기기/브라우저에 맞춰 사용자를 위한 클라이언트 애플리케이션 개발을 담당합니다. (출처: https://www.instagram.com/p/CQXLFvODOfF/) TypeScript, React Native 를 기반으로 Android / iOS 애플리케이션을 개발하고 배포합니다. 상황에 맞게 적절한 형태로 IOS, Android 네이티브 구현과 웹앱 구현을 나눠 진행합니다. 모바일 영상 플레이어, OAuth 를 비롯한 각 서비스에 필요한 기능들을 구현, 개선 합니다. 요즘은 특히 모바일 영상 플레이어와 영상 보호 기술 (DRM) 에 대한 고민이 많이 있습니다. 시스템 전반의 성능 최적화를 위해 API 호출 최소화 / 렌더링 최적화 / 빌드 & 번들링 최적화 등을 상시로 진행합니다. DataDog APM, Firebase 등을 통해 사용자 디바이스에서 발생하는 에러에 대해서 추적하고 해결합니다. Figma를 통해 디자이너와 함께 사용자를 위한 UI/UX 개선을 고민하고 적용합니다. Swagger, Codegen 기반으로 백엔드 개발팀과 함께 데이터에 대해 협업합니다. 웹 프론트엔드 개발파트와 함께 사용할 공통의 라이브러리 등을 개발/개선 합니다. 기술 스택 모바일 앱 개발파트에서는 다음과 같은 기술 스택을 사용하고 있습니다. TypeScript React & React Native Native Video Player React Query, Zustand Jest & Cypress Firebase Git, Github MS CodePush, Github Actions 업무 방식 스타트업 특유의 빠른 제품 릴리즈와 서비스 안정성 이라는 2마

개발 파트 소개 - 2. 웹 프론트엔드 파트

인프랩 채용 공고 안녕하세요. 저희 인프랩 개발팀은 현재 백엔드, 프론트엔드, 모바일, 데브옵스 파트로 나뉘어져 있습니다. 각각의 개발 파트가 어떻게 일 하는지, 어떤 사람과 함께 하고 싶어하는지 등을 소개드리려 합니다. 두 번째로 웹프론트엔드 파트를 소개드리겠습니다. 같이 일하게 될 사람들은 어떤 사람들일까? 배포 프로세스는 어떻게 될까? 자동화가 되어있을까? 코드리뷰는 하고 있는걸까? 서비스 기능 개발하기에 바빠서 각개전투 하는건 아닐까? 테스트 코드를 작성하고 있을까? 모니터링과 로깅은 제대로 구축되어있을까? 구성원의 성장을 위해 회사에서는 어떤 지원을 해줄까? 개발자의 성장에 있어 가장 중요한건 개인의 노력인데요. 그 사람이 성장할 수 있는 좋은 재료와 환경을 제공해주는 것이 아닐까 싶습니다. 지금부터는 인프랩의 웹 프론트엔드 파트를 소개드리려고 합니다. 좋은 개발자로 성장할 수 있지 않을까 생각해보는 시간이 되셨으면 합니다. 직군 소개 현재 인프랩 프론트엔드 파트는 총 9명의 개발자로 이루어져있습니다. 프론트엔드 개발자는 프로덕트 조직인 셀 (Cell) 과 프론트엔드 파트 (Part) 에 속합니다. 셀 (Cell) 에서는 PM, 디자이너, 백엔드 개발자와 함께 모여 일하며 셀에서 맡은 제품을 개선하고 문제를 해결하고 있습니다. 프론트엔드 파트 (Part) 에서는 매주 정기적으로 모여 각 셀에서 발생했던 장애에 대한 공유나 좀 더 일을 잘하기 위한 방법, 기술적인 공유 등을 하는 시간을 가지고 있습니다. 스프린트 회고, 프로젝트 회고, 분기 회고, 반기 회고 등 다양한 회고를 기반으로 항상 더 나은 방식으로 문제를 해결하기 위한 개선을 진행합니다. 그 외에도 9명의 프론트 엔드 개발자는 24시간 365일 장애 없는 서비스 환경 구성과 복잡한 비즈니스 로직 처리, 다양한 기기/브라우저에 맞춰 사용자를 위한 웹 개발을 담당합니다. (출처: https://www.instagram.com/p/CQXLFvODOfF/) VanillaJS (ES6), TypeScript, React, Next.js 를 기반으로 인프랩의 여러 서비스의 웹 프론트를 개발하고 배포합니다. TypeScript 기반의 정적 타입 개발을 하여 안정적인 서비스 개발을 진행합니다. Server Rendering과 Client Rendering을 상황에 맞게 적절히 선택하고 이들을 위한 마크업을 개발합니다. 시스템 전반의 성능 최적화를 위해 API 호출 최소화 / 렌더링 최적화 / 번들링 최적화 등을 상시로 진행합니다. 사용자를 위한 UI/UX 개선을 고민하고 적용합니다. 온라인 PR, 오프라인 페어프로그래밍 등 코드리뷰를 통해 성장하는 문화를 지향하고 있습니다. 모니터링 서비스인 Datadog을 적극적으로 사용하여 시스템에서 발생하는 모든 이슈 사항에 대해서 추적하고 해결합니다. 이외에 인프랩 웹 프론트엔드 파트의 개발자들은 어떤 고민들을 하고 있고, 어떤 문제들을 해결하기 위해 노력하고 있는지는 아래 기술 블로그를 통해 확인할 수 있습니다. 인프랩 기술 블로그 기술 스택 현재 웹 프론트엔드 기술 스택은 크게 2가지로 나눠져있습니다. 현재 대부분의 인프런 기능을 담당하고 있는 기존 시스템 새 기술 스택으로 기존 기능을 하나씩 이관 중인 신규 시스템 랠릿 역시 신규 스택으로 구성되어 있습니다. 기존 시스템 스택 JavaScript, Yarn FxJS / FxDOM Fx 라이브러리를 이용한 함수형 프로그래밍으로 대부분의 코드가 구성되어있습니다. Date-fns SCSS Webpack 신규 시스템 스택 TypeScript React, Next.js React Query Vite pnpm Turborepo Module Federation Codegen 사내에서 별도로 구현한 Code Generator Figma, Mantine, Storybook 이외 인프라 요소는 두 시스템 모두 비슷한 형태를 취하고 있습니다. Docker DataDog 모니터링 AWS ECS (EC2) - Express, Next.js Server Git / GitHub Jenkins

Backend , Frontend 공통 IDL 적용

백엔드와 프론트엔드가 같은 API를 각자의 타입으로 중복 정의하던 문제를 공통 IDL로 통일한 과정입니다. interface.ts와 models.ts 작성 규칙, 주석 컨벤션, 프로젝트 관리 방식을 예제와 함께 정리했습니다.

W CARE 서비스 프론트엔드를 TDD로 개발해본 후기

안녕하세요! 올리브영에서 프론트엔드 개발자로 일하고 있는 재미입니다. 오늘은 지난 3월 10일 올리브영 앱에 런칭한 W CARE 서비스의 프론트엔드를 TDD로 개발한 후기를 남겨보고자 합니다. W CARE 서비스란? W CARE…