모두싸인

RSS

게시글: 30
등록: 2026년부터

All Frontend Backend AI DevOps Architecture Etc

Frontend
하나의 프론트엔드 코드로 멀티 환경 운영하기
본 글은 하나의 프론트엔드 코드로 여러 환경의 요구사항에 대응하며 개발 생산성과 유지 보수성을 높이는 방법을 다룹니다. 모두싸인은 일반 기업용, 공공용, 온프레미스 세 가지 환경에 대한 서비스를 제공하며, 각 환경별 요구사항이 달라 발생하는 문제점을 해결하기 위해 단일 코드베이스 전략을 채택했습니다. 초기에는 if/else 조건문으로 환경별 분기를 처리했으나, 코드 복잡성과 유지보수 어려움이 발생했습니다. 이에 AST(추상 구문 트리)와 ESLint 플러그인을 활용하여 조건 분기를 체계적으로 관리하고 코드 일관성을 유지하며 개발 과정을 개선한 경험을 공유합니다.
멀티 환경 운영FrontendAST
모두싸인·2025년 9월 12일
DevOps
모두싸인 QA의 일 하는 방식 — E2E 테스트 자동화
이 글은 모두싸인 QA 팀이 개발 속도 향상과 품질 유지라는 두 마리 토끼를 잡기 위해 E2E 테스트 자동화를 어떻게 운영하고 있는지 소개합니다. 빠른 개발 사이클 속에서 QA가 직면하는 어려움을 해결하고, 품질을 향상시키기 위한 다양한 활동 중 Playwright를 활용한 테스트 자동화 구축 경험을 공유합니다. Playwright는 자동 대기, 강력한 locator, 편리한 디버깅 기능 등을 제공하여 테스트 코드의 안정성과 유지보수성을 높이며, 낮은 Flaky code 비율과 자체 리포트 기능으로 별도의 추가 리소스 없이 안정적인 테스트 운영이 가능함을 강조합니다. 이를 통해 고객에게 더 큰 가치를 빠르고 안전하게 전달하는 것을 목표로 합니다.
E2E 테스트테스트 자동화Playwright
모두싸인·2025년 8월 26일
Backend
로그 인리치먼트(Log Enrichment)
이 글은 감사로그 프로젝트에서 로그 인리치먼트(Log Enrichment)를 설계하고 구현한 경험을 공유합니다. 로그 인리치먼트는 로그에 메타데이터나 컨텍스트를 추가하여 로그를 더 풍부하게 만드는 과정으로, 보안, 규정 준수, 문제 해결에 필수적인 로그 데이터의 활용도를 높입니다. 특히 민감 데이터를 다루는 B2B 서비스에서 사용자 활동을 정확하게 기록하는 것이 중요하며, 단순히 ID만 있는 로그는 분석에 한계가 있습니다. 글에서는 로그 인리치먼트 구현 방식인 동기 방식과 비동기 방식을 비교하고, 모두싸인에서 마이크로 서비스 아키텍처(MSA) 환경에 비동기 방식을 선택한 이유를 설명합니다. 비동기 방식은 성능 유지에 유리하지만 데이터 정합성 이슈가 발생할 수 있어 별도 시스템 구축이 필요함을 언급합니다.
로그로그 인리치먼트메타데이터
모두싸인·2025년 3월 6일
Frontend
SPA 환경에서의 버전 업데이트를 위한 모두싸인의 최신 버전 업데이트 기능 구현기
모두싸인에서 SPA 환경의 버전 업데이트 문제를 해결하기 위해 개발한 최신 버전 업데이트 기능 구현기를 공유하는 글입니다. React, Vite, AWS S3, CloudFront를 기반으로 구축된 배포 환경에서 버전별로 격리된 구조를 사용하며, 이로 인해 발생하는 구 버전 리소스 충돌 문제를 해결하기 위한 기술적 방안과 개발 과정을 상세히 설명합니다. 코드 분할 및 지연 로딩 시 최신 버전의 청크 파일을 가져오는 문제를 방지하고, 이전 버전을 이용하는 사용자가 안정적으로 서비스를 이용할 수 있도록 구현한 기능에 대해 다룹니다.
SPA버전 업데이트React
모두싸인·2025년 2월 12일
Backend
NestJS v10 업데이트의 여정
모두싸인 백엔드 팀에서 NestJS v6에서 v10으로 메이저 업데이트를 진행한 여정을 공유합니다. 오래된 버전을 사용하면서 발생했던 최신 라이브러리 호환성 문제와 쌓여온 기술 부채를 해결하기 위해 이번 업데이트를 결정했습니다. 엔지니어링 컬쳐 길드 활동을 통해 동료들과 함께 진행했으며, 이 글에서는 업데이트 과정에서 겪었던 주요 변경점과 해결 방법을 소개합니다. 특히 `createParamDecorator`의 파라미터 변경 등 실제 코드 예시를 통해 구체적인 변화를 설명하며, 메이저 버전 업데이트의 필요성과 그 과정에서 얻은 경험을 공유합니다.
NestJSNode.jsTypeScript
모두싸인·2025년 1월 23일
Etc
비동기 메시지 가시화 파티가 1년 간 개발 문화를 바꾼 방법
모두싸인 백엔드 엔지니어 루디는 엔지니어링 컬처 길드 활동 중 '비동기 메시지 가시화 파티'를 통해 1년간 개발 문화를 개선한 경험을 공유합니다. 이 글은 MSA 환경에서 복잡해지는 비동기 메시지 흐름 파악의 어려움을 해결하고, 비동기 작업의 체계적인 발행 및 관리를 통해 개발 생산성을 향상시킨 과정을 담고 있습니다. 길드 활동을 통해 비동기 메시지 사용의 비효율성을 개선하고, 개발자 간의 협업을 증진시키며 긍정적인 개발 문화를 조성한 사례를 소개하며, 유사한 어려움을 겪는 조직이나 개발자들에게 실질적인 도움을 제공하고자 합니다.
개발 문화비동기 메시지MSA
모두싸인·2025년 1월 22일
Backend
달리는 서비스의 이벤트 버스 개선하기
모두싸인에서 CSAP 인증 취득을 위해 AWS에서 네이버 클라우드 플랫폼(NCP)으로 서비스를 마이그레이션하는 과정에서 발생한 레거시 비동기 메시지 시스템의 문제점을 분석하고 개선한 경험을 공유합니다. 기존 시스템은 비동기 메시지에 대한 명확한 규칙 부재와 다양한 물리적 구현 패턴 사용으로 인해 관리의 어려움이 있었습니다. 특히 MSA 아키텍처 도입 이후 서비스 성장과 함께 다양한 개발자들이 각기 다른 패턴을 적용하면서 비동기 메시지 시스템이 통일되지 못했습니다. 이러한 문제 해결을 위해 이벤트 버스 개선을 중심으로 시스템을 재정비하고 표준화하는 과정을 다룹니다.
이벤트 버스MSA비동기 메시지
모두싸인·2024년 11월 29일
Backend
B2B를 위한 인가 체계 구축기: 워크스페이스 프로젝트
본 글은 B2B 서비스인 모두싸인에서 워크스페이스 프로젝트를 통해 개편된 인가 체계 구축 경험을 공유합니다. 초기에는 소규모 스타트업을 대상으로 했으나, 엔터프라이즈 고객층 확대로 인해 여러 사용자가 함께 이용하고 권한을 제어해야 하는 니즈가 발생했습니다. 이를 해결하기 위해 기존의 소유자 중심 접근 방식에서 조직 단위로 리소스를 소유하고 사용자에게 권한을 부여하는 방식으로 인가 체계를 개편했습니다. 이 과정에서 인증과 인가의 차이점을 명확히 하고, 유연하고 확장 가능한 인가 시스템을 설계하는 데 중점을 두었습니다. 글은 인가 개념을 이해하는 개발자를 대상으로 하며, 실제 구축 과정과 개선점을 상세히 다룹니다.
인가AuthorizationB2B
모두싸인·2024년 9월 26일
Backend
TypeORM으로 데이터베이스 마이그레이션하기
이 글은 TypeORM을 사용하여 데이터베이스 마이그레이션을 수행하는 방법에 대한 기술 블로그 게시물입니다. 모두싸인 백엔드 개발자가 작성했으며, TypeORM의 마이그레이션 기능을 활용하여 데이터베이스 스키마 변경을 효율적으로 관리하는 과정을 설명합니다. 데이터베이스 마이그레이션은 애플리케이션 개발 및 유지보수 과정에서 필수적인 작업으로, 스키마 변경 사항을 추적하고 적용하는 데 도움을 줍니다. TypeORM은 ORM(Object-Relational Mapping) 라이브러리로, JavaScript/TypeScript로 데이터베이스 작업을 추상화하여 개발 생산성을 높여줍니다. 본문에서는 TypeORM 마이그레이션의 기본 개념, 설정 방법, 마이그레이션 파일 생성 및 실행 과정 등을 다룰 것으로 예상됩니다. 이를 통해 개발자는 데이터베이스 변경 사항을 안전하고 체계적으로 관리할 수 있습니다.
TypeORMDatabase MigrationSQL
모두싸인·2021년 11월 30일
Backend
여러 AWS S3 Object를 하나로 압축하기
본 글은 모두싸인 백엔드 서비스에서 여러 AWS S3 객체를 하나의 ZIP 객체로 압축하는 기능 개발 경험을 공유합니다. 기존에는 문서 파일을 하나씩만 다운로드할 수 있어 고객의 불편함이 있었으나, 이를 해결하기 위해 여러 파일을 한 번에 다운로드할 수 있는 기능을 개발하게 되었습니다. 시스템 디자인 단계에서는 Node.js 환경에서 stream을 활용하는 방식을 채택했습니다. S3 객체를 하나씩 읽어 압축 stream으로 연결하는 방식으로, 서버에서 모든 파일을 다운로드하여 압축하는 방식보다 효율적인 처리가 가능할 것으로 기대했습니다. 이 글은 AWS S3 객체 압축 기능 개발의 필요성, 시스템 디자인 결정 과정, 그리고 stream을 활용한 구현 방안에 대해 설명합니다.
AWS S3Node.jsStream
모두싸인·2021년 5월 12일
Backend
여러 AWS S3 Object를 하나로 압축하기
본 글은 모두싸인 백엔드 서비스에서 여러 AWS S3 객체를 하나의 ZIP 파일로 압축하여 제공하는 기능 개발 경험을 공유합니다. 기존에는 문서 파일을 하나씩만 다운로드할 수 있어 고객의 불편함이 있었으나, 이를 해결하기 위해 여러 파일을 한 번에 다운로드할 수 있는 기능을 기획했습니다. 시스템 디자인 단계에서는 Node.js 환경에서 stream을 활용하여 S3 객체를 효율적으로 압축하는 방식을 채택했습니다. 서버에서 모든 파일을 다운로드하여 압축하는 방식은 시간이 오래 걸릴 수 있으므로, stream을 통해 데이터를 처리하는 방식을 선택하여 성능을 개선하고자 했습니다. 이 글은 S3 객체 압축 및 다운로드 기능 구현에 대한 기술적인 접근 방식을 설명합니다.
AWS S3Node.jsZIP
모두싸인·2021년 5월 12일
Frontend
“잘” 사용할 수 있는 디자인 시스템 컴포넌트 만들기
이 글은 React 기반 프론트엔드 개발팀이 "잘" 사용할 수 있는 디자인 시스템 컴포넌트를 만들기 위해 고민했던 과정을 공유합니다. 디자인 시스템 구축 이전에는 공통 스타일을 scss 폴더에 정의하고 클래스를 가져다 쓰는 방식이었으나, 컴포넌트 수가 늘어나면서 관리의 어려움이 발생했습니다. 이에 따라 레고처럼 조립하여 사용할 수 있는 디자인 시스템 구축을 결정했습니다. 이상적인 협업 프로세스로서, UI 컴포넌트의 variation에 대한 명확한 인지를 바탕으로 최소한의 커뮤니케이션으로 빠르게 동기화하여 개발하는 것을 목표로 합니다. 이를 통해 개발 생산성과 협업 효율성을 높이고자 합니다.
디자인 시스템UI 컴포넌트React
모두싸인·2021년 4월 26일
Frontend
“잘” 사용할 수 있는 디자인 시스템 컴포넌트 만들기
이 글은 "잘" 사용할 수 있는 디자인 시스템 UI 컴포넌트를 만들기 위한 고민 과정을 공유합니다. 모두싸인 프론트엔드 팀은 React 기반으로 개발하며, 디자인 시스템 구축 이전에는 SCSS의 shared 폴더에 공통 스타일을 정의하고 클래스를 가져다 쓰는 방식을 사용했습니다. 하지만 컴포넌트 수가 늘어나면서 관리의 어려움이 발생했고, 이에 레고처럼 조립하여 사용할 수 있는 디자인 시스템 구축을 결정했습니다. 이상적인 협업 프로세스로는 최소한의 커뮤니케이션으로 UI 컴포넌트의 variation에 대해 빠르게 동기화하는 것을 목표로 합니다. 이를 통해 개발 생산성과 협업 효율성을 높이고자 합니다.
디자인 시스템UI 컴포넌트React
모두싸인·2021년 4월 26일
Backend
외부 서비스 장애가 전파되지 않게 하기 위한 한 가지 방법
이 글은 외부 서비스 장애가 내부 시스템으로 전파되는 것을 방지하는 방법에 대해 설명합니다. 특히, 서킷 브레이커 패턴을 활용하여 외부 서비스의 장애 발생 시 요청을 차단하고, 일정 시간 후 재시도를 통해 시스템 안정성을 확보하는 방안을 제시합니다. 서킷 브레이커는 외부 서비스의 응답 지연이나 오류가 발생했을 때, 해당 서비스로의 요청을 즉시 실패 처리하여 내부 시스템의 부하를 줄이고 장애 확산을 막는 역할을 합니다. 이를 통해 서비스의 가용성을 높이고 사용자 경험을 개선할 수 있습니다. 글에서는 서킷 브레이커의 작동 원리와 적용 사례를 통해 백엔드 시스템의 견고성을 강화하는 방법을 공유합니다.
장애 전파외부 서비스Circuit Breaker
모두싸인·2021년 1월 27일
Backend
외부 서비스 장애가 전파되지 않게 하기 위한 한 가지 방법
본 글은 외부 서비스 장애가 내부 시스템으로 전파되는 것을 방지하는 방법에 대해 다룹니다. 외부 서비스의 장애는 연쇄적인 장애를 유발하여 서비스 전체의 안정성을 해칠 수 있습니다. 이를 해결하기 위한 방법으로 '서킷 브레이커' 패턴을 소개합니다. 서킷 브레이커는 외부 서비스 호출 시 일정 횟수 이상 실패하면 해당 서비스로의 호출을 차단하고 즉시 실패 응답을 반환하는 방식입니다. 이를 통해 장애가 발생한 외부 서비스가 복구될 시간을 벌어주고, 내부 시스템의 부하를 줄여 연쇄 장애를 방지할 수 있습니다. 글에서는 서킷 브레이커의 동작 방식과 구현 시 고려사항을 설명하며, 서비스 안정성 확보를 위한 필수적인 패턴임을 강조합니다.
장애 전파서킷 브레이커외부 서비스
모두싸인·2021년 1월 27일
Frontend
프론트엔드에서 의미있는 테스트 코드 작성하기
이 글은 프론트엔드 개발에서 의미 있는 테스트 코드를 작성하는 방법에 대해 다룹니다. 프론트엔드 테스트의 어려움, 특히 UI/UX 영역에서 입력, 실행, 결과 검증을 어떻게 격리하고 테스트할지에 대한 고민을 공유합니다. 과거에는 E2E 테스트나 Enzyme을 사용했지만, 유지보수 비용이 높고 컴포넌트 내부 구조에 의존적인 단점이 있었습니다. 현재는 React Testing Library와 axios-mock-adapter를 활용하여 사용자가 실제 사용하는 방식대로 DOM 노드를 기반으로 테스트하고, API 요청을 모킹하여 UI 변경까지의 전체 흐름을 신뢰성 있게 테스트하는 방법을 제시합니다. 이를 통해 테스트 코드의 작성 비용은 줄이면서도 높은 신뢰도를 확보할 수 있습니다.
테스트 코드FrontendJest
모두싸인·2021년 1월 19일
Frontend
프론트엔드에서 의미있는 테스트 코드 작성하기
이 글은 프론트엔드 개발에서 테스트 코드 작성의 중요성과 어려움, 그리고 효과적인 테스트 전략에 대해 다룹니다. 사용자와 가장 먼저 만나는 프론트엔드 영역의 테스트는 격리된 환경에서 작성하기 어렵다는 점을 지적하며, 과거에는 E2E 테스트나 Enzyme을 사용했지만 유지보수 비용이 높다는 단점이 있었습니다. 하지만 React Testing Library와 axios-mock-adapter와 같은 도구를 활용하면 사용자가 실제 사용하는 방식과 동일하게 DOM 노드를 활용하여 테스트할 수 있으며, API 요청에 대한 Mocking을 통해 전체적인 사용자 경험 흐름을 효과적으로 테스트할 수 있음을 강조합니다. 이를 통해 테스트 코드의 신뢰성을 높이고 개발 생산성을 향상시킬 수 있습니다.
테스트 코드FrontendJest
모두싸인·2021년 1월 19일
Backend
알림 서비스 탄생 비화
모두싸인 백엔드 개발자가 알림 서비스의 탄생 배경과 개선 과정을 공유하는 글입니다. 기존 계약 서비스 내에 알림 기능이 포함되어 외부 서비스 장애 시 계약 기능까지 영향을 받는 문제점과, 계약 정보와 알림 기능 간의 모호한 경계가 드러났습니다. 이러한 문제를 해결하기 위해 계약 서비스와 알림 서비스를 분리하는 결정을 내렸으며, 이는 마이크로서비스 아키텍처(MSA)의 필요성을 보여줍니다. 글에서는 서비스 분리의 계기와 과정, 그리고 이를 통해 얻게 된 개선점을 설명합니다.
알림 서비스서비스 분리MSA
모두싸인·2021년 1월 15일
Backend
알림 서비스 탄생 비화
모두싸인에서 백엔드 개발자가 겪었던 알림 서비스 관련 문제점과 개선 과정을 공유하는 글입니다. 기존 계약 서비스에 알림 기능이 통합되어 외부 서비스 장애 시 계약 기능까지 영향을 받는 문제와, 새로운 알림 기능 요구사항이 계약 기능에 영향을 미치는 경계 모호성 문제가 발생했습니다. 이를 해결하기 위해 계약 서비스와 알림 서비스를 분리하는 아키텍처 개선을 진행했습니다. 이 과정에서 서비스 분리의 필요성과 고려사항을 설명하며, 백엔드 개발 관점에서 시스템 설계 및 개선에 대한 인사이트를 제공합니다.
알림 서비스서비스 분리MSA
모두싸인·2021년 1월 15일
DevOps
Terraform + AWS 셋팅하기 Part 2
본 글은 Terraform과 AWS를 연동하여 인프라를 설정하는 "Terraform + AWS 셋팅하기 Part 2"에 대한 내용입니다. Part 1에서 다룬 초기 셋팅에 이어, 본 글에서는 Terraform의 assume_role과 workspace 기능을 활용하여 AWS 환경을 더욱 효율적으로 관리하는 방법을 중점적으로 다룹니다. assume_role은 IAM 역할을 위임하여 여러 AWS 계정이나 프로젝트 간의 권한을 안전하게 관리할 수 있도록 돕고, workspace는 동일한 Terraform 코드를 사용하여 여러 환경(개발, 스테이징, 프로덕션 등)을 분리하고 관리할 수 있게 합니다. 이를 통해 인프라 코드(IaC)의 재사용성을 높이고, 복잡한 AWS 환경을 체계적으로 구축 및 운영하는 데 기여합니다.
TerraformAWSassume_role
모두싸인·2020년 12월 29일