신나는 코딩세상

“개발 중 예상하지 못한 오류가 발생했거나, 의도하지 않은 동작이 일어나는 경우 어떻게 해결하시나요?” 면접에서 위 질문을 하면 열에 아홉은 Google이나 StackOverflow에서 찾아보고, 해결책을 적용한다고 대답합니다. 하지만 서비스를 개발하다 보면 더 복잡한 요구 사항을 처리해야 할 때도 있고, 우리의 스택과는 맞지 않는 해결책이 일반적인 경우도 있습니다. 클래스101의 웹 애플리케이션에 서버 사이드 렌더링을 적용하기 위한 여정이 바로 이런 경우에 속합니다. 여러 가지 이유로 클라이언트 사이드 렌더링만 지원하던 웹 애플리케이션에서 서버 사이드 렌더링까지 지원해야 했고, 이 과정에서 styled-components로 만든 컴포넌트들을 서버 사이드에서 그려줄 때 몇 가지 문제가 발생했습니다. 물론 이 경우에도 문제를 해결하는 방법은 여러 가지가 있습니다. styled-components 대신 비슷한 API를 제공하는 다른 CSS-in-JS 라이브러리를 사용할 수도 있고, …

클래스101 서비스가 날마다 크고 있는만큼 코드의 규모도 커졌고, 그에 따라서 버그 발생확률도 높아졌습니다. 서비스 규모가 작을 땐 담당자가 직접 UI를 테스트하는 등 기존의 QA 프로세스로도 충분했지만 이제는 작업 범위와 시간이 많이 소요되기 때문에 더욱 체계적이고 새로운 프로세스가 필요해졌습니다. 소프트웨어 테스트에는 유닛 테스트, 통합 테스트 등 여러 방법이 있지만 유저와 최대한 비슷한 환경에서 테스트를 진행하는 E2E 테스트를 구축하기로 했습니다. 특히 안정성과 성능을 고려해 널리 쓰이고 있는 Cypress를 E2E 테스트 툴로 선정했죠. 참고: 테스트 필수사항 클래스101의 모든 코드는 TypeScript 기반으로 작성되어 있다. 그러므로 앞으로의 유지보수와 확장성을 고려해 기본언어인 JavaScript가 아닌 TypeScript로 테스트 코드를 작성한다. 서비스에서 가장 중요한 기능인 결제와 유저 인증, 클래스 수강을 필수적으로 테스트한다. Action Plan Requ…

이왕이면 심부름도 한 번에 하면 좋잖아요? Overview 많은 앱 서비스들이 복잡한 요구사항들을 충족하려고 한 페이지 안에서도 많은 요청을 보냅니다. 하지만 규모가 커지면 이야기는 달라집니다. 수많은 요청이 한꺼번에 밀려오는 파도를 만났을 때, 이 난관을 어떻게 헤쳐나갈 수 있을까요? 수많은 Request 들.. 클래스101 앱 서비스의 모든 클라이언트 요청은 GraphQL을 기반으로 이루어져 있습니다. GraphQL로 모든 요청을 계층화하고, 단일 요청으로 데이터를 Fetch한다면 꼭 필요한 데이터만 정의해서 받아올 수 있습니다. 하지만 리액트 환경에서 개발할 땐 조금 다릅니다. 컴포넌트의 계층을 나눠 캡슐화하고, 컴포넌트의 재사용성을 높이기 위해 데이터 Fetch 로직을 분할해 사용하는 컴포넌트와 함께 배치되도록 구성합니다. 이런 패턴은 널리 알려졌고 또 유용하지만, 오히려 한꺼번에 많은 요청이 들어온다면 각각의 요청으로 네트워크 연결이 많아질 뿐 아니라 오버헤드까지 발생하…

Overview 개발자들은 느낄 겁니다. 몇 달만 지나도 새로운 프레임워크나 언어가 나오고, 개발 방향을 잡아주는 개발 방법론에도 트렌드가 있다는 것을 말이죠. 요즘은 TDD(Test Driven Development)가 큰 인기를 휩쓸고 있습니다. TDD는 간단하게 이야기해서 테스트가 개발을 이끈다고 해서, 테스트 코드를 먼저 짜고 그 다음 메인 코드를 짜는 방식으로 개발을 진행합니다. 테스트를 먼저 짜게 되면서 자연스럽게 예외 상황과 동작 방식을 생각하게 되어 메인 코드를 작성할 때 더 좋은 코드가 나올 수 있습니다. 또한 팀 내 개발자가 코드를 잘못 건드리더라도 테스트를 통과하지 못하기에 빠르게 문제 원인을 찾고 해결할 수 있습니다. 이는 사이드 이펙트를 줄이는데도 큰 도움이 될 것입니다. (전제 조건은 좋은 테스트 코드를 짜는 것입니다.) 클래스101이 테스트를 도입하게 된 계기 우리는 기술의 ‘안정성’과 ‘기능 개발’ 두 가지를 모두 잡기 위해 고군분투하고 있습니다. 하…

클래스101을 런칭했을 땐 단 몇 명의 개발자가 서비스를 만들어야 했습니다. GCP’s Firestore(Google Cloud Platform’s Firestore)를 활용해 단 일주일 만에 서버를 구축하지도 않고 서비스를 런칭했죠. 이제 클래스101은 많은 이들의 취미를 찾아주는 서비스가 되었습니다. 그리고 여러 체계가 잡히고 서버도 구축하면서 정들었던 GCP’s Firestore를 떠나보낼 때도 되었습니다. 개발자가 사랑했던 GCP’s Firestore, 어떤 특징이 있을까요? Firestore는 스케일 업, 스케일 아웃과 같은 확장성은 전혀 걱정하지 않아도 되는 키-밸류 저장소입니다. 물론 비용을 제때 내야 합니다. 비용 지불에 문제가 생기면 바로 무료 플랜 limit을 넘어가는 모든 Firestore 요청이 실패할 테니까요. 각종 플랫폼에 SDK가 문서화되어 있고, react-native는 오픈소스인데다 react-native-firebase도 잘 운영되고 있습니다. 개발…

웹과 모바일 환경이 발달하면서 검색은 가장 중요한 도구가 되었습니다. 역량과 전문성을 드러내고 싶어하는 모든 개인과 기업은 당연히 검색 결과에 관심을 가지기 시작했죠. 이제 사람들은 지식을 외우지 않아도 됩니다. 책장에서 책을 꺼내듯 모르는 것이 있으면 검색만 해도 웬만한 전문가보다 더 많은 지식을 얻을 수 있기 때문입니다. 기업은 사람들의 이러한 행동 변화를 놓치지 않았습니다. 검색이 중요해지다 보니 자연스레 에이전시 형태의 콘텐츠 대행사를 중심으로 콘텐츠 소비자가 주목할 만한 검색어나 키워드, 유행에 따라 콘텐츠를 제작해 단기적으로 조회 수, 댓글 수 등을 온라인 영향력의 기준으로 삼았습니다. 하지만 디지털 시대에 단기적 성과를 달성하기 위한 수치들이 진정으로 개인과 기업의 온라인 영향력 확장에 도움이 되는 걸까요? 만약 노출 수, 조회 수와 같은 수치가 성과의 기준이 된다면 당연히 광고홍보비용을 많이 투자한 기업이 온라인의 승자가 될 게 분명합니다. 그렇다고 검색 결과 화면을…

Overview 클래스101에서 추천 서버를 담당하고 있는 Esmond입니다. 최근에 TF-IDF(Term Frequency - Inverse Document Frequency)를 활용해 클래스 간의 유사도를 분석하고 이를 API로 올렸습니다. 그 개발 과정과 이를 통해 앞으로 개선할 점을 두 편의 글로 쓰겠습니다. 개발 배경 및 목표 클래스101 앱에서 볼 수 있는 수백 개의 클래스를 어떻게 분류할 수 있을까요? 우리는 크게 두 가지의 기준을 가지고 있습니다. 첫째, 클래스가 처음 제작될 때 지정되는 클래스의 카테고리로 분류한다. 둘째, 클래스 오픈이 확정된 이후 비슷한 주제로 엮이는 클래스의 컬렉션으로 분류한다. 요즘은 클래스101이 빠르게 성장하면서 늘어난 유저에게 카테고리나 컬렉션과 같이 간단한 추천만 하기엔 역부족으로 보입니다. 보다 구체적으로 추천할 수 있는 로직이 필요해졌기에, 개발팀에서는 ‘클래스 간의 유사도’라는 지표를 분석하고 활용해보기로 결정했습니다. 이번 개발…

편집자 주 ‘Python’은 독자의 가독성을 높이기 위해 글의 제목과 코드를 제외한 본문 전체에서 ‘파이썬’으로 한글 표기함. 이는 외래어 표기법 상 관용에 해당함. Overview 개발자가 3년 정도의 경력을 쌓으면 새로운 개발을 꿈꿉니다. 저도 마찬가지였습니다. 활기찬 스타트업에서 웹 백엔드를 맡아 개발하고 싶은 마음이 생겨났죠. 클래스101으로 이직한 이유이기도 합니다. 그렇다면 파이썬(Python)과 JS(JavaScript), TS(TypeScript)가 언어적으로 무엇이 다를까요. 크게 네 가지로 알아보겠습니다. 혹시 저처럼 서버 개발자에서 웹 백엔드 개발자로 새로운 일에 도전해보고 싶다면 이번 글이 분명 도움이 될 겁니다. Dictionary 사용법 Dictionary는 데이터의 가공과 저장이 편리합니다. 개발자들이 자주 쓰는 타입이기도 하죠. 보통 맵의 key를 순회시키면 아래와 같이 씁니다. 하지만 JS에서는 아래와 같이 씁니다. 해당 객체의 method가 아닌 를…