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를 사용해 검색 서비스를 테스트하고 검증합니다.
- 협업 및 공동 편집이 가능한 웹 기반 오피스 애플리케이션을 개발(Office365, GoogleDocs와 같은 웹 오피스)
- 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으로 설정됨
- Fragment를 보관
- 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 재사용
- 엔터를 치면 밀려나는 paragraph들의 레이아웃
- 이와 같이 일반적인 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를 칠 경우
- 예를 들어, 총 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) 표준 문서를 보며 연구
- HTTPS 통신에 사용되는 SSL 인증서에 대한 이해 및 인증서 관리 분석
- 계층적 해싱 구조
- W3C에서 재정한 XML Signautre Syntax and Processing Version 1.1 문서를 참고해 XML 전자서명 연구를 시작하면서, MS 오피스의 XML 전자서명 스펙은 일반적인 XML 전자서명 스펙과 조금 다른 형식이라는 것을 알게됨
- 일반적인 XML 전자서명이 XML 문서 하나 혹은 메시지 하나를 암호화하는 것에 비해, MS 오피스 XML 전자서명은 다양한 xml 파일들로 구성된 docx 파일의 위변조를 검증해야 하기 때문에 계층적 해싱 구조를 가짐
- 계층적 해싱 구조는 모든 개별 데이터 각각을 해싱한 다음 해쉬값을 모아서 다시 해싱하는 방식을 의미함
- 계층적 해싱 구조를 가진 XML 전자서명을 연구하면서 단순히 하나의 메시지 혹은 데이터가 아닌, packaing 형태의 압축파일 혹은 블록 단위에 대해서 전자서명하고 위변조를 검증하는 방법을 배움