배경(기존)​

이전 회사에서는 암호화 방식은 AES-256-CBC 방식을 사용하고 있고 사용자를 판별하기 위한 토큰 암호화에만 이를 사용했습니다.

암호화에 대해 잘 모르고 있었기 때문에 단순히 key, iv 값을 통해 암호화 전문(string)을 생성하고 key, iv 값을 통해 복호화 전문(string)을 만들어 사용했습니다.

기존의 암호화 사용방식은 아래와 같았습니다.

1. 암호화 로직을 꼬는 방식
   1. 암호화 하는 방식
      1. 랜덤으로 AES 암호화 키 세트 생성.
      2. a의 키 세트를 서버의 환경 변수를 통해 암호화.
      3. 평문을 a에서 생성한 암호화 키 세트를 통해 암호화(token 생성).
      4. 데이터베이스에 b에서 암호화된 암호화 키 세트와 c를 통해 암호화 된 token 저장.
   2. 암호화 푸는 방식
      1. 데이터베이스에서 2-b 암호화된 암호화 키 세트를 가져와 서버의 환경변수를 통해 암호화를 풀어줌.
      2. a의 암호화 키 세트를 통해 2-c token 암호를 풀어 고객을 찾아내는 방식.

원래 있었던 평문을 암호화하고 암호화 문을 평문화하는 2가지 모듈에 로직을 약간 넣어 혹시 모를 키 유출에 대비하려고 했었습니다.

그러던 중 외부 금융권 회사(보안 중요)와 협업을 하게 됐는데, 그 회사에서는 암호화 키 노출에 대해 민감히 반응했고 암호화 방식 하나만이 아닌 다른 암호화 방식도 추가해 도입하길 원했습니다.

고객사의 요청 사항은 아래와 같았습니다.

비대칭 암호화를 통해 대칭키를 암호화해 주고 받고 통신 시 암호화해서 주고 받았으면 하는데 이 때 서로 다른 암호화 방식 2개(AES, RSA)를 사용했으면 한다는 것이었습니다.

AES 암호화 방식도 겨우 쓰고 있었기에 무슨 소리인지 알지 못했고 검색을 통해 AES 암호화 방식이 대칭키이고 RSA 암호화 방식이 비대칭키인 것을 알게 됐습니다.

AES 암호화는 암호화를 하거나 풀 때 동일한 키를 통해 암복호화를 진행하기 때문에 대칭키고 RSA 암호화는 public key, private key 중 하나로 암호화 하면 다른 하나로 복호화하는 방식이기에 비대칭키인 것으로 이해했습니다.

결론적으로 고객사의 니즈를 정확히 파악하다가 결국 간단한 프로세스를 만들어 냈습니다.

1. 데이터를 주고 받을 시 AES로 암호화 하여 주고 받습니다.
2. RSA로 AES 암호화 키를 암호화해 주고 받아 AES 암호화 키 유출을 막습니다.

RSA + AES 암호화 구성​

위의 프로세스를 구성하기 위해서는 RSA 암호화 모듈, AES 암호화 모듈, 교체 주기에 따라 암호화 키들을 생성 업데이트 하는 모듈이 필요했고 아래와 같이 설계할 수 있었습니다.

RSA+AES 암호화 빙식 프로세스

역할​

1. RSA 암호화 모듈
   1. RSA 암호화 키 세트 랜덤 생성
   2. RSA encode
   3. RSA decode
2. AES 암호화 모듈
   1. AES 암호화 키 세트 랜덤 생성
   2. AES encode
   3. AES decode
3. AES 교체 주기마다 AES 암호화 모듈에 요청해 데이터베이스에 교체해주는 모듈
4. RSA 교체 주기마다 RSA 암호화 모듈에 요청해 데이터베이스에 교체해주는 모듈

과정​

1. RSA 암호화 모듈을 통해 저장해둔 rsa public key와 AES 암호화 키세트를 고객사에 제공(api)
2. 고객사는 AES 암호화 모듈로 랜덤하게 생성한 AES 키세트를 이용해 body를 암호화.
3. AES 암호화 키 세트를 rsa public key를 이용해 RSA 암호화.
4. RSA 암호화 된 AES 암호화 키 세트와 AES를 통해 암호화 된 body를 서버로 전송
5. 서버에서 저장해 둔 rsa private key를 통해 AES 암호화 키 세트를 복호화.
6. 복호화한 AES 암호화 키 세트를 통해 암호화 된 body를 복호화.
7. 반환 시는 고객은 이미 랜덤하게 생성한 rsa 암호화 이전 AES 암호화 키를 가지고 있기 때문에 6번에서 복호화한 AES 암호화 키를 그대로 사용해 암호화 해 body로 전송하면 됩니다.

프로세스를 통한 이점​

1. 매 요청 마다 AES 암호화 키를 랜덤하게 생성 보안에 좋음.
2. RSA 암호화 키를 주기적으로 교체하고 고객사도 이 정보를 주기적으로 받아 처리해 보안에 좋음.
3. 고객사와 서비스 서버 간에 랜덤하게 생성한 후 rsa public key를 통해 암호화한 AES 암호화 키 세트를 요청 시 주는 것 외에 키를 주고 받지 않아 보안에 좋음.
4. 암호를 풀 수 있는 rsa private key는 db server 에만 존재해 통신 시 보안이 DB 서버의 보안과 같이 높아짐.
5. 고객사의 요청을 충족시켜줌

로직 변경​

모든 걸 api를 통해 처리하고 자동화하려던 위의 프로세스 설계는 고객사 측의 기존 니즈와 다르고 완전하지 못한 설계였기에 좀 더 보완이 필요했고 고객사에서 원하는 방향대로 아래와 같이 로직을 다시 변경했습니다.

1. 고객사에서 사용할 언어에 맞게 암호화 모듈을 제공하고 이를 통해 rsa 암호화 키를 생성 후 우리에게 rsa_public_key를 메일로 제공합니다.
2. 해당 키를 저장하고 고객사에서 요청 시 랜덤으로 aes_key를 생성하고 저장해 둔 rsa_public_key를 encode 해 고객사에 api를 통해 전달합니다.
3. 고객사에서는 해당 키를 encoded_aes_key를 decode 해 저장하고 우리와 통신 시 aes_key로 https body 를 encode 해 우리 서비스에 요청합니다.
4. 고객에 요청에 의해 랜덤하게 생성한 aes_key를 저장해둔 것을 이용해 body를 decode하고 서비스 로직 실행 완료 후 다시 encode해 고객에게 반환합니다.
5. 언제든 rsa_key 또는 aes_key 업데이트는 고객사의 요청에 따라 교체할 수 있게 합니다.

초기 설계한 로직에서 이미 기능들은 모두 만들었기 때문에 해당 로직을 구현하는데 어려움은 없었고 고객사의 니즈를 제대로 충족할 수 있었습니다.

결론​

암호화 방식에 대해서 좀 더 공부해 볼 수 있는 동기부여가 되는 시간이었고 그 동안 잘못 사용하고 있던 것들을 바로 잡을 수 있었습니다. 또한 여러 암호화 방식을 이용해 보안을 더 강화하는 재밌는 로직에 대해서도 알 수 있는 흥미로웠고 배울 수 있는 시간이었습니다.

배경​

수 많은 케이스들을 더해 각 케이스들을 조합해 목적값을 찾는데 이 때 각 케이스의 금액이 가장 저렴한 케이스를 찾아야 할 때 조합 최적화 방법이 필요합니다.

최적의 조합​

연구 과제​

먼저 조합을 하려면 조합하기 위한 경우의 수를 찾아내야 합니다.

예를 들어 A, B, C, D 특성이 있다고 하면,

A, B, C 는 조합에 사용될 케이스이고 D 는 가격 특성이라고 하면 A, B, C 의 값 범위는 0~1로 동일하다고 하면 A, B, C 가 합쳐져 만들어지는 케이스를 구해보면,

0~1(2개) X 2 X 2 => 8개의 케이스가 생깁니다.

이와 같은 케이스 생성 방법은 Cartesian Product를 활용하여 쉽게 도출할 수 있습니다.

이제 A, B, C 간의 조합을 통해 목적값을 구한다고 생각해 보면,(아래는 목적값)

이 목적값을 구하기 위해 아래와 같은 여러 개의 가능한 조합들이 생깁니다.

조합은 2개의 행으로 조합될 수도 있고 3개의 행으로 조합될 수도 있습니다. 이번 목적값과 데이터셋에서는 불가하지만 1개의 행으로도 충족하는 상황도 있습니다. 이 때 아래와 같이 D 컬럼이 가격이라고 하고 행 간 조합을 통해 합산된 가격이 가장 저렴한 조합을 찾는다고 해보면,

가격이 위와 같을 경우 위의 조합이 가능할 때 합산 금액은 첫번째는 7, 두번째는 4인데 조합이 가능한 케이스가 2개의 조합뿐이라고 할 때 두번째 조합이 최적의 조합입니다.

하지만 만약 조합 컬럼 개수가 10개 정도 된다면 그리고 컬럼마다의 값의 범위가 0~9 정도 된다면 Cartesian Product를 통해 10^10개의 조합 재료가 생깁니다. 이 조합 재료의 총 진부분집합(공집합을 제외한 부분집합) 개수는 자그마치 2^10000000000개가 됩니다. 2의 백억승이 되는데 16000승만 되도 이미 5천 자리를 넘어서게 됩니다. 이 같이 모든 조합을 구하는 방식은 조합 방식에 따라 가능, 불가능 여부를 따지게 됩니다.

목적 조합​

위와 같이 모든 조합 케이스를 다 만드는 순간 왠만한 프로그램은 멈추거나 몇 일 뒤에 결과가 나는 등 아주 안 좋은 결과를 얻을 수 있습니다.

그래서 위의 그림과 같이 모든 조합을 만들고 목적조합을 찾는게 아닌 역으로 조합의 목적값을 생성하는 방식으로 조합을 만들게 됩니다.

2개 조합으로 생각하면 목적값이 111 이라고 가정하면, 첫행과 마지막행, 그리고 두번째행과 마지막에서 두번째행, ... 이런식으로 가운데까지 조합이 생깁니다.

3개 조합으로 생각하면 첫행과 둘째행과 마지막에서 두번째 행, 첫행과 세번째행과 마지막에서 세번째행, ... 이런식으로 조합이 생깁니다.

위와 같이 목적값에 따라 행열 구조에서 대각선의 일정 규칙을 지닌 조합들을 찾아낼 수 있습니다.

이렇게 하면 모든 조합 케이스를 찾는 말도 안되는 조합 개수를 생성해 목적값 충족하는지 여부를 조합들 하나 하나 계산해 봐야 하는 프로세스를 제외시키고 조합 마다의 가격 비교만 하면 최적의 조합을 찾아낼 수 있습니다.

다른 방법 소개​

위의 조합 방법은 Google OR-Tools를 활용해 간단하게 해결할 수도 있습니다.

Google 신의 OR-Tools는 원래 C++로 작성됐는데 python으로 사용 가능하고 선형 계획법, 혼합 정수 계획법, 제약 조건 프로그래밍, 차량 경로 지정 및 관련 최적화 문제를 해결하기 위해 개발한 무료 오픈 소스인데 여기서 cp_model을 활용해 해당 문제들을 해결합니다.

아래는 pandas를 활용한 Cartesian Product로 데이터 셋을 활용하고 랜덤 가격을 적용한 후 Google Ortools의 cp_model을 활용해 간단히 조합 찾아내는 예제를 만들어낸 페이지 예시입니다. 숫자를 입력하고 랜덤을 누르면 입력한 숫자가 목적값이 되고 랜덤으로 생성된 가격의 최적 조합을 찾아냅니다.(react + fastapi 조합)

현재는 heroku 유료화로 백엔드가 정상동작되지 않아 추후 정상화할 예정

결론​

위의 조합을 이용해 bin-packing 화면을 구현하려 했지만 시간도 늦었고 해야될 다른 작업들이 많아(귀찮아서) 하진 않았습니다. 이런 최적 조합을 찾는 방법들은 좀 더 최적화된 방법들을 사람들이 만들어낼 텐데 더욱 좋은 기술들이 나와 세상에 수 많은 최적 조합이 필요한 경우를 가장 효율적으로 해낼 수 있다면 좋을 것 같습니다.

혹시나 내가 최적의 조합을 만드는 알고리즘을 성장시키는데 일조한다면 그 또한 뿌듯할 거 같습니다.

배경​

현업에서 업무를 하다 보면 배정 관련해서 데이터베이스 쿼리를 통해 가장 적게 배정 받은 순서로 플래너를 배정하고 안심번호를 배정하는 경우가 있습니다. 이때 요청이 많을 경우 문제가 발생합니다.

예를 들어 배정이 가장 적게 된 사람을 검색하고 그 사람은 이제 배정 됐음을 데이터베이스를 통해 업데이트를 하게 된다면, 이 프로세스를 진행하는 동안 수 많은 고객들이 데이터베이스가 업데이트 되기도 전에 같은 프로세스를 돌면서 중복 업데이트, 중복 배정의 문제가 발생됩니다.

설계​

솔루션을 활용한 방법(rabbitmq, kafka, redis, …)​

순서​

1. 백엔드로 요청이 들어오면 배정을 위해 필요한 데이터를 준비하고 그 순서를 큐에 쌓아둡니다.
2. 쌓아둔 큐를 규칙에 따라 cron이 돌면서 가져와 순차적으로 배정됩니다.
3. 이 때 큐의 규칙은 FIFO로 설정해 먼저 쌓인 요청부터 처리하는 방식이 신뢰도 있게 동작할 수 있습니다.

결론​

메시지 큐 관련 솔루션을 활용해 배정이 필요한 부분을 쌓아둔 뒤, 일정 규칙에 맞게 cron을 돌려 쌓아둔 배정을 순차적으로 처리하는 방식입니다.

MySQL user-level lock 기능을 활용하는 방법​

소개​

MySQL은 사용자 레벨에서 데이터베이스를 조작할 수 있는 Lock 기능을 아래와 같이 제공합니다.

GET_LOCK(str, timeout): Lock의 이름을 설정하고 해당 락 프로세스 수행이 오래 걸릴 시를 대비해 timeout도 설정합니다.

IS_FREE_LOCK(str): GET_LOCK에서 설정된 이름을 조회해 현재 이 Lock이 사용중이라면 0, Lock이 풀렸다면 1, 만약 오류가 있다면 null 을 반환합니다.

IS_USED_LOCK(str): 이름에서 보는 것과 같이 IS_FREE_LOCK과 반대로 동작합니다.

RELEASE_ALL_LOCKS(): 해당 세션에서 설정한 모든 락을 풀어줍니다.

RELEASE_LOCK(str): Lock의 이름을 찾아 Lock을 풀어줍니다.

순서​

동시성에 대해 문제가 발생하는 위의 그림과 같이 lock을 걸고 insert, update 를 처리한 후에 lock을 release 해주어 이를 해결하는 방법입니다.

1. 배정이 가장 적게 된 사람을 검색하고 배정 됐음을 업데이트 하는 프로세스를 코드 실행 상 가장 근접하게 구성합니다.
2. 1번에서 구성된 프로세스 앞 단에 GET_LOCK 쿼리를 하고 로직 수행 후 RELEASE_LOCK을 수행합니다.

결론​

솔루션을 활용하는 방법 보다 서버 구성의 복잡도를 줄일 수 있고 백엔드 서버 내에서 코드적으로 처리할 수 있는 이점이 있습니다.

Operating Architecture

배경​

누군가한테 질문을 받았다. 분명 파이썬에서 멀티 프로세스를 사용하거나 고랭에서 멀티 쓰레드를 사용해 성능을 향상 시켰었는데 어떻게 사용해 봤다만 이야기 했습니다.

모르는데 해봤다고 말하니 모르고 막 사용한 거 같은 부끄러움이 밀려왔다. 다음부터는 좀 더 알아보고 사용해야지 싶어 간단히 정리해 봅니다.

Process & Thread​

Process​

운영체제로부터 자원을 할당받는 작업의 단위로서 프로그램이 메모리에 올라가 실행 중인 상태가 될 때 그 상태 단위를 프로세스라고 합니다.

Thread​

할당 받은 자원을 이용하는 실행의 단위로서 하나의 process 내에 여러 개의 thread 가 생길 수 있습니다.

결론​

process는 작업을 수행하기 위한 단위이고 thread는 process를 수행하기 위한 단위입니다.

Multi Process & Multi Thread​

Multi Process​

여러 개의 process로 하나의 작업을 처리하는 것입니다.

하나의 process에서 오류가 생겨도 프로그램은 동작하는 장점이 있고 context switching 비용이 발생하는 단점이 있습니다.

Multi Thread​

여러 개의 thread로 하나의 process를 처리하는 것입니다.

시스템 자원 소모 감소와 처리 비용 감소, thread 간 자원 공유 등의 장점이 있고 debugging이 어렵고 동기화 이슈 발생, 하나의 오류로 process 문제 발생시키는 단점이 있습니다.

결론​

multi process, multi thread 방식의 큰 차이점은 multi thread의 경우 하나의 process 내부에서 데이터를 공유하며 동작할 수 있다는 이점이 있어 비용을 감소시키고 메모리 공간도 적게 사용해 효율적이다. multi process는 하나의 작업을 수행하기 위해 프로세스 간 context switching을 거치게 되는데 multi thread는 공유 자원을 가지고 있어 context switching에 들어가는 비용이 절감되는 장점도 있습니다.

위의 장점만으로 보면 multi thread의 장점만 보이지만 공유 자원을 이용하는 만큼 공유 자원에 동시 접근에 의한 오류들이 생길 수 있고 debugging 또한 까다로워 신중하게 고려해야 하는 까다로움이 있습니다.

Thread Safe & Context Switching​

Thread Safe​

여러 thread 가 동시 동작해도 안전하다는 의미로서 함수 A, B가 여러 thread에서 호출되도 하나의 thread에서 호출됐을 때와 같은 결과가 보장되는 것을 말합니다.

Context Switching​

여러 process나 여러 thread를 돌아가면서 작업을 처리하는 과정을 context switching이라 합니다.

Semaphore & Mutex​

여러 process와 thread 작업을 수행 시 자원을 공유하게 되는데 이 때 공유 자원에 접근하는 부분을 Critical Section이라 함. 공유 자원에 대한 접근 처리를 제대로 하지 않으면 많은 문제들을 야기하게 되는데 이를 위해 사용하는 대표적인 방식으로 Semephore, Mutex가 있습니다.

Semaphore​

공유 자원에 여러 개의 프로세스가 접근하는 것을 막는 것을 의미하는데 이를 위해 공유 자원의 상태를 나타내는 카운터 변수를 사용합니다. 이 변수는 실제 운영체제, 커널의 값으로 저장되어 각 프로세스가 이를 확인하고 변경할 수 있게 됨. 각 프로세스가 상태값을 보고 사용중인지 사용 가능한 상태인지를 인지해 사용 가능한 때를 기다렸다가 사용하는 방식임. Mutex와는 달리 0, 1 과 같은 이진수 외에 더 큰 숫자를 가지게 할 수 있어 1개의 프로세스만이 자원을 점유하지 않고 공유 자원에 접근할 수 있는 임계치가 되어 접근할 수 있는 process의 개수를 통제할 수 있습니다.

Mutex​

상호 배제를 의미하는데 critical section을 가지는 thread들의 실행 시간이 겹치지 않게 해주는 방법을 사용합니다. semaphore와는 달리 1개의 thread만 critical section에 접근할 수 있게 함. Lock, Unlock 개념을 사용하고 Binary Semaphore와 같은 개념으로 쓰임. 하나의 therad가 자원을 사용할 때 Lock을 걸어 다른 thread 접근을 통제하고 작업이 끝나 Unlock하면 다른 thread들이 기다렸다가 접근해 Lock을 하며 동작하게 됩니다.

결론​

Mutex는 Binary Semaphore의 일종으로서 가장 큰 차이점은 Mutex는 오직 1개의 thread만 공유 자원에 접근할 수 있고 Semaphore는 지정된 변수 값 만큼 접근할 수 있는 차이점이 있다는 것입니다.

배경​

사내에서 react를 활용한 어드민 페이지 개발이 다수의 서비스에 도입되면서 다수의 어드민 페이지 개발을 통일성 있게 개발해 보자는 니즈가 있었고 이를 위해 공용 모듈을 통해 통일성을 찾아보자는 방법을 연구하기 시작합니다.

프로세스 설계​

공통 UI Library 프로세스 설계

1. UI Library Developer는 reactjs, storybook, tailwindcss를 이용해 공통으로 사용할 만한 UI 컴포넌트를 제작해 storybook을 통해 이를 테스트해 볼 수 있도록 하는 웹을 Netlify를 통해 배포합니다.
2. UI Designer와 함께 웹을 보면서 Storybook을 통해 수치를 조정하거나 컴포넌트 변경에 대해 논의 및 수정합니다.
3. 협의된 컴포넌트를 Npm을 통해 라이브러리로 배포합니다.
4. Frontend Developer는 Storybook을 통해 컴포넌트의 UI셋팅값에 맞게 UI Designer와 함께 웹 서비스를 개발합니다.

• 장점

1. 매 프로젝트별 동일하게 사용하는 컴포넌트 개발을 프로젝트 별로 분리 개발하지 않고 설치해서 바로 사용 가능합니다.
2. Storybook을 웹에 배포해 UI Designer와 함께 직접 컴포넌트 셋팅값을 조정해 개발적으로도 가능 범주를 조정해 줄 수 있고 UI Designer도 실제 눈앞에서 조정해 볼 수 있어 효율적입니다.
3. UI 라이브러리를 지속적으로 업그레이드 해 기존 프로젝트 별 일회성 컴포넌트가 아닌 자산화가 가능합니다.

• 단점

1. 공용으로 사용하는 모듈의 사용을 강력히 권고하면 프로젝트 별 자유도를 떨어트립니다.
2. UI 라이브러리의 지속적 업데이트 관리가 필요하며 사용하는 프로젝트에서의 라이브러리 버전 특성을 고려해야 합니다.

• 주요 고려 사항

1. 공용으로 사용하는 모듈의 사용은 편의를 제공하기 위함이므로 사용을 권고하기 보다 원하면 사용하도록 하는 것이 좋을 것으로 보입니다.
2. 공용으로 반드시 사용할 수 있을 만한 컴포넌트 단위를 신중히 선정해야 할 것으로 보입니다.

개발 과정​

React Typescript 빌드 설정​

1. React 프로젝트 생성: npm init -y

2. 필수 라이브러리 설치: npm install --save-dev react react-dom @types/node @types/react @types/react-dom typescript

3. package.json 설정

   • peerDependencies란 실제로 패키지에서 require, import 하지는 않지만 특정 라이브러리 툴에 호환성을 필요로 할 경우 명시하는 dependencies인데 아래와 같이 react 버전과 react-dom 버전을 명시함으로써 해당 버전에서 사용할 수 있는 라이브러리임을 명시해 오류를 줄이기 위함입니다.
   • files는 npm 라이브러리 배포 시 폴더를 설정하기 위함입니다.
   • scripts는 tsc를 통해 빌드하는 타입스크립트 빌드 build:esm 과 바닐라JS사용 유저를 위해 build:cjs 를 둘 다 빌드하게 합니다.

   {
     "peerDependencies": {
       "react": "^18.1.0",
       "react-dom": "^18.1.0"
     },
     "files": ["dist"],
     "scripts": {
       "build": "rm -rf /dist && npm run build:esm && npm run build:cjs",
       "build:esm": "tsc",
       "build:cjs": "tsc --module CommonJS --outDir dist/cjs"
     }
   }
   

4. Typescript 설정

   • 타입스크립트 초기 설정: tsc --init
   • tsconfig.json 설정

   {
     "compilerOptions": {
       "allowSyntheticDefaultImports": true,
       "declaration": true,
       "esModuleInterop": true,
       "jsx": "react",
       "lib": ["ES5", "ES2015", "ES2016", "DOM", "ESNext"],
       "types": ["node"],
       "module": "es2015",
       "moduleResolution": "node",
       "noImplicitAny": false,
       "noUnusedLocals": true,
       "outDir": "dist/esm",
       "sourceMap": true,
       "strict": true,
       "target": "ES6"
     },
     "include": ["src/**/*.ts", "src/**/*.tsx"]
   }
   

Storybook 설정​

1. Storybook 초기 설정: npx sb init

2. 실행 확인: npm run storybook

   

Npm 배포​

1. 라이브러리로 배포 후 사용하기 위해서는 path 설정을 해줘야 하는데 이를 위해 컴포넌트 별로 export * from “./Button” 이런 식의 경로 설정을 폴더별 index.ts에 적용합니다.
2. 빌드: npm run build
3. 배포: npm publish (npm login이 안되어 있다면 이를 선행해야 합니다.)

Netlify Storybook 배포​

1. 위의 storybook 초기 설정을 하고 나면 자동으로 package.json에 "build-storybook": "build-storybook” script가 생성되는데 이를 이용해 static한 파일들을 storybook-static폴더에 생성할 수 있습니다.(storybook 배포용 폴더)
2. Netlify에 접속해 해당 깃허브를 연결하고 배포 시 Build Command를 npm run build-storybook 으로 해 storybook-static 폴더를 생성하고 이를 Output Directory로 설정해 깃허브에 푸시하면 storybook 웹싸이트가 자동으로 publish 되도록 자동 배포가 쉽게 설정됩니다.

TailwindCss 적용​

1. 필요 라이브러리 설치 및 초기 설정합니다.
   • 아래를 실행하면 자동으로 tailwind.config.js 가 생성되는데 이 설정파일을 통해 tailwind에서 설정하고 있는 색, 크기, 적용범위, 플러그인 등을 모두 설정할 수 있습니다.

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

1. tailwind를 사용하기 위한 css 파일을 생성합니다.

@tailwind base;
@tailwind components;
@tailwind utilities;

1. 컴포넌트 라이브러리와 storybook 확인 시 모두 tailwind를 적용하기 위해 src/index.ts 와 .storybook/preview.js 에 tailwind.css 를 import 하면 모두 적용됩니다.
2. 빌드 셋팅

tailwind 공식 홈을 참고해 tailwindcss 파일을 빌드 파일에 추가합니다.

{
  "build": "rm -rf /dist && npm run build:esm && npm run build:cjs && npm run build:tailwind",
  "build:esm": "tsc",
  "build:cjs": "tsc --module CommonJS --outDir dist/cjs",
  "build:tailwind": "tailwindcss -i ./src/styles/tailwind.css -o ./dist/cjs/styles/tailwind.css && tailwindcss -i ./src/styles/tailwind.css -o ./dist/esm/styles/tailwind.css"
}

결론​

tailwindcss가 적용된 형태로 storybook 웹 싸이트가 구현된 모습입니다.

npm 패키지 배포된 모습입니다.

배포한 라이브러리 설치한 코드입니다.

설치한 라이브러리의 버튼을 가져다 사용한 코드입니다.

UI Library를 직접 설치해 웹에서 사용한 모습입니다.

***참고사항

1. 라이브러리를 설치는 정상적으로 되고 실행도 정상적으로 되지만 sourcemap 오류가 발생하는데 이를 해결하기 위해 .env 파일에 GENERATE_SOURCEMAP=false 를 작성해 저장하면 실행 시 오류 메시지가 보이지 않습니다.
2. tailwindcss 설정 순서에 따라 적용이 잘 안 될 수 있어 순서대로 설정해야 합니다.
3. 소스: https://github.com/hanhyeonkyu/react-ui-lib-ts-test

참고 문서​

UI라이브러리 제작: https://javascript.plainenglish.io/build-a-react-component-library-using-typescript-storybook-86d3562aa53a

Storybook - Tailwind Netlify: https://theodorusclarence.com/blog/nextjs-storybook-tailwind

TailwindCss 공홈: https://tailwindcss.com/docs/guides/create-react-app

배경​

그 동안 react, nextjs, hugo ... 등을 활용해 프론트엔드 개발을 진행하고 간단히 주변에 공유할 때 Netlify 를 자주 활용해 왔습니다. 하지만 요새 공부 중인 Flutter 는 웹도 앱도 모두 한번에 개발할 수 있는 신무기지만 Netlify 를 활용해 배포해 본 적이 없어 간단한 작업이지만 블로그에 남겨봅니다.

소개​

Netlify는 웹 애플리케이션 및 정적 웹사이트를 위한 호스팅 및 서버리스 백엔드 서비스를 제공하는데 저의 경우 간단하게 프론트엔드를 배포할 때만 사용하고 있습니다.

Flutter는 모바일 앱과 웹 앱, 데스크톱 앱을 단일 코드 베이스로 개발할 수 있도록 Google이 개발한 프레임워크인데 Google 답게 Docs가 아주 잘 되어 있고 공부할 수 있도록 많은 지원을 해주고 있고 Flutter 자체가 가진 기능들이 많기 때문에 react-native 개발 때 느꼈던 dependency 지옥으로부터 조금이나마 해방된 느낌입니다.

팀원들에게 Flutter를 이용해 웹, 앱 모두 간단하게 개발된다는 것을 보여주기 위해 Netlify에 로그인 해 배포하려 했는데 이것을 몰라 찾아 봤고 금방 해답을 찾을 수 있었습니다.

수동 배포​

우선 기본 전제는 Flutter 설치를 완전히 했다는 전제로 시작합니다.(공식문서 참고)

1. 우선 Flutter 프로젝트를 생성합니다. flutter create [project_name]

2. 프로젝트 폴더로 들어가서 flutter build web을 실행하면 build/web 폴더가 생성되고 배포용 js 빌드 파일들이 생성됩니다.(이것이 프론트엔드 배포용 소스)

3. 아래와 같이 Netlify에 접속에 Deploy manually 를 클릭하면

   

4. 2번에서 생성한 배포용 폴더를 아래와 같이 Drag & Drop 하면 배포 성공!

   

아주 간단해서 정리할 것도 많지 않았지만 그래도 정리해 두면 다음번에 생각을 덜해도 되니까 적어둬야지 😎

자동 배포​

위에서 봤던 수동 배포로 해도 과정이 간단하고 실수로 자동으로 배포되는 것을 원치 않기 때문에 수동 배포를 좀 더 원하지만 자동 배포에 대해서도 알게 되어 이 또한 정리해 봅니다.

1. 수동 배포의 1번을 완료하고 아래와 같이 Netlify에 접속 후 import an existing project 를 클릭합니다.

2. 본인의 git repository를 선택하고 해당 레파지토리를 netlify에 공유할 수 있도록 설정합니다.

3. 이제 Deploy & Build 셋팅을 설정하는데, 명령과 셋팅은 아래와 같습니다.

• Build command

아래와 같이 만약 flutter 폴더가 있으면 git pull을 통해 최신화 하고 없다면 git clone 을 통해 flutter를 가져오고 flutter 폴더에 있는 실행파일을 활용해 프로젝트에 웹을 적용하고 웹을 빌드해 배포합니다.

if cd flutter; then git pull && cd ..; else git clone https://github.com/flutter/flutter.git; fi && flutter/bin/flutter config --enable-web && flutter/bin/flutter build web --release

• Publish directory

배포 폴더를 build/web으로 하여 Build command에서 생성한 배포 폴더로 설정합니다.

build/web

이렇게 설정하면 git에 푸시할 때마다 build command가 실행되고 설정된 publish directory설정에 따라 배포하게 되면서 자동 배포가 완성됩니다.

아직 공식 홈페이지에서 Deploy 셋팅 방법에 대해 Flutter는 다루고 있지 않지만 위와 같은 방식으로 처리가 가능합니다.

도움이 되는 포스팅이기를 빕니다. 🧑🏻‍💻

회사에서 동료들과 이야기하던 중 우리 회사도 redux를 도입해야 하는 거 아니냐는 말을 들었습니다. 그렇습니다. 사실 redux를 도입하던 global state 관리할 만한 뭔가를 진작 도입했어야 했습니다. 우리는 왜 여태 컴포넌트 간의 props 를 넘겨가며 코드를 계속 복잡하게 만들고 있어야 했나...

배경​

사실 시작은 이렇다. 처음 개발한 개발자 분이 react 기본 router, state 관리 방식까지 모두 자기만의 스타일로 만들어 그 패턴으로 개발했습니다. 황당했지만 굴러드러온 돌이고 바빴기 때문에 이를 고칠 시간적 여유도 없었습니다.

그렇게 시간이 흘러 여러 차례 마이그레이션, 신규 런칭 과정을 거쳤지만 이번에도 같은 실수를 반복하며 제대로 개선되지 못하고 본인만의 패턴들을 꽉 체워 두었습니다. 결국 모두가 새로 나가고 한번 더 새로운 사람들로 체워지면서 현재의 새로운 프론트엔드, 앱 개발자들은 이 상황을 맞닥뜨려야 했습니다.

바쁜 일상​

프론트엔드, 앱, 서비스 백엔드 개발자 분들은 계속된 요구사항과 유지보수 개발에 지쳐있었습니다. 문제를 이야기한지 시간이 많이 지났지만 그 누구도 기술적 검토나 토론을 이어가지 않았습니다.

그래서 자의로 스터디도 할 겸, 사내 문서도 만들 겸, 테스트해 react의 global state 관리 방식에 대해 조사해보기로 했습니다.

위의 링크에 있는 비교 분석을 참고해 실제 적용하며 테스트했고 recoil 로 적용하자고 결론에 다다랐습니다.

이번 회사에서는 면접 자리에서 연봉협상을 통해 헨드헌터와 이야기 했던 연봉 보다 낮춰진 체로 입사하게 되어 떨떠름 했지만 그래도 기존 연봉보다는 20% 넘게 올렸기 때문에 그걸 위안 삼기로 했습니다.

2019년 10월부터 2022년 9월까지 거의 3년을 근무한 회사의 경험입니다.

입사일​

처음 출근 하기 전 영어 이름을 정해야 했습니다. 이번에도 이전에 정한 익숙한 이름 알렉스로 정했습니다.

출근해 보니 정해져 있는 자리가 있었습니다. 그리고 OT가 시작됐다. OT는 다른 스타트업과 비교해 독특하게 개발과 상관없는 모든 부서의 장들이 직접 부서 업무에 대해 소개해줬습니다. (알고 보니 개발과 굉장히 밀접한 부서들이었습니다.)

OT를 거치면서 부서장 분들이 직급과 상관없이 서로 편하게 말할 수 있는 분위기인 것을 강조해 좋은 인상을 받았습니다.

내가 속해 있던 개발팀은 CTO인 브라이언과 내 또래의 프론트엔드 개발자 휴버트가 있었고 샘이라는 개발자는 신사업팀으로 따로 팀이 있는 상황이었습니다. 개발자가 3명인데다가 말도 잘 통해 보이고 나이대도 비슷해 든든했습니다.

자기 일만 제대로 한다면 쉬는 시간도 자유롭고 영어이름을 쓰며 높은 직급에도 격의없이 서비스에 대해 논의하고 개발자에 대해 존중해주는 수평적인 분위기가 보였고 회사에 대한 기대가 생기는 첫 날이었습니다.

회사의 과거 이야기​

OT가 끝나고 휴버트는 프론트엔드 소스를 공유했습니다. 본인이 맡고 있는 프론트엔드부터 같이 해보자고 해서 본격적인 업무를 시작하게 됩니다. 소스를 보니 typescript, react로 구성된 웹이었고 회사의 앱은 react-native에 웹뷰를 띄워 거의 모든 동작은 웹뷰에서 이뤄지게 만들어져 있었습니다.

react-native 소스도 받았지만 수정을 안 한지가 거의 6개월이 지난 상태였습니다. 그리고 react-native로 앱 스토어에 배포한 경험이 있는 사람도 회사에 없었습니다. 알고 보니 내가 들어오기 1달 전 제이드라는 개발자가 앱을 맡고 있다가 인수인계 없이 퇴사를 했다고 합니다.

점심 식사를 하면서 회사의 과거 이야기를 듣게 됐습니다. 사실 회사에는 개발자 숫자가 거의 15명이 될 정도로 개발인원이 많았었는데 투자 유치 및 개발 산출물의 반응이 좋지 않아 적자에 허덕였고 그 때 퇴사 권유를 받아 대부분 퇴사하게 되고 개발자 샘과 보험 데이터 기획자 에릭이 남게 되었다고 합니다.

그렇게 남게 된 샘은 조금씩 작은 개발 관련 일처리를 하다가 회사에 투자 유치가 되서 에릭과 함께 보닥이라는 서비스를 만들기로 했고 그 서비스를 만들기 위해 개발자들을 채용하게 됐습니다. 그 때 뽑은 인원이 휴버트와 제이드였고 휴버트는 프론트엔드, 제이드는 앱 및 서버 구성, 샘은 백엔드를 담당해 훌륭한 합을 보여줬다고 합니다.

에릭과 개발팀들은 열심히 목적을 향해 나갔고 앱을 출시하고 유지보수하며 잘 운영해 회사의 캐시카우가 되었습니다. 그런데 앱이 성공적으로 출시되고 회사가 안정된 돈이 들어오게 되면서 다른 투자들을 더 받기 위해 새로운 시도들이 계속 요구됐는데 이 과정에서 샘과 경영진 간 마찰이 많았다고 합니다.

샘은 개발자 입장, 경영진은 투자를 받기 위한 입장이기 때문에 마찰이 있을 수 있었지만 경영진이 샘을 컨트롤하기 힘들어졌다 생각해 추후 더 큰 개발팀이 되면 뽑으려 했던 CTO를 급하게 고용했다고 합니다. CTO는 나를 면접 봤던 브라이언이었고 브라이언은 경영진이 원하는 바를 빠르게 도입할 수 있는 체계를 만들기 위해 현재 개발된 내용들을 모두 단순화하기 위해 다 갈아치울 거라고 말했습니다.

브라이언은 처음에 앱의 규모만 보고 혼자 모두 새로 만들어도 2~3개월이면 될 듯이 말했고 경영진은 이것을 믿어주고 힘을 실어줬습니다. 하지만 샘은 이런 브라이언의 태도를 가만 볼 수 없었고 브라이언의 원하는 바를 해주지 않았고 여전히 강경한 입장을 고수하고 있었습니다. 그렇게 샘과 틀어진 브라이언은 남은 2명과 샘을 이간질하고 샘을 팀에서 추방해 샘과의 대화를 통제하기 시작했습니다.

하지만 3명은 이미 개발 합을 맞추며 깊은 관계였고 이 모든 것은 3명 모두의 반감을 사게 됩니다. 브라이언은 애초에 CTO로 입사할 때부터 실무를 하려 한 게 아니었기 때문에 개발자들의 도움이 필요했는데 그나마 말을 좀 들어주던 제이드와 휴버트에게 일을 시켰지만 브라이언이 급하게 설계한 데이터베이스와 백엔드는 아주 많이 수정이 필요했고 이에 2명 또한 지쳐갔습니다.

브라이언은 3명 모두의 신임을 잃었기 때문에 경영진에게는 3명이 돕지 않아 문제가 된다며 그들 탓을 계속 반복 했지만 일정 압박을 받았고, 이 때부터 회사에서 자유롭게 사용하던 개발자들의 연차까지 반려시키기 시작했습니다. 이로 인해 제이드는 사적으로 안 좋은 상황에 처하게 됐고 그로 인해 바로 퇴사하게 됐다고 들었습니다.

그래서 회사에서 사용중인 서비스들의 계정 관련 정보들, 배포 프로세스, 앱 배포 등을 아는 사람이 없는 상황이었습니다. 생각보다 심각한 상황이었습니다. 배포체계에 갑자기 문제가 생긴 상태에서 급하게 서비스에 이슈가 생긴다면 그걸 고치기 위해 전체 프로세스를 새로 만들어야 할 수도 있었습니다.

브라이언은 저와 샘과의 대화를 지속적으로 막았습니다. 브라이언 때문에 신사업팀으로 배정돼 업무에서 배제된 샘이 사실은 회사의 모든 백엔드 내용을 알고 있는데 대화를 할 수도 없고 불편하고 난감한 상황이었습니다.

퇴사 레이스​

입사했을 때부터 샘은 퇴사 일정이 잡혀 있었습니다. 업무를 배제시키고 경영진 또한 CTO에게 힘을 실어주고 있으니 샘도 회사에 있을 이유가 없어 보였습니다. 하지만 샘에게 배우고 싶어 회사에 남아있었던 휴버트는 샘이 나가면 나가겠다고 했습니다. (샘은 개발 능력이 아주 뛰어난 개발자였습니다.)

CTO는 해내겠다고 한 일정보다 6개월이 더 걸려서도 일을 해내지 못했고 게다가 모든 팀원들이 퇴사 의지를 밝혀 찰스에 의해 결국 강제 퇴사를 당하게 됐습니다. CTO가 퇴사 당했지만 회사에 질려버린 샘도 거의 비슷한 시일에 일정대로 퇴사했고 휴버트는 간단하게 웹뷰에 대한 배포 방법을 알려준 뒤 샘의 소개로 다른 회사에 추천되어 이직을 성공하게 됩니다.

퇴사하기 전 샘과 휴버트는 경영진에게도 많은 상황 어필들을 했으나 모든 것들이 소용이 없었다고 생각해 회사에 실망을 한 상태였기 때문에 마음을 돌리 수도 없었습니다. 그렇게 결국 다시 개발팀에 혼자 남게 됐는데 그래도 에릭이 이전 개발에 대한 히스토리를 알고 있어 옆에서 많은 도움을 줬고 유지보수에 많은 도움이 됐습니다.

유지보수​

프론트엔드​

react, typescript로 구성된 서비스는 대부분 웹뷰를 통해 독특하게 구성되어 있었습니다. 프론트엔드에서 api를 사용하기 위해서는 백엔드 개발 시 같이 배포하는 api용 타입 라이브러리를 npm에 배포하고 이것을 프론트엔드에서 업그레이드해 사용하는 패턴을 취하고 있어 양 쪽의 오류를 덜 수도 있었지만 혼자 있는 상황에서 많은 일을 빠르게 개발할 때 불편한 족쇄 중 하나였습니다.

게다가 소스를 보면 react-router, redux, react 기본 기능인 state 관리, UI컴포넌트 등을 모두 JS로 직접 만들어 사용했는데 설정 방식도, 기능도, 성능도 모두 좋지 않았습니다. 하지만 혼자 남은 상황에서 패턴을 모두 변경하고 새로 개발하기엔 버거웠기 때문에 패턴에 맞춰 개발했습니다. 독립적으로 변경할 수 있는 부분들만 다른 개발자들도 좀 더 익숙한 형태로 변경해 나갔습니다.

앱​

react-native, typescript로 구성된 앱은 앱에서 구동되는 광고용, 비지니스용 트랙킹 라이브러리들, 딥링크들을 사용하기 위해 구성되어 있고 앱의 가장 주요 기능 중 하나인 신정원 회원가입, 로그인, 스크랩핑을 위해 필요했습니다.

나머지는 웹뷰에서 구현되어 있기 때문에 사실 앱 UI는 아무것도 없는 빈 껍떼기에 불과한 상황이었습니다. 하지만 이 시점부터 react-native는 빠르게 업그레이드 되고 앱스토어, 플레이스토어의 정책 변경과 웹뷰가 많은 앱에 대한 심사가 까다로워지는 등 이슈들은 계속 생겨났습니다.

앱에 익숙하지 않고 스토어에 배포까지 해 본 적은 없어서 좀 더 앱에 익숙해지기 위해 열공하고 이슈도 해결해 나갔습니다. 직접 토이 프로젝트 앱도 스토어에 배포해 보고 테스트도 하면서 조금씩 앱에 대해 익숙해져 갔습니다.

메인 Api​

메인 Api는 모두가 퇴사하고 나서 유지보수를 하면서 처음 보게 됐습니다. 회사의 모든 언어 스택이 typescript로 알고 있었는데 사실은 아니었습니다. 깃허브를 열심히 뒤져보며 찾게 된 실 구동중인 소스는 php laravel로 구성된 백엔드였습니다.

php는 아예 처음 들어본 상황인데, 유지보수는 급했고 소스를 열심히 읽어가며 무작정 Larabel의 패턴을 익혀 패턴에 맞춰 개발했습니다. 배포 방법은 에릭에게 질문하고 readme에 적힌 내용을 토대로 테스트하며 결국 배포할 수 있게 됐습니다.

php로 로컬 환경을 구성하는 법도 모르던 상황에서 빠르게 유지보수를 해야 했기 때문에 당시에는 빨리 고치고 테스트 환경에 배포해 테스트 앱에서 확인한 후 실 서비스에 바로 반영 했습니다. 지금 생각해 보면 얼마나 불편하고 무서운 행동이었는지, 당시에 고객이 많지 않아 실수했을 때 얼마나 다행이었는지 모릅니다.

엔진​

메인 Api는 개발 문서에 적힌 ERD상에 있는 데이터베이스에 있는 내용들을 가져와 보여주거나 상담신청에 대한 플래너 배정 정도를 담당하고 있었습니다.

사실 이 앱의 핵심은 엔진에 있었는데 엔진은 typescript, expressjs로 구성됐습니다. 앱, 웹, 엔진에 공통적으로 보이는 데이터 구조를 만들거나 다루는데 사용하는 라이브러리가 보였습니다. 알고 보니 퇴사한 샘의 개인 npm repository에 있는 라이브러리였습니다.

샘의 개발 구성 방식은 MS사에서 개발하는 방식을 따랐다고 하고 C++ 개발자 출신이라 전형적인 Typscript 개발과 다르게 굉장히 체계적이고 작은 기능에도 규모가 컸습니다. 사용 방법이나 코멘트들도 적혀 있지 않아 아주 많은 것을 상속 받으며 정의되어 있는 기능들이 어떤 기능인지를 찾는데 많은 고생이 필요했습니다.

샘의 개인 라이브러리드들은 모든 소스에서 속속들이 사용하고 있어서 걷어내려면 마치 앱을 새로 만드는 듯한 정성이 필요했습니다.

엔진은 보험 데이터를 통해 도출된 머신러닝 데이터와 고객의 보험 데이터 간의 수식을 통해 점수를 산출하는 진단과 수 많은 보험 데이터들 간 조합 알고리즘을 통해 도출되는 최적의 보험 상품 조합을 도출하는 추천 기능을 가지고 있었습니다.

앱의 가장 중요한 기능 2가지를 담고 있는 회사의 코어 자산이었습니다. 엔진 소스는 백엔드랑은 비교도 안되게 복잡하게 구성되어 있었고 엔진 기능 관련 api를 제공하는 서버와 코어 기능이 담긴 라이브러리, 그리고 보험 데이터를 조작하고 관리하는 펙토리 기능 이렇게 3가지 소스가 나눠져 있었는데 제대로 이해하기까지 3개월 정도 시간을 쏟았던 기억이 납니다.

클라우드​

클라우드 구성은 AWS에 2계정으로 관리되고 있었습니다. 첫 번째 계정은 메인 api와 웹뷰, 데이터베이스 서버 등이 구성되어 있었고 두 번째 계정은 엔진이 구성되어 있었습니다. 구성된 상태는 ELB에 ACM을 연결해 ssl을 연결했고 EC2들이 ELB에 연결되어 있었습니다.

EC2에서 서버는 http로 동작해도 ELB에 연결되기 때문에 따로 https 설정을 할 필요는 없었습니다. 도메인은 이미 구매되어 있어서 route53 서비스를 통해 연결되어 있었습니다.

AWS의 서버구성 방식은 간단히 구성되어 있었고 걱정했던 것보다 조작하거나 구성하기 쉬웠습니다. 엔진의 경우 Api를 통해 업데이트하도록 설계되어 특정 패스로 api 요청하면 워커들을 하나씩 업데이트 해가며 코드 레벨에서 blue-green(무중단 배포)이 실행됐습니다. 덕분에 배포 시 편하게 api 요청만 하면 끝이었습니다.

하지만 메인 api와 웹뷰의 배포 방법은 굉장히 불편했습니다. 프론트엔드 소스의 개발을 마무리 한 후 라이브러리로 빌드해 npm에 배포한 뒤 이를 Laravel 백엔드에서 설치해 폴더별로 path를 지정하여 웹에 포팅했습니다.

그렇게 백엔드 소스와 한 몸으로 만든 뒤 사설 깃랩 서버에 올리고 깃랩 내에 설정해둔 대로 로컬에서 명령을 날리면 vagrant와 virtualbox가 실행되면서 이미지를 만들고 이 이미지를 운영중인 서버로 설치해 배포되게 됩니다. 과정을 알아내는 것도 힘든 과정이었지만 오류도 잦았고 해결을 위해 많은 시간을 소비했던 기억이 납니다.

지금 생각해 보면 Docker와 ECR을 활용했다면 보다 빠르고 효율적으로 관리하면서 고생을 덜 수 있었을텐데 그 때의 나에게 돌아가 알려주고 싶습니다.

문서 작성​

회사에 개발자로서 혼자 남아 있는 상태에서 경영진은 개발 산출물들에 대한 정보를 지속적으로 나에게 요구하고 있었습니다. 이미 퇴사한 개발자들이 정상적으로 뒀는지 염려가 많이 됐던 모양입니다.

개발 소스들과 많은 서비스 계정들, erd, 클라우드 구성 등이 대부분 문서로 되어 있지 않았고 제대로 되어 있지 않은 것들이 많았습니다. 이전에 남겨놓은 문서들은 대부분 경영진에게 그럴싸하게 보이기 위해 브라이언이 만들었던 as is, to be 문서 였고 심지어 틀린 내용도 수두룩했습니다.

유지보수를 하기에도 어차피 한번 정리가 필요했기 때문에 이왕 정리하는 김에 제대로 해서 다음 개발자들도 적응하기 좋도록 체계적으로 정리하고 싶어졌습니다. erd 구성부터 백엔드로직, api 문서 등 개발에 대한 정리를 시작했고 문서화해 나갔습니다. 소스와 구성들을 보면서 사용 중인 계정들을 더 알게 되고 사용 중인 계정과 패스워드들을 문서에 작성해 경영진들과 에릭에게 공유했습니다.

그리고 찰스가 이해하기 좋도록 클라우드 구성, 서비스 플로우, 배포 프로세스 등을 도식화 해 설명했고 이를 활용해 경영진들에게 현재의 산출물들의 체계를 제대로 알릴 수 있었습니다.

이후로도 정리하는 습관이 생겨 이슈 사항에 대한 리포트하는 법부터 설계 시작 단계부터 마무리까지의 과정들까지 정리했습니다. 이 정리들은 추후에 많은 공통 이슈들을 해결할 때 자주 찾아보며 사용하게 됐습니다.

신규 프로젝트​

1년 치 요구사항​

기존에 있던 개발자들과 CTO 간의 다툼으로 경영진들과 마켓팅 부서에서는 하고 싶은 일들이 넘쳐났지만 진행하지 못했던 수 많은 일들을 진행하고 싶어했습니다. 작은 일들은 유지보수를 하며 조금씩 요구사항들에 맞게 수정했지만 추가 기능들에 대해 요구가 계속 많아졌고 결국 프로젝트가 되어 돌아왔습니다.

그렇게 버겁게 유지보수를 하면서 프로젝트들을 시작하게 됐습니다. 회사는 기본적으로 인슈어테크 회사이고 결국 목적은 상담을 많이 유도해서 고객 계약을 따내는 것인데, 설계사분들은 모두 자영업이고 회사가 아닌 개인적으로 아는 고객들이 많았는데 이들의 상담과 계약 건도 앱과 연동해 진행하길 원했습니다.

그렇게 플래너분들의 개인 고객들을 연결해 플래너 개인 고객들에 대한 기능을 넣어주기 위한 앱 내, 관리자 앱의 기능을 추가해 주는 것이 필요했습니다.

또 필요한 기능으로 청구 기능이 있었는데, 당시에 청구는 실손 관련 간편 청구만 구현 가능했고 대부분의 인슈어 테크앱에서 이미 구현해 놓은 기능이었습니다. 우리도 기본적인 청구 기능을 구현하겠지만 늦게 출시하는 만큼 다른 앱들과는 다른 포인트가 필요했습니다.

연구 끝에 청구하려는 내용에 해당하는 청구 관련 분쟁조정사례를 보여 주고 청구 시 참조할 수 있도록 해주는 간편한 청구에 심화적인 내용을 정보로 주어 조금 어려운 청구 기능의 경우 플래너들이 직접 청구를 돕거나 이것을 기회로 보험 상담을 진행할 수 있게 하는 기능이었습니다.

에릭과 함께 기획이 끝났고 앱과 웹, 백엔드에 적용해야 할 아이템들을 검토해 기간을 산출했고 이를 통해 계획을 세워 프로젝트의 가닥이 잡혔습니다.

이 외에도 앱 내 게시판, 공지 기능 추가와 에디터 적용 등 많은 기능 추가들이 있었지만 회사의 개발자는 혼자였기 때문에 업무 배정, 협의에 대한 시간 소요 없이 빠르게 처리할 수 있어 모든 일들이 빠르게 테스트까지 마무리 되고 앱 심사까지 성공적으로 런칭할 수 있었습니다.

신규 엔진 개발​

회사에서 가장 중요한 코어 기능을 엔진 서버에 구현해 뒀는데 핵심 기능으로 보험 진단과 추천이 있었습니다. 하지만 기존에 만들어 놓은 엔진은 백엔드와 너무 의존적인 관계여서 독립적으로 서비스할 수 없었습니다.

불필요한 동작, 재동작들이 너무 많아 성능이 좋지 않았고 이로 인해 보험 진단 한번에 1분이 넘는 시간이 걸릴 때도 있었습니다. 심지어 ERD를 공유하면 복잡한 DB 구조로 인해 신규 인력들이 적응하는데 이것이 허들이 될 정도였습니다. 게다가 구조 상 모두 엮여 동작해 엔진을 조금 수정하면 서비스 전체에 영향을 끼칠 정도였습니다.

여러 불만들이 취합되어 결국 새로운 엔진을 만들게 결정이 됩니다. 보험에 대해 잘 알지 못했던 당시에 나는 보험을 진단하는 과정에 대해 온전히 이해하지 않고 코드상으로만 이해하고 있었습니다. 다행히 동료 중 에릭이라는 보험 설계사 출신 데이터 기획자 분이 있어 같이 엔진을 설계해 나갈 수 있었습니다.

우선 서비스에서 쌓여 있던 수 많은 진단 정보와 신용정보원 데이터 등을 취합했고 그 데이터들을 가공해 데이터 포맷과 피쳐들을 일원화했습니다. 데이터를 분석하면서 플래너들, 에릭과 상의해 보험의 여러 특성들을 도출했고 이를 통해 5가지 특성을 이용해 점수화하자는 기획이 섰습니다. 수동과 자동을 섞어가며 플래너 분들과 함께 데이터를 라벨링하기 시작했습니다.

라벨링 된 데이터를 통해 머신러닝 모델을 만들고 계속된 검증과 성능을 높이기 위한 작업을 진행했습니다. 결국 정확도 높고 원하는 결과를 도출하는 모델을 만들어 낼 수 있었습니다. 그렇게 엔진 코어 기능 중 하나인 진단 기능을 완성했고 그 외 추가적인 요구사항들인 관련 집계 기능, 차트 데이터 등을 완성해 가며 보험 진단을 마무리 했습니다.

보험 추천은 보험의 여러 특성들을 토대로 최적의 보험 패캐지를 찾아내는데 집중했습니다. 현재 판매중인 보험사들의 상품 정보를 모아서 그 데이터를 통해 고객인 원하는 보장 및 보장금액을 가진 최저가의 보험 패키지를 만들기 위해 bin packing 등의 알고리즘을 도입해 일반적인 방식으로는 감당할 수 없는 경우의 수를 쪼개 프로그램으로 감당할 수 있게 만들었습니다.

그렇게 보험 상품의 조합으로 고객의 요구 사항에 맞는 보험 패키지를 최저가로 찾아주는 보험 추천 기능을 완성했고 그 외에 원하는 보험사로 추천을 받는 기능, 신뢰도 있는 보험사로 추천받는 기능 등의 커스텀 동작들을 붙여 또 하나의 코어 기능을 완성했습니다.

보험 진단과 추천은 기존 성능 대비 40배 가량 성능이 빨라졌고 백엔드와의 의존성이 제거되어 독립 동작할 수 있어 나중에 BtoB 서비스로 보험 솔루션 SaaS의 개발 기반이 됩니다.

Bussiness To Bussiness​

앱이 성장하고 회사가 더 조금씩 알려지면서 보험 진단, 보험 추천 등의 기능을 인슈어 테크 회사들이 도입하고 싶어했습니다. 보험사들과 도입을 위한 회의를 진행하고 보험사에 맞는 내부망 서버 구성과 엔진의 커스터마이징 등 많은 부분을 협의해 나갔습니다.

처음 도입한 보험사는 보안을 이유로 내부망에 설치해 운영하고 싶어했습니다. 나중에 실제 이유는 서비스가 내부에 설치되어 있으면 이를 분석해 보험사 내에 자산화하고 싶은 이유였던 것을 알게 됐습니다. 그래서 그런지 유지보수 계약도 하지 않았습니다.

하지만 설치형 엔진은 기술 유출을 막기 위해 난독화, 암호화를 이중으로 하고 이것을 바이너리 파일로 제공했기 때문에 보험사에서 코드를 하나도 확인할 수 없어 결국 자산화는 실패하고 보인들의 입맛으로 커스터마이징하는 것도 할 수 없어 결국 유지보수 계약도 하게 됩니다.

시간이 많이 흐른 뒤에는 신용정보원 개편이나 여러 보험적 이슈들에 대해 직접 가서 설치해야 하기 때문에 빠른 대응을 할 수 없었기에 SaaS 형태의 엔진으로 계약을 변경해 건당 사용 요금을 받는 방식으로 변경해 사용하게 됩니다.

첫 도입한 회사에서 정상적으로 엔진이 운영되면서 타 회사들에도 신뢰가 생겼는지 여러 보험사들과 협의를 거쳐 진행했고 한번에 3개의 보험사와 계약을 하는 등 빠르게 발전해 갔습니다. 각 보험사들마다 요구사항에 맞는 새로운 서비스들(약관 조회서비스, 약관 분석 서비스 등...)을 요청해 요청한 내용들도 바로 개발해 제공했고 그렇게 BtoB 아이템들을 늘려나갈 수 있었습니다.

마이데이터​

어느 날 국가에서 데이터를 개방한다는 발표가 있었고 마이데이터를 통해 기존의 신용정보원 크롤링 데이터를 좀 더 체계화 된 데이터로 받을 수 있는 기대감이 생겼습니다. 얼마 안 지나서 경영진은 마이데이터를 해야 인슈어 테크 회사로서 살아남을 수 있다고 이건 숙명적 과정이라는 결론을 내렸습니다.

마이데이터에 통과되기 위해 공기업 격인 코스콤 클라우드로의 클라우드 구성 이전과 여러 보안 사항들, 그리고 옮기는 김에 하자고 하는 것들이 많아졌습니다.

당시에는 개발자가 3명이었는데 1명은 입사한지 1개월이 됐고 프론트엔드 개발자였는데 html, css만 다둘 줄 아는 분이어서 react를 공부하고 있었고 진행 인원에서 제외되게 됩니다. 1명 더 있던 CTO와 일을 진행하게 됩니다.

CTO는 프론트엔드 개발자였고 node 외에 언어를 다뤄 본적이 없었습니다. 그래서 당시 백엔드 소스만 php로 되어 있는 것을 눈에 가시로 여겼기 때문에 이것을 typescript로 변경하자고 제안했습니다. (CTO는 입사 후 3개월 동안 ERD도 개발 문서도 그 어떤 것도 제대로 보지 않고 원 페이지 웹싸이트를 새로 개발하며 자랑을 하던 분이었습니다.)

달갑지는 않았습니다. CTO는 현재의 구성을 전혀 고려하지도 않고 단순히 기술 스택만 이야기하며 이걸로 바꾸자가 전부였기 때문입니다. 심지어 백엔드만 변경하기로 했는데 추가 기능, 성능 향상이 있는 것도 아니고 언어만 바꿀 이유가 있나 싶었습니다.

하지만 CTO가 경영진과의 소통 참구를 본인을 통해서만 하도록 막았기 때문에 경영진을 설득해 본인이 원하는 스택으로 내가 개발해 줘야 하는 마이그레이션이 시작됐습니다.

서버의 코드들을 꼼꼼히 읽어 나가면서 기능들 간의 연결 관계와 의미들을 파악하고 필요한 기능을 구현하기 위한 서비스들과 앱과 웹에서 사용할 api 로직들을 설계할 수 있었습니다.

새로 구현된 api들과 프론트엔드, 앱 간에 연결을 한번 더 검토하고 효율적인 방향을 모색해 프론트엔드/앱과 백엔드를 양방향으로 수정해 나갔습니다. 그렇게 개발 소스를 수정하는 동안 CTO는 클라우드 구성을 했었는데 마이그레이션 개발과 DB 마이그레이션이 2개월만에 완료 됐지만 4개월 동안 클라우드 구성만 했고 2개월 간은 클라우드 구성 마저 지원해야 했습니다.

마이데이터 보안 구성을 위한 회의에서 CTO는 자신이 보안이 아주 높은 중국계 코인 회사에서 일 했었다며 자신의 의견을 계속 관철하고 구성을 주도 했는데 CTO의 말대로 구성을 완료하고 마이데이터 심사에서 여러 번 떨어지면서 실제 마이데이터 사업자를 취득하는데 기간만으로만 1년 정도 걸렸습니다.

마이그레이션​

마이데이터를 위해 코스콤으로 망을 이동이 끝나자 앱의 UI를 개선을 진행하자는 의견이 점점 커져 갔습니다. 이에 CTO는 앱 소스만 변경하지 말고 이참에 기존 레거시들을 모두 버리고 새로 만들기를 원했습니다.

이미 코스콤을 위해 마이그레이션 비슷한 경험을 해 봤기 때문에 마이그레이션 하기 위해서 해야 할 것들을 리스팅했습니다. 우선 기존의 ERD구성과 각 api 별 로직들과 영향관계들을 파악하고 프론트엔드에서의 데이터 흐름을 우선적으로 파악한 뒤 신규 ERD 구성과 api 로직들을 설계하고 웹, 앱에서 어떻게 보여줄지에 따라 backend를 수정 개발하는 것이 필요하다고 제안했습니다.

하지만 CTO는 기존 레거시를 6개월 동안 보지 않았기 때문에 레거시와 상관없이 db 마이그레이션 계획도 없이 기획자분과 함께 새로운 앱을 구성하기로 마음 먹고 그렇게 그냥 시작이 됐습니다.

더 많은 설득을 하고 싶었지만 당시 신규 엔진을 연구하며 개발하고 있었기 때문에 여유도 없고 계속 말해도 듣지를 않으니 관여하기가 참 난감한 상황이었습니다. 3개월 뒤 서비스 개발의 진도는 프론트엔드, 앱만 완료되어 가고 있었고 데이터베이스와 백엔드는 기획도 설계도 되어 있지 않았다.

그렇게 무계획으로 시작된 프로젝트는 3개월이라는 CTO의 근자감 일정 안에 끝나지 않았고, CTO의 주도 하에 개발자 3명이 같이 붙어 강행된 개발이 언제 끝날지 모르는 상황이었습니다. 그런 가운데 투자자들에게 신규 앱 런칭을 3개월 뒤로 공표한 비지니스 담당자들은 난감함에 점점 개발쪽에 압박이 높아져 갔습니다.

엔진 개발을 맡고 있던 저는 일정을 맞췄지만 플랫폼 개발 쪽은 점점 시간이 지체되어 갔습니다. 도와주며 빠르게 진행하고 싶었지만 CTO가 코드를 볼 수 있는 권한을 각 부서별로 막았기 때문에 엔진 개발하는 사람은 엔진만 볼 수 있는 상황이었습니다.

그렇게 1년이 지나 앱 런칭 테스트를 진행했고 테스트 이후 2개월 뒤인 1년 2개월 만에 앱이 런칭되면서 고비를 한번 넘게 됩니다. 이 기간 동안 많은 이슈들이 발생하고 경영진과 마찰이 빚어지면서 CTO와 CTO 인맥으로 들어온 개발자들이 프로젝트 후 일을 아예 안 하면서 이상한 행동들을 하다가 얼마 지나지 않아 인수인계 없이 CTO와 함께 다 같이 퇴사했습니다.

그 후...​

CTO와 CTO 인맥들이 모두 퇴사하는 동안 가장 먼저 나간 CTO 이후 새로운 CTO도 여러번 입사하고 퇴사했습니다. 비지니스 요구사항과 CTO의 억지로 막 만들어져 있고 많은 것이 소실된 현재의 상태를 제대로 고쳐나갈 사람이 등장하지 않았습니다. 하지만 시간이 지나고 현 상황을 받아들이고 같이 헤쳐나갈 새로운 개발자들이 체워졌고 점점 체계가 잡혀가면서 업무를 서로 덜어가며 발전해 나갔습니다.

초기 스타트업이었던 이 회사가 다니는 동안 220억 이상 규모의 투자를 유치해 Series C 스타트업이 됐고 이제는 상장을 준비하고 있습니다.

피플팀도 생겨서 직원들의 복지를 고민하며 늘려 가고 카페테리아까지 있어 공짜 음료도 맛 보고 재택 근무도 주 2일을 할 수 있게 분위기가 조성되기 시작했습니다. 기획팀의 숫자도 늘어나고 마켓팅, 브랜딩 등 회사가 더 성장해 나가기 시작했습니다.

나도 회사의 가치를 성장시키기 많은 문제들을 해결하고 신규 BtoB 사업들을 성공적으로 완수해 43개 보험사에서 모두 사용할 수 있는 솔루션을 SaaS로 제공하고 핵심 업무들을 도맡아 수행하며 보험에 대해 끊임없이 스터디했습니다. 신규 인력들이 들어오면서 그 동안 사내에 문서화 해 놓은 자료들을 통해 교육 자료로 사용하고 직접 교육을 하기도 하는 뿌듯한 일도 했습니다.

SaaS를 통한 서비스를 모두 총괄하고 있고 주력 앱인 보닥의 핵심인 보험 엔진 개발 또한 총괄 했습니다. 또한 신규 서비스 개발을 위해 데이터 가공, 분석, 기획 등의 작업을 진행하며 팀원들과 함께 새로운 가치를 발굴하며 새로운 서비스도 찾아나갔습니다.

이직 결심​

회사의 여러 요청으로 여러 차례 CTO 포지션을 제안 받았지만 관리 보다는 엔진 개발에 좀 더 몰두하고 싶어 이를 거절했는데, 다른 오랜 연차의 CTO가 입사했습니다. 이 분은 이미 개발자가 많아 직접 개발하진 않았고 개발 상황을 경영진에게 설명하는 중간자 역활을 했는데 회사에서 가장 오래된 개발자이고 유일한 초기 맴버인 내가 눈에 가시였던 것 같습니다.

아기가 태어나면서 육아를 좀 더 도와줄 수 있도록 풀재택 근무가 필요해졌습니다. 회사에서는 최대 가능일을 저를 위해 2일로 늘려주었지만 이미 엔진과 SaaS 쪽은 풀재택으로도 일을 처리할 수 있는 상황을 어필하자 경영진 쪽에서 이를 허락해 줬습니다.

그러나 개발자들이 차별을 느낀다며 다시 거절됐고 결국 풀재택이 가능한 곳을 찾아보게 됩니다. 나중에 알게된 사실이지만 개발팀원들과 서로 편히 이야기하며 모두 아기 때문에 재택하는 것을 지지해주던 상황이었는데 CTO로부터 그런 이야기가 나오며 거절된 것을 알았습니다.

그렇게 최선을 다해 오던 회사를 나오게 됩니다.

데이터 분석 직무로 이직했던 극 초기 스타트업에서의 이야기입니다.

지원​

IT 구인난이었는지 사람인에 이력서 업데이트만 했는데도 아주 많이 연락이 왔습니다. 얼마 되지 않는 경력인데도 실무를 해 본 신입이라는 것이 좋은 타이틀이 된 것 같습니다.

하지만 직무는 거의 프론트엔드였습니다. 이전 회사에 지원했던 것처럼 일단 회사에 들어가고 직무를 변경해 보자라는 생각은 이전 회사의 밀당 경험 덕분에 일찍이 포기했습니다. 그래서 이번에는 확실히 데이터 분석 직무에 지원했습니다.

검색하다 보니 데이터 분석 직무는 여전히 석사 이상, 캐글 대회 수상자 등 진입장벽이 높았습니다. 오랜 검색 끝에 경력이 적어도 데이터분석 직무를 시켜주는 스타트업을 찾았습니다. 워낙 희귀했기 때문에 당장 그곳에 지원했습니다.

헬스케어 분야의 빅데이터를 통해 서비스를 하고자 하는 초기 스타트업이었습니다. 휴가를 내고 면접을 보러 갔는데 대표님이 생각보다 젋어 보이시는 여자 대표님이셨습니다.

대표님은 데이터 분석 직무로 입사하지만 스타트업 특성상 다른 개발 업무들도 같이 수행할 수 있다는 이야기를 했습니다. 스타트업의 구조상 인력이 부족하면 자금이 부족할 때 인력으로 막아야 하는 것은 이전 회사에서 경험해 봤으니 그 정도는 각오가 되어 있었습니다.

그렇게 순조롭게 면접을 마무리 짓고 연락을 기다렸습니다. 며칠 뒤 입사해달라는 연락이 왔고 다니는 회사에 바로 알린 뒤 2주 간의 인수인계를 거치고 입사하게 됐습니다.

입사일​

입사 당일, 동탄에서 판교 직행 버스로 출근하다가 미금으로 출근하려니 버스를 갈아타고 시간도 오래 걸려서 첫 날이기도 하고 아주 일찍 출근했습니다. 사무실에는 아무도 없었고 당연히 문도 열리지 않았습니다.

사무실 앞에서 노래 들으면서 1시간 가까이 대기했던 기억이 납니다. 대기하다 보니 9시 10분 쯤 되서 어떤 남자분이 걸어왔는데 문 앞에 서 있으시길래 물었더니 그 분도 오늘이 입사일이었습니다.(앞으로 영님이라고 합니다)

그러고 조금 시간이 더 지나 9시 30분 쯤 되자 대표님과 함께 남자 2명이 같이 나타났습니다. 남자 한 분은 나이가 좀 있어 보였고 한 분은 어려 보였는데 남자 분의 부하 직원처럼 나이 있으신 분이 지시를 했습니다.

사무실 문을 얼른 열어주더니 먼저 비밀번호를 알려줄 걸 그랬다며 미안해 하셨고 컴퓨터 부품들을 들고 와서 먼저 왔던 영님과 짐 옮기는 걸 도와 셋팅을 시작 했습니다. 알고 보니 3명 모두 3명이 팀으로 구성해서 이제 시작하는 동기들이기 때문에 입사일을 맞췄다고 합니다.

나이 있으셨던 남자 분은 대표님의 남편분(앞으로 교수님이라고 함)이셨고 그 어린 남자 분은 교수님의 제자(앞으로 석사생님이라고 함)였습니다. 영님과 석사생님과 나, 교수님, 대표님은 회의를 시작했고 회사의 연혁을 상세히 말해주셨습니다.

대표님은 원래 브랜딩 분야에서 경력이 많고 그 분야의 강의로도 꽤 높은 수입을 얻고 계시다가 교수님이 하고 싶은 사업이 있다며 대표님 이름을 빌려서 시작한 사업이 현재의 사업라는 것. 그 동안 투자 유치를 하고 인력을 뽑아 개발 중 수 차례 실패했고 이번에 다시 투자 유치에 성공해 이번엔 제대로 진행하려고 하고 기획은 거의 완성단계에 있다고 했습니다.

완성 단계에 있는데 초기 인원이 지금 입사한다는 것이 뭔가 이상했습니다. 역시나 불안한 느낌은 틀리지 않았고 실제로는 기획서, 요구사항, 그 어떤 것도 없는 그냥 대화하면서 이런 앱을 만들자 정도의 기획이 되어 있었습니다.

데이터 분석 직무를 하려고 들어왔으니 참아보자 생각했지만, 면접 당시 곧 출시할 듯한 늬앙스로 말씀하셔서 기대했는데 실망스러웠습니다. 역시 쉽게 하고 싶은 일을 할 수는 없는건가 생각하며 앱을 런칭해 데이터를 모으면 데이터를 다루는 업무를 해볼 수 있어! 라며 마음을 다 잡았습니다.

그렇게 가져온 노트북을 셋팅하며 하루가 지나갔고 첫 날이기 때문에 저녁 때 고기를 같이 먹자며 회식을 했습니다. 고기를 조금 먹고 내일부터 다 같이 열심히 해보자고 기약하며 하루가 끝났습니다.

프로토타입​

다음날 아침 교수님이 또 나타났습니다. 아침 회의가 시작됐고 원하는 앱에 대해 이야기하고 얼마나 걸릴 것 같냐고 묻더니 우물쭈물 생각하던 사이 1.5주만에 프로토타입을 만들어 달라고 했습니다. 기능만 간단하게 돌아가는 UI를 고려하지 않아도 되는 앱과, 웹 페이지를 만들어 달라고 하며 상황이 밀어부쳐졌습니다.

간단하게 개발 기획을 같이 하고 영님과 석사생님, 그리고 나는 역할 분담을 해야 했습니다. 영님과 석사생님은 네이티브로 안드로이드 앱 개발을 하기로 했고 나는 백엔드, 프론트엔드로 웹 개발과 앱에서 사용할 서버도 백엔드에 같이 만들기로 했습니다.

데모앱에서 시작해 나중에 실제 서비스로 발전할 계획이어서 인력이 적은 지금 ios, aos 모두 가능한 react native로 하는 것을 제안했지만 두 분은 전혀 경험이 없다며 거절하고 안드로이드 스튜디오를 활용해 UI를 조금씩 만들어 나갔습니다.

우선적으로 앱에서 사용할 백엔드 개발 시 참고할 api 규격서를 작성해 앱 개발 시 더미데이터로 참고해 만들도록 문서를 전달했습니다. 그런 뒤 expressjs 를 활용해 api 규격서 대로 백엔드를 개발하기 시작했습니다.

프론트엔드는 UI 컴포넌트를 직접 css로 다 만들지 않고 이전에 서비스에 사용했던 mui를 활용해 개발했습니다. 개발에 속도가 붙어 갔고 개발 기한은 출근일수로 8일 안에 만들어야 했기 때문에 매일 9 to 9으로 일하며 열심히 만들었습니다.

그러다 보니 화, 수, 목, 금, 월 5일 만에 개발을 완료할 수 있었습니다. 개발이 완료되고 수요일에 있을 개발 산출물 점검 때 발표할 내용을 만들면서 외부에서 시연할 때 프론트엔드와, 백엔드, 데이터베이스 서버를 클라우드에 구성하는 방법들을 검색해 봤습니다. 어느덧 수요일이 왔고 발표의 시간이 됐습니다.

회의가 시작되고 웹 개발 산출물에 대해 먼저 발표가 진행됐습니다. 간단하게 ERD 구성을 설명했고 구축된 데이터베이스를 보여준 뒤 시연이 시작됐습니다. 회원가입, 로그인은 bycript, crpyto(AES-256-CBC), jwt를 활용해 암호화 및 토큰 관리를 구현해 웹에서 회원가입, 로그인 시의 동작을 데이터베이스 상의 변화와 함께 시연했습니다.

건강검진 pdf 파일을 웹에서 업로드하면 자동으로 데이터를 파싱한다는 모델이었는데 파싱 모델은 아직 개발되지 않았기 때문에 예시로 만들어 놓은 더미 데이터를 데이터베이스에 넣어 두었습니다. 더미데이터와 교수님이 가져온 10만명의 건강검진 데이터를 결합해 통계 시각화를 만들었고 이를 대시보드 형태로 보여주고, 업로드한 pdf파일 내용을 웹상에서 볼 수 있도록 했습니다.

이제 앱을 시연할 차례였습니다. 앱에서는 시연 시 잘 보이지 않으니 건강검진 사진을 찍어 업로드하는 부분이 구현되어 있으면 됐습니다.

하지만 버튼들이 한 줄로 나열되어 있는데 버튼 글자도 아직 test1, test2, test3, ... 식으로 되어 있었는데 test1을 눌러도 다른 버튼을 눌러도 화면 전환만 되고 기대하는 동작이 일어나지 않았습니다. 회의실의 분위기는 급격히 얼어붙었고 교수님과 대표님은 그 동안 뭘 한 거냐며 급 화를 냈고 실제 투자 시연일은 다음주라며 이번주 안에 어떻게든 마무리 지으라고 했습니다.

그렇게 회의가 끝나고 영님과 석사생님은 멍한 상태가 되었고 이미 웹 개발과 데이터베이스 서버를 클라우드에 구성했기 때문에 앱 개발에도 참여하게 됐습니다. 사실 우리 셋 중 누구도 앱을 개발해 본 사람은 없었고 그나마 react랑 비슷하다는 react native로 개발해 보자는 의견이 잘 먹혀서 금요일까지 혼자 앱 개발을 한 뒤 개발한 내용에 대해 두 분에게 설명했습니다.

react native로 갤러리 사진이나 카메라 사진을 업로드하는 예제를 인터넷에서 찾아 ui를 간단히 구성한 뒤 api를 통해 건강검진 데이터를 데이터베이스화 했다는 요청을 만들어 적당히 완성할 수 있었습니다.

그렇게 투자 유치를 위해 사용할 프로토타입 앱을 완성했고 대표님이 스피치를 잘 하셨는지 투자를 받으셨고 디자이너, 카피라이터, 의료데이터 전문가 등 많은 분들이 채용되기 시작했습니다.

퇴사 레이스​

석사생​

프로토타입을 완성하고 시연이 끝난 후 대표님은 앱 개발했던 두 분에게 탐탁치 않았는지 강한 어조로 변하셨습니다. 그 중에서도 석사생님에게 그 압박이 좀 더 강했는데 야근하지 않고 집에 가려 하면 30분 정도 일 제대로 했는지 체크하기도 하고, 일에 대한 컨펌을 할 때는 할 줄 아는 것이 없다며 월급을 줘야 하는지 고민이라는 말도 해가며 폭언을 이어갔습니다.

내가 들리던 몇몇 말들 외에도 점심 식사 때 석사생님에게 들은 많은 폭언들은 심각했고, 석사생이면서 알바로 업무를 하던 중이었는데, 결국 석사생님은 얼마 지나지 않아 다시 대학원으로 돌아갔습니다.

디자이너​

대표님이 가르치던 브랜딩/디자인 강의의 수강생 중 현재 부산에서 디자이너로 일하고 있던 분을 스카웃하셨습니다. 디자이너는 대표님 강의를 들을 때 감명 깊었는지 대표님을 존경하고 있었습니다. 그래서 부산에서 분당으로 자취방까지 얻어 다니던 직장도 퇴사하며 이직을 한 것입니다.

하지만 기획자가 없이 디자이너만 있다 보니 기획, 디자인을 모두 담당해야 했는데 교수님, 대표님을 직접적으로 컨택하며 일을 해야 했습니다. 문제는 교수님이나 대표님 모두 개발에 필요한 기획에 대해 무지한데 대표님이 디자인에 감각이 있다 보니 꼼꼼히 디자인에 대해 지적들을 하다가 결국 화를 내기 시작했습니다.

얼마 지나지 않아 대표님은 다시 월급 루팡이라는 식의 발언을 조금씩 하며 디자이너에게 연봉을 낮춰 계약하려 했고 결국 디자이너는 자취방 계약 기간을 체우지 못하고 1달 만에 다시 부산으로 내려갔습니다.

카피라이터, 의료데이터 전문가​

디자이너가 나갈 때 쯤 의료데이터 전문가와 카피라이터가 들어왔는데, 의료데이터 전문가는 간호사 출신으로 의료 코드를 넣는 등의 행정일을 도맡아 오다가 의료데이터를 다루는데 익숙하고 현재는 사업을 하나 런칭 준비중인 어리고 열정 넘치는 분이었습니다.

카피라이터는 다른 직종에 있다가 블로그를 쓰면서 카피라이터를 하게 됐는데, 신입이어서 이 회사에서 많은 일을 하고 싶어했습니다.

의료데이터 전문가는 의료코드 정리 업무부터 맡았고 그 코드들에 대한 소비자를 위한 설명을 달아주는 일을 했는데 생각한 것보다 빠르게 적응하며 일을 잘 해 나갔습니다. 하지만 카피라이터는 정량적인 일이 아닌 느낌있는 글을 써야 했기에 대표와 큰 마찰을 빚었습니다.

대표와 본인의 스타일이 전혀 안 맞는다며 입사 후 1주일도 되지 않아 퇴사를 결정했고 퇴사 이유를 대표한테 분명히 말하고 퇴사했습니다. 의료데이터 전문가도 대표의 업무 중 눈치주는 것과 디자이너, 카피라이터 등 여러 사람들이 퇴사하는 것을 지켜보더니 사업에 전념하고 싶다며 퇴사했습니다.

나도 언제까지나 무리한 일정과 주변에서 듣는 폭언을 듣고 보다 보니 나에게도 일어날 수 있다는 불안감이 들기 시작했고 마음 속으로 퇴사에 대한 생각이 들기 시작했습니다.

건강검진 데이터 구축 서비스​

입사했다가 금방 사람들이 나가는 뒤숭숭한 분위기 속에서 남아 있는 영님과 나는 회의실에서 교수님과 진지하게 회의를 했습니다.

건강검진을 하면 병원에서 공단으로 결과를 전달하는데 그 때 만들어지는 공단 전송 파일을 pdf로 프린트 할 수 있고 병원과 제휴해 pdf 파일을 제공받으면 이 데이터를 토대로 건강검진 데이터를 얻고 그 데이터로 여러 서비스를 할 수 있으니 일단 병원 별로 다른 pdf 데이터를 자동으로 추출하는 모듈을 만들어 보자고 했습니다.

이미 교수님이 100만 개의 건강검진 pdf 파일을 가지고 있었고 이것을 통해 작업을 시작할 수 있었습니다. pdf 파일에서 text를 추출하는 작업은 처음하는 일이었는데 pdfminer, tesseract, pypdf 등 사용할 수 있는 것이 많았지만, 정확도가 떨어졌습니다. 그래서 결국 다른 빠르고 정확한 방법을 찾아내 대부분의 pdf 파일을 만족하며 txt를 정상적인 순서로 불러오는 것에 성공했습니다.

그 후에는 여러 순서로 되어 있는 txt에서 원하는 txt를 불러오기 위한 수작업들이 오래 지속됐지만 결국은 100만 개 중 80%를 만족시키는 자동화 모듈이 완성했습니다. 나머지 20%도 완전히 정확히 가져오는 것이 아닐 뿐 대부분의 필요한 txt를 추출했습니다.

하지만 다음 pdf 파일에서 어떤 형식이 올 지는 모르는 상황이기 때문에 자동화로 가져오는 txt에 대해 가져올 가능성이 없거나 있는 txt들을 모아 Validation 모듈을 만들었습니다.
이 후에는 자동 추출 후 Validation 에서 실패한 케이스를 모아 웹에서 쉽게 이미지를 조정하며 확인해 수동으로 수정할 수 있는 관리자 싸이트도 만들었습니다.

그렇게 빠르게 2주가 지나갔습니다.

아래는 자세한 과정입니다.

텍스트 추출​

우선 100명 분의 건강검진 데이터를 대상으로 pdf 파일에서 텍스트를 추출해 보고 여러가지 라이브러리, 심지어 유료 라이브러리의 체험판도 이용해 보며 추출을 시도해 봤지만 모두 추출된 텍스트를 사용하기에 적절하지 않아 보였습니다.

여러 시도를 하던 중 크롬에서 pdf 를 열어 전체 선택 후 복사해 txt 파일로 저장해 봤는데 각 필드 결합을 하기에 그나마 가장 적합하게 텍스트가 추출됐습니다. 하지만 방대한 pdf 파일을 모두 열어 수동으로 텍스트를 복사해 파일로 저장하는 것은 불가능하니 이를 자동화 할 방법을 찾았고 pyautogui 를 활용해 자동화하여 텍스트를 추출할 수 있었습니다.

텍스트 분류​

초기 100명 분의 텍스트 추출과 필드 추출을 위한 규칙들은 1000개의 작업부터는 다시 예외들로 가득 찼습니다. 예외들에 대한 대응 코드들과 케이스들을 포괄하기 위한 포괄 코드들을 잘 조합해 가며 개수를 점점 늘려가며 테스트했습니다.

1000개에서 2000개로 2000개에서 3000개로 조금씩 늘려갈수록 점점 예외 케이스가 보이지 않았고 7000개에서 10000개 사이에는 예외가 없어졌습니다. 모든 케이스를 검증해보면 좋겠지만 그렇다면 이 자동화 모델을 만들 이유가 없기에 만 개 까지만 고려해 만들어 보고 가지고 있던 나머지를 함께 테스트 해봤습니다.

10만개 데이터에서 예외없이 정상 동작해 분류됐고 이제 활용할 수준이 됐다는 생각이 들었습니다. 그렇게 100만 개 데이터까지 테스트를 완료할 수 있었습니다.

하지만 역시 pdf 텍스트 추출과 분류 과정은 덕지덕지 붙여서 겨우 완성시킨 모델에 불과했기 때문에 분류 실패 케이스를 확실히 인지하고 이를 수동 수정하여 삽입할 수 있게 하는 것이 더 중요하다 생각했습니다. 그래서 각 필드 값들에 대한 범위를 구해내고 그 범위와 다른 잘못된 값들이 있을 시 인지해 수동 수정할 수 있도록 하는 체계를 만들었습니다.

어드민​

텍스트 분류 모델이 완성 됐으니 이를 활용할 수 있도록 어드민 페이지가 필요했습니다. 로그인, 회원가입 기본 구성에 모델에서 실패 케이스를 pdf 를 보며 수동 분류하는 페이지, 나중에 앱에서 사진 파일 업로드한 걸 보며 수동 입력해 분류하는 페이지를 만들고 자동으로 분류된 데이터를 고객 또는 필드들에 따라 검색하는 페이지 등 많은 기능을 구현했습니다.

병원용 웹​

교수님과 많은 병원들에 제휴하기 위해 병원들의 상황을 확인해 본 적이 있는데 작은 병원들의 대부분은 종이로 환자들의 검진 데이터를 쌓아두고 있었습니다. 환자 관리 또한 서류로 이뤄지고 있었습니다.

큰 병원들은 자체적으로 앱도 만들고 많은 부분이 디지털화 되어 있지만 제휴를 맺기는 힘들고 중소 병원들을 최대한 많이 제휴해 데이터를 모야야 했습니다. 병원 측에 지도 정보, 환자 정보를 디지털화 해서 환자 관리 및 분류 시스템을 만들어 주고 대시보드도 구성해 주는 것을 건강검진 데이터를 정보 제공 동의한 환자에 한 해서 구축해 주는 것을 제안했습니다.

하지만 병원에서는 실질적으로 사용해 보지 않은 서비스에 관심이 없어서 그 의미에 대해 별 생각이 없었습니다. 그것보다 건강검진 결과를 병원에서 제공해 주면 그 결과를 우편으로 발송해 주는 업무를 대행해 줬으면 했습니다.

이건 속도전이라며 교수님은 빠른 개발을 계속 요구했고 영님과 나는 병원용 웹 + 발송 대행 업무를 할 수 있도록 협약을 하나 둘 맺어 가며 개발 기획에 맞춰 더미데이터를 만들고 환자 관리 시스템을 구축하고 있었습니다. 구축하던 중 추가적으로 의사분들이 원하는 다른 요구사항들이 생겨나면서 프로젝트는 점점 방대해져 갔습니다.

개발 협약​

병원용 웹을 개발하면서 의사분들의 요구사항은 점점 더 커져갔고 병원마다 환자들이 정보 제공 동의받는 것부터 데이터를 입력받는 태블릿 앱까지 만들어 납품해 달라는 요구가 있어 이 또한 만들어야 했습니다.

그 와중에 대표님이 런칭하고 싶어서 카피라이터까지 구해서 진행하던 헬스케어 앱 개발을 빨리 진행했으면 좋겠다며 압박이 들어오기 시작했습니다. 영님은 웹, 앱 구성에 대한 경험이 없는 상태로 옆에서 도움이 되지 못했고 더 이상 혼자서 많은 플랫폼을 만드는데는 한계가 있었습니다.

교수님과 대표님의 상상력은 눈덩이처럼 계속 불어났고 이에 대해 계속 호소하는 영님과 나에게 문제를 인식했는지 개발 인원이 부족한 것을 안다며 대표님이 아는 멘토님의 회사에서 개발자, 디자이너, 기획자, PM 등을 지원받는 협약을 하겠다고 했습니다.

멘토 분은 대표님이 투자받기 위해 다니다가 투자 관련 검토를 해주던 분 중 하나인데, 우리와 개발 협약을 하기로 한 회사의 이사였습니다. 그래서 그 회사 근처에서 미팅을 했습니다.

미팅 자리에서 이사분은 협약을 한다면 개발 주도권을 완전히 그쪽에서 가져가고 기존 개발진들도 우리가 시키는 바를 했으면 한다고 말했습니다.

나로서는 이미 친해졌던 분들이 퇴사 압박을 받다가 퇴사하게 되고 업무는 개발에 대한 고려없이 밀려오는 상황에서 이미 퇴사할 마음을 가지고 있었지만 개발 가능 인원이 없는 체로 발 동동거리는 대표님과 교수님을 두고 퇴사하기가 인간적으로 힘들어 버티고 있었던 터였기 때문에 희소식이었습니다. 이 타이밍이 기회라는 생각이 들었습니다.

이직​

퇴사 생각이 있었기 때문에 미리 이력서를 업데이트 했었습니다. 그래서 헤드헌터들로부터 제안을 받는대로 최소 10인은 되는 회사들을 찾으며 좋은 연봉 조건인 회사들로 면접을 다니기 시작했습니다.

그러던 어느 날 의료 빅데이터 포럼을 모두 같이 참관하러 간 날, 적당히 포럼을 듣고 중간에 나와 면접을 보러 갔습니다. 면접을 보러 간 회사에 도착했고 환경이 좋아 보이는 사무실에 들어섰고 회의실로 안내받아 면접이 시작됐습니다.

CTO님과 부대표님이 면접을 봤는데 부대표님이 동년배 같아 보여 말이 잘 통할 것 같았고 CTO님도 굉장히 호의적인 자세로 질문을 하셔서 이야기도 술술 풀렸습니다. 면접은 잘 마무리 된 느낌으로 채용을 진행할 듯 보였는데 전체 경영진과 함께 2차 면접이 있다고 하여 결과를 기다려야 했습니다.

얼마 지나지 않아 면접 일정이 잡혔고 회사에 도착하니 같은 회의장으로 안내 받았습니다. 면접을 보는 경영진분들은 5명 정도 있었고 그 중에 대표님 찰스도 있었습니다.

실무적으로 뭘 해봤는지에 대해 간략히 설명했고 이후로는 일을 진행하는 방식, 문제를 숨기지 않는 성격인지 등의 인성적인 질문들이었는데 나름대로 잘 대답한 듯 했습니다.

좋은 분위기 속에서 찰스가 그래도 경력이 너무 적어 신임하기 힘들다며 갑자기 경력을 이용해 연봉을 낮추려 하셨고 모두가 있는 자리에서 연봉 협상을 시작하셨습니다. 이미 헤드헌터와 이야기한 연봉보다 500만원이나 낮춘 금액으로 협상이 됐고 그렇게 하루 이틀 뒤 전화로 입사일 조정을 하며 입사가 결정됐습니다.

국비지원 교육이 끝나고 새로운 직종으로의 첫 취업을 하고 직장생활을 다시 시작한 이야기입니다.

지원​

국비지원 과정을 수강하던 시절 SI회사 PM으로 이사로 지내시던 분이 본인이 사업을 준비하기 전 개발을 배워 개발자로 전향해 보고 싶어하던 동기분이 있었는데, 수업이 마무리 될 쯤, 그 분이 본인이 점 찍어 둔 학우들에게 이전에 다니던 SI회사로 취업을 권유하셨습니다. 권유를 듣고 지원한 학우들도 꽤 있었는데 수업이 끝나기 전 취업에 대해 알아봤기 때문에 SI회사에 대한 소문을 많이 들어 고민이 됐습니다.

업무 강도가 강하고 시키는대로만 하고 철수해서 시간이 지나도 서비스에 대한 경험이 안 생긴다는 등 많은 글들을 봤습니다. 그래도 무경력에 나이도 있어서 지원을 할까 망설였지만 거절했습니다.

지나고 보니 어느 분야에 있어 첫 회사는 생각보다 의미가 큰 것 같습니다. 직종이라는 대분류를 변경하려고 정말 많은 노력이 필요했던 것처럼 첫 회사는 대분류까지는 아니지만 중분류를 결정하는 일이었습니다.

이 중분류는 앞으로의 커리어를 정할 때 내 경험의 분류를 정하기 때문에 노선을 정하는 역활을 합니다. 그리고 이 중분류 또한 많은 노력을 해야 변경할 수 있다고 생각합니다.

IT회사에 지원하기 위해 전략을 세워 봤습니다. 자기 객관화가 먼저 시작했습니다. 나이도 많고 교육과정 수료한 것이 전부인 나와 나이도 어리고 컴공을 졸업한 학생들과 비교했을 때 실력이 비슷하더라도 나 같으면 어린 친구들을 뽑을 것 같았습니다. 그래서 대기업은 우선 포기했습니다.

대기업을 제외하니 남는 건 중소기업이었는데 IT계열에서는 신생 중소기업들을 스타트업이라고 멋있게 표현하고 있었습니다. 스타트업이라는 단어는 회사 규모가 작지만 자유롭고 빠른 성장을 위해 도전하는 느낌이었습니다. 수평적인 분위기에 스스로 공부하고 도전하는 나의 가치관과도 맞았습니다.

IT회사들은 구로디지털단지, 가산디지털단지, 강남, 판교 등의 지역으로 나뉘어져 있었습니다. 강남이 이미 좀 커진 회사들이 옮겨간 회사들이 많은 것 같았고, 판교가 대기업도 있지만 스타트업들도 많고 전체적인 분위기가 가장 좋아보였습니다. (구로, 가산은 좀 옜날 느낌...)

직무는 데이터분석 직무를 택하고 싶었지만 고학력자와 경력이 많은 사람들만 지원 가능했습니다. 그래서 데이터분석 직무가 있는 회사로 신입이 잘 뽑히는 프론트엔드 직무로 지원하기로 했습니다.

결론은 판교 쪽에 위치한 스타트업 중 분위기가 좋아보이면서 데이터분석 직무를 채용하고 있으면 그 회사의 프론트엔드 직무로 지원을 시작했습니다. 많은 곳에 지원 했지만 연락오는 기업은 없었습니다. 불안감에 SI회사 지원, 이전 직종으로의 복귀 등 많은 가능성들을 염두하며 12월까지 채용이 되지 않으면 안타깝지만 포기하고 이전 직종으로 돌아가기로 결정했습니다.

12월 중순쯤, 하나의 회사에서 면접 연락이 왔고 면접 준비를 열심히 임했습니다.

면접​

건물에 들어가자 공간이 아주 크고 넓었습니다. 휴게실도 크고 티비보며 누워있는 사람들도 있고 독특한 조형물들도 있고 이전에 일하던 장소와는 전혀 다른 자유로운 분위기였습니다. 이게 판교의 IT 회사인가 싶어 신나 있는 상태에서 걷다 보니 여러 회사들이 같은 층에서 여러 시설을 공유하면서 사용하고 있는 것처럼 보였고 마침내 면접 보기로 한 회사를 찾았습니다.

2분의 실무진과 유리로 오픈되어 보이는 회의실 같은 곳에 데려가 면접을 진행했습니다. 우선 간단하게 이 분야의 짧은 이력을 가지고 자기소개를 시작했습니다.

그런 뒤 이전의 경력들을 통해 내가 다른 신입들 보다 좀 더 회사 생활에 익숙하고 잘 할 수 있음을 어필했습니다. 또한 지금까지 뭘 공부해 왔고 무엇을 할 수 있는지, 개발해 본 경험은 무엇이 있는지 아주 상세히 설명했습니다.

내 이야기가 끝나고 면접을 보는 선임분들은 입사하고 개발 시 사용하게 될 개발 스택에 대한 설명을 미리 해줬습니다. 그리고 바로 입사에 동의하는 듯 말하며 대표님 면접만 잘 마무리되면 입사를 결정하겠다고 말했습니다.

서로 영어이름으로 대화하던 선임들이 많이 이질적으로 보였지만 대표님이 많이 꼰대라며 대표님 때문에 지원의사를 취소하지 말하달라며 농담을 하는 것을 보고 여느 회사와 다르지 않다 생각했습니다. 그리고 굉장히 수평적인 회사인 것 같아 인상이 참 좋았습니다.

대표님과의 대화는 참 길었습니다. 처음보는 나에게 본인이 해 보고 싶은 개발 과제에 대해 말했고 개발자로서 어떤 삶을 살아야 하는가에 대해 도덕책에 적혀있을 것처럼 도덕적으로 나를 코칭 했습니다. 좋은 어른이라 그런건가 싶어 열심히 경청했고 그 자세가 맘에 들었는지 대표님은 바로 출근 일정을 물었습니다.

그리고 나서도 계속 대화를 이어갔는데 이번엔 기독교에 대한 이야기를 이어가셨습니다. 종교를 강요하는 듯한 조금 불편한 대화였지만 대표님과의 대화이니 참아냈습니다.

전체 면접만 3시에서 8시가 다 되도록 진행됐고 면접 날이 금요일이었는데 바로 다음주부터 월요일 출근하기로 결정됐습니다.

이 때는 모든 게 좋아 보이던 때라 많은 단서를 놓쳤던 것 같습니다.

첫 날​

환경이 참 좋은 판교에 매일 일하러 간다니! 포기하고 이전 직종으로 돌아가려 했었는데, 결국 IT 쪽으로 취업할 수 있어 기뻤습니다. 일찍 출근해서 대표님과 인사하고 개발에 사용할 아이맥을 받았습니다.

나중에 들은 바로는 면접을 보던 2명의 개발자를 제외하고 병특으로 사람을 뽑아 쓰는 식으로 정규직 채용을 안하고 사람을 돌려서 쓰던 포지션을 이번에 나부터 정규직으로 채용한 케이스였습니다.

당시에는 맥OS를 처음 사용해 봤고 개발 셋팅하는 법도 모르고 트랙패드를 주셔서 트랙패드를 사용하고 하니 참 불편했습니다. 인터넷으로 검색해 가며 iterm2 부터 하나 하나 셋팅해 이쁘게 만들어 가며 뿌듯해 하던 기억이 납니다.

iterm2 셋팅을 하고 면접 당시 들었던 javascript 개발을 위해 첫 출근 전 주말에 공부했던 react 프레임워크에 대한 개발 셋팅을 했습니다. 그렇게 개발 셋팅을 완료하고 꾸준히 개발에 사용하다 보니 이후로는 윈도우로 개발하는게 너무 불편해 맥만 사용하게 됩니다.

일찍 출근해 한참 뒤 다른 선임들이 왔는데 30분 정도 유동적으로 출퇴근 하는 것 같았습니다. 개발 인원은 실무진 면접 때 들어왔던 선임 개발자 2분이 전부였고 영어 이름을 지어오라고 해서 영어 이름을 알렉스로 정해 말씀드리고 기분 좋게 첫 출근을 마쳤습니다.

업무 시작​

javascript 언어는 jquery를 사용할 때 처음 접했고 그마저도 UI 조작용으로만 간단히 배워서 개발할 수 있는 수준이 되지 못했습니다. 면접 때 react로 프론트엔드를 마이그레이션 할 예정임을 들었는데 입사 당시에는 MarionetteJS를 사용하고 있었습니다. 전부 새로운 프레임워크와 언어 환경에 적응해 가며 3일 정도 소스파악을 하고 간단한 유지보수를 했습니다.

그리고 작은 회사이었기 때문에 선임들은 CS업무를 어쩔 수 없이 맡아야 하는데 지금까지는 선임 개발자가 막내였어서 전화를 거의 받았다며 이제 전화를 내가 받아야 한다며 입사한지 얼마 되지 않았는데 고객을 상담하는 전화를 받아야 했습니다. 개발자가 고객의 소리를 듣고 잘못된 부분을 빠르게 수정해 적용할 수 있다는 말을 했는데 옳은 말 같았고 막내기도 했으니까 다음 막내가 오기까지 일을 맡게 됐습니다.

마이그레이션​

열심히 유지보수를 진행하다 보니 어느덧 면접 때 말한 마이그레이션 시기가 다가왔습니다. ReactJS로의 마이그레이션이었습니다. 입사 전부터 유지보수하는 동안에도 꾸준히 공부해 왔기 때문에 class component 방식으로 React 프론트엔드를 구성하는 것이 어렵지 않을 것 같았습니다.

자신했던 것과 달리 실제 개발하면서 부족함을 실감하게 됩니다. react를 사용하는데 보다 효율적으로 코딩을 하기 위한 redux, router 등 여러 다른 라이브러리들이 있었고 처음 보는 것이 react, redux, router, mui 등 라이브러리 지옥에 진입하게 됩니다.

동시에 기본기가 없었던 나에게 javascript, react 개발에 필요한 최적화 패턴들과 원리들을 경험하며 그 동안 공부한 건 아무것도 아니구나 재차 느끼게 됩니다. UI 구성을 위한 라이브러리들과 기본기 공부를 하며 고된 시간이었지만 그래도 결국 기한 내에 마이그레이션을 마무리 할 수 있었습니다.

개발을 진행하고 완료해 가면서 프론트엔드에서 요청한 api가 어떻게 만들어지는지 궁금해 백엔드 코드를 보고 싶었지만 선임 개발자는 코드를 보여주기를 꺼려했습니다.

정부 과제​

입사 전 계획처럼 프론트엔드 개발을 잘 해내고 나면 데이터분석 직무에 관심이 있으니 그 직무도 할 수 있다고 면접에서 대표님이 말씀하셨었기에 호시탐탐 업무를 노리고 있었습니다. 그러던 중 정부 과제로 사업을 따 냈고 그 사업에 데이터 분석 업무가 필요했습니다.

선임 개발자들은 데이터 분석, AI에 관심이 없었기 때문에 이건 내가 맡을 수 있는 업무다 라고 확신하고 있었습니다. 과제는 청각 장애인을 위한 AI를 활용한 SRT 수화 방송 서비스 개발이었습니다.

데이터 수집​

대표님에게 개발에 적극 참여하고 싶은 의사를 밝혔고 대표님도 이 분야가 원래 나의 관심사인 것을 알고 있었고 마이그레이션도 성공적으로 마무리되서 이를 수락했습니다.

처음에 전달 받은 업무는 데이터 분석을 위한 데이터 수집을 하기 위해 음성 수집 기계를 직접 가지고 SRT에 방문해 배선 공사 대표님들과 함께 이동하며 수집 장치를 설치했습니다. 통신 테스트를 통해 수집이 정상적으로 이뤄지는지도 확인하며 데이터가 쌓이는 것을 보며 얼른 쌓여라 생각하며 기대 했습니다.

수 차례 기계 설치를 완료하고 애니메이션 업체와 컨택해 수화 방송에 대한 컨셉을 같이 잡았고 회사에서 음성 분석을 위한 AI 엔진인 에트리 엔진과 슈퍼 컴퓨터도 구매했습니다.

머신러닝과 에트리 엔진 소프트웨어를 사용할 수 있도록 python, tensorflow-gpu 등을 1대의 컴퓨터에 셋팅을 완료 했습니다. 기쁜 마음으로 셋팅을 완료했을 때 갑자기 데이터 분석 직무의 개발자가 신입으로 입사했습니다.

신규 앱 런칭​

신입 데이터 분석가로 입사한 개발자는 아직 대학 졸업도 안한 개발자였고 실제로 개발 자체에 대한 경험도 없는 사람이었습니다. 심지어 국문학과에 부전공으로 데이터 분석을 했기 때문에 데이터 분석 자체에 대한 기술적 역량이 없었지만 그래도 언어적인 이해가 높다 하여 결국 정부 과제에서 물러나게 됩니다.

정부 과제에서 물러나고 나에게 다른 업무가 배정됐는데, 또 새로 들어온 인턴분과 함께 진행하게 됐습니다. 업무는 회사의 코어 기술을 활용할 신규 서비스에 대해 생각해 보고 생각해 본 서비스에 대해 시장조사부터 시작해서 UI설계까지 해 신규 앱을 런칭하는 것이었습니다.

간만에 학원에서 하던 팀 과제를 진행하는 기분이었습니다. 인턴분과 브레인스토밍을 같이 하며 여러 후보군이 나왔고, 그 중 대표님이 선택한 몇 개의 아이디어들에 대해 시장조사를 시작했습니다.

후보군은 아래와 같았습니다.

1. 중고차 시장에서의 고객 관리 서비스
2. 부동산 시장에서의 고객 관리 서비스
3. 동네 마트의 고객 관리 서비스

시장조사​

3개의 주제로 중고차 시장부터 부동산, 마트 등 여러 곳에서 하고자 하는 서비스를 직접 영업점에 가서 설명드리고 그 서비스가 있다면 사용하겠는지와 더 필요한 기능들에 대해 인터뷰를 했습니다. 처음에는 잘 안 받아줬지만 대학생인 척하고 과제 수행중이라고 하자 생각보다 흔쾌히 인터뷰에 임해줬습니다.

여러가지 의견들이 있었습니다. 본인들의 업무가 굉장히 복잡하기 때문에 조금도 고객 관리를 자동화할 수 없을 거라고 업무를 설명해주지 않는 분들도 많았고 앱의 필요성을 이야기하며 주도적으로 쓰고 싶어하는 분들, 자식같다며 좋아하시는 분들 등등 시장조사에 대한 결론으로 당시 회사에서 운영중인 앱을 사용하던 고객 중 슈퍼마켓에서 사용하는 고객이 있었는데 그 분의 요구사항을 들어주는 걸로 결론이 났습니다.

이럴거면 시장조사는 왜 한 건가 싶었지만 그래도 좋은 경험했다 생각하기로 했습니다.

UI 설계​

주제가 정해지고 와이어프레임 작업을 시작했습니다. 당시 회사에 나오던 디자이너분이 있긴 했지만 그 분은 출근을 했다 안 했다 하는 대표님의 지인이어서 업무를 도와주지는 않아 스스로 해야 했습니다.

와이어프레임은 요구사항과 같이 간단하게 고객 목록에 메시지를 보낼 수 있으면 되는 것이라 어렵지 않았습니다. 많은 기능이 있지 않았으면 했고 간단한 일만 하게 될 컴퓨터에서 돌아갈 앱이니 UI 구성이 중요하지 않다고 했습니다.

그래서 필요한 기능만 있고 필요한 기능만 버튼도 큼직하게 사용하기 좋은 UI를 구성했습니다. 그 후 카카오 오븐에서 프로토타입을 만들어 완성했고 날을 잡아 전직원이 사용성 테스트를 진행해 처음 보는 사람도 사용에 설명조차 필요 없는 형태라고 칭찬받으며 UI 설계가 마무리 됐습니다.

개발 및 런칭​

개발에 익숙했던 react로 앱을 구성했습니다. 신규 프로젝트에 router, redux 등 기본 구성들로 레이아웃을 만들고 로그인, 회원가입 등 기본 페이지를 완성했습니다. 선임분은 백엔드 소스를 이 때까지도 보여주지 않고 있었어서 모두 더미데이터로 UI 설계된 대로 화면을 구현했습니다.

Api 문서도, 백엔드 소스도 보여주지 않고 있던 선임개발자는 시간이 촉박해지자 백엔드 소스를 보여줬고 그제서야 expressjs 공부해 백엔드를 이어 나갈 수 있었습니다. 그리고 얼추 개발이 완료될 쯤 커밋 사항들을 보고 있었는지 선임개발자가 그렇게 개발하면 사용할 수 없다며 나누어 개발하던 내 브랜치를 로컬과 리모트에서 맘대로 제거한 뒤 본인이 만든 내용으로 바꾸라고 통보했습니다.

설명도 없이 소스도 지우고 프론트엔드 구성도 고려하지 않고 만들어진 백엔드로 다시 고쳐야 하는 상황에 화가 났지만 웹 개발팀 직속 선임이고 IT 첫 회사에서 무경력 상태로 혹시나 짤리지 않을까 걱정되서 참아야 했습니다.

그렇게 이를 악물고 수정해서 웹에서 정상 동작하는 것을 테스트 완료해 배포하려 하는데, 고객사에서 웹 싸이트가 아닌 데스크톱 앱으로 배포해 달라는 요청이 왔습니다. 데스크톱 앱은 뭐지? 처음 배운 것도 웹이고 지금까지 한 것도 웹이라 데스크톱 앱을 만들라니 깜깜했습니다.

그렇게 검색을 하다 보니 데스크톱 앱으로 개발을 다시 해야 하는지부터 언어를 c 계열로 바꿔야 한다는 둥 여러 의견들이 있었는데, 이미 개발 완료한 react 소스를 버리기 싫어 검색하던 중 ElectronJS를 찾아 냅니다.

electron을 이용하면 javascript와 react로 구성된 웹 페이지를 데스크톱 앱으로 감싸서 배포할 수 있었습니다. 그렇게 재개발의 위기에서 이것을 통해 기한을 맞춰 서비스를 런칭할 수 있었습니다.

이직 결심​

IT 분야의 첫 회사였고 첫 인상도 좋았는데 이직을 하게 된 데는 여러가지 이유가 있었습니다.

선임 개발자​

가장 큰 원인은 직속 선임이었던 선임 개발자였습니다. 선임 개발자는 음식에 진심인 사람이었고 다 같이 먹는 점심 식사에 본인이 먹고 싶은 메뉴로 꼭 먹어야 하는 사람이었습니다. 그리고 식사 시간에는 본인의 정치 성향을 강조하며 이에 반하는 사람에게 폭언을 하거나 그런 사람들에 대해 뒷담화하는 시간을 가졌습니다.

시간이 지나면서 본인의 정치성향을 넘어 가치관들까지 강요하기 시작했습니다. 예를 들면 신입 때는 야근을 해서 살아남으려고 노력해야 한다는 등의 말도 안되는 소리들이었습니다.

그리고 예전에 판교에서 복싱을 배웠는데 아주 잘했다며 작은 키로 센 척을 많이 해댔는데 사람이 참 작아 보였습니다. 어린 나이가 아닌 40대인데도 불구하고 눈 앞에서 진심을 담아 쉐도우 복싱하며 위협하던 건 잊혀지지 않는 기억입니다.

본인과 담배를 피러 같이 가주지 않으면 삐지기도 하고 혼잣말로 욕설이나 폭언도 가끔 하는 정신적으로 불안한 선임이었습니다. 위의 상황들은 군대도 갔다 왔으니 적당히 맞춰 줄 수 있는 문제들이었다.

하지만 업무에 있어 내가 만든 소스를 아무런 설명도 없이 삭제하거나 기한이 있는 업무에 협조하지 않고 개발 소스를 공유하지 않는 행동들은 같이 일하는 성인의 태도가 아니었습니다.

나중에 선임 개발자와 퇴사를 결정하기 전 같이 허심탄회하게 이야기를 했었는데 어차피 이 회사에 2명만 있으면 일이 돌아가고 어린 여직원을 채용하고 싶다고 했습니다. 그래서 일부러 일을 가르쳐주지도 않았고 소스도 안 보여줬다고 말했습니다. 의문은 풀렸지만 노총각의 행동에 기분은 좋지 않았고 나가야 할 회사라는 생각이 더 확실해졌습니다.

대표님​

대표님은 기독교에 신실하고 진심인 분이었습니다. 그래서 나에게 종교생활을 강요했습니다. 매주 주말에 교회를 갔다 왔는지 물었고 수요일 점심시간엔 직장인 예배에 데려갔고 멘토까지 이어주며 관심이 없음을 여러차례 돌려서 말했지만 종교에 나를 빠뜨렸습니다.

회사가 어려워져 입사 전 약속됐던 점심 복지도 직원들을 위해 지불하는 4대 보험도 밀리는 상황에서도 직장인 예배에 교인들에게는 본인이 굳이 점심을 구매해 제공했습니다. (회사 인원은 5명, 교인들은 100명 가까이 됐습니다.)

대표님도 퇴사의 이유긴 했지만 그래도 결정하기 전 회사의 대표인 대표님과 이야기하고 싶었습니다. 종교 강요는 그래도 참을 수 있으니까, 선임 개발자와 있었던 여러 일들과 부당한 행동들에 대해 이야기를 했는데 종교의 힘으로 이겨낼 수 있음을 이야기 했고 본인도 사람 다루는데 있어 정말 힘들지만 해야 하는 일이라며 이상한 논리를 펼치기 시작했고 마치 내가 이 회사를 위한 순교자처럼 희생해야 할 것 같은 답변을 내놓았습니다. 더 이상 말이 통하지 않을 것 같다는 느낌이 들었고 이후로는 말을 섞지 않았습니다.

결말​

결심이 굳어졌습니다. 이제 이직을 준비해야 합니다. 이번에는 데이터분석 직무를 줄 듯 말 듯 밀당하는 회사에 들어가지 않고 정확히 그 직무로 지원하려고 마음먹었습니다.

빠른 이직을 하기 위해 스타트업을 알아봤습니다. 그 중 하나를 찾았는데 이전부터 관심있는 도메인인 헬스케어 관련 스타트업이었습니다. 그래도 면접에서 첫 회사를 다니며 해 온 실무들 덕에 자신있게 말할 수 있었습니다.

면접 결과가 나왔고 인수인계 때문에 2주 뒤 출근하기로 했습니다. 바로 대표님에게 이야기했는데 대표님은 무경력에 취업시켜줬는데 배은망덕하다며 화를 냈고 온갖 충고를 보태 한참 이야기 했습니다.

사실 공장자동화 plc 엔지니어였기에 IT 분야에서는 무경력이었고 나이도 있는 나를 취업시켜줬던 것은 정말 감사했던 일이긴 합니다. 하지만 그 외에 다른 행동은 나한테 미안해 하셨으면 했지만 전혀 그럴 분이 아니었습니다.

마지막이다 생각하고 충고들과 저주 섞인 말들을 들어주자 갑자기 나중에 힘들 때 연락하라며 급 따뜻한 마무리를 하셨습니다. 그렇게 인수인계 기간 2주를 가진 뒤 다음 스타트업으로 이직을 하게 됐습니다.