(NHN) NHN FORWARD 22 내용 요약

by

(NHN포워드22)

Concise Summary

NHN의 다섯 번째 오프라인 컨퍼런스

날짜: 2024년 11월 22일

'추천 관련글,

장소: 그랜드 인터컨티넨탈 서울 파르나스

(NHN 기조연설) – 오프닝

사회자: NHN클라우드 박근한, 이진수, 김명신

  • 작은 단계가 큰 차이를 만듭니다
  • NHN컴퍼니 소개 (게임, 결제, 커머스, 데이터, 클라우드)
  • GameAnvil, GameTalk 소개
    • 게임 모루
      • 게임 서버 템플릿, 웹 운영 도구, 성능 테스트 도구 등을 제공합니다.
        • 개발 경험이 적은 게임 개발자라도 게임 서버 개발과 서비스, 서비스 운영을 한번에 할 수 있습니다.
        • 게임 토크
        • 게임 내 채팅을 쉽게 구현할 수 있는 솔루션
  • 좋은 기술이란?
    • 고객이 인정하는 기술 창조
  • 데이터 센터의 국내 및 국제 확장 계획
  • AI 기술의 확장
    • 동화책을 읽다
      • 일반 AI가 읽는 것이 아닌 감정이 들어올 수 있도록
    • 가상 아나운서
      • 실제로 무대에 올라 발표하지 않고 텍스트를 입력하는 것만으로 말하는 것과 같습니다.
    • 만화를 만드는 기술
      • 그림이 있는 만화..?
        ## (마이크로 프런트엔드를 구축하기 위한 거대한 서비스 분석)

발표자: NHN 두레이 이웅재

  • 모놀리식 SPA 반응 마이크로 프런트 엔드 소개
    • 두레이 리뉴얼 프로젝트
      • 2021년 10월 21일 리노베이션 공사 재개
        • 반응하다
        • 타자기
        • Vite(프로젝트 설정 프로세스를 간소화하는 빌드 도구)
        • Redux + Redux Saga(조건 관리)
    • 갱신에 문제가 있습니까?
      • 서비스는 점점 더 복잡해지고 있으며 FE 엔지니어가 모든 도메인 지식을 마스터하기는 어렵습니다.
        • 나는 또 다른 거대하고 새로운 레거시 시스템을 구축하고 싶지 않습니다.
        • 소스 코드가 커지고 개발/빌드가 점점 길어지고 있습니다.
        • 통합, 품질 보증 및 배포 프로세스는 어렵습니다.

그냥 서비스 독립적인 개발, 배포, 운영이 안되나요?

  • 변경 전 드라이브, 메일, 위키 등 서비스 개발 후 하나로 취합Test, Build, Deploy -> QA -> Production의 과정을 거쳤습니다.

  • 변경 후 드라이브, 메일, 위키 등 서비스 개발 후 각각 Test, Build, Deploy -> QA -> Production 프로세스를 통해 통합되었습니다.

  • SPA(단일 페이지 애플리케이션)
    • 연결된 단일 페이지 응용 프로그램
      • 각 서비스는 URL 시작 부분으로 구분되며 독립형 SPA로 구축됩니다.
        • 팀 내에서는 History API를 사용하여 클라이언트 측 라우팅을 사용합니다. (소프트 내비게이션)
        • 팀 간에는 하이퍼링크가 있는 하드 탐색이 사용됩니다.

단, Linked SPA 방식은 Dooray와 호환되지 않습니다.

  1. Dooray는 사용자가 서로 다른 서비스 사이를 자주 전환하는 데 사용하는 앱입니다.
  2. 장점은 서로 다른 서비스 간에 통합된 기능을 제공한다는 것입니다.
    • 메일을 작업으로 등록하는 기능
    • 드라이브 서비스를 사용하여 이메일에 공유 링크를 만들고 첨부하는 기능
    • 목표는 이러한 기능을 확장하는 것입니다.
  • 통합 스파
    • 애플리케이션 셸
      • 모든 하위 서비스의 상위 애플리케이션 역할
        • 라우팅에 따라 모든 수신 요청을 하위 서비스로 전달
        • 공통 레이아웃
        • 서비스 비즈니스 로직을 포함하지 않음
        • 인증 또는 앱 전체 설정
  • 페이지 내 서비스 간 통합
    • 드라이브 서비스의 추가 개발
      • Drive 서비스 패키지는 분리되어 있으며 다른 서비스에서 공유되는 코드 스니펫은 “Shared”라는 위치에 수집됩니다.
        • 인터페이스는 컴파일 타임에 TypeScript에 의해 검증되기 때문에 코드만으로 서로 사용법을 어렵지 않게 이해할 수 있었습니다.
        • 드라이브 서비스가 제공해야 하는 코드 조각의 한계에 대해 생각하기 시작했습니다.
        • 그리고 드라이브의 백엔드 API를 다루는 경우 드라이브 서비스가 작업하고 공유하기로 결정했습니다.
  • Webpack 5 모듈 네트워크
  • 페이지, 프래그먼트 및 상태의 분리
  • Micro Frontend는 특정 기술이 아닙니다.
    • 증가하는 복잡성을 따라잡을 수 있을 만큼 서비스가 커졌을 때 선택할 수 있는 몇 가지 대안 중 하나입니다.
    • 마이크로서비스의 발전도 중요하지만 운영 과정에서 발생하는 요인들을 지속적으로 고민하고 발전시켜 나가야 합니다.
    • 코드의 특정 섹션이 변경될 때 어디까지 테스트할 수 있는지 알고 싶다면 명확합니다.
    • 코드 중복은 불가피합니다. 이점에 집중해야 합니다.
      • 코드를 복사하는 것을 두려워하지 마십시오.
    • 모놀리식 SPA를 만드는 데 사용되는 팀 구조로 마이크로 프런트엔드를 사용하면 제대로 작동하지 않을 것이라고 생각합니다.
      • 대상 메일 프론트 엔지니어는 프론트 엔지니어가 아닌 메일 스케줄러 및 메일 BE 엔지니어와 많은 대화를 나눠야 합니다.
    • FE 엔지니어 간의 기술 교류를 위한 채널을 만들고 아키텍처를 발전시키기 위한 노력을 기울여야 합니다.

(구글 디자인 시스템의 진화)

진행자: Google 디자이너 이정영

디자인 시스템이 필요한 이유

UX 접근
개별 기능 설계의 완성도에 중점 -> 컴포넌트를 통한 빠른 테스트 환경 제공, 시간 확보를 통한 사용자 가치 검토

  • 능률
    • 개발과 설계가 동기화된 컴포넌트, 용어 등의 일관성 있는 사용으로 전체 제품 조직의 효율성과 생산성이 크게 향상됩니다.
  • 사용자 친근성
    • 일관된 UX는 제품 팀의 효율성을 높이는 것 이상으로 더 나은 사용자 경험을 만듭니다.
    • 예상대로 작동하는 구성 요소와 복잡한 상황에서도 즉시 이해할 수 있는 사용자 흐름.
  • 제품 아이덴티티
    • 제품의 전체적인 모양을 결정하는 색상, 타이포그래피 및 일러스트레이션은 개별 기능이 아닌 디자인 시스템에 의해 정의됩니다.
    • 잘 관리되고 공유되는 디자인 시스템은 제품 자체의 완성도를 나타냅니다.

진화하는 디자인 시스템

(0단계)

  • 맞춤형 디자인 지침(psd)
    • 로컬 파일로 존재
    • 디자이너들 사이에서도 동기화가 명확하지 않음
    • 일회성 프로젝트
    • 주제 불명

(1 단계)

  • 클라우드 테마 라이브러리
    • 클라우드에서 라이브러리 제공
    • 디자인 시스템 팀 구조
    • UI 업데이트
    • 일관성 개선
    • 레거시 개선 설계
    • 디자인재단 설립

(2단계) – 현재 단계

  • 코드 및 디자인 동기화(figma)
    • 부품 제조
    • UX/Eng 문서
    • UI 마이그레이션

(3단계)

  • 엔터프라이즈급 디자인 시스템
    • 각 프로젝트에 대한 디자인 시스템의 존재
    • 상속의 정의
    • 디자인 원칙 재정의
    • 디자인 토큰 소개
    • 크로스 플랫폼

디자인 시스템을 위한 신호

  • 결과적으로 팀이 커지고 불일치가 무너집니다.
  • UX 조직이 규모를 키우고 역할을 확장해야 할 때
    • 실제 사용자에게 임팩트 있는 경험을 생각하는 디자인 시스템을 구축하여 업무 효율성 증대 효과 활용
      • 연구용
        • A/B 테스트 및 실험 확장
        • 제품 사용자 가치의 정의
        • CUJ 모델 소개
  • 일반적인 제품 디자인 업데이트에 직면한 경우
  • 때로는 새로운 디자인 도구(예: Figma)의 출시와 일치하기도 합니다.

노하우와 팁

  • 손에 보이는 이정표
    • 디자인 시스템은 오랜 시간을 투자해야 하는 바닥 공사와 같습니다.
    • 지치지 않으려면 명확하게 보이는 이정표를 설정하는 것이 중요합니다.
    • 다크 모드의 사용과 컬러 디자인이 라인에 번들되었습니다.
  • 처음부터 제품에 미치는 영향을 바로 확인
    • UX, Eng 실무자의 업무 효율성을 즉각적으로 높여주는 프로젝트이지만, 리더의 큰 지지와 이해를 얻기 위해서는 목표를 설정하고 소통하는 것이 필요합니다.
  • 가시성을 생각하고 팀을 확장하십시오
    • 완벽을 위해 노력하는 대신 무엇이 도움이 되는지 팀에 알리면 더 많은 관심과 지원을 받을 수 있습니다.
  • 공개적으로 여러 채널에서 커뮤니케이션
  • 디자인 시스템은 지속적으로 실행되는 모델입니다.
    • 프로세스 자체가 50% 이상이라고 할 정도로 디자인 시스템이 워크플로를 잘 정의하는 것이 중요합니다.
    • 자연스럽게 처리할 수 있는 프로세스를 만드는 데 많은 시간을 할애하자

(괴상한 Dooray! 웹 앱 정리)

발표자: NHN 두레이 김부승

2014년 Dooray 개발 시작
메신저를 제외한 나머지 서비스는 SPA로 수행
사용한 프레임워크: Angular js

Angular는 지원이 2022년 1월에 종료될 것이라고 발표했습니다.
2019년에 vue로 전환 시도
주소록 및 결제 서비스만 현재 vue에서 작동합니다.

  • Vue로 정리된 코드 문제
    • 유형 추론이 제대로 작동하지 않음
    • 대형 부품
    • 시계 코드를 연결하여 코드를 추적하기 어렵습니다.
    • 코드 스타일 조각화
  • Angular와 Vue 사이에 일반적인 서비스 문제가 있습니다.
    • 새로운 개발로 양쪽에서 작업을 두 번 수행해야 합니다.
    • 같은 오류
    • 서로 다른 라이프 사이클을 가지고 있습니다

ZeroJace에서 다시 작업 시작 -> React
왜 반응합니까?
-> React는 시장점유율이 높기 때문에 참고할 만한 레퍼런스가 많다.

구성 요소 정리
구성 요소 참고 사항

  • 경우에 따라 구성 요소가 동일한 소품으로 동일한 결과를 렌더링하는 경우 React.memo를 래핑하여 결과를 호출하고 저장함으로써 성능 향상의 이점을 얻을 수 있습니다.
  • 즉, React는 구성 요소를 렌더링하지 않고 결국 렌더링된 결과를 재사용합니다.

안전한 상태

( 장점과 단점 )

  • 컨테이너
    • 상태를 쉽게 추가
    • 외부 상태 참조의 어려움
    • 계산 논리는 컨테이너에만 있습니다.
    • 비동기 로직을 ​​다루기 어려움
  • 컴퓨터에 저장
    • 바쁜 조건 추가
    • 상태를 쉽게 볼 수 있습니다.
    • 전산 논리 위치 무료
    • 다루기 쉬운 비동기 로직

(역할)

  • 중재자
    • 화면을 칠하다
    • 이벤트 발생 시 컨테이너에 알림
  • 컨테이너
    • 거래 상태를 발표자에게 연결
    • Presenter에서 작업할 때 스토어에 연결
  • 컴퓨터에 저장
    • 안전한 상태
    • 계산 논리의 실행
    • API 호출