서론드디어 레거시를 갈아치울 수 있는 기회가 주어졌다. 송아리 당뇨는 Flutter와 Vue3 기반의 하이브리드 앱이다. 기존 웹 코드는 Vue3 기반이었고, 내가 입사하기 전 외주업체를 통해 개발된 서비스였다. 기능을 추가하고 버그를 수정하면서 기존 구조를 익혀왔지만, 변경할 때마다 함께 확인해야하는 코드의 범위가 점점 넓어졌다. 주석과 문서만으로는 로직 사이의 의존 관계를 파악하기 어려워, 실제 실행 흐름을 따라가며 확인해야 하는 경우도 빈번했다. 그 중에서도 가장 으뜸이었던 부분은 메인 레이아웃 컴포넌트였다. 이름만 보면 페이지의 공통 레이아웃을 담당하는 컴포넌트처럼 보이지만, 실제 파일은 1200줄에 달하는 데다, 인증, Native Bridge 등록, 블루투스 혈당기/혈압계 이벤트 처리, 광고,..
서론이전 글에서는 리포트 생성 과정에서 대량의 데이터 복호화와 가공 연산이 메인 스레드를 점유하면서 발생했던 문제를 Web Worker를 통해 개선한 과정을 다뤘다. 하지만 리포트 페이지에서는 가공 연산을 워커 스레드로 이전하는 것 이외에도 더 개선할 점이 있었다. 이전 포스팅에서 언급했던 것처럼 리포트 생성을 위해서는 IoT를 통해 측정후 암호화 되어 저장된 산소포화도/맥박수 데이터를 DynamoDB에서 조회한 뒤 복호화하고 가공하는 과정이 필요하다. 24시간 연속 측정을 기준으로 주간 리포트에서 처리해야하는 암호화 데이터는 약 24만 개, 월간으로 범위를 넓히면 103만 개까지 증가한다. 문제는 이렇게 많은 데이터를 한 번 조회한 이후에도 동일한 기간을 다시 조회할 때 DynamoDB를 재조회하고 있..
서론기존의 레거시 서비스인 송아리 웹DM을 개발하면서 리포트 기능의 병목을 개선했던 내용을 정리해보고자 한다.송아리 웹DM은 회사 서비스들을 이용하여 입력한 데이터들을 기반으로 그래프와 통계 형태로 정보를 제공하는 대시보드 서비스다.자사의 대표 서비스인 송아리에어는 산소포화도 측정하는 IoT를 통해서 측정한 산소 포화도와 맥박수를 DynamoDB에 암호화된 형태로 저장하게 된다. 이 암호화된 데이터는 0.5초마다 하나의 정보를 가지고 2.5초 즉, 다섯개의 데이터를 하나의 데이터 셋으로 하여 암호화 후 DynamoDB에 저장되는 형태다. 송아리 웹DM에서는 해당 데이터를 가지고 평균 산소포화도, 평균 맥박수, 최저 산소포화도, 최저 맥박수, 위험 구간 기록 등 여러 정보를 리포트 형태로 나타내주는데, 이..
문제 설명첫 접근 방향네 개의 주사위에서 나온 숫자의 중복 형태에 따라서 점수를 계산하는 문제였기 때문에, 일단은 가장 쉬운 방식으로 접근해보기로 했다.a, b, c, d 모든 숫자에 대해서 각각의 조건을 만족하는 조건문을 작성해보려고 생각을 했는데, 네 개의 조건 비교만으로도 너무 많은 노다가를 필요로 했다.if (a === b && b === c && c === d) { // 모두 같은 경우 }위와 같이 작성을 해보려다가 바로 잘못된 접근 방식인 것을 확인하고 다른 방향으로 접근해야겠다고 생각했다.숫자를 직접 비교하는 대신 각 숫자가 몇번 등장했는지 세자.각 숫자의 등장 횟수를 세기 위해서는 Map을 사용하는 것이 가장 효율적이라고 판단했고 다음과 같이 코드를 작성했다.const dice = [a, ..
최근 회사에서 기존 프로젝트 마이그레이션을 진행중이다. 자사 앱을 사용해서 의료 데이터를 쌓아온 유저에게 통합 데이터를 제공하는 서비스인데,다루는 데이터가 사용자의 민감한 의료 데이터다 보니 기존 레거시보다 보안과 데이터 제어에 신경을 써야했다. (도입계기에 대해서는 추후 별도의 블로그 포스팅으로 더 자세하게 풀어보겠다.) 아무튼 Remix를 통해 SSR 프로젝트로의 마이그레이션을 진행하던 도중 문득문득 개발하면서 이전에 올렸던 블로그 포스팅이 떠올랐다. 당시에는 이론적으로 '정의'에 대해서 좀 집중했다면, 실제 프로덕션 레벨에서 SSR을 마주하다보니 좀 더 체감이 컸다. 개발하면서 이전 블로그 포스팅에서 떠올랐던, 그리고 강조했던 핵심 부분은 다음과 같다."MPA와 SSR, SPA와 CSR를 동일하다고..
들어가며졸업, 취준 이후에 프론트엔드 개발자로서의 1년이 지나갔다. 조금 늦은 회고록이지만, 아직도 가끔은 스스로에게 물을때가 있다. "과연 나는 1년차 개발자 답게 살고 있을까?" 취준생일 때 상상했던 1년차 개발자는 혼자서 어느정도의 문제는 술술 해결할 줄 아는 개발자였지만, 실제로 경험한 1년차는 여전히 주니어였고, 술술 해결하기보다는 조금 덜 헤매고, 조금 더 익숙해진 정도였다. 신입이었던 나의 1년전 모습과 지금 모습의 차이를 꼽자면, 이제는 회사의 비즈니스 도메인과 워크플로우가 몸에 익어 문서를 들락날락하지 않아도 자연스럽게 일을 할 수 있다는 것 정도라고 생각한다. 돌아보면, 1년동안 가장 많이 성장하고 배웠다고 생각한 순간들은 실제 프로젝트에 참여해서 부딪힌 경험에서 나왔다.이전에 현업에 ..
덕풀 프로젝트가 성공적으로 끝나면서 리팩토링 해야 할 부분을 지속적으로 찾기 시작했다. 확실히 프로젝트를 실제로 사용하면서 이미지의 레이아웃 시프트, 이미지 리소스 용량 비대와 같은 문제점을 발견했고, 해당 부분을 좀 더 개선시켜야겠다고 생각했다. 홈 페이지를 기준으로 덕질자랑과 덕질토크의 최근 10개 게시물을 불러오도록 하고, 실제 유저에게는 swiper를 사용하여 덕질자랑과 덕질토크 게시물 각각 데스크탑 기준 5개, 4개 모바일 기준 3개, 2개의 이미지만 보여지게된다. 이 때 총 20개의 이미지 리소스를 모두 다운로드 받게되면 페이지 로딩 시간이 길어지는 문제가 발생했다. 이 부분을 Lazy Loading을 통해 성능적으로 많은 개선을 이루어서 해당 포스팅을 통해 소개해보고자 한다. 가장 먼저 이미..
서비스를 구현함에 있어서 에러처리는 굉장히 중요한 부분이다. 실제로 유저들이 서비스를 사용하면서 에러가 발생했을 때 그에 따른 처리를 구현해놓지 않는다면 사용자는 에러로 인한 터진 애플리케이션을 보게되고, 현재 서비스에 어떤 문제가 있는것인지 유저들은 확인할 수 있는 방법이 없다. 따라서 고스란히 서비스에 대한 신뢰성 하락과 유저 이탈로 이어질 수 있다. 여러 프로젝트를 진행하면서 에러처리에 신경을 썼다고 생각했지만, 에러가 발생할 만한 컴포넌트 내에서 에러 처리를 해준다거나 try catch를 남발하는 등,, 지금 돌이켜보면 효과적으로 에러처리를 진행하지는 못한 것 같다. 따라서 덕풀 서비스를 구현하면서 에러처리 중앙화에 대해서 고민했던 상황들을 소개해보고자 한다. 발생 가능한 에러 상황 나는 덕풀 프..
