Portfolio

I’m…

Name : Sunghyun Moon
Tel : 010 - 4900 - 5883
Email : shmoonlight@kaist.ac.kr
M.S. 2019 KAIST Electrical Engineering
Github : https://github.com/sunghyunMoon

Award & Paper

문성현, Tianwai Bo, 김병곤, 김훈, “EML을 이용하여 생성된 40 Gb/s OFDM 신호의 Kramers-Kronig 직접 검출”, in Proc. COOC, 2018, paper W1-A. (우수 논문상)
Sunghyun Moon, Tianwai Bo, Byung Gon Kim, Daeho Kim, and Hoon Kim, “Kramers-Kronig Direct Detection of 40-Gb/s OFDM Signal Generated by using EML” in Proc. OECC, 2018, paper 4B4-2.

Work Experience

Web Developer(2021.05 - current)
- 협업 및 공동 편집이 가능한 웹 기반 오피스 애플리케이션을 개발(Office365, GoogleDocs와 같은 웹 오피스)
  - 기존 파일 안의 문서 데이터를 DB화하여 데이터 활용성을 극대화하고, 실시간 동시 편집이 가능한 오피스 제품입니다.
- Frontend
  - 오피스 제품 성능 최적화, 워드 제품 페이지 레이아웃 최적화, 댓글 기능, 인쇄/썸네일 기능, z-index, PDF/HTML 문서 호환 기능을 설계 및 구현 후 유지 보수하고 있습니다.
  - 각 기능들에 대해 공동 편집이 되도록 개발합니다. 웹소켓을 통해 받은 JSON 메세지를 파싱해 자바스크립트 모델 객체를 생성, 업데이트, 삭제하여 특정 위치에 렌더링하는 레이어를 구현하고 유지 보수하고 있습니다.
  - Typescript의 강력한 타입시스템을 활용하여 타입 안정성을 보장하려 노력했습니다. React를 사용해 값을 기반으로 컴포넌트 UI를 구성했습니다. 그리고 Mobx를 통해 상태 관리를 하고, 이를 기반으로 컴포넌트 UI를 동적으로 업데이트합니다.
  - Jest를 이용해 단위 테스트를 하고, Cucumber와 Puppeteer를 통해 브라우저 환경을 구축해 E2E(End-to-End) UI 테스트를 수행하고 있습니다. 이를 CI 환경에서 자동화해 코드 변경 시 영향을 줄 수 있는 side-effect을 조기 발견해 안정성과 유지 보수성을 향상 시키려 노력합니다.
- Backend Dev
  - Java & Spring Boot 기반 백엔드 개발을 합니다.
  - 오피스 파일은 OOXML이라는 XML 스펙을 기반으로 구성되어 있고, 이 XML 파일들을 서버의 별도의 Layer에서 파싱해 JAVA 인스턴스를 생성하고, 이를 Mybatis와 Tibero 환경에서 DB 업데이트를 합니다.
  - 또한, PL/SQL 프로시저를 이용해 오피스 텍스트 검색 서비스를 구현해 유지 보수하고 있습니다.
  - Junit5를 사용해 검색 서비스를 테스트하고 검증합니다.
C++ Developer(2019.09-2021.4)
- C++ 11/14를 이용하여 Linux, Window 환경에서 워드 제품 기능 개발 및 유지 보수를 했습니다.
- ToOffice Word 제품 개발
- Static Analysis
- XML Digital Signature Architecture 설계 및 구현
  - docx 문서의 인증과 무결성을 위한 PKI(Public Key Infrastructure) 기반 디지털 서명 기능
- 탐색창 페이지 탭 refacotring 설계 및 구현
  - 1000 페이지 이상의 대용량 문서에서 탐색창 페이지 탭에 대해 Event-Driven Architectuire를 이용해 레이아웃

Skill

JavaScript, TypeScript, React.js, Vue.js, HTML/CSS/SCSS
Java, Sprint Boot, Orcale SQL, Tibero SQL, AWS EC2
Jest, Cucumber, Puppeteer, Junit4/5
Mobx를 통해 대부분의 상태 관리를 하지만, 특정 컴포넌트 트리에 대해 국소적으로 상태 관리가 필요한 경우, Context API를 활용해 props 전달을 줄여 코드 복잡도를 낮춘 경험이 있습니다.
React hooks를 능숙하게 사용하고, hook을 이용해 공통 비즈니스 로직을 적절히 모듈화해 사용할 수 있습니다.
UI를 개발할 때 시각적인 요소뿐 아니라 웹 접근성을 고려해 포괄적이고 더 나은 사용자 경험을 제공할 수 있도록 신경을 씁니다. 시맨틱 요소를 적절히 활용해 구조를 명확히 하고, ARIA 속성으로 추가 정보를 제공하며, Tab 키를 통한 키보드 접근 등도 세심하게 설계합니다.
CSSModules를 사용해 컴포넌트 기반 스타일 관리에 익숙합니다.
Git을 통한 CI/CD 환경에 익숙하고, 변경 사항을 추적하기 쉽도록 히스토리를 자세하게 기록합니다. Husky를 통해 Git Hooks를 관리하는 데 익숙합니다.

오피스 댓글 기능 공통 프레임워크화

개발 기간 : 2024.08. ~ 2024.09
기존 워드 모듈의 댓글 기능을 셀 및 포인트 모듈에서도 사용할 수 있도록 공통 프레임워크화 진행
성과 ** 코드 중복 최소화: 댓글이 삽입 가능한 모든 객체는(예: 그림, 도형, 슬라이드, 셀) commentList 프로퍼티와 관리 메서드가 필요하고, 그 과정에서 코드 중복을 방지하기 위해 TypeScript의 Mixin 패턴을 적용 ** 유연한 구조 설계: 각 객체에 댓글 기능을 손쉽게 추가할 수 있도록 Mixin을 통해 재사용 가능한 코드를 구성 ** 타입 안전성 및 유지보수성 향상: Mixin이 적용된 객체에 대해 새로운 타입과 타입가드를 정의해 타입 안정성을 보장하고 유지보수성 개선 ** 정리 : https://sunghyunmoon.github.io/typescript/2024/03/09/typescript-mixin_apply/

RG사 A-Book 썸네일 기능 제공 설계 및 구현

개발 기간 : 2024.03. ~ 2024.01
워드의 모든 페이지 썸네일을 제공하는 기능 요청이 와서 구현 시작
썸네일 이미지를 만들기 위해 HTML이 필요하고, 해당 HTML을 SVG로 변환
성과
- HTML을 SVG로 변환할 때에 HTMLElement을 SVGElement에 append하면서 브라우저 렌더링이 일어남
- 해당 페이지 컴포넌트에서 userLayoutEffect 훅을 이용해 브라우저 렌더링이 일어나기 전 시점의 페이지 HTML을 SVGElement에 append해 브라우저 렌더링이 한번만 일어나게해 성능을 60% 향상 시킴
리액트의 virtual DOM과 실제 DOM이 동기화되지 않지만 re-render가 필요 없는 상황이고, 일회성으로 썸네일 이미지를 만들면 되기 때문에 성능 최적화에 집중함

오피스 인쇄 기능 성능 향상을 위한 리팩토링

개발 기간 : 2024.06. ~ 2024.07
대용량 문서 인쇄 모드 진입시 10초 멈춤 현상 발생하는 문제
편집 모드는 viewport에 걸쳐진 페이지들만 partial하게 렌더해 성능 최적화를 하지만, 인쇄 모드는 모든 페이지를 PDF화 해야하기 때문에 full HTML을 일괄적을 렌더하기 때문
성과
- Hybrid HTML 렌더 방식 제안으로 즉각적으로 인쇄 모드에 진입할 수 있도록함
- 인쇄 모드시 partial HTML로 표현하되, JS단에서 동시성을 이용해 순차적으로 리액트 렌더링된 페이지 HTML을 DocumentFragment에 캐싱했다가, 인쇄시 DocumentFragment를 iframe으로 넘겨주는 방식으로 구현

오피스 로딩 성능 개선

개발 기간 : 2023.08.
문서를 처음 열 때 오래 걸린다는 고객사 VoC가 있어 성능 개선
성과
- 성능 67% 향상시킴
비동기 후속 처리 및 번들 최소화
- 오피스는 리액트 Suspense를 이용해 ‘fetch-then-render’ 방식으로 로딩하고 있음
- 하지만, fetch 이전에 font 초기화와 같은 오래 걸리는 비동기 작업들이 많아 fallback UI를 표시하며 첫 화면 렌더링이 오래 걸림
- 오래 걸리는 비동기 작업들을 fetch 이후로 옮기도록 가이드
- 특정 상황에서만 필요한 라이브러리들은 dynamic import를 통해 번들 사이즈를 줄임
- 라이브러리의 소수의 메서드만 사용하는 경우 라이브러리를 사용하지 않고 직접 구현 가이드

워드 레이아웃 성능 최적화 설계

개발 기간 : 2023.02. ~ 2023.07.
워드 레이아웃
- 워드 docx의 XML 스펙에는 페이지 개념이 없고, JS단에서 직접 레이아웃을해 페이지를 계산함
- 워드는 이전 paragraph의 위치와 높이가 정해져야 다음 paragraph을 레이아웃 할 수 있고, 레이아웃은 항상 위에서부터 아래로 진행됨
- 따라서 아래 그림과 같이 밑에 페이지와 paragraph이 많다면 메인스레드에서의 레이아웃이 완료될때까지 사용자 event block이 발생할 수 있음

성과
- 자바스크립트의 동시성을 지원하는 브라우저의 이벤트 루프와 테스크 큐를 이용한 레이아웃 최적화 아키텍처 설계
- viewport까지 한번에 레이아웃을하고 viewport 밑으로는 작은 단위로 잘게 나누어 레이아웃하는 방식으로 구현해 애플리케이션의 반응성을 극대화함

Blink Layout 분석을 통한 SuperWord Layout 성능 점검

개발 기간 : 2022.08. ~ 2022.10.
Blink Layout
- DOM 요소의 크기와 위치를 결정하는 fragment를 만드는 과정
- LayoutObject가 LayoutAlgorithm을 통해 결과물인 LayoutResult를 만들어 내는 과정

ConstraintSpace
- 부모로부터 받은 Layout 정보
- offset : 어디서부터 레이아웃 할지에 대한 정보
- available_space : 레이아웃 가능한 공간
- exclusion_space : 레이아웃 불가능한 공간
LayoutResult
- Fragment를 보관
  - 일반적으로 LayoutObject와 1대1 관계
  - Page나 Column의 경우 1대다 일 수 있음
- Fragmentation Context
  - Fragmentation Type으로 page, colum이 있고, 일반적인 경우는 none으로 설정됨
Blink Dirty Layout System
- LayoutObject는 layout을 다시 할지 결정하는 dirty_bit을 들고 있음
- 텍스트가 입력된 layoutObject에 대해서 dirty_bit이 true로 설정
- 부모 layoutObject마다 dirty_bit을 true로 설정
- LayoutView까지 dirty_bit을 true로 설정한 후, LayoutView에 대해 레이아웃 수행

Blink에서는 레이아웃 후 모든 레이아웃을 다시 수행하지 않도록 layoutObject는 layoutResult를 캐싱
layoutResult에는 대표적으로 fragment와 offset 정보가 있어서 경우에 따라서 캐싱해둔 layout_result를 재사용
Layout시 최상단 layoutObject는 항상 dirty_bit이 true기 때문에 layoutAlgorithm을 통해 fragment를 다시 만듬
Layout 과정 속에서 자식의 dirty_bit이 true이면 자식도 새롭게 fragment를 만들고, 반대로 dirty_bit이 clear한 경우는 캐싱 해둔 layoutResult를 통해서 재사용 여부를 결정
Fragment Caching
- 엔터를 치면 밀려나는 paragraph들의 레이아웃
  - 밀려나는 paragraph 들은 dirty_bit이 clear하기 때문에 캐싱해둔 layoutResult를 통해 fragment 재사용 여부 결정
  - 캐싱해둔 layoutResult에 저장된 available_space와 offset을 새로운 값들과 비교
    - 모두 같은 경우, 캐싱 해둔 layout_result 재사용
    - offset만 밀리는 경우, layoutResult의 offset 정보만 업데이트 시키고, fragment 재사용
이와 같이 일반적인 BlinkLayout System 분석을 토대로한 SuperWord Layout 성능을 분석함

Super Word 메모 Architecture

개발 기간 : 2021.11. ~
기존 기록을 하기 위한 주석 관점의 메모에서 의견을 주고 받기 위한 협업 관점의 새로운 Super Word Comment UX/UI 제안
레퍼런스 웹 오피스 제품인 office365, google docs의 메모 기능(simple editor)을 뛰어 넘어 OOXML 스펙 기반의 paragraph, 그림, 테이블 등이 삽입 가능한 메모 기능(complex editor) 구현

기존의 말풍선을 클릭하면서 열었다 닫을 수 있는 다이얼로그의 형태에서 페이지의 오른쪽에서 언제든 볼 수 있는 코멘트 박스의 형태로 UI를 변경
Submit 기능을 추가해 메모 내용을 작성하고 Submit을 눌러야 해당 메모가 DB에 저장되도록 변경

Comment DB
- 내부에 메모 단위로 comment element가 존재하고, 메모 내용이 paragraph element들이 자식으로 달리는 형태
- COMMENT_ELEMENT DB 테이블을 구성해 속성인 author, data, id를 관리
Comment Layout
- 본문의 레이아웃은 blink에서 처리하고, 코멘트 박스들에 대해서는 JS단에서 위치 업데이트
- 본문의 렌더링이 모두 끝난 후에 후처리 방식으로 JS 단에서 위치 업데이트

Super Word Graphic 개체 z-index Architecture

개발 기간 : 2021.09. ~ 2021. 11.
OOXML z-index
- 화면상에서 z 축 좌표를 의미
- OOXML 스펙상으로 z-index는 unique한 id & 양수만 가능

MS 워드에서의 z-index
- global하게 z-index 관리
- Default(=251659264)부터 시작해 새로운 도형 생성 마다 문서 전체의 최대 z-index + 1024

웹 표준 z-index
- CSS의 z-index로 설정
- 초깃값은 auto(=0)
- 음수와 양수 모두 설정 가능

Stacking Context
- z-index가 설정되면 stacking context가 생성됨
- Stacking context는 HTML element의 3차원으로 개념화
- Stacking context에 따라 element의 부모/자식 간 페인트 순서가 결정됨
- Element -> negative z-index children -> normal flow children -> z-index==0 children -> positive z-index children
- 부모인 paragraph의 z-index가 있으면, 자식인 shape2의 z-index가 음수더라도 절대로 부모 밑으로 paint 될 수 없다.(paragraph이 stacking context를 생성하기 때문)
- 부모인 paragraph의 z-index가 없으면, stacking context가 생성되지 않기 때문에, 자식의 z-index가 음수이면 부모 밑으로 paint 된다.
Super Word/Hangul z-index 설계
- 웹 표준 z-index를 CSS style에 설정해 구현
- 이전 ToOffice에서는 Paint단에서 layer를 제어했지만, SuperOffice에서는 웹 표준 z-index를 사용

탐색창 페이지 탭 Lazy Synchronization Architecture

개발 기간 : 2020.10. ~ 2020. 12.
탐색창 페이지 탭?
- 검색 기능을 제공하는 툴페인으로 페이지탭이라는 세부 기능이 존재
- 페이지탭 기능은 문서 전체 페이지를 미리보기 리스트 형태로 보여주며 본문의 셀렉션에 따라 현재 보고있는 페이지에도 강조표시가 됨
- 페이지탭의 페이지 이미지를 클릭하면 해당 페이지로 본문이 이동 됨
- 검색 기능도 제공하는데 검색한 단어가 있는 페이지만 모아서 보여주기도 함
문제 상황
- 예를 들어, 총 1000페이지 문서에서 탐색창은 1000페이지를 보고 있고, 사용자는 1페이지에서 enter를 칠 경우
탐색창이 닫힌 경우, 1페이지에서 enter를 쳐도 editing이 연속적으로 가능
탐색창이 열려 1000페이지를 보고 있고, 사용자는 1페이지에서 editing 할 경우
- 한번에 1000페이지까지 레이아웃 후 탐색창에 업데이트, 그 과정 동안 사용자 editing이 block되는 문제
레퍼런스 제품인 MS의 경우도 본문과 탐색창의 sync를 맞춘 후 editing이 가능하기 때문에 editing block 현상이 있었음
- Word는 첫 페이지에서 엔터를 치면 그 아래 paragrpah 들의 위치가 밀려나게 되고 페이지도 늘어날 수 있게 된다. 그래서 엔터 친 아래의 모든 paragraph들의 좌표를 정해주는 layout이라는 과정을 거쳐야 한다. layout은 이전 paragraph의 위치와 높이가 정해져 있어야 다음 paragraph을 layout할 수가 있기 때문에, layout은 항상 위에서부터 아래로 진행이 된다.
- 1000 페이지 정도의 문서를 한번에 layout하는 것은 소모가 큰 작업이고, 1000페이지를 layout한 결과를 바탕으로 페이지 탭을 rendering해주기 때문에, editin block 현상이 생김
본문과 탐색창의 sync보다는 사용자 editing이 우선이라고 판단함
- 사용자의 editing이 가능하면서 sync를 맞추는 방법이 없을까?
- 아이디어 : 본문과 탐색창을 lazy하게 sync를 맞추어 사용자 editing을 가능하게 하자
본문의 viewport 이후의 페이지에 대해서는 Event-Driven Architecture를 이용해 본문과 탐색창을 lazy하게 sync를 맞추어 사용자 editing이 가능하도록 해결함
Event-Driven?
- IT 영역에서 아주 오래된 키워드
- 어떤 하나의 큰 일을 잘게 쪼갠것들을 각각 task라고 지정한 다음 UI event를 계속 받아야 하는 event loop에 순서대로 넣어주는 것으로 생각하면 이해가 쉬울듯 하다. 이렇게 하면 task 사이 사이 사용자의 event가 들어올 수 있어, 사용자가 editing을 하면서도 페이지 Layout이 가능하게 된다.

XML Digital Signature Architecture 설계 및 구현

개발 기간 : 2020.02. ~ 2020. 07.
디지털 서명?
- 문서를 작성한 서명자가 내가 예상한 서명자 인지를 보장할 수 있음
- 디지털 서명된 문서는 전송 과정 중 어떠한 위변조도 없는 것을 보장할 수 있음

분석
- HTTPS 통신에 사용되는 SSL 인증서에 대한 이해 및 인증서 관리 분석
  - OS에 기본으로 내장된 웹 브라우저에서 CA의 공개키가 들어 있는 인증서들을 어떻게 관리하고, 내장된 CA의 인증서를 이용해 서버로 받은 인증서를 검증할 때 어떤 라이브러리들을 사용하는지에 대해 분석함
- PKI(Public Key InfraStrurcture) 기술 이해
  - 공개키를 인증하기 위한 공개키 인증서, 전자서명의 서명과 인증 원리, CA, 인증서 체인, X.509 포맷 등 PKI의 구조에 대한 연구
- XML 전자 서명 연구
  - docx 워드 파일은 다양한 xml 파일들로 packaging 되어 있는 형태이고, 전자서명을 하면 docx 안에 xmlsignatures라는 디렉토리에 sig.xml이라는 xml 파일이 생성됨
  - sig.xml 파일 안에 있는 모든 XML element와 attribute를 W3C에서 재정한 XML Signautre Syntax and Processing Version 1.1와 XML Advanced Electronic Signatures (XAdES) 표준 문서를 보며 연구
계층적 해싱 구조
- W3C에서 재정한 XML Signautre Syntax and Processing Version 1.1 문서를 참고해 XML 전자서명 연구를 시작하면서, MS 오피스의 XML 전자서명 스펙은 일반적인 XML 전자서명 스펙과 조금 다른 형식이라는 것을 알게됨
- 일반적인 XML 전자서명이 XML 문서 하나 혹은 메시지 하나를 암호화하는 것에 비해, MS 오피스 XML 전자서명은 다양한 xml 파일들로 구성된 docx 파일의 위변조를 검증해야 하기 때문에 계층적 해싱 구조를 가짐
- 계층적 해싱 구조는 모든 개별 데이터 각각을 해싱한 다음 해쉬값을 모아서 다시 해싱하는 방식을 의미함
- 계층적 해싱 구조를 가진 XML 전자서명을 연구하면서 단순히 하나의 메시지 혹은 데이터가 아닌, packaing 형태의 압축파일 혹은 블록 단위에 대해서 전자서명하고 위변조를 검증하는 방법을 배움