서버 개발자가 헥사코드를 몰라도 되게 만들기
안녕하세요, 카카오스타일 지그재그 전시BE파트 밀리입니다. 전시 개발자로서 혹시 이런 하루를 보내고 있나요?
안녕하세요, 카카오스타일 지그재그 전시BE파트 밀리입니다. 전시 개발자로서 혹시 이런 하루를 보내고 있나요?
안녕하세요! 앱 개발팀의 레이몬드입니다. 2024년에 진행했던 모듈화 여정을 1년 동안의 iOS 모듈화 진행기 로 공유했었는데요, 이번에는 그 여정의 다음 단계인 Component 모듈 에 대해 이야기해보려 합니다.
안녕하세요, 카카오스타일 지그재그 서비스 FE팀의 제이슨입니다. 올해 저희는 지그재그 앱 내에 포치의 선물가게라는 게임 서비스를 오픈했습니다. 이 글에서는 포치의 선물가게 게임을 웹 환경에서 구현하면서 겪었던 기술적 선택들과 그 과정에서 했던 고민을 공유해보려고 합니다.
안녕하세요. 지그재그 서비스팀 로빈입니다.🙂 오늘은 저희 팀에서 관리하고 있는 상품상세페이지(Product Detail Page. 이하 PDP) 서비스의 프로젝트 아키텍처에 대해 간단히 소개해보려고 합니다. PDP 서비스는 2024년부터 “Domain-Driven 헥사고날 아키텍처"의 프로젝트 구조를 띠고 있는데요, 이렇게 운영한지 어느덧 1년을 향해 가고…
안녕하세요! 앱개발팀의 레이몬드입니다. 2024년 한 해동안 모듈화를 경험하면서 느낀점들과 후회하는 것들을 글로 써보고자 합니다. 2023년 초부터 논의해 오던 모듈화를 2024년에 본격적으로 진행했고 지금도 모듈화 작업을 이어 나가고 있습니다. 1년동안 진행한 작업들을 되돌아 보니 생각보다는 많은 작업들을 진행했더라구요. 많은 모듈화 관련 포스트들이 모듈…
안녕하세요, 카카오스타일 지그재그 서비스 FE팀의 제이슨입니다. 2023년 초, 저희 팀은 비즈니스와 더불어 기술적인 개선이 필요하다는 것을 느꼈습니다. 그중에서도 특히 여러 지면에서 독립적으로 관리되고 있던 상품 카드 컴포넌트의 일원화 작업이 중요하게 여겨졌고. 이 문제를 해결하기 위해서는 단순 리팩토링을 넘어, 팀 전체의 UI/UX를 통합적으로 관리할…
지그재그는 상품 판매를 촉진하기 위해 이벤트나 기획전을 주요 마케팅 수단으로 활용합니다. 기획전은 한정된 기간 동안 고객에게 특정 상품 정보와 추가적인 할인 혜택을 명확하게 제시하여 판매를 유도하는 역할을 합니다. 따라서 다양한 기획전을 지속적으로 발행해 고객의 관심을 유도하고, 브랜드 충성도를 높이며, 구매율을 증가시키고 있습니다. 또한, 다양한 테마와…
테스트를 거치지 않은 소프트웨어는 없습니다. 하지만 많은 기능을 가져 복잡해진 현대의 소프트웨어를 온전히 테스트하는 것은 굉장히 어려운 일입니다. 이러한 테스트를 자동화하지 않은 채 소프트웨어를 지속적으로 배포하는 것은 불가능에 가깝다고 할 수 있습니다. 이번 글에서는 카카오스타일에서 진행하는 UI 테스트 자동화 시스템에 대해 설명해보겠습니다.
카카오스타일에서는 서버 드리븐 UI(Server Driven UI, 이하 SDUI) 를 통해 UI의 유연성을 가져가고 있습니다. 서버가 클라이언트 UI를 동적으로 제어하므로써 빌드 및 배포 없이도 UI 업데이트를 할 수 있고, A/B 테스트도 효율적으로 수행할 수 있었습니다. 다만 이렇게 구축된 시스템을 몇년간 운영하다보니 몇가지 문제점이 발생했습니다. 이…
근래의 많은 기업과 마찬가지로 카카오스타일도 불필요한 비용 낭비가 발생하지 않도록 많은 노력을 기울이고 있습니다. 물론 이전이라고 사용하지 않는 리소스를 방치하며 비용을 낭비한 것은 아니고, 좀 더 세밀한 부분까지 주의를 기울이기 시작했다고 생각해주시면 됩니다. 이번 글은 그 중 하나를 소개해보려고 합니다.
안녕하세요, 카카오스타일 전시 UX팀의 샌즈입니다. 모두들 알고 계시듯 null(널)은 값이 없음을 나타냅니다. 그리고 null 값인 객체에 접근하려고 하면 그 유명한 NullPointerException(NPE)이 발생합니다. 그런데 null 값을 가지지 않는 다고 설정한 변수에서 NPE가 발생하는 현상을 겪어 그 내용을 공유해보려고 합니다.
이전 글에서는 테스트 전략과, 테스트를 작성하는 방법들에 대해서 알아봤습니다. 하지만, 테스트를 실행하는 환경에 대해서는 스토리북을 사용한다고 가정했을 뿐, 구체적인 이야기를 진행하지는 않았습니다. 이번 글에서는, 테스트 프레임워크를 활용해서 테스트를 자동으로 실행할 수 있는 환경을 구성하는 방법에 대해 알아보겠습니다. 설명하는 내용의 특성상, 개념적인 이…
이전 글에서는 제품의 요구사항을 분석하며, 테스트 케이스를 산출하는 방법에 대해 알아봤습니다. 이 글에서는 구체적으로 어떻게 테스트 코드를 작성할 수 있는지에 대해 알아봅니다.
저번 글에서는 프론트엔드의 테스트 자동화에 대해서 소개하고, 테스트 전략에 대해서 간단하게 다뤄봤습니다. 테스트 자동화가 아무리 중요하다고 해도, 테스트 작성을 시작하는 것은 쉽지 않습니다. 설정해야 하는 것들이 많고, 효과적인 테스트 작성 방법을 찾는 것도 어렵습니다. 이 문서에서는 프론트엔드에 맞춘 테스트 작성 방법을 고민해봤습니다. 물론 프로젝트마다…
프론트엔드는 입력/출력이 명확하지 않기 때문에 테스트를 작성하면서 고민해봐야 할 내용이 많습니다. 프론트엔드 관점에 맞춰 테스트 자동화, 테스트의 정의와 방향성에 대해서 다뤄봤습니다.
카카오스타일의 파트너센터 서비스에서는 UI 테스트와 문서화를 위해서 Storybook과 MSW를 사용하고 있습니다. Storybook의 각 스토리마다 MSW GraphQL mock을 개별로 정의해서 사용하고 있었는데, 이로 인해 코드가 중복되고 mock 누락으로 인한 오류가 자주 발생했습니다. 이런 문제를 해결하기 위해, 스토리마다 따로 정의된 MSW mo…
GraphQL.js 리졸버의 마지막 인자는 info입니다. info는 현재 처리 중인 질의에 대한 정보가 들어가 있습니다. 보통은 리졸버 구현에 info가 필요하지 않지만 최적화나 복잡한 연결을 위해서는 info의 내용이 필요합니다.
GraphQL.js 리졸버의 세번째 인자는 context입니다. 이 인자는 온전히 사용자가 설정하는 것으로 매 요청마다 새로 생성되며 같은 요청을 처리하는 리졸버가 상태를 공유하기 위해 사용합니다.
GraphQL.js 리졸버의 두번째 인자는 args입니다. 해당 필드에 인자가 주어지면 그 값이 들어옵니다.
GraphQL.js의 리졸버는 네개의 인자를 가지고 있습니다. 그 중 첫번째 인자는 source 입니다.
GraphQL 스키마를 정의했고, 클라이언트에서 온 요청을 서버가 처리하기 위해 필요한 기술을 알아봤습니다. 이제 클라이언트에서 온 요청에 따라 적절한 데이터를 반환하는 과정이 남았습니다. 이는 리졸버(resolver)라는 것이 담당합니다. Java쪽에서는 데이터 페처(data fetcher)라고도 부릅니다. 리졸버를 완전히 이해하면 GraphQL을 전부를…
이전 글 에서 GraphQL 스키마를 정의했습니다. 이제 이 스키마에 질의를 하고 그 결과를 받을 수 있습니다.
안녕하세요! 카카오스타일 SRE팀 네사입니다. 오늘은 카카오스타일 SRE팀에서 올해 EKS 클러스터 이전을 하며 새롭게 도입 했던 AWS Karpenter 에 대해 공유를 해보려 합니다.
지그재그 에픽 서비스는 여러 웹뷰를 사용하도록 구성되어 있습니다. 한 화면에서 변동된 데이터를 다른 화면에 반영해야 하는 기술 이슈가 발생했는데 이를 해결한 방법에 대해 설명합니다.
GraphQL은 query 방식만 정의한 단순한 스펙입니다. 하지만 개념이 간단하다고 그것을 동작하도록 구현하는 것까지 간단한 것은 아닙니다. GraphQL을 실제 제품에 적용하기까지는 많은 것들을 이해해야 합니다. 이에 대해 차례로 설명해보려고 합니다. 첫번째로 다뤄볼 내용은 스키마 정의입니다.
반복해서 실수가 발생해서 수많은 사람들의 시간을 낭비하는데, 사실 시스템 개선에 조금만 시간을 썼으면 발생하지 않았을, 그런 문제들이 있습니다. 이런 상황을 알면서도 바쁘다는 핑계로 넘어가곤 하는데, 이번에 1년 이상 머리 한 구석에만 뒀던 이슈를 해결해 공유해볼까 합니다.
저희는 주기적으로 Node.js 모듈을 최신 버전으로 업데이트하고 있습니다. Node.js를 10년째 사용 중인데, CoffeeScript → TypeScript, 콜백 → Async.js → Promise(& async, await) 전환 하면서 몇 번 혼란의 시기가 있었습니다. 하지만 모듈 시스템은 쭉 이어져왔습니다. 그런데 최근에 이 모듈 시스템에 큰…
이전 글에서는 ECS / EKS에서 서비스 하는 것에 대한 개념을 풀어 써봤습니다. 이번 글에서는 잘 만들어진 모듈을 이용해 빠르게 구성해보겠습니다.
ECS 아티클에 이어 이번 글에서는 같은 서비스를 EKS로 구축해보도록 하겠습니다. 간단하게 구축하는 것은 eksctl을 쓰면 되지만, 내부 이해를 위해 여기서는 기본부터 구현하도록 하겠습니다.
카카오스타일에서는 한동한 ECS를 사용해서 어플리케이션을 서비스했습니다. 현재는 EKS로 전환하고 있지만, ECS가 상대적으로 단순하기 때문에 서비스 구축 개념을 익히는데 좋은 것 같습니다. (간단한 서비스는 굳이 쿠버네티스를 쓸 필요가 없다고 생각합니다) 그런 의미에서 이번 글에서는 ECS를 이용해 단순한 서비스를 오픈하는 과정을 단계별로 설명해보려고 합…