<div id="readability-page-1" class="page"><div><p>2021년이 되고도 제법 지난 시점이지만, 그래도 더 늦기 전에 작년의 개발 내용들을 회고해본다.</p>
<h3 id="trust-chain-services-프로젝트"><code>trust-chain-services</code> 프로젝트</h3>
<p>2020년 개발의 진정한 시작은 3월에 시작되었다. 나는 3월에 <code>trust-chain-services</code> 라는 백엔드 서버 프로젝트를 시작했다. 이전에 우리 서비스는 <code>trust-chain-service-platform</code> 라는 API 서버가 백엔드를 담당하고 있었다. <code>node.js</code> 기반의 이 서버는 2018년 12월에 첫 커밋이 되어, 2020년 3월 19일에 론칭된 <code>0.10.2</code> 버전을 마지막으로 개발이 종료되었다. 이 API 서버를 대체할 목적으로 시작한 <code>trust-chain-services</code> 프로젝트는 2020년 3월 13일, 첫 커밋이 되었다.</p>
<p><code>trust-chain-services</code> 프로젝트는 "토큰, 사용자, 커뮤니티 등의 각기 다른 서비스를 트래픽에 따라 유연하게 인스턴스 개수를 조절"할 수 있도록 하기 위해 시작되었다. 이 외에 <code>trust-chain-service-platform</code> 에서 임기응변으로 처리되었던 많은 기술부채들을 해결해야 했고, 코드베이스가 Stronly typed 되어있기를 바랬다. 또한 프론트엔드에 제공하는 서버 API 라이브러리의 지나친 복잡성을 해결해야했다. 이를 위해 <code>trust-chain-services</code> 는 다음과 같은 구조를 갖췄다.</p>
<ul>
<li>마이크로서비스 서버 구조. 처음에는 7개의 서버 인스턴스를 가졌지만, 2021년 현재, 5개의 서버 인스턴스로 축소. 하나의 코드베이스에서 모든 서버 인스턴스가 빌드되도록 공용화</li>
<li>REST API를 JSON RPC로 교체. 이로써 프론트엔드에 제공하는 서버 API 코드가 매우 간결해짐.</li>
<li>Strongly typed 언어로써 Go 언어를 선택.</li>
</ul>
<p>마이크로서비스 구조를 구성하는 5개의 서버를 모두 하나의 코드베이스에서 개발, 빌드하는 건 재밌는 도전이었다. 서버 아키텍처를 코드 관점에서 설계하고, 이를 바탕으로 공통부, 가변부를 추출한다. 그리고 공통부는 <code>lib</code> 패키지에, 가변부는 <code>apps</code> 패키지에 각각 개발한다. 그리고 지속적으로 개발하면서, 공통부로 해결이 안되거나, 공통부가 지나치게 복잡해지면, 일정부분 가변부로 이전했다.</p>
<p>마이크로서비스 아키텍처는 사실 우리에겐 아주 필요한 아키텍처는 아니었다. 우리 서비스는 여전히 작고, 트래픽이 적은 상태에서는 단일 서버가 성능면에서는 월등히 우월하다. 그럼에도 API Gateway, Fabric SDK Client Server와 서비스 서버들을 완전히 분리한 것은 좋은 결정이었다고 생각한다.</p>
<p><code>trust-chain-services</code>는 2021년 2월, 현재 버전 <code>1.5.x</code>로 안정화 단계에 있다. 새로운 기능을 추가하는 속도는 월등히 빨라졌고, 공통부는 지속적으로 시험, 운영되어 코드의 신뢰성이 상당히 높다. 그럼에도, 더 나은 수준의 로깅과 테스트, 모니터링 문제가 남아있고, 내부 호출을 gRPC로 업그레이드 하는 등의 작업들이 남아있다.</p>
<h4 id="2021년-백엔드의-과제는-개발-고도화">2021년 백엔드의 과제는 개발 고도화</h4>
<p><code>trust-chain-services</code> 는 로깅, 테스팅, 모니터링, 빌드 &amp; 배포 프로토콜에 문제가 있다. 정확히는 이들이 제대로 잡혀있지 않다. 겉으로는 모든 기능이 잘 동작하지만, 그 속은 튼튼하지 못하다. 올해는 이런 부분을 제대로 채워 진정한 프로덕션 서버로 나아가야 하지 않을까.</p>
<p>여기에 더해, Firebase같은 클라우드 플랫폼들의 가능성, 우리 서비스와의 결합 등을 지속적으로 공부하고 고민해야 하는 한해가 될 것 같다. 그리고 마지막으로 Docker Swarm 기반에서 Kubernates 기반으로 이전하는 것은 올해의 큰 목표 중 하나다.</p>
<h3 id="각종-앱-프로젝트">각종 앱 프로젝트</h3>
<p>2020년 상반기에는 난 프론트엔드에서는 관리자용 웹앱과 트래커(블록체인의 블록, 트랜잭션 모니터링 앱) 웹앱을 담당하고 있었다. 2020년 상반기, 이 두 웹앱의 버전 <code>1.x.x</code>을 <code>create-react-app</code> 과 <code>antd</code> 를 이용하여 개발했다. <code>antd</code>는 당시에 보기엔 관리자 앱을 개발하기에 상당히 나이스한 UI 프레임워크라고 생각해서 적극 사용했는데, 결론부터 말하자면, 2021년 현재 관리자용 웹앱 <code>2.0.0</code>은 <code>material-ui</code> 기반으로 재개발되고 있다.</p>
<p>2020년 하반기, 나는 소비자용 웹앱, 모바일앱 개발까지 맡게되었다. 혼자서 3종류의 웹앱과 모바일앱까지 맡게 되면서, 생존(?)을 위해 적극적인 코드 공용화가 필요하게 되었다. 그래서 나는 웹앱과 모바일앱에서 로직을 공유하기로 계획했다.</p>
<p>우리 회사 프론트엔드 앱을 살펴보니, 로직이라는 것은 결국 서버로부터 데이터를 읽어와서 UI에 보여줄 형태로 적당히 가공하는 것을 의미했다. 이 로직은 모바일앱과 웹앱 모두 동일했고, 이를 위해 웹앱과 모바일앱의 페이지들 구조를 최대한 유사하게 설계했다. 그리고 공용 로직들은 모두 React Hook으로 개발한 후, 이를 <code>itdot-lib</code> 이라는 이름의 라이브러리로 만들었다. 7월 28일에 이 라이브러리의 첫 커밋이 시작되었다.</p>
<p>이 라이브러리를 중심에 두고 <code>material-ui</code> 를 사용하여 웹앱이 개발되어 8월 7일 출시되었고, 12월 21일, React Native 기반의 모바일앱을 개발 완료했다. 최대한 UI 느낌을 통일하기 위해 모바일앱은 <code>React Native Paper</code>를 사용했다.</p>
<p>개발은 아주 재밌었다. 공용 라이브러리는 생각보다 잘 작동했고, 개발 시간은 월등히 줄어들었다. 백엔드가 JSON RPC로 변경된 덕분에 새로운 API가 추가되거나 기존 API가 변경되어도 프론트엔드에서 수정할 범위가 극히 좁았다. 왠만한 것들은 공용 라이브러리 수정 선에서 그치곤 했다. 이전에 개발된 관리자용 웹앱과 트래커 웹앱도 일부 핵심적인 부분은 이 라이브러리를 쓰도록 수정되었다. 현재는 이 라이브러리의 기능을 완전히 사용해서 버전 관리자용 웹앱 <code>2.0.0</code>을 개발 중이다.</p>
<h4 id="2021년의-프론트엔드-개발">2021년의 프론트엔드 개발</h4>
<p>원래 2021년 1월 경에 잠시 <code>create-react-app</code> 에서 <code>next.js</code> 로의 이전을 고려해보았었다. 몇가지 실험을 해보았지만, 일단 시간적인 문제도 있고하여 <code>create-react-app</code> 을 유지하는 방향으로 했다. 하지만 현재의 코드는 SPA 특성을 제대로 살리지도 못하고 있고, 그렇다고 PWA로 진화하지도 못하고 있다. SPA 인가, PWA 인가, 아니면 SSR인가. 그 방향을 제대로 결정하여 고도화하는 것이 올해의 임무가 되지 않을까 싶다. 2020년에는 웹앱으로써 기능하는데에만 집중했다면, 올해는 '좋은' 웹앱이 되도록 업그레이드 하는데 한 해를 보내려 한다.</p>
<p>여기에 더해, Flutter 또한 살펴보고 있다. 나는 물론 웹앱이 아주 큰 비중을 차지하고 있고, 이제야 React를 좀 이해하는 마당에 Flutter로 옮겨갈 생각은 전혀없다. 하지만 매우 유망한 기술임은 분명하다. Flutter Web이 프로덕션에서 활용될 정도로 고도화되는 순간이 오면 정말 고려해볼만한 훌륭한 솔루션이 될거라 본다. 일단 올해는 개인 프로젝트를 Flutter로 진행해보려한다.</p>
<h3 id="hyperledger-fabric-22버전-업그레이드">Hyperledger Fabric 2.2버전 업그레이드</h3>
<p>우리 회사의 블록체인을 담당하고 있는 Hyperledger Fabric의 버전을 기존 1.4에서 2.2로 업그레이드 했다. 2.2 버전은 새로운 LTS이며, 2.x 대에서 첫 LTS 버전이다. 이 버전은 아주 훌륭한 변경사항들을 갖고 있는데, 우선 Go 언어 체인코드 개발이 Go Modules 기반으로 완전히 변경되었다. 덕분에 <code>trust-chain-services</code> 에서 스마트컨트랙트를 호출하는 부분까지 모두 typed 할 수 있었다. 게다가 Install &amp; Instantiation &amp; Upgrade 에서 Install &amp; Approve &amp; Commit 이라는 보다 직관적이고 상식적인(?) 체인코드 라이프사이클을 갖게된 점도 좋다.</p>
<p>아쉬운 점은 관리자 관련 API들이 SDK에서 대거 삭제된 것인데, 수차례 커뮤니티에 문의해본 결과, 근시일내에 복귀할 가능성은 별로 없다. 사실 변경 자체는 올바른 방향이라고 보는데, 내가 설치, 운영, 배포 등에 쓰던 모든 API들이 삭제되어 한동안 2.2버전으로 Bash 스크립트를 짜느라 고생을 좀 했다. 지금은 모두 잘 동작한다. 그리고 이 변경 때문에 트래커 웹앱이 한동안 죽어있었는데, Hyperledger Explorer 프로젝트를 레퍼런스 삼아 복구할 수 있었다.</p>
<p>2.2로 업그레이드 하는 경험은 아주 좋았다. 좋은 정도를 넘어서 너무 부드럽게 마이그레이션이 이루어져 "여기에 모든 역량을 투입했나" 싶을 정도였다. 그저 도커 컨테이너를 한번 재시작 해주는 것만으로 모든 것이 끝났다. 정말 대단한 경험이었다.</p>
<h4 id="2021년-hyperledger-fabric">2021년 Hyperledger Fabric</h4>
<p>Hyperledger Fabric은 올해 초부터 우울한 소식(<a href="https://www.tokenpost.kr/article-52402">IBM 블록체인 사업부, 사실상 해체 수준</a>)을 접했다. 물론 IBM은 통상적인 재배치라고 했지만, 개발 자체에 힘이 좀 빠질 것은 분명하다. 우리 회사는 2018년부터 다양한 데이터를 블록체인에 저장해서 서비스를 구성하는 실험을 계속해왔다. 결과적으로 분산 사용자 인증(DID)과 토큰 시스템, 그리고 기록 검증 시스템으로 자리를 잡을 것 같다. 범위는 축소되겠지만, 서비스 내에서 좀 더 명확하게 블록체인의 데이터베이스로써의 역할을 수행할 것으로 본다. Hyperledger Fabric은 지금 상태로도 가장 견고한 프라이빗 블록체인 시스템이다. 2021년에도 우리 회사는 Hyperledger Fabric과 함께 갈 것이라고 본다.</p>
<h3 id="2020년은-버전-10의-해">2020년은 버전 1.0의 해</h3>
<p>2020년 개발은 나와 우리 회사의 서비스에 있어서 버전 1.0의 해였다. 2018년 - 2019년의 혼란과 경험을 바탕으로 '우리에게 필요한 것'이 뭔지 이제야 좀 잡혀서, 그걸 위해 개발한 한해였다. 많은 소프트웨어들이 소위 '프로덕션' 수준의 안정감을 갖추어갔다. 하지만, 아직 한참 멀었고, 여전히 '껍데기는 그럭저럭 유지되지만 속은 비어있는' 상태이다. 2021년은 바로 비어있는 속이라고 할 수 있는 로깅, 테스팅, 모니터링, 빌드 &amp; 배포 프로토콜 등을 제대로 채워넣어 진정한 프로덕션 수준 소프트웨어로 거듭나길 바란다. 2021년은 버전 2.0의 해가 되길.</p></div></div>

byron1st.log

안휘

2021년이 되고도 제법 지난 시점이지만, 그래도 더 늦기 전에 작년의 개발 내용들을 회고해본다.
trust-chain-services 프로젝트
2020년 개발의 진정한 시작은 3월에 시작되었다. 나는 3월에 trust-chain-services 라는 백엔드 서버 프로젝트를 시작했다. 이전에 우리 서비스는 trust-chain-service-platform 라는 API 서버가 백엔드를 담당하고 있었다. node.js 기반의 이 서버는 2018년 12월에 첫 커밋이 되어, 2020년 3월 19일에 론칭된 0.10.2 버전을 마지막으로 개발이 종료되었다. 이 API 서버를 대체할 목적으로 시작한 trust-chain-services 프로젝트는 2020년 3월 13일, 첫 커밋이 되었다.
trust-chain-services 프로젝트는 "토큰, 사용자, 커뮤니티 등의 각기 다른 서비스를 트래픽에 따라 유연하게 인스턴스 개수를 조절"할 수 있도록 하기 위해 시작되었다. 이 외에 trust-chain-service-platform 에서 임기응변으로 처리되었던 많은 기술부채들을 해결해야 했고, 코드베이스가 Stronly typed 되어있기를 바랬다. 또한 프론트엔드에 제공하는 서버 API 라이브러리의 지나친 복잡성을 해결해야했다. 이를 위해 trust-chain-services 는 다음과 같은 구조를 갖췄다.
마이크로서비스 서버 구조. 처음에는 7개의 서버 인스턴스를 가졌지만, 2021년 현재, 5개의 서버 인스턴스로 축소. 하나의 코드베이스에서 모든 서버 인스턴스가 빌드되도록 공용화
REST API를 JSON RPC로 교체. 이로써 프론트엔드에 제공하는 서버 API 코드가 매우 간결해짐.
Strongly typed 언어로써 Go 언어를 선택.
마이크로서비스 구조를 구성하는 5개의 서버를 모두 하나의 코드베이스에서 개발, 빌드하는 건 재밌는 도전이었다. 서버 아키텍처를 코드 관점에서 설계하고, 이를 바탕으로 공통부, 가변부를 추출한다. 그리고 공통부는 lib 패키지에, 가변부는 apps 패키지에 각각 개발한다. 그리고 지속적으로 개발하면서, 공통부로 해결이 안되거나, 공통부가 지나치게 복잡해지면, 일정부분 가변부로 이전했다.
마이크로서비스 아키텍처는 사실 우리에겐 아주 필요한 아키텍처는 아니었다. 우리 서비스는 여전히 작고, 트래픽이 적은 상태에서는 단일 서버가 성능면에서는 월등히 우월하다. 그럼에도 API Gateway, Fabric SDK Client Server와 서비스 서버들을 완전히 분리한 것은 좋은 결정이었다고 생각한다.
trust-chain-services는 2021년 2월, 현재 버전 1.5.x로 안정화 단계에 있다. 새로운 기능을 추가하는 속도는 월등히 빨라졌고, 공통부는 지속적으로 시험, 운영되어 코드의 신뢰성이 상당히 높다. 그럼에도, 더 나은 수준의 로깅과 테스트, 모니터링 문제가 남아있고, 내부 호출을 gRPC로 업그레이드 하는 등의 작업들이 남아있다.
2021년 백엔드의 과제는 개발 고도화
trust-chain-services 는 로깅, 테스팅, 모니터링, 빌드 & 배포 프로토콜에 문제가 있다. 정확히는 이들이 제대로 잡혀있지 않다. 겉으로는 모든 기능이 잘 동작하지만, 그 속은 튼튼하지 못하다. 올해는 이런 부분을 제대로 채워 진정한 프로덕션 서버로 나아가야 하지 않을까.
여기에 더해, Firebase같은 클라우드 플랫폼들의 가능성, 우리 서비스와의 결합 등을 지속적으로 공부하고 고민해야 하는 한해가 될 것 같다. 그리고 마지막으로 Docker Swarm 기반에서 Kubernates 기반으로 이전하는 것은 올해의 큰 목표 중 하나다.
각종 앱 프로젝트
2020년 상반기에는 난 프론트엔드에서는 관리자용 웹앱과 트래커(블록체인의 블록, 트랜잭션 모니터링 앱) 웹앱을 담당하고 있었다. 2020년 상반기, 이 두 웹앱의 버전 1.x.x을 create-react-app 과 antd 를 이용하여 개발했다. antd는 당시에 보기엔 관리자 앱을 개발하기에 상당히 나이스한 UI 프레임워크라고 생각해서 적극 사용했는데, 결론부터 말하자면, 2021년 현재 관리자용 웹앱 2.0.0은 material-ui 기반으로 재개발되고 있다.
2020년 하반기, 나는 소비자용 웹앱, 모바일앱 개발까지 맡게되었다. 혼자서 3종류의 웹앱과 모바일앱까지 맡게 되면서, 생존(?)을 위해 적극적인 코드 공용화가 필요하게 되었다. 그래서 나는 웹앱과 모바일앱에서 로직을 공유하기로 계획했다.
우리 회사 프론트엔드 앱을 살펴보니, 로직이라는 것은 결국 서버로부터 데이터를 읽어와서 UI에 보여줄 형태로 적당히 가공하는 것을 의미했다. 이 로직은 모바일앱과 웹앱 모두 동일했고, 이를 위해 웹앱과 모바일앱의 페이지들 구조를 최대한 유사하게 설계했다. 그리고 공용 로직들은 모두 React Hook으로 개발한 후, 이를 itdot-lib 이라는 이름의 라이브러리로 만들었다. 7월 28일에 이 라이브러리의 첫 커밋이 시작되었다.
이 라이브러리를 중심에 두고 material-ui 를 사용하여 웹앱이 개발되어 8월 7일 출시되었고, 12월 21일, React Native 기반의 모바일앱을 개발 완료했다. 최대한 UI 느낌을 통일하기 위해 모바일앱은 React Native Paper를 사용했다.
개발은 아주 재밌었다. 공용 라이브러리는 생각보다 잘 작동했고, 개발 시간은 월등히 줄어들었다. 백엔드가 JSON RPC로 변경된 덕분에 새로운 API가 추가되거나 기존 API가 변경되어도 프론트엔드에서 수정할 범위가 극히 좁았다. 왠만한 것들은 공용 라이브러리 수정 선에서 그치곤 했다. 이전에 개발된 관리자용 웹앱과 트래커 웹앱도 일부 핵심적인 부분은 이 라이브러리를 쓰도록 수정되었다. 현재는 이 라이브러리의 기능을 완전히 사용해서 버전 관리자용 웹앱 2.0.0을 개발 중이다.
2021년의 프론트엔드 개발
원래 2021년 1월 경에 잠시 create-react-app 에서 next.js 로의 이전을 고려해보았었다. 몇가지 실험을 해보았지만, 일단 시간적인 문제도 있고하여 create-react-app 을 유지하는 방향으로 했다. 하지만 현재의 코드는 SPA 특성을 제대로 살리지도 못하고 있고, 그렇다고 PWA로 진화하지도 못하고 있다. SPA 인가, PWA 인가, 아니면 SSR인가. 그 방향을 제대로 결정하여 고도화하는 것이 올해의 임무가 되지 않을까 싶다. 2020년에는 웹앱으로써 기능하는데에만 집중했다면, 올해는 '좋은' 웹앱이 되도록 업그레이드 하는데 한 해를 보내려 한다.
여기에 더해, Flutter 또한 살펴보고 있다. 나는 물론 웹앱이 아주 큰 비중을 차지하고 있고, 이제야 React를 좀 이해하는 마당에 Flutter로 옮겨갈 생각은 전혀없다. 하지만 매우 유망한 기술임은 분명하다. Flutter Web이 프로덕션에서 활용될 정도로 고도화되는 순간이 오면 정말 고려해볼만한 훌륭한 솔루션이 될거라 본다. 일단 올해는 개인 프로젝트를 Flutter로 진행해보려한다.
Hyperledger Fabric 2.2버전 업그레이드
우리 회사의 블록체인을 담당하고 있는 Hyperledger Fabric의 버전을 기존 1.4에서 2.2로 업그레이드 했다. 2.2 버전은 새로운 LTS이며, 2.x 대에서 첫 LTS 버전이다. 이 버전은 아주 훌륭한 변경사항들을 갖고 있는데, 우선 Go 언어 체인코드 개발이 Go Modules 기반으로 완전히 변경되었다. 덕분에 trust-chain-services 에서 스마트컨트랙트를 호출하는 부분까지 모두 typed 할 수 있었다. 게다가 Install & Instantiation & Upgrade 에서 Install & Approve & Commit 이라는 보다 직관적이고 상식적인(?) 체인코드 라이프사이클을 갖게된 점도 좋다.
아쉬운 점은 관리자 관련 API들이 SDK에서 대거 삭제된 것인데, 수차례 커뮤니티에 문의해본 결과, 근시일내에 복귀할 가능성은 별로 없다. 사실 변경 자체는 올바른 방향이라고 보는데, 내가 설치, 운영, 배포 등에 쓰던 모든 API들이 삭제되어 한동안 2.2버전으로 Bash 스크립트를 짜느라 고생을 좀 했다. 지금은 모두 잘 동작한다. 그리고 이 변경 때문에 트래커 웹앱이 한동안 죽어있었는데, Hyperledger Explorer 프로젝트를 레퍼런스 삼아 복구할 수 있었다.
2.2로 업그레이드 하는 경험은 아주 좋았다. 좋은 정도를 넘어서 너무 부드럽게 마이그레이션이 이루어져 "여기에 모든 역량을 투입했나" 싶을 정도였다. 그저 도커 컨테이너를 한번 재시작 해주는 것만으로 모든 것이 끝났다. 정말 대단한 경험이었다.
2021년 Hyperledger Fabric
Hyperledger Fabric은 올해 초부터 우울한 소식(IBM 블록체인 사업부, 사실상 해체 수준)을 접했다. 물론 IBM은 통상적인 재배치라고 했지만, 개발 자체에 힘이 좀 빠질 것은 분명하다. 우리 회사는 2018년부터 다양한 데이터를 블록체인에 저장해서 서비스를 구성하는 실험을 계속해왔다. 결과적으로 분산 사용자 인증(DID)과 토큰 시스템, 그리고 기록 검증 시스템으로 자리를 잡을 것 같다. 범위는 축소되겠지만, 서비스 내에서 좀 더 명확하게 블록체인의 데이터베이스로써의 역할을 수행할 것으로 본다. Hyperledger Fabric은 지금 상태로도 가장 견고한 프라이빗 블록체인 시스템이다. 2021년에도 우리 회사는 Hyperledger Fabric과 함께 갈 것이라고 본다.
2020년은 버전 1.0의 해
2020년 개발은 나와 우리 회사의 서비스에 있어서 버전 1.0의 해였다. 2018년 - 2019년의 혼란과 경험을 바탕으로 '우리에게 필요한 것'이 뭔지 이제야 좀 잡혀서, 그걸 위해 개발한 한해였다. 많은 소프트웨어들이 소위 '프로덕션' 수준의 안정감을 갖추어갔다. 하지만, 아직 한참 멀었고, 여전히 '껍데기는 그럭저럭 유지되지만 속은 비어있는' 상태이다. 2021년은 바로 비어있는 속이라고 할 수 있는 로깅, 테스팅, 모니터링, 빌드 & 배포 프로토콜 등을 제대로 채워넣어 진정한 프로덕션 수준 소프트웨어로 거듭나길 바란다. 2021년은 버전 2.0의 해가 되길.

2020년 개발 회고

댓글