Stellar One

스텔라 원(stellar one)은 최근 마무리한 프로젝트의 제품 이름이다. D&F(discovery and framing) 이후 프로젝트에 참여했기 때문에 제품 이름이 어떻게 스텔라 원(stellar one)으로 정해졌는지 모르겠다. 여러가지 의미가 담겨 있겠지만, 1번 별이라는 이름이 다음 별들도 있을 것이라는 암시를 주기 때문에 꽤 괜찮은 이름인 것 같다.

일본 고객사와 함께 진행한 프로젝트였기 때문에 대부분이 일본어로 진행됐다. 처음엔 일본어를 “아리가토 고자이마스” 밖에 할 줄 모르던 내가 과연 프로젝트를 잘 해낼 수 있을까 걱정이 많았다. 랩스 피봇(pivot)들의 서포트와 고객사 팀원들의 배려 덕분에 팀에 기여할 있었고, 다행히 프로젝트를 잘 마무리할 수 있었다. 스텔라 원 프로젝트를 통해 어떤 것들을 배웠고, 부족함을 느꼈는지 정리해보자.

Junhyun’s User Manual

프로젝트에 투입된 첫 날 내가 어떤 사람인지 팀원들에게 소개하는 시간이 있었다. 6가지 프롬프트(prompt)들이 주어졌다.

1. 내가 일하기 좋은 환경
2. 나에게 동기를 부여해주는 것들
3. 나와 커뮤니케이션하기 위한 좋은 방법
4. 내가 힘들어하는 것들
5. 내가 효과적으로 학습하는 방법
6. 나를 웃게 하는 것들

순발력이 뛰어나지 않은 나는 당일에 이런 질문들을 받았다면 굉장히 당황스러웠을 것 같다. 다행히 프로젝트 투입 전에 미리 준비 요청을 받아서 고민할 시간을 가질 수 있었다. 쉬운 질문인 것 같지만, 나는 스스로가 어떤 사람인지 생각해본 적이 없었기 때문에 1시간을 넘게 고민한 것 같다. 가장 어려웠던 질문은 나에게 동기를 부여해주는 것들이었다. 나는 주변에서 “열심히 한다.”, “열정이 많다.”라는 피드백을 종종 받는데 무엇이 나를 그렇게 열심히 움직이게 하는지 고민해 봤다.

내 답변은 호기심, 프로 정신, 고객이었다. 나는 내 일에 관련해서 궁금한 게 많다. 그래서 항상 질문이 많은 편이다. 모르는 것은 메모해두고 시간 날 때 찾아본다. 도움이 되는 정보들은 정리해서 블로그에 올려두고 필요할 때마다 찾아 본다. 블로그에 글을 쓰는 일은 비용이 정말 크다. 글 하나를 쓰는 것도 짧게는 3시간씩 소비한다. 공부하면서 충분히 이해가 될 때까지 궁금한 것들을 계속 확인하기 때문이다. 돈도 안 되는 일에 3~4 시간이라는 큰 비용을 들이는 이유는 모르는 것을 충분히 이해하고 싶다는 내 욕망 때문인 것 같다.

Frontiers 프로젝트 회고 글에서도 프로 정신에 대해 언급한 적이 있었던 것 같다. 나의 가치를 구매한 고객들에게 나의 모든 역량을 쏟아낸 좋은 품질의 프로덕트를 전달하고 싶은 책임감이 나를 움직인다. 열심히 일 할수록 스스로 배우는 것도 많기 때문에 성장을 위한 긍정적인 순환 루프가 만들어지는 것 같다.

고객은 나에게 일을 맡긴 회사나 사람일수도 있지만, 나는 더 넓은 범위에서 고객이라는 단어를 사용한다. 첫 직장 상무님께서 이런 이야기를 자주 하셨다.

고객은 단순히 돈 주고 일을 맡기는 사람이 아니다. 모두가 내 고객이다. 심지어 준현씨도 나에겐 고객이다. 모든 고객에게 잘해라.

당시 사회 초년생인 나에겐 이 말이 크게 와닿지 않았지만, 7년 정도 직장 생활을 해보니 몸소 실감하는 것 같다. 내 일에 연관된 모두가 나의 고객들이다. 함께 일하는 팀원들, 프로젝트 스테이크홀더(stakeholder), 나를 믿고 일을 맡기는 매니저 모두 나의 고객이다. 그들을 위해 내가 할 수 있는 일은 무엇일지 고민해보고 움직였을 때 돌아오는 긍정적인 피드백들이 나의 힘이 되어준 것 같다.

이번 자기 소개 준비가 내 스스로에 대해 생각해볼 수 있는 좋은 계기가 된 것 같다. 자기 소개를 하고 몇 주 뒤에 소프트웨어 장인라는 책을 읽기 시작했다. 나에게 동기를 부여해주는 것들과 내가 효과적으로 학습하는 방법들이 프로페셔널 소프트웨어 엔지니어가 가져야 할 마음가짐이나 행동이라는 내용들을 책에서 읽었을 때 내가 좋은 방향으로 성장하고 있다는 사실에 기뻤다.

What I learned

프로젝트를 통해 무언가 깨달음을 얻은 것들을 정리해봤다.

Japanese standup and language barrier

내가 프로젝트에 투입된 첫 날 랩스 피봇 중 한 명이 이런 이야기를 꺼냈다.

지난 주 회고 시간에 나온 이야기인데 앞으로 영어로 스탠드업(standup) 미팅을 해보는건 어떨까?

회고 글 도입부에서 언급했듯 나는 “아리가토 고자이마스”를 제외하고 할 줄 아는 일본어가 없었다. 일본어를 못하는 나를 위한 배려심에 피봇들이 이야기를 꺼내봤던 것 같았다. 질문에 대한 일본 팀원들의 답변은 “무리”였다. 그날 밤 생각해봤다. ‘그들이 영어를 못 한다면 내가 먼저 어설픈 일본어라도 시작해보자. 탄주 랩스에서 나의 역할인 엔지니어이자 사람들의 성장과 변화를 돕는 코치로써 먼저 다가가보자.’

다음 날 스탠드업 미팅에서 준비해 온 일본어 대본을 어설프게 읽고 이렇게 이야기했다.

나는 앞으로 이 프로젝트를 하는 동안 일본어로 스탠드업을 하겠습니다. 종료까지 3개월 남았으니 이 프로젝트가 끝날 쯤 나는 100개의 일본어 문장을 말할 수 있을 것 입니다.

그 이후 하루도 빠짐 없이 아침마다 한 시간씩 일본어 2~3 문장을 준비해 갔다. 스탠드업에서 대본을 들고 떠듬떠듬 일본어를 읽는 내 작은 행동이 일본 팀원들에게 큰 자극을 준 것 같다. 영어 스탠드업이 무리라 했던 팀원들도 그 다음 주부터 영어로 떠듬떠듬 말하는 연습을 시작했다. 아침마다 입 안에서 하고 싶은 이야기를 우물거리는 스탠드업이 시작됐다. 여기서 나는 작은 인사이트를 얻었다.

• 나의 작은 실천이 팀원들에게 영감을 주거나 팀원들을 고무시키는 데 효과적이었다.
• 완벽하지 못한 모습을 부끄러워하지 않고 개선하려는 노력이 팀의 분위기를 바꾸었다.

서로 노력하는 모습을 응원하는 것이 팀의 심리적 안전감을 가져다준 것이 아닐까 싶다. 나의 일본어 실력은 대본이 꼭 있어야 말할 수 있는 수준에서 준비한 문장은 대본 없이 말할 수 있는 수준까진 올라왔다. 준비하는 시간도 20분 정도로 많이 줄었다. 3개월 동안 작은 실천이 나에게도 많은 변화를 가져다주었다.

스스로 한계도 많이 느꼈다. 피봇들끼리는 영어로 일 했지만, 영어도 잘하는 편이 아니기 때문에 피봇들의 메시지도 70%정도 밖에 이해하지 못 했다. 개발이나 기술적인 이야기가 아니라면 내 의견을 전달하는 것에 어려움을 느꼈다. 영어 공부도 많이 필요할 것 같다. 일본어는 완전 초보 수준이기 때문에 피봇들에게 많이 의지했다. 내가 아무리 테크닉컬 스킬이 좋더라도 이것을 제대로 전달하지 못하면 아무런 가치가 없다. 체력과 무대포 의지로 밀고 나가는 것의 한계가 있다는 것을 체감했다. 이번 프로젝트가 끝나면서 본격적으로 일본어 공부를 해보기 위해 학원을 끊었다. 다음 프로젝트도 일본에서 일할 것 같으니 나름 미래를 위한 준비를 시작했다.

Server Seperation

이번 프로젝트는 운영 환경이 매우 열악했다. 공장 내부에 애플리케이션을 배포해야 하는데 DMZ 영역에 그나마 서버라고 부를 수 있는 머신이 있었다. DMZ 영역에 위치한 머신을 서버A라고 칭하겠다. 공장 내부 센서로부터 수집되는 데이터들이 외부로 노출되면 안 되기 때문에 서버A에 데이터베이스, MQTT 브로커 모스키토(mosquitto), ETL 도구 나이파이(nifi)를 설치했다.

이번 프로젝트에서 개발한 웹 애플리케이션은 DMZ 네트워크와 연결이 가능한 사내 네트워크에 위치한 서버에서 호스팅했다. 이 머신을 서버B라고 칭하겠다. 문제는 이 서버B가 팀원의 개인 랩톱(laptop)이라는 점이었다. 엔터프라이즈 기업에서 개인 랩톱 서버가 웬말인가 싶었지만, 회사 지원이 MVP(minimal viable product) 릴리즈보다 느린 상황이었다. 어찌됐든 MVP 릴리즈 이후 서버B가 다음과 같은 원인 때문에 몇 번 다운된 적이 있었다. 트래픽도 높지 않고, 데이터도 많지 않았기 때문에 서버가 다운될 것이라곤 생각도 못했다.

• 윈도우즈 운영체제에 8GB 메모리를 가진 랩톱이였다. 윈도우즈에서 도커 컨테이너를 실행하려면 WSL(windows subsystem for linux)이 필요하다. 별다른 설정이 없는 경우 메모리를 50% 혹은 8GB 중 작은 것을 사용하는데 WSL 머신이 너무 많은 메모리를 차지해 서버가 다운됐다.
• 윈도우즈 자동 업데이트로 인해 새벽에 서버가 다운됐다.

의도적이진 않았지만, 데이터를 수집하는 역할을 서버A에 분리한 덕분에 MVP 서비스를 호스팅하는 서버B가 다운되었더라도 실시간으로 수집한 데이터를 잃지 않을 수 있었다. 정상적으로 데이터가 수집되었기 때문에 서버B가 빠르게 복구되면 문제 없이 서비스를 이어갈 수 있었다. 이번 경험은 실시간 데이터가 필요한 서비스라면 데이터를 수집하는 역할을 별도 서버에 분리하는 것이 더 안정적인 시스템을 만들 수 있다는 인사이트(insight)를 주었다.

Data Resilience

이 주제도 열악한 운영 환경 때문에 발생한 문제다. 공장 내에서 사용할 수 있는 서버는 위에서 언급한 서버A뿐이었다. 서버A에 이미 설치된 데이터베이스에 우리 MVP 서비스가 필요한 논리 데이터베이스를 하나 더 만들어 사용했다. 릴리즈 이후 몇 일 뒤 시스템에 문제가 발생했는데, 서버 운영자가 데이터베이스 버전을 올리기 위해 데이터베이스 서버를 다운시킨 것이 원인이었다. 공지가 없었던 탓에 우리 팀은 굉장히 당황스러웠지만, 다행히 나이파이 프로세서들 사이 큐(queue)에 메시지가 보관되어 데이터 유실을 피할 수 있었다.

나이파이는 MQTT 모스키토 브로커의 구독자(subscriber)로 사용하기 위해 도입했다. 매우 작은 MVP 서비스이기 때문에 나는 구독자 애플리케이션을 직접 구현하려고 했지만, 데이터베이스가 내려가 시스템 장애가 발생한 상황에서 돌이켜 생각해보면 굉장히 좋은 선택이었다. 데이터베이스에 장애가 발생했지만, 나이파이 덕분에 데이터 유실을 방지하고 데이터베이스가 정상 복구되었을 때 빠른 회복탄력성(resilience)를 가진 시스템이 되었다. 만약, 직접 구현한 구독자 애플리케이션이었다면 데이터 유실을 피할 수 없었을 것이다.

이번 경험을 통해 몇 가지 깨달음을 얻었다.

• 각 시스템 구성 컴포넌트의 장애를 고려해 데이터 회복탄력성을 고려한 애플리케이션 설계에 대한 고민이 필요하다.
• 물리적으로 하나의 서버를 사용했지만, 시스템 구성 컴포넌트 간에 독립성을 위해 가상머신(virtual machine)을 도입했다면 이런 문제가 발생하지 않았을 것이다. 인터넷이 연결되지 않은 네트워크 환경이었지만, 시간을 들여 가상 머신으로 데이터베이스, 나이파이, MQTT 브로커를 호스팅했다면 더 안정적인 서비스 운영이 가능할 것이다.

Considering of different systems’ clock

이번 프로젝트 시스템에 참여하는 물리적인 서버는 3개였다.

• 공장 내부 센서들로부터 데이터를 수집해 MQTT 브로커에게 전달해주는 MQTT 발행자 역할의 PLC 게이트웨이(gateway) 서버
• MQTT 브로커, 데이터베이스, 나이파이를 호스팅하는 DMZ 네트워크 영역의 서버A
• MVP 서비스 애플리케이션을 호스팅하는 사내 네트워크 영역의 서버B

3개 서버 중 PLC 게이트웨이가 잘 동작하는지 확인하는 기능 구현을 맡게 되었다. PLC 게이트웨이 서버에서 매 초 단위로 생존(liveness) 여부를 메시지로 발행하는 방식으로 설계했다. 필요한 기능을 하나씩 구현해나가는 중 불현듯 데이터 중심 애플리케이션 설계라는 책에서 읽었던 신뢰성 없는 시계 내용이 떠올랐다.

위 세 개의 컴퓨터들은 서로 다른 시간 개념을 갖고 있었다. 특히 PLC 게이트웨이 서버는 인터넷에 연결되어 있지 않았기 때문에 실제 시간 갭이 사람이 인지할 수준이었다. NTP(network time protocol)을 사용한 동기화도 기대할 수 없었다. 나는 어떤 서버의 시계를 믿어야할까?

나는 데이터베이스의 현재 타임스탬프를 기준으로 삼았다. 다음 두 타임스탬프를 비교했다.

• PLC 게이트웨이 서버로부터 받은 생존 메시지를 데이터베이스에 삽입(insert)하는 시점의 데이터베이스 타임스탬프
• 백엔드 애플리케이션이 PLC 게이트웨이 생존 여부를 조회하는 시점의 데이터베이스 타임스탬프

세 개의 컴퓨터가 통신하는데 유일한 연결 고리를 만들어주는 데이터베이스의 타임스탬프를 사용하는 것이 가장 정확할 것이라 믿었다. 책에서 얻은 지식 덕분에 문제를 예방할 수 있었다. 앞으로도 많은 인사이트들을 책으로부터 얻기 위해 다독해야겠다. 책을 통해 지혜를 공유해주는 모든 작가들에게 감사하다.

Nifi as ETL tool

나이파이를 이번 프로젝트에서 처음 사용해본 것은 아니다. 이전 프로젝트에서 사용했었는데 당시엔 나이파이 사용 방법을 몰라 잘 알고 있던 팀원이 대부분 셋업했었다. 이번 프로젝트에선 나도 좀 더 본격적으로 다뤄봤다.

데이터 유실 문제를 막아주기도 했지만, ETL(extract, transform, load) 도구답게 MQTT 브로커로부터 실시간으로 들어오는 데이터를 적절한 포맷으로 변경해 데이터베이스 쌓는 기능을 만드는 것이 매우 쉬웠다. 프로젝트 초기에 나는 MQTT 구독자 애플리케이션을 직접 구현하려고 했다. 물론 비즈니스 확장을 고려해 설계했지만, 메시지 토픽이 늘어남에 따라 기능을 쉽게 확장할 수 있는 것은 나이파이라는 사실을 직접 사용해보면서 체감했다.

• 토픽이 늘어나면 기존에 있던 구독자 프로세서를 복사해 필요한 프로퍼티(property)만 바꿔주기만 하면 된다.
• 프로세서 사이에 큐가 자동으로 생성되어 데이터 유실을 방지하기 때문에 개발자의 고민 거리를 덜어준다.
• 서비스를 재배포하는데 시간이 소모되지 않는다. 웹 콘솔에서 새로 만든 프로세서를 실행(run), 중지(stop)하는 것만으로 적용, 중단이 가능하다.

나이파이 프로세서들을 잘 구축했는지 확인하려면 실제로 돌려봐야하기 때문에 단위 테스트 같은 빠른 검증 피드백이나 자동화 된 테스트가 어렵다는 단점은 있지만, 잘 만들어진 나이파이 같은 솔루션을 사용한다면 개발자들은 다른 비즈니스나 기능에 집중할 수 있기 때문에 프로젝트 진행이 더 원활해지는 효과를 얻을 수 있을 것 같다.

Thanks, Team Stellar One

프로젝트 아웃셉션 때 서로 롤링 페이퍼를 써줬는데 나는 긍정적 에너지에 대한 좋은 피드백들을 받았다. 감사한 마음을 갖고 나의 스킬들과 에너지를 앞으로도 계속 키워나가야겠다. 이번 프로젝트에서 배운 것들이 정말 나의 것이 될 때까지 수련하자.