다음에는 꼭 잘 대답하고 넘어가자 🔥

1. sql vs nosql의 차이점과 선택기준

1. 스키마의 유무
   sql과 nosql의 가장 큰 차이점은 스키마의 유무라고 생각합니다.

• sql은 사전에 정의된 스키마에 맞는 데이터만 삽입할 수 있으므로 사전에 정의되지 않은 데이터를 삽입하기 위해서는 스키마의 재정의가 필요합니다. 데이터는 정의된 테이블간 관계에 따라 중복없이 저장되며 JOIN을 통해 통합적으로 조회할 수 있습니다. 또한 SQL이라는 표준화된 쿼리 언어를 가지고 있으며 인덱스에 기반한 쿼리를 수행할 수 있습니다.

• 반면 몽고db와 같은 nosql은 스키마의 제약없이 자유로운 형식으로 데이터를 삽입가능합니다. JSON과 같이 document에 해당되는 모든 데이터를 동일한 컬렉션에 삽입합니다.

2. 확장성 측면
   확장성 측면에서도 큰 차이가 있습니다. 일반적으로 SQL는 인스턴스 크기를 키우는 수직적 확장에 용이하고, nosql은 새로운 서버를 추가하는 수평적 확장에 유리하다는 특성이 있습니다. nosql의 경우 서버를 늘리면 읽기와 쓰기 성능이 모두 늘어나는 특성이 있습니다. SQL의 경우 read-replica를 활용해 수평적 확장이 가능하지만 쓰기 트래픽에 대한 확장은 제한적이라는 단점이 있습니다.

3. 선택기준
   SQL
   쇼핑몰과 같이 데이터가 정형화되어 있고 테이블간 조인이 자주 일어나는 경우에는 SQL을 선택해야 합니다. 또한 변경될 여지가 별로 없고, 엄격히 정의된 스키마가 사용자와 데이터 모두에게 유리한 경우에 SQL을 선택해야 한다.
   NoSQL
   소셜미디어와 같이 유저가 폭발적으로 증가할 수 있고, 간단한 구조의 데이터가 많이 삽입되는 경우엔 NoSQL이 적합하다고 생각합니다. 읽기를 자주 수행하지만 데이터 변경이 많이 없는 경우에도 NoSQL이 유용하다고 생각합니다.

4. SQL을 선택한 이유

   cds 프로젝트의 데이터는 스마트 컨트랙트에 의존적이므로 데이터가 정형화되어 있고, Transaction, User, Swap이라는 테이블간 조인이 자주 일어나는 쿼리를 자주 사용합니다. 또한 금융 서비스의 특성상 데이터무결성이 매우 중요하므로 안전성을 위해 SQL을 선택했습니다. 또한 이더리움 네트워크의 비교적 느린 블록생성 시간으로 인해 쓰기 트래픽의 상한이 고정되어 있다는 점도 SQL을 선택한 이유 중 하나입니다.

   프로젝트 진행중 컨트랙트의 잦은 변경으로 매번 스키마를 수정해야되는 부담이 있었지만 typescript와 typeorm의 기능을 활용하여 효과적으로 대응했습니다.

2. 컨트랙트 배포 자동화한 이유

1. 일반적으로 스마트컨트랙트는 기본 틀이 정의되어 있으므로 배포자동화가 필요 없을 수도 있다. 하지만 cds 프로젝트는 기존에 존재한 금융상품을 구현하는 프로젝트이지만 관련 레퍼런스를 찾을 수 없었고 따라서 레퍼런스 없이 컨트랙트를 직접 만들어가면서 개발해 나가야 했다. 당연히 시행착오도 많았고 컨트랙트를 자주 배포하게 되었다.

2. 초기엔 배포자동화 없이 컨트랙트를 수동으로 배포하고 CA를 수동으로 공유했었다. 이러한 과정에서 드는 커뮤니케이션 비용이 컸으므로 자동화된 배포와 자동화된 테스트를 도입했다. 가장 중요한 컨트랙트가 변경될 때마다 팀원들에게 컨트랙트 변경내역이 자동으로 공유되었고, 초기 설정을 위한 토큰발행, 계약 생성, 수락 등의 트랜잭션도 자동으로 배포된 상태로 컨트랙트가 배포되도록 설정하였다. 이를 통해 효과적으로 커뮤니케이션을 하면서 각자 맡은 부분을 진행했기에 개발의 효율성이 향상되었다고 생각한다.

3. api 서버 테스트 작성

사실 이번 프로젝트에서 api 테스트는 작성하지 못했다. 대신 컨트랙트는 truffle suite로 작성했다.컨트랙트가 가장 중요하다고 생각했기 때문이다.(면접관 표정이 어두워졌음....)

4. geth 노드는 어떻게 구현했는지 왜 적용했는지

처음엔 가나슈로 구성했다가 멘토의 멘토링을 받고 geth노드로 변경했다. 프로젝트의 큰 목적중 하나인 학습을 위해서 적합하다고 생각했기 때문이다. 네트워크에서 사용할 이더를 마음대로 설정할 수 있다는 점도 고얼리 네트워크 대신 프라이빗 블록체인 네트워크를 선택한 또 다른 이유다. 구현은 geth 도커 이미지를 받아서 소파밑의 노트북에서 노드 4개를 연결시켜서 구동했다. 1개 노드는 나머지 3개 노드를 연결하는 부트노드 역할을 수행하고 나머지 노드는 경쟁하면서 블록을 생성하는 역할을 수행했다. geth 공식문서를 참고하여 블록을 연결하고 http, ws rpc endpoint를 외부에 공개해서 활용했다. geth와 연동되는 모니터링 툴도 손쉽게 부착할 수 있어서 개발 경험과 블록체인에 대한 지식이 향상되었다고 생각한다.