안녕하세요!카카오엔터테인먼트 FE개발자 클로토입니다. 최근 핫한 ChatGPT를 주제로 주니어 FE개발자의 관점에서 글을 작성해 보았습니다.재밌게 봐주셨으면 좋겠습니다. FE개발자 클로토!❗️이 글은 ChatGTP 3.5 버전을 기준으로 작성된 점 참고 부탁드립니다. (글 작성 중에 ChatGTP 4.0이 발표되었네요!)   요즘 ChatGPT가 뜨거운 감자입니다. 출시일 5일 만에 100만 명의 사용자를 모으고 2달 만에 사용자 1억 명에 달했습니다. 블로거, 기자, 유튜버 등 누구 할 것 없이 ChatGPT에 관해 이야기하고 있습니다. 많은 사람들이 일자리를 잃게 될지도 모른다고 이야기하는 여론도 심심치 않습니다. 평소 인공지능에는 관심이 있던지라 ChatGPT가 FE개발자의 업무를 과연 어디까지 보조 또는 대체할 수 있을지 궁금해졌습니다. 그럼 한번 용의자인 ChatGPT에게 먼저 물어보도록 하죠. 물론 FE개발자를 대체할 리 없다고 대답하겠지만요. <>HTML 삽입미리보기할 수 없는 소스<>HTML 삽입미리보기할 수 없는 소스용의자 ChatGPT의 진술<>HTML 삽입미리보기할 수 없는 소스역시 예상대로 발뺌(?)하는군요. ChatGPT 말을 순순히 '그렇구나'하고 포기했다간 제 글이 여기서 끝나버립니다. 그럴 수는 없죠. 간단한 미니 프로젝트를 통해 gpt(ChatGPT와 GPT는 다르지만 여기서부터 gpt라 줄여서 표현하겠습니다)가 어디까지 활용될 수 있을지를 한번 확인해 보도록 하겠습니다. gpt에 대한 설명보다는 실제 문답을 통해 코드를 작성하는 과정으로 설명할 예정입니다. 미니 프로젝트로는 간단한 웹툰 서비스를 기획해 보았습니다. 기획하는 과정에서도 gpt에게 물어보며 주로 어떤 장르가 인기가 있는지, 장르에 쓰일 작품을 답변받아 추가했습니다. 이미지들은 stable diffusion webui를 사용해서 txt2img로 작품 키워드에 맞는 이미지를 생성하여 넣었고 더미 이미지는 pixabay를 사용했습니다. 그리고 간단한 API 연동을 위해 TMDB API를 활용한 페이지도 추가했습니다. 완성된 프로젝트는 https://next-gpt-test.vercel.app/ 에서 데모를 확인할 수 있습니다. (vercel hobby plan이라 약간의 제약이 있을 수 있습니다). 어떤 과정을 통해 만들게 되었는지는 아래 ChatGPT로 개발하기 부분에서 설명할 예정입니다. 우선 gpt가 어떤 일을 할 수 있을지 알아보기 전에 FE개발자가 어떤 업무들을 수행하고 있는지부터 알아보겠습니다. https://next-gpt-test.vercel.app/ next-gpt-test.vercel.app | FE개발자가 하는 일FE개발자는 주로 어떤 일을 할까요? 간단하게 생각해 봤을 때는 다음과 같은 일들이 있습니다.프로젝트 환경설정요구사항에 맞는 html 작성디자인에 맞는 css 작성상태를 관리하여 동작 처리하기(react state, redux, recoil 등)서버에서 데이터 불러오기(axios, reat-query, graphql 등

올해 9월 21일, 카카오페이지 웹 서비스가 새롭게 개편되었습니다. 많은 기능이 추가되고 바뀌었지만 가장 눈에 띄는 부분은 바로 웹 사이트의 전반적인 디자인이 변경되었다는 것입니다.저희 FE개발그룹에서는 새로운 웹 사이트의 디자인을 구현하기 위해 Tailwind CSS (이하 tailwind)라는 라이브러리를 매우 활발하게 사용했습니다. 이 글에서는 tailwind를 사용하기로 결정한 이유를 소개하고, 몇 달간 프로젝트를 진행하며 tailwind를 실제로 사용해보면서 얻은 팁들을 공유하고자 합니다.FE개발그룹의 코제가 이미 한 차례 tailwind에 대한 전반적인 설명을 해주는 글을 쓰신 적이 있기 때문에, tailwind가 무엇인가에 대한 개론적인 설명은 이 글에서 생략하도록 하겠습니다. Tailwind CSS라는 라이브러리에 대해 처음 들어보신 분이라면 이 글을 먼저 참고해주세요.Tailwind CSS를 도입한 이유카카오페이지 웹 서비스를 개편할 때 처음부터 tailwind 라이브러리를 사용하려고 했던 것은 아닙니다. tailwind를 도입하려면 스터디를 할 필요가 있었고 이렇게 시간을 투자할만한 가치가 있을지 판단이 서지 않았습니다. 또한 기존 작업방식에서는 이전부터 사용하던 CSS 라이브러리 - Emotion CSS - 를 tailwind로 변경할 필요성을 크게 느끼지 못하기도 했습니다.기존에는 별도로 합의된 디자인 시스템 없이, 디자인 팀에서 특정 페이지에 대한 디자인 시안을 제작한 후 전달해주면 해당 페이지를 처음부터 끝까지 시안대로 구현하는 것이 일반적인 작업 플로우였습니다. 정형화된 시스템 없이 단순히 디자인 시안을 따라 페이지를 작업하는 경우는 대체로 반복 작업이어서 새로운 기술을 도입할 필요가 없다고 생각했기 때문에, 이전부터 사용해온 익숙한 Emotion CSS를 사용하면서도 코드를 작성하는데 큰 불편을 느끼지 못했습니다.하지만 웹 사이트의 전반적인 개편을 시작하기에 앞서 기존 작업방식을 검토하다 보니 다음과 같은 문제가 있었습니다.기존 작업방식의 문제점1. 공통 컴포넌트에 대한 인식 부재위에서 언급했듯이 기존에는 페이지 단위로 UI 작업을 진행했었습니다. A라는 페이지를 모두 만든 후 B라는 페이지 작업을 진행했는데 이때 A 페이지와 B 페이지에 비슷해 보이는 컴포넌트를 발견해도 웬만해서는 이를 공통 컴포넌트로 합칠 생각을 하지 못했습니다. 디자인팀과 별도로 합의된 시스템이 없다 보니 두 컴포넌트가 공통적인 요소를 가지고 있으므로 공통 컴포넌트로 합치기에 적절하다는 판단을 내릴 근거가 부족했기 때문입니다. 이로 인해 비슷한 UI를 가진 컴포넌트들이라도 공통 컴포넌트로 만들기보다는 별도의 컴포넌트로 만드는 상황이 자주 발생했습니다.이런 상황이 반복되다 보니 비슷한 컴포넌트들이 이름만 바뀐 채 여러 개 만들어졌고, 이런 컴포넌트가 기하급수적으로 늘면서 각 컴포넌트의 용도를 파악하는 게 어려워져 결국 요구사항이 바뀌더라도 선뜻 손대기 힘든 지경까지 이르렀습니다.2. 여러 팀이 공유하는 이름의 부재기존에는 디자인에서 사용하

카카오엔터테인먼트 FE개발팀에서는 작년 하반기부터 Esme의 주도적인 조사에 힘입어 Tailwind CSS (이하 Tailwind)를 적극적으로 도입하고 있습니다. Tailwind의 utility-first 특성과 장단점은 이미 많은 곳에서 소개가 되고 있고, 저희 팀에서도 장점이 더 많다고 판단하였습니다. 직접 Tailwind를 경험해본 바로는 개발 속도가 빨라지는 장점이 크게 와닿았습니다. 스타일 시트를 오가는 컨텍스트 스위칭도 없고, 클래스 이름을 시맨틱하게 정하기 위해 고민해야 하는 시간도 사라졌습니다. 페이지를 수정할 때도 CSS가 어떻게 적용되었는지 한 눈에 파악할 수 있어 스타일 수정에 드는 시간도 단축되었습니다. 아직 Tailwind를 많이 사용한 것은 아니지만, 신입 개발자가 Tailwind를 처음 사용해보면서 저희 팀에서 겪었던 문제를 똑같이 겪는 것을 볼 수 있었습니다. 이 글에서는 Tailwind의 소개나 장단점은 조금 생략하고, Tailwind를 사용하기로 하고 막 시작하는 단계에서 미리 알아두면 좋을 것 같은 소소한 팁들을 소개하고자 합니다. ARBITRARY VALUES 줄이기 <p class="text-[14px]"> <!-- ... --> </p> Tailwind는 주로 사용하는 CSS를 모아둔 집합으로 보아도 무방합니다. fontSize를 예시로 들면, 크기를 나타내는 숫자에 무한한 값이 올 수 있는데, Tailwind에는 주로 사용되는 숫자를 모아두고 이 중에서 사용할 수 있도록 해줍니다. fontSize는 xs, sm, base, lg, xl, 2xl, , 9xl 의 크기만 지원하고 있어서 이 중에서 선택하여 사용할 수 있습니다. 이 크기만으로 디자인이 구성되면 문제가 없겠지만 이 외의 값으로 크기를 설정해야 하는 경우 Tailwind에서는 대괄호로 감싸서 arbitrary value를 입력할 수 있는 기능을 제공하고 있습니다. 그런데 때에 따라 이 Arbitrary values 기능을 매우 자주 사용해야 하는 경우도 발생합니다. 예를 들어 rem이 아닌 px 단위로 디자인 요구사항을 맞추어야 하는 경우에는 상당히 빈번하게 사용해야 합니다. 예시로 <div className="p-[8px] h-[35px] text-[12px] rounded-[5px]"> 와 같은 코드를 작성하게 될 수도 있죠. 이는 작성할 때도 피로하고, 한 줄이 차지하는 너비가 길어지므로 코드를 읽는 개발자에게도 좋지 않습니다. 이러한 부분들은 테마를 커스터마이징하여 해결할 수 있습니다. 만약 px단위로 디자인 요구사항을 충족해야 하는 경우라면 다음과 같이 미리 px에 대한 프리셋을 전부 extend로 등록할 수 있습니다. // tailwind.config.js const px0_10 = { ...Array.from(Array(11)).map((_, i) => `${i}px`) }; const px0_100 = { ...Array.from(Array(101)).map((_, i) => `${i}px`) }; const px0_200

안녕하세요 Hakuna Studio, Web Dev Team 의 Easton (신동리) 입니다. 저희 팀은 Hakuna 앱에 포함되는 Webview 화면 개발, Hakuna 앱의 웹 버전인 웹 클라이언트 개발, 어드민 개발 등 웹 기술을 활용하여 Hakuna Studio에서 발생하는 다양한 문제를 풀어내고 있습니다. Hakuna는 기본적으로 앱이지만 일부 화면에 한해서는 빠른 배포를 위해 Webview로 구성되어 있는데요. 이번에 저희 팀에서 일부 Webview 화면을 React Native로 전환하는 PoC(Proof of Concept) 를 진행했습니다. 이번 글에서 React Native로 전환하게 된 배경과 그 과정에서 어떠한 고민들이 이루어졌는지 소개해 드리겠습니다. 왜 REACT NATIVE를 도입해야 하는가 ? 1. 사용성 개선 Webview는 네트워크를 통해서 서버를 거쳐 로딩하기 때문에 페이지가 로드될 때 발생하는 로딩 시간을 피할 수 없습니다. 반면, React Native는 CodePush 를 사용하여 미리 다운로드 받은 화면을 보여주기 때문에 번들을 갱신할 때를 제외하고는 별도의 로딩 시간이 필요하지 않습니다. 또한, React Native 코드는 자바스크립트로 작성되지만 브릿지 역할만 할 뿐 네이티브 코드로 렌더링되기 때문에 Webview보다 좀 더 네이티브에 가까운 경험을 제공할 수 있습니다. (가끔 Android 에서 보이는 UI와 iOS 에서 보이는 UI가 일관되지 않게 보이는 경우가 존재하긴 합니다) * Webview * React Native 2. CodePush 그림 1. CodePush 출처 CodePush란 Microsoft 에서 만든 오픈 소스로써 앱 스토어 배포 없이 사용자의 디바이스에 직접 배포할 수 있도록 해주는 App Center Cloud Service 입니다. React Native에서 코드는 두 부분으로 나뉘는데요. * Native Binary * Javascript Bundle Javascript Bundle을 갱신할 때 CodePush를 통하여 실시간으로 업데이트가 가능하다는 장점이 있습니다. > 네이티브 영역의 코드가 변경되어야 하면 앱 스토어 배포가 필요합니다 ! FLUTTER VS REACT NATIVE 그림 3. Flutter vs React-native 출처 그렇다면 React Native 말고 Flutter 라는 다른 선택지도 있지 않나요? 라고 물으실 수도 있을 것 같습니다. Flutter 대신 React Native를 선택한 이유는 두 가지가 있습니다. 1. 상대적으로 낮은 러닝 커브(Learning Curve) 저희는 이미 웹 프론트엔드 개발을 할 때 주로 React 라이브러리를 사용하기 때문에 React Native 를 학습하기 위한 비용이 현저하게 낮았습니다. 2. 아자르, 매트릭스 등 사내 타 스튜디오에 운영되고 있는 React Native 프로젝트들을 참고할 수 있다. 아자르, 매트릭스 등 사내 타 스튜디오에 운영되고 있는 React Native 프로젝