물음표 문자가 생기는 이유를 알기 위해 유니코드에 대해 알아보고, 한글 문자 구성도 확인했습니다. 이제 euc-kr과 함께 utf까지 알아볼 차례입니다. 이 과정을 거쳐 유니코드의 U+FFFD라는 스펙을 찾아내고, 문제를 해결한 과정을 공유하겠습니다. 한글이 어떤 식으로 저장이 되고, 브라우저에서는 어떤 식으로 표현되는지 기억해 주면 좋겠습니다. 또 제가 문제를 해결한 과정을 힌트 삼아 문제가 생길 소지를 살펴보면, 비슷한 문제를 해결하는 데 도움이 될 것이라 생각합니다.

이 글은 함께 일하던 매니저님이 보낸 슬랙 메시지에서 시작되었습니다. “텍스트 에디터로 글을 작성하는 도중에 긴 글을 작성하면 이상한 물음표 글자가 자꾸 생겨요.”, “이 글자를 지우기 위해 글을 수정하고 다시 업로드를 하면 또 다른 곳에 나타나요. 꼭 두더지 같아요!” 이 메시지를 보낸 매니저님은 이런 현상을 보고 ‘유니코드 지옥’이라고 표현했습니다. 이 물음표가 왜 등장하는지, 이 문제를 어떻게 해결할 수 있는지, 그 여정을 함께 해보겠습니다.

이번 글에서는 프론트엔드에 거는 버프 마법, 애셋, 오픈 그래프, 웹 모듈 마법을 알아보려고 합니다. 나아가 7가지 마법의 절망 편도 알아보겠습니다. 7가지 마법을 잘 활용하면 안정성 높고 개발하기 쉬운 프론트엔드 인프라를 구축할 수 있습니다. 한편 절망 편에서 소개한 시행착오 내용들은 유의하여 앞으로 만나게 될 문제점들을 이겨내는 데 도움을 줄 것입니다.

토스 코어에는 86명의 FE 개발자들이 함께 있고 250개의 서비스를 운영하고 있습니다. 제가 속한 플랫폼 팀에서는 86명의 FE 개발자가 사용하는 모노리포를 관리하며 250개 서비스의 배포부터 모니터링까지 같이 관리하고 있습니다. 이런 인프라 관리를 좀 더 쉽게 하기 위해서 IaC를 통해 형상 관리를 자동화하고 있고, 다양한 개발자들이 기여할 수 있는 환경을 만들기 위해 노력하고 있습니다. 토스 코어 팀의 프론트엔드 개발자들이 이러한 다양한 업무들에 집중하는 목적이 무엇일까요? 가장 큰 목적은 토스의 프론트엔드 UX/DX를 세계 최강으로 만들기 위함입니다. 토스의 프론트엔드 플랫폼이 세계 최강의 프론트엔드가 되기 위해 어떤 노력을 하고 있는지 하나씩 살펴보겠습니다.

올해로 여덟 번째를 맞이한 FEConf의 세션은 그 퀄리티가 높기로 유명합니다. 프론트엔드 개발자로 근무하는 실무자들이 현장에서 마주친 문제와 그 해결 과정을 생생하게 전달하기 때문이죠. 그런 만큼 올해 FE의 새로운 트렌드를 가장 빠르게 만날 수도 있고요. 어떤 이야기가 오갈지 궁금한 분들을 위해 요즘IT에서 이번 FEConf 2024 발표자들을 만났습니다. 메인 세션의 발표부터 이번 행사에 새로 도입되는 라이트닝 토크 발표까지. 2024년, 프론트엔드 개발자들은 어떤 문제를 만났고 무슨 고민을 하고 있을까요?

이번 글에서는 앞서 발행된 ‘크로스 플랫폼 디자인 시스템, 1.5년의 기록(1)’에서 살펴본 정의를 실제 컴포넌트 구현에 어떻게 적용할 수 있는지 알아보겠습니다. 우선 차크라와 스펙트럼의 API를 다시 한번 살펴보겠습니다. 제품 언어를 만드는 입장에서 일관성을 최우선으로 추구하여 오른쪽의 API처럼 간결하게 제공하고 싶은 것은 당연한 생각입니다. 그러나 일관성을 추구하는 형태로 제공함으로써 발생할 수 있는 모든 케이스의 90%를 커버할 수 있다고 하더라도, 사용자 입장에서는 커버하지 못하는 10%의 케이스로 인해 개발이 지연될 수 있습니다.

안녕하세요. 저는 당근에서 디자인 시스템을 만들고 운영하고 있는 하태영입니다. 이번 글에서는 제가 1년 반 동안 디자인 시스템을 만들며 시도했던 다양한 접근 방법과 그 과정에서 함정에 빠진 경험, 그리고 이 경험을 통해 배운 것 들을 공유하고자 합니다. 디자인 시스템을 만들다 보면 ‘디자인 시스템’이라는 단어가 굉장히 넓은 스펙트럼을 가지고 있고 이로 인해 팀원간 소통의 오류나 팀의 방향성이 흐트러지는 경험을 하게 됩니다.

‘React Native, Metro를 넘어서’ 1회에서는 번들러가 무엇인지와 번들러의 역할로 Resolution, Load, Optimization에 관해 소개했습니다. 1부 마지막에서 파일 크기를 줄이기 위한 Optimizaton을 간단히 이야기하고, 파일 크기를 줄이는 테크닉에는 크게 Minification과 Tree Shaking이 있다고 말씀드렸죠. 이 글인 2부에서는 Metro와 ESBuild의 차이를 조금 더 명확하게 알기 위해서, 이 각각의 테크닉이 구체적으로 어떤 역할을 하는지 살펴보겠습니다. 그리고 토스에서 Metro를 ESBuild로 바꾼 여정도 소개합니다.

토스에서 프론트엔드 개발자로 일하고 있는 박서진이라고 합니다. 이 글에서는 저희가 매일 사용하고 있는 Metro, webpack 아니면 ESBuild와 같이 그런 번들러가 무엇인지에 대해서 자세하게 알아보겠습니다. 번들러가 무엇인지를 알면 Metro도 ESBuild도 생긴 것만 다른 똑같은 번들러라는 걸 알게 되고, 두 번들러를 (쉽지는 않습니다만) 갈아끼울 수 있다는 것도 알게 될 것입니다.

숨고에서 기술 부채 해결, 팀의 생산성을 개선하는 업무를 맡고 있는 프론트엔드 엔지니어 정지만입니다. 이 글에서는 서비스의 프레임워크를 Vue에서 Next로 전환한 경험을 공유하고자 합니다. 프레임워크 마이그레이션 배경, 점진적인 페이지 단위 마이그레이션, 마이그레이션 과정에서 고려해야 하는 포인트, 그리고 마이그레이션 중에 겪었던 이슈와 그걸 해결한 과정을 공유합니다.