FEConf-2022

<목차>

• 디자인 시스템, 형태를 넘어서
• 일백개 패키지 모노레포 - 우아하게 운영하기
• UX 개발자, 대형 서비스 빠르게 프로토타입하기
• 내 import 문이 그렇게 이상했나요?

 

회사에서 지원을 받아서 Frontend Conference를 다녀왔다. 

새로운 지식과, 열정을 느낄 수 있는 시간이었다. 

디자인 시스템, 형태를 넘어서

이소영flex

"기능이 형태에 결합되지 않는 디자인 시스템은 어떻게 만들어야 할까?"
flex의 세 번째 디자인 시스템 "linear"이야기를 통해 이 물음에 답을 찾아가는 과정을 공유합니다."

 

<요약>
주의할 점
디자인 시스템은 병목 또는 제약으로 작용하면 안된다. 
관리 주체가 명확해야 한다. 

설계 아이디어
하위 아이템을 커스텀 가능한 아이템과 기본 아이템 중 택 1 을 선택하여 개발하도록 설계하는 건 어떨까?
기본 기능은 스크롤 영역, 접근성, 키보드 탐색 등 최소한으로 보장하여야 한다. 

문제 해결
컴포넌트들을 최대한 조합할 수 있는 형태로 제공하되, 반복 작업이 많은 부분은 디자인시스템에서가 아닌, 새로운 라이브러리에서 구성으로 제공하는 방법도 있다. 

<생각>
디자인 시스템만 만들고 있기에는 개발리소스가 너무 부족하다. 공통 컴포넌트를 만들때, 설계 아이디어라도 참고해 보자...

 

확장성

디자인 시스템이 병목이 되지 않기 위해 갖추어야 함

• 형태가 강하게 결합되면 안됨
• 확장성을 갖추지 못했을 때의 문제점
  • 컴포넌트 형태인 style : custom 필요한 경우가 있음
    • 각 요구사항 마다 컴포넌트 생성 : 파편화 → 복잡성 추가
    • prop 추가 : 디자인시스템 책임 무거워짐, 컴포넌트 기능 다양해짐 → 복잡성 추가

디자인 시스템

• 정의
  ex. select-component
  • 형태 = 스타일 : color, layout 등…
  • 기능 : 아이템 선택 등
  • 접근성 : popup 요소에 대한 힌트
  • 커스텀 : needs 에 따라 형태나 기능을 쉽게 custom 가능
    • 커스텀과 제약(형태, 기능)은 반비례 형태 가짐

linear : flex 디자인 시스템

• 기존 버전 아쉬운점
  • 관리 주체 x : interface 일관성 x
  • ant design 시스템의 아쉬운점 그대로 가짐
    • 형태 커스텀 불가능
    • 키보드 지원 불가

3가지 principles

• 기능은 형태와 독립적
  • checkbox, radio : 기본형태가 필요한 경우와 custom 이 필요한 경우에 따라 다른 item 컴포넌트 사용가능
  • trigger : children으로 trigger 컴포넌트를 선언하는 것만으로 select 등의 content component 와 상태 공유 가능하도록 개발
• 기본 동작 보장
  • 신중하게 결정, 디자인 시스템이 제약이 되지 않도록
  • ex. scroll 영역, 접근성 : 키보드 탐색
  • 완성형 x, 조합형
• 최소한의 제약
  • 최대한의 자유도, 디자이너들이 디자인할 때 제약을 갖지 않도록
  • 컴포넌트에서 자유로운 커스텀 영역을 제공 :
• 문제점
  • 조합에 대한 비효율 : 모두 liner 디자인 시스템에서 수용하면 유연성, 확장성 잃을 수 있음
  • 해결방법 : linear extension 생성 : 반복잡업의 비효율 줄임, 구체적인 dataType 가질 수 있음

일백개 패키지 모노레포 - 우아하게 운영하기

오창영토스

토스 전 계열사에서 사용하고 있는 거대한 사내 라이브러리 모노레포의 운영 경험에 대해 공유합니다.

모노레포 : 잘 정의된 관계를 가진, 여러개의 독립적인 프로젝트들이 있는 하나의 레포

 

<요약>
모노레포 장점 + 모노레포 사용할 때 주의할 점

<생각>
인상깊었던 것은 코드 품질 관리 설명중에서.. jsdoc 으로 주석을 작성하면 자동 배포되어 문서화 된다는 것이다. 어떻게 세팅하는지 확인해봐야겠다. 

멀티레포의 문제점

• 상황 : projectA projectB 가 따로 있음
  • 구성원 권한부여 번거로움
  • 재사용 코드 중복
  • ci/cd lint test ts 등 재설정
• 새 프로젝트 생성 비용 큼
• 프로젝트간 코드 공유 어려움
• 같은 이슈 수정 위해서 각각 레포에 커밋 필요
• 히스토리 관리 어려움
• 제각각인 툴링으로 개발자 경험이 일관적이지 않음 →
  jaranda: app.jaranda.kr 모노레포로 생성하고 lint, prettier 세팅 단일화함으로써 해결

모노레포 장점

• 새 프로젝트 생성 비용 x
• 프로젝트간 코드 공유 쉬움
• atomic commits
• 히스토리 관리 쉬움
• 공통된 툴링 → 일관적인 개발자 경험 제공
• Monorepo features
  • 속도
    • local caching
    • local task ochestration
      • ochestration : 자동화된 설정
    • 하나의 프로젝트만 수정해도 나머지 프로젝트에 반영할 수 있는 기능
  • 관리
    • source code sharing
    • 의존성 관계 설정

toss FE chapter library

• library only monorepo
  • 배포 : npm privacy
  • 의존성 관리
    • node_modules 의 문제점
      • phantom dependency : 명시되지 않은 라이브러리 불러올 수 있음 →
        해당 라이브러리를 사용하면 의존성이 혼란스러워지고 run-time error 의 원인이 될 수 있음
    • yarn 사용
      • .pnp.cjs 를 통한 엄격한 의존성 관리
      • zero install
      • 빠른 의존성 검색
    • peer dependency 주의할 점
      • 상속 dependency : 중복해서 제공하지 않고 가장 상위의 번들링에만 포함
      • 문제점 : 전파된다 → p(b 포함)를 사용하지 않더라도 b를 사용하기 위해 p package 명시 필요 → 의존성 복잡도 증가
      • 잠재적 런타임 에러가 될 수 있음
      • 꼭 싱글턴으로 존재해야 하는 패키지일 때만 peer dependency로 명시
    • 버전 관리
      • semver : 버전넘버가 어떻게 할당되는지 명시적인 규칙과 요구사항
        • 형태 : major.minor.patches
      • 토스 : lerna version 사용하여 관리
  • 코드 품질 관리
  • RFC = request for comments
    • 본격적인 코드 작성 전 설계에 대한 리뷰와 피드백 가능
  • PR
    • library code owner 코드 검증 & 승인 → 코드 품질 향상
    • pure dependency error & dead code export 없는지 & 배포가 잘 되는지 등을 ci 로 체크
  • 문서화
    • 코드 주석 jsdoc 로 작성 → 문서화 시스템 통해서 toss FE chapter docs 로 자동 배포, 추가
• service monorepo
  • 배포 : 내부 인프라
• toss 공개 모노레포 링크
  https://github.com/toss/slash

UX 개발자, 대형 서비스 빠르게 프로토타입하기

박신연구글 검색

다소 생소할 수 있는 UX 개발자와 그 역할 중 프로토타입 제작에 대해 이야기합니다.
최근에 구글 검색, 쇼핑에서 주로 사용하는 프로토타입 유형들을 알아보고 그중 대형 서비스의 특성상 발견하게 된 특별한 프로토타입 유형을 자세히 소개 합니다.

 

<요약>
프로덕션 환경의 프로토타입을 빠르게 만들고 공유하는 방법으로 google extension 을 사용하는 것은 어떨까?

<생각>
오.. 현업에서 쓸.. 일이 있을수도? 생각하지 못한 방법이라서 흥미롭다. 

 

• 주제 : 대형 서비스(한 서비스에 각각의 영역 담당하는 개발팀이 있는 경우)에서 빠르게 프로토타이핑하고 테스트해야 하는 경우 UX 개발자의 방법 공유
• UX 개발자 : 디자인과 사용성에 집중하는 개발자 (디자이너편)
  • 관심 : 디자인 시스템, 프로토 타이핑, user test, 내부 도구 만들기

prototype

• 전체적인 기능을 간단한 형태로 구현한 시제품
• 개발자는 왜 프로토타이핑을 할까?
  • 다른 부서에게 빠르게 공유 → 효과적인 의사소통
  • 개발자가 서비스에 미칠 수 있는 영향 극대화

prototype 종류

• pretotype
  • pre (프로토타입 만들기 전) + 제품이나 서비스인 척 하는 것
• design prototype
  • 디자인 파일을 브라우저에서 확인
  • tool : figma 등
• 개발자 prototype
  • 실제 프로덕트의 데이터를 이용하는 모션 포함, 새로운 상호작용(interaction)을 제안
  • ux 개발 프로토 타입 종류(개인적)
    • mock-up environment
      • 목적 → 환경의 자유도 결정
        • 무엇을 테스트
        • 어떤 사용자 대상
        • 몇 명 사용자
        • 어떤 방식
      • ex : mouse hover → 이미지가 커져야 한다 : 어느 정도 예민해야 할까?
      • 특정 부분이나 기능만 구현, 나머지 부분 이미지 대체, 제한적 user research 에 사용
    • components environment
      • 데이터의 반영 필요한 경우
      • 한계점 : 디자인 시스템 정의 요구, 재사용 x, 시간이 오래 걸림, 어디까지 만들어야 할까..
      • ex. storybook 사용
    • product environment : chrome extension 사용 (발표자가 소개하고 싶은 것)

product environment

• 환경 구성 방법
  chrome extension 제작 → 배포 → 사용자(설치 후 크롬 브라우저에서 특정 사이트 접속) -> 스크립트와 스타일 실행 → 실시간으로 새롭게 생성된 사이트 환경 확인 → 사용자 : 익스텐션의 설정 변경 → 확인 가능
• 장점 : 실제의 환경을 이용한 프로토타이핑
  • 환경 구성 x
  • chrome extension 자동 배포
• 코드 레벨 설명
  • manifest.json : extension 생성할 때 사용
    content_scripts : 특정 url(환경 구축하고 싶은 url) 과 매칭되면, 실행해야 하는 코드 생성
    ex : css로 실제 product 에서 id, class 찾아서 변경, js 도 반영가능
    코드 공유 :
  • 관련 개발 문서 : https://developer.chrome.com/docs/extensions/
    위 링크 참고해서 product environment를 google extension 으로 생성 가능하다
• 단점
  • 실제 환경이 변화했을 때, selector 가 사라졌을 수 있음
  • 외부 사용자에게 test 할 때, chrome extension을 설치하도록 유도 필요
  • mobile 에서 확인 불가(pc 에서 mobile 테스트 필요)

내 import 문이 그렇게 이상했나요?

박서진토스

프론트엔드 개발자에게 있어 import 문은 더 이상 낯선 개념이 아닙니다. 그런데 잘 살펴보면 그렇게 작성된 import 문은 JavaScript 표준과는 거리가 있을 가능성이 높습니다.

표준 모듈 시스템인 ECMAScript Modules에 대해 소개하면서, 왜 ESM으로 가야 하는지, 어떻게 갈 수 있는지 소개합니다.

 

<요약>
ESM 과 CommonJs 의 라이브러리 사용 방법 혼용으로 다양한 에러의 원인이 된다. 
현재는 ESM 지원 문제가 있어, 옮기기는 힘들지만 언젠가는 옮겨가야 함으로 꾸준히 관심을 가지고 대비하자.
미리 대비하는 방법 : 일단 확장자를 붙여 import 해볼까?

<생각>
오.. ts import 는 가짜였구나.. esm 으로 갈때, 고생할듯 ㅠㅠ

 

• 이상한 import 문으로 발생하는 error
  • error message : unexpected token import
  • require() of ES Module
• error 원인
  • 동기에서 비동기 사용은 매우 어려움 반대로 비동기에서 동기 사용은 가능
  • commonJS 에서 import 가능, ESM 에서 require 사용 어려움
• 해결 방법 : commonJS → ESM 도입(이 방법밖에..)

commonJS

• 과거 : 모듈 시스템 없는 JS
  • script 태그 직접 import → commonJS 모듈 시스템 생성 (require) → 파일 단위 개발 가능
• commonJS 문제점
  • node.js 에서만 사용 가능 (브라우저 x)
  • 정적 분석의 어려움
    • require 이 keywords 가 아닌 함수이기 때문에.. 변수 저장 연산자 내 사용 등이 가능.
  • 비동기 모듈 정의 불가능
  • global require 함수 재정의 가능 : jest, ts-node, yarn 라이브러리 등에서 변경 : esm 에서 동작하지 않음 → 향후 각 라이브러리에서 esm 대응 필요

ESM

• import export 문법
• 쉬운 정적 분석 : 조건문을 통한 import 불가
• import export는 keyword 이기 때문에 재정의 불가
• 비동기 동작 가능
• 언어표준 지정 : 브라우저, node, deno 환경에서 모두 사용 가능
• package를 ESM으로 옮기기
  • 난관
    • 우리가 사용하는 가짜 esm : 실제 동작이랑 다를 수 있음
      함정 : ts, babel 사용 → import 가 commonJS 의 require 로 변환됨.
    • 성숙하지 않은 생태계 : 많은 라이브러리들이 아직 common-js 이용
      • ts 에서 esm 지원을 아직 하지 않음 → 정식 버전에서 이제 시작
        • 문제점 있음 : ts 파일만 있어도.. js 파일로 import 해 ㅎㅎ..
      • 라이브러리를 쓸 때, / 포함하여 일부만 Import 하면 문제가 된다
        • 원인 : esm 에서는 확장자를 명시해야 해야해서..
  • Node.js 에서의 ESM 규칙
    • package.json
      • type: module → js 파일 esm 방식으로 동작
      • 확장자 제공 : esm 안에서 common-js 사용가능
        • .cjs → commonJs 동작
        • .mjs → esm 동작
    • package.json
      • type: commonJs(default) → js 파일 commonJs 방식으로 동작
• 올바른 import 문을 쓰는 방법
  • 진짜 import 은 확장자 포함 필요: .js 등
  • require 은 확장자를 자동으로 찾아주지만.. esm의 import 는 아님 → 확장자가 없으면 번들링 늦어지고, node.js 성능이 나빠짐
• 어떤 서비스를 옮길 수 있을까 → jaranda 서비스는 아직 불가능
  • ts 안쓸 때
  • 사용하는 라이브러리가 esm 환경 지원
    • next-js x, react 0
  • jest, yarn Pnp, ts-node 등 commonJS 환경에 깊이 의존하는 라이브러리를 사용하지 않을 때
  • 향후 esm 으로 점점 변화하지 않을까
• 내 서비스를 옮기는 방법
  • type: module 을 package.json 에 축
  • import 파일 확장자 모두 찾아서 추가해 주기^^
  • require 문 모두 import export 로 변환
    • require 문 남겨야 하면.. {createRequire} from ‘module’ 해서 사용해도 되고..