프로젝트

Resume 기반

Core Skills

• Q. 이력서를 보아하니 Core Skills에 Full stack web development, DevOps engineering, ML engineering 이라고 써놓으셨네요?
• A. 넵, 제가 회사에 있으면서 진행했던 프로젝트들이나 업무들이 관련된 업무들이어서 그렇게 작성했습니다. 예를 들어, 풀스택 개발 같은 경우에는 GUI 와 CLI 를 포함한 프론트엔드를 개발하고, REST API 기반의 백엔드를 개발했습니다. 그리고 팀내에서 사용하는 기본적인 github 와 jenkins 를 셋업하고 정책을 정하여 개발 및 배포 자동화를 셋업했습니다. 마지막으로 데이터를 수집하고, 저장하고, 이를 머신러닝을 활용하여 솔루션을 제안하는 프로젝트들을 진행했습니다.

Language

• Q. 주로 사용하는 언어는 무엇인가요?
• A. 백엔드를 개발할 때는 Python을 사용하고, 프론트 엔드를 개발할 때는 Vue.js 와 Electron 을 사용했습니다.

Internship

• Q. 미국 인턴에서 software trading platform 을 개발했다고 작성하셨는데, 이것은 무슨 의미인가요?
• A. 미국에 있는 스타트업 인큐베이터에서 2개월동안 지냈었는데, 그 기간동안에 다양한 사람들을 만나 얘기할 수 있는 기회가 있었습니다. 거기서 짧은 해커톤을 진행했었는데, kaggle 과 같이 소프트웨어를 모듈 단위로 사고 파는 거래 플랫폼을 제안하고 간단하게 개발했습니다.

Toy Projects

• Q. Cryptocurrency monitoring website 에서 blockchain transaction data 도 수집했다고 하는데, 어떤 것을 수집한 것인가요?
• A. 크립토 관련된 가격을 빗썸 API 를 통해서 받아오고, 각 프로젝트의 github repositiory 의 commit 기록을 확인하고, 고래의 움직임을 포착할 수 있는 API 를 활용하여 일정시간동안에 고래의 움직임이 in 이 많은지 out 이 많은지 파악할 수 있는 차트를 개발했습니다. 이건 올해 초에 개발했던 간단한 토이 프로젝트였습니다.

Presentations

• Q. web3 korea 에서 발표한 내용은 어떤 것이었나요?
• A. 블록체인과 해킹 사건에 대한 발표였는데요, 2가지 사건을 다뤘습니다. 첫번쨰는 엑시인피니티의 로닌 네트워크 사건이고, 다른 하나는 인버스 파이낸스 사건이었습니다. 로닌 네트워크 사건은 중요한 자산을 관리하는 사이드체인의 노드의 키에 대한 보안이 허술했다는 점이 문제였습니다. 그리고 인버스 파이낸스의 경우 높은 담보 인정 비율과 oracle 의 취약점때문에 발생한 문제였습니다. 그리고 이 과정에서 oracle 을 속이기 위해 해커는 Disperse 를 이용하여 200여개의 계좌에 가스비를 입금하였고, 200여개의 계좌에서 스팸성 트랜잭션을 날림으로써 oracle 을 속일 수 있었습니다. 이 문제는 chainlink 의 oracle 과 같은 오라클을 사용하는 것이 안전한게 핵심인데 아쉽게도 체인링크의 오라클은 INV 토큰의 가격을 지원하지 않았기 때문에 다른 대안이 없었습니다. 다만 Keep3r 이라는 오라클이 문제가 있다고 알려진 TWAP 알고리즘을 사용하는 것이 아니라 좀 더 정밀한 알고리즘을 사용했으면 하는 아쉬움은 있습니다.

프로젝트 기반

Exynos Test Clustering

• Q. Exynos Test Clustering 에 프로젝트에 대해서 설명해주세요.
• A. 네, 그 프로젝트는 수만개의 테스트 중에서 어떤 테스트 순서로 수행해야지 다양한 버그들을 가장 빠른 시간 안에 찾을 수 있을까에 대한 문제에서 시작한 프로젝트입니다. 기존에는 그런 기준없이 엔지니어의 도메인 지식에 의존하여 수행되었다면, 제가 진행한 프로젝트에서는 로그 데이터를 기반으로 테스트들을 클러스터링하고, 각 클러스터 안에서 가장 거리가 먼 데이터 포인트를 샘플링하여 테스트를 수행하는 방법을 제안했습니다.
• 저는 이 프로젝트에서 클러스터링을 하고, 테스트를 샘플링하는 알고리즘을 제안하였고, 데이터를 추출하고 클러스터링하는 과정을 분산화된 시스템 기반의 파이프라인을 구축하였습니다. 다양한 로그에서 필요한 데이터를 추출하는 과정을 Spark를 통해서 분산처리할 수 있었고, K-means Clustering 을 분산처리함으로써 데이터 처리 시간을 줄일 수 있었습니다.
• Q. 왜 K-means clustering 을 선택했는지 알 수 있을까요?
• A. 네, 사실 다른 클러스터링 알고리즘인 DB Scan 과 xxxx 를 비교해서 성능을 테스트 해보았습니다. 하지만, K-means Clustering 이 가장 정확도도 높았고, 데이터를 분산처리하여 가장 적은 데이터 처리 시간을 가질 수 있었기 때문에 선택하였습니다.
• K means algorithm: 여러 번의 수행을 통해서 데이터 포인트들을 클러스터링하는 비지도학습 방식 중 하나. 작동 원리는, 초기에 임의의 k 개의 데이터 포인트 (centroid)를 잡는다. 그리고 모든 점에 대해서 어느 centroid 에 더 가까운지 거리를 계산하고 가장 가까운 centroid의 클러스터에 포함시킨다. 모든 데이터에 대해서 선택했으면, 다시 클러스터에서 centroid 를 선택하고, centroid 에서 가까운 데이터 포인트를 선택하여 클러스터를 생성. 이 과정을 계속 반복하는데, 언제까지 반복할지 결정하기 위해서는 실루엣 스코어와 elbow method 라는 두 가지 클러스터링 평가 지표를 사용한다. 이 평가 지표에 기반한 k 값을 선택해야 하는데, k mean clustering 은 NP-hard 문제로 정의된다. 즉, 최적화된 결과를 찾기는 어렵고, local minimum 만 찾을 수 있다는 의미이다.

출처: https://towardsdatascience.com/silhouette-or-elbow-that-is-the-question-a1dda4fb974

1. 실루엣 스코어: K-means clustering 에서 k 가 잘 골라졌는지 평가하는 방법. 원리는, 하나의 클러스터에 모여있는 데이터 포인트들이 다른 클러스터와 얼마나 거리가 있는지(mean nearest-cluster distance), 그리고 한 클러스터 내에서 거리가 가까운지(mean intra-cluster distance)를 계산한다. 실루엣 스코어가 높을수록 클러스터링이 잘 되었다는 의미이다. 실루엣 스코어는 -1에서 1 사이의 값을 가지고, 1에 가까우면 클러스터가 다른 클러스터와 잘 구분이 되고, 클라스터 안에는 잘 밀집되어 있음을 의미하고, -1 에 가까우면 클러스터링이 잘 안된다는 것을 의미한다.
   a. 원리: 실루엣 상관계수를 활용한다
2. 관성 스코어 (inertia score): 관성 스코어는 클러스터 내의 편차를 확인한다.
   a. 원리: elbow method를 사용한다. Elbow method 는 가장 급격한 경사가 발생한 지점을 k 값으로 잡을 수 있기 때문에 다소 휴리스틱한 측면이 있다.

실루엣 스코어와 관성 스코어를 확인하고 그 사이의 적절한 k 값을 선택해야 한다. 즉, 어느정도 클러스터 내부와 외부의 밀집 정도를 만족시키면서 클러스터 내부의 편차는 줄이는 방식을 선택해야 한다.

• Q. 이 프로젝트에서 분산 시스템을 사용한 부분은?
• A.
  1. Spark: 로그 데이터들을 분산처리하여 핵심 성분 추출의 속도를 높일 수 있었음
  2. Parallel pandas : CPU 의 코어를 최대한 활용하여 DataFrame을 병렬처리하도록 설정함 원래 pandas 는 CPU 1 core 만 사용함.
• Q. 데이터 분석 파이프 라인은 어떻게 디자인을 했나요?
  1. 먼저 테스트가 종료된 로그 데이터를 수집합니다. 수집하는 데이터는 로그 파일에서의 테스트 이름, component 들을 추출합니다. 그리고 추출한 component 들에서 불필요한 문자열들은 제거를 했습니다. 이 과정은 pandas의 parallel_apply 를 적용하여 core의 최대치를 사용하여 속도를 높였는데요, 즉, 수 만개의 로그 파일들의 전처리는 병렬적으로 처리해도 문제가 없기 때문에 parallel pandas 를 사용했습니다. 이 로그 파일이 유효한 것인지 확인하기 위해서도 parallel apply를 적용했습니다. 즉, 웬만한 로그 파일 전처리와 component 추출은 pandas parallel 을 적용하였고, 여기에 한 걸음 더 나아가서 여러 서버에서 처리할 수 있도록 spark 적용하여 분산처리와 멀티 프로세싱을 최대한 활용했습니다
  2. 추출한 component 들에 기반하여 모두 TF-IDF 벡터를 추출하였습니다. 그리고, 추출한 TF-IDF 값에 대해서 PCA 를 수행했습니다. 그 이유는 기존에 존재하는 수천개의 component들을 고려하여 클러스터링을 하는 것보다 차원이 축소된 핵심 성분으로 클러스터링을 하는 것이 훨씬 빠르고 정확한 클러스터링을 할 것 이라고 기대했습니다.
  3. 클러스터링은 K-means clustering, DB-SCAN, OPTICS 이렇게 3가지의 비지도학습을 선택했는데, 그 중 K-means clustering 의 성능이 가장 좋았을 뿐만 아니라 앞으로 map-reduce 를 활용한 분산 시스템의 활용 여지가 있기 때문에 선택했습니다.
  4. K-means clustering 에서 핵심인 K 값은 여러 번의 약 30까지의 클러스터링을 통해서 실루엣 스코어와 관성 스코어를 비교하여 적절한 k 값을 찾았습니다.
  5. 마지막으로 이렇게 K 개의 클러스터에서 centroid 랑 가장 멀리 떨어져있는 데이터 포인트를 선택해서 이 테스트 케이스를 먼저 수행을 시키도록 했습니다. 이러한 방식으로 다른 알고리즘들에 비해서 더 빠른 시간 안에 더 많은 종류의 버그를 찾을 수 있었습니다.
  6. 이러한 내용을 논문 레벨에서 적용을 하여 그 가능성을 보았고, 현재는 이러한 방법을 자동적으로 적용하기 위한 준비 단계에 있습니다.

Exynos Design Verification Automation Platform

• Q. 프로젝트에 대해서 설명해주세요.
• A. 이 프로젝트는 반도체 설계 검증을 하기 위한 플랫폼 개발입니다. 제가 여기서 한 역할은 CLI 와 GUI를 포함한 frontend 를 개발했고, 데이터베이스를 효율적으로 활용하기 위한 백엔드 아키텍처를 구축했습니다. 초기 이 서비스의 구조는 클라이언트와 데이터베이스로만 이뤄져있는 구조였습니다. 하지만, 이런 구조는 사용자들이 증가함에 따라서 비효율적인 구조임을 알 수 있었습니다. 예를 들어, 비슷한 기능인데, 다른 어플리케이션에서도 동일한 쿼리를 작성하여 데이터를 조회하는 중복 개발의 문제점이 있었고, 최근에 조회한 데이터를 다시 조회할 때 동일하게 데이터베이스로 쿼리를 수행하는 문제점이 있습니다.
• 이러한 문제점을 해결하기 위해서 REST API 기반의 백엔드 아키텍처를 제안했습니다. 제안한 백엔드 아키텍처는 기능에 따라서 REST API 를 제공하고, 클라이언트 측에서는 이 REST API 를 정해진 규칙에 따라서 호출함으로써 어떤 언어로 개발되던지, CLI 든 GUI 든지 동일한 인터페이스로 데이터를 조회할 수 있도록 제공했습니다.
• 뿐만 아니라, 웹서버인 nginx를 reverse proxy 로 사용함으로써 load balancing 의 역할과 caching 의 역할을 맡도록 하였습니다. 그리고 중간에 gunicorn 으로 worker 를 생성하고 gevent 설정을 통해서 하나의 connection 만 처리하는 것이 아니라 여러 개의 connection 을 비동기방식으로 처리하도록 설정했습니다.
• 이러한 방식을 통해서 일 평균 1만에서 2만건의 트래픽을 처리할 수 있었습니다. 또한, 서버를 2개로 분리하여 데이터를 저장하는 처리를 많이 하는 서버를 별도로 두고, 다른 하나는 서비스가 원활히 되어야 하는 서버를 두어서 운영했습니다.
• 추가로 말씀드리자면, 특정 타입의 데이터를 저장하는 기능을 하는 서버 어플리케이션에 대해서는 Django 에서 ORM 을 통해 2가지 종류의 데이터베이스에 데이터를 저장했습니다. 왜 2개에다 저장했냐면, RDB 의 형태로 데이터를 봐야하는 니즈도 있고, 전체 계층구조를 가진 상태의 데이터를 보고싶어하는 경우도 있었습니다. 일반적인 경우에는 전체 계층구조의 데이터를 보고 싶어하기 때문에 이를 효율적으로 저장할 수 있는 mongodb를 사용했습니다. 만약에 이 데이터를 RDB에 저장을 하려면 테이블을 총 5개에 저장해야되는데, 이들을 join 해서 가져오는 것은 시간이 오래걸리는 것을 확인했습니다. 따라서 monogodb 로 훨씬 깔끔하게 관리할 수 있었습니다. 두 종류의 데이터에 데이터를 저장하는 것은 코드상으로 깔끔하지 못한데, 이를 해결하기 위해서 Django 에서 제공하는 ORM 을 사용하여 동일한 인터페이스로 데이터를 저장할 수 있었습니다.

Emulation Resource Management with Reinforcement Learning

• Q. 이 프로젝트에 대해서 설명해 주세요
• A. 이 프로젝트는 약 1000명 규모의 전체 사업부 인원이 사용하는 에뮬레이션 큐잉 시스템의 리소스 관리를 위한 솔루션을 개발했습니다. 기존에 에뮬레이션 큐잉 시스템은 리소스의 원활한 활용을 위해서 big 과 small 이라고 정의할 수 있는 타입을 지정하고, job 을 지정된 에뮬레이터 팜에 할당을 했는데요, 이 방법은 big 에 job 들이 몰렸을 때, small 타입의 job 이 몰렸을 때 dynamic 하게 대응할 수 없는 문제점이 있었습니다. 사람이 문제가 발생하면 눈으로 확인하고 리소스 설정값을 변경하곤 했는데, 시스템에 의해서 자동적으로 리소스를 관리할 수 있도록 개발했습니다.
• 일단 이 문제를 해결하기 위해서 큐잉 시스템의 데이터를 수집하는 것이 중요했는데요, job 이 적재되어있는 데이터베이스를 참조하여 5분 주기로 현재 에뮬레이션의 상태를 파악했습니다. 이 때 수집한 정보는, 현재 대기중인 job 의 개수, 각 타입별 job 의 누적된 pending time, 최대 pending job의 pending time 그리고 각 type 별 평균 pending time 을 계산했습니다. 그리고 주어진 데이터에 기반해서 3가지 요소를 고려한 알고리즘을 개발했습니다. 즉, big 타입의 job 이 많이 기다리고 있다라고 판단이 되면, big 에 더 많은 리소스를 할당하고, small 타입의 job 이 많이 기다리고 있다고 판단이 되면 small 에 더 많은 리소스를 할당하도록 했습니다. 그리고 이 작업은 매 5분마다 판단하도록 배치 프로그램을 작성했습니다.
• 그 결과 , 기존 대비해서 전체 pending time 은 70% 감소했고, 에뮬레이터 리소스의 utilization 도 20% 증가하는 등 더 적은 job 이 대기를 하고, 더 많은 job 들이 리소스를 사용할 수 있었습니다. 이러한 내용을 바탕으로 사업부에서 우수 논문상을 받을 수 있었습니다.
• Q. Total pending time score 는 100점 만점으로 책정이 된 것인가요? 점수 계산은 어떤 기준에 의해서 된 것인가요?
• A. 100 에서 normalized pending time sum 을 계산했습니다. 정규화된 pending time sum 은 100보다 작은 값을 갖도록 설정했구요, 따라서 pending time sum 이 크면 클수록 점수는 낮아지게 됩니다. 100 점은 pending time 이 아예 없었다는 의미가 되고, 0점에 가까울수록 pending time 이 매우 컸다는 것을 알 수 있습니다.
• Q. 강화학습에서 DQN 을 사용한 이유는 무엇일까요?
• A. DQN 전에 있는 Q learning 을 업그레이드한 것이 DQN 인데요, 여기서 replay memory 를 사용한 방식과 target network 를 사용한 방식으로 인해서 강화학습의 급진적인 발전을 이뤄낼 수 있었습니다. 대표적인 예제가 아타리였는데요, replay memory 는 학습에 사용되는 데이터를 일정 크기만큼 저장해서 랜덤 셔플하여 데이터를 학습시켜 순차적으로 데이터를 학습하는 것의 문제를 해결했구요, target network 는 학습 중에 모델을 고정시켜서 안정적으로 학습할 수 있는 역할을 했다고 합니다

DevOps / MLOps

• Q. 이 프로젝트에 대해서 설명해주세요
• A. 이 프로젝트는 메인 프로젝트보다는 제가 개발환경을 조금 더 편리하게 만들고, 다른 팀원들도 편리하게 개발할 수 있는 환경을 셋업한 것이었습니다. DevOps 환경으로는 github 와 jenkins 의 정책을 정하고 셋업하였습니다. 예를 들어, github 의 브랜치 전략과 어떻게 하면 로컬 환경에서도 간단히 사용할 수 있는지에 대한 정책을 제안했구요, github 이벤트 발생시 jenkins 로 webhook 을 써서 trigger 가 되도록 했습니다. 뿐만 아니라 오프라인에서 개발하는 부서 특성상 파이썬 환경의 통일성을 맞추기 위해서 정책을 지정해서 사용하도록 했습니다.
• MLOps 관련되어서는 머신러닝 파이프라인 구축을 했던 것 뿐만 아니라, 모델을 RestAPI 를 통해서 사용할 수 있도록 인메모리 구조를 만들었습니다. 인메모리 구조란, 학습된 모델을 수행하는데 기존에 잡 스케쥴러를 거치고 디스크에서 읽어서 inference 결과를 얻는 시간이 평균적으로 1분정도 걸렸습니다. 하지만, 이 1분의 시간은 사용성이 떨어지고, 동일한 inference 결과도 동일한 방법으로 읽어오는 비효율적인 부분이 있었습니다. 그 문제를 해결하기 위해서 모델을 디스크가 아닌 메모리에 상주시켜놓고 사용하고, RestAPI 로 제공하면 어떨까 생각을 했습니다. 그리고 캐시 서버를 활용하여 동일한 inference 요청에 대해서는 모델까지 가지 않도록 했습니다.
• 이러한 인메모리 구조를 설계하기 위해서 Django 라이프 사이클 중 서버 인스턴스가 로드가 될 때 싱글톤 클래스로 정의되어 있는 메모리를 로드하도록 했습니다. 따라서, RestAPI 를 통해서 inference 한 결과를 가져올 수 있도록 했고, 또 때에 따라서 모델이 업데이트 된 경우에는 reload 를 하도록 API 를 개발했습니다.