개요
- 요약
- 도입
- 배경
- 아이디어 제안과 채택까지의 과정
- 중요한점
- 마무리
요약
외국계 제조업 회사에서 자바 커넥터 개발 프로젝트를 1년동안 진행했습니다. 첫번째 인터그레이션을 마치고 새로운 팀원분이 합류하셨고 다음 타겟으로 넘어가던 도중 데이터 복잡성이 심화되며 데이터 Inconsistency 문제가 발생하는 것을 발견했습니다. 새 팀원 분께서 해당 문제를 해결하기 위해 중간에 데이터 프로세싱 프록시 서버를 두는 아이디어를 제안해 주셨고 한국 팀 내부 회의를 통해 근거자료 확보와 의견 합의를 이뤘습니다. 글로벌 팀 회의 때 아키텍쳐 변경 아이디어를 제안했고 퍼포먼스 비교 등 근거자료를 제시했습니다. 미국 팀 리드분이 이를 액셉하셨고 미국 엔지니어 리더십 팀회의에 이를 제안하시고 아키텍쳐 변경이 확정되었습니다.
도입
외국계 제조업 회사에서 개발자로서 소프트웨어 엔지니어링 일을 한지 2년이 조금 넘었습니다. 외국계 기업 특성상 스페인, 미국, 그리고 한국에 팀원들이 있습니다. 이번에 제가 속한 한국팀에서 제안한 아키텍처 변경 아이디어가 채택되었습니다. 아이디어 제안부터 채택까지 과정에서 느낀점을 공유하고자 합니다. 보안 상의 문제로 프로덕트 관련 디테일한 부분은 일반적인 내용으로 대체하는 점 양해 부탁드립니다.
배경
우리 팀은 프로덕트 생산과정에 필요한 데이터를 중앙화하여 관리하는 내부 툴을 개발하는 팀에 속해 있습니다. 깃헙과 같은 중앙화 형상관리 서비스는 다른 팀이 개발을 담당하고 있습니다. 실제 역학 분석을 진행하는 팀들과 해당 플랫폼을 연결하는 커넥터를 개발하는 것이 우리팀의 역할입니다. 팀 구성은 외국에 3명의 시스템 엔지니어가 있고 외국과 한국에 각 1명의 소프트웨어 엔지니어가 있습니다.
Java를 사용하는 역학 분석 프로그램을 중앙화 플랫폼에 직접 연결하는 커넥터를 1년동안 개발해온 상황이었습니다. 첫번째 역학분석 팀 인터그레이션을 마치고, 다음 팀으로 넘어가는 순간 데이터의 복잡성이 늘어나며 특정 부분에서 데이터 Consistency 문제가 발생한 상황이었습니다.
아이디어 제안과 채택까지의 과정
1. 기존 아키텍처와 문제점
기존 아키텍처는 클라이언트 앱이 직접적으로 중앙 플랫폼의 API와 통신하는 구조였습니다. 형상관리 플랫폼에 데이터를 업로드하기 위해서는 API 스펙에 맞춘 시리얼라이제이션 뿐만 아니라 데이터를 특정 형식을 변경하는 데이터 프로세싱이 필요했습니다. 해당 데이터 프로세싱은 회사 내부 개발 파이썬 라이브러리를 활용해야 했고 인터그레이션 타겟 프로그램은 자바였습니다.
- 데이터 프로세싱 전담 파이썬 엔진
- 자바 런타임에 파이썬 라이브러리 호출
- 파이썬 라이브러리를 자바로 구현하여 활용 - 채택
당시에는 인터그레이션 타겟 프로그램과 중앙 플랫폼의 직접 통신이 요구사항이었기에 데이터 프로세싱을 위한 파이썬 엔진을 따로 두는 것이 채택되지 않았습니다. 자바 런타임에서 파이썬 라이브러리를 사용하는 방안도 디버깅의 어려움과 퍼포먼스 저하, 데이터 시리얼라이제이션 요구되는 환경 셋팅 등의 이유로 채택되지 않았습니다. 첫번째 인터그레이션 타겟의 데이터프로세싱의 복잡도가 낮았기에 리버스 엔지니어링을 통해 해당 회사 내부 파이썬 라이브러리를 자바로 구현해 사용하는 방안이 채택되었습니다. 개인적으로 데이터 프로세싱 엔진을 따로 두는 저의 바램이었지만 주니어 엔지니어로서 해당 의견을 관철시키는 것은 쉽지 않았습니다.
해당 아키텍처로 첫번째 인터그레이션을 마치고 다음 타겟으로 넘어가던 도중 데이터가 복잡해짐에 따라 자바 데이터 프로세싱의 결과값과 파이썬 데이터 프로세싱의 결과값이 다른 문제가 발생했습니다. 데이터를 중앙화하여 형상관리를하는 구조에서 치명적인 문제였습니다.
2. 새로운 아키텍처
한국 팀에 새롭게 조인하신 시니어 개발자님의 의견으로 시작하여 우리 팀에서 제안한 아이디어는 데이터 프로세싱과 중앙 플랫폼 API와 소통하는 파이썬 프록시 서버를 두는 것이었습니다. 해당 서버는 중앙 플랫폼이 관리하는 컨테이너 서비스에 배포됩니다. 인터그레이션 타겟인 역학분석 프로그램들은 중앙 플랫폼 API와 직접 소통하는 것이 아닌 한단계 더 추상화된 파이썬 프록시 서버로 요청을 보내는 구조입니다. 이렇게 하면 다양한 언어에서 해당 데이터 프로세싱 라이브러리를 직접 구현할 필요가 없고 이로 인해 발생하는 데이터 Consistency 문제로 걱정할 필요가 없습니다.
3. 아키텍처 변경의 어려움
두번째 인터그레이션 타겟으로 확장하며 발생한 문제에 대한 해결방안으로 새로운 아키텍처를 제안하는 것이었습니다. 첫번째 인터그레이션 프로덕션을 앞둔 상황에서 아키텍쳐 변경은 굉장히 큰 결정이었고 이는 이전 아키텍쳐 설계의 미흡함을 인정하는 느낌을 줄 수 있기에 어려움이 있었습니다. 또한 초반 탑다운 방식으로 내려왔던 인터그레이션 타겟과 중앙 플랫폼이 직접 소통해야한다는 요구사항을 변경해야 했습니다.
4. 근거 자료
한국 내부 팀에서 아래의 3가지 근거 자료를 준비했습니다.
- 데이터 Consistency 문제 발생 패턴
- 기존 아키텍쳐와 새로운 아키텍쳐 퍼포먼스 비교 분석
- 아키텍쳐 유지시 필요한 리팩토링 업무, 걸리는 시간
데이터 Consistency 문제 발생 패턴 자료를 통해서 해당 문제가 형상관리 측면에서 혼란을 일으킬 수 있다는 점을 조명하여 프로덕션 배포의 어려움을 정확히 표현했습니다. 두가지 아키텍쳐에서 소요되는 http 통신 소요 시간을 비교하여 직접 소통이 퍼포먼스가 좋긴 하지만 프록시 서버를 통해 소통하더라도 퍼포먼스 측면에서 치명적인 문제가 없다는 점을 주장했습니다.
5. 입장정리
위 근거 자료를 바탕으로 다음과 같이 한국 개발 팀의 입장을 정리했습니다.
"기존 아키텍쳐에서 발생하는 데이터 Consistency 문제는 프로덕션에서 큰 이슈를 발생시킬 수 있다. 아키텍처 유지하며 리팩토링을 통해 해당 문제를 해결하기 위해서는 현재까지 발견한 것으로는 x, y, z 부분을 손봐야하고 xx일이 걸릴 것으로 예상한다. 기존 아키텍처로 직접 통신하는 것이 퍼포먼스가 가장 우월하지만, 한국 팀에서 진행한 비교분석에 따르면 새로운 아키텍쳐에서 치명적인 퍼포먼스 저하는 발견되지 않았다. 개발 프로그램이 적용되는 워크플로우를 살펴보면 실시간 쌍방향 통신이라기 보다는 최신 데이터를 중앙화 플랫폼에 업로드하는 패턴이다. 따라서 데이터 Consistency가 가장 중요한 것으로 판단된다. 따라서 파이썬 프록시 서버를 두는 새로운 아키텍처를 제안한다."
6. 제안과 결과
글로벌 팀 미팅때 시니어 엔지니어 분께서 외국의 팀리드께 새로운 아키텍처 제안을 드렸습니다. 현재 상황에서 이는 아주 큰 결정이라는 것이 처음 반응이었습니다. 이후 인터그레이션 타겟과 중앙 플랫폼이 직접 소통해야하는 요구사항에 대해서 물어보았고 이는 리드의 결정이었다고 답이 왔습니다. 그 시점에 퍼포먼스 비교자료를 제시하여 직접 소통이 퍼포먼스가 가장 좋은 데이터를 보여주었고 동시에 새로운 아키텍쳐의 퍼포먼스도 그렇게 나쁘지 않다는 사실을 전달했습니다. 고려해보겠다는 팀리드의 답변을 듣고 첫번째 글로벌 팀 미팅은 끝났습니다.
이후 일주일 이후 다음 미팅 때 팀 리드가 해당 아키텍쳐로 변경하는 것이 좋겠다고 아이디어를 제안해줘서 고맙다고 이야기했습니다. 팀 리드는 한국 팀의 아이디어를 제안 받고 미국 엔지니어링 리더십 미팅에서 해당 아키텍쳐를 리포트 했고 그곳에서의 피드백이 좋아 아키텍쳐 변경을 결정했다고 했습니다.
중요한 점
철학적 논의를 마무리하는 수치화된 근거자료
아키텍쳐 관련 디스커션을 진행하다 보면 주로 특정한 소프트웨어 개발 프린시플을 기반으로 특정 아키텍처를 주장하게 됩니다. 예를 들면, 성능, 확장성, 데이터 정합성, 유지보수성 등이 있습니다. 즉 각 아키텍처 옵션들은 해당 아키텍처를 뒷받침하는 프린시플들이 있고 결국 뒤에는 어떤 프린시플을 선택할 것인가의 논의로 수렴하게 됩니다. 여기서는 철학의 문제로 끝을 맺기가 굉장히 어렵습니다.
위 사례에서는 첫번째 아키텍처는 직접 통신, 성능이 프린시플이었고 새로운 아키텍처는 데이터 정합성이 프린시플이었습니다.
결국 필요한 것은 소프트웨어가 사용되는 환경에서 어떤 프린시플이 어느만큼 중요한가를 파악하는 것이라고 생각합니다. 이를 뒷받침 하기 위해서는 프로덕션 환경에서의 비교분석 수치화 자료가 필요합니다. 이번 아키텍처 제안에서 준비한 자료는 두 아키텍쳐의 통신 소요시간 비교였습니다. 이를 통해 데이터 정합성이 가장 중요하다는 점을 주장하며 첫번째 아키텍처가 주장하는 프린시플인 성능 측면에서 치명적인 저하를 가져오지 않는다고 주장할 수 있었습니다.
상황에 따라 다르겠지만 아키텍처 변경과 같은 결정은 주로 작은 팀 내에서 논의를 하고 해당 논의을 상위 레벨의 결정권자들에게 리포트하여 다시 논의를 한 후 결정을 내리게 됩니다. 따라서 팀 리드 입장에서 믿음직한 근거자료가 없다면 해당 의견을 상위 레벨의 미팅에서 주장하기가 어렵습니다. 실제로 글로벌 팀 리드가 한국팀이 제안한 아키텍처를 상위 미팅에서 제안했을 때, 퍼포먼스 측면과 유지보수 측면에서의 반박이 들어왔다고 들었습니다. 직접 들은 건 아니지만 팀 리드 입장에서 수치화된 분석자료를 기반으로 큰 문제가 없다고 방어할 수 있었다고 생각합니다.
제안 시기
새로운 멤버가 팀에 합류했을 때가 가장 좋은 것 같습니다. 새로운 팀원은 개발 환경, 아키텍처 등 질문을 할 수 있는 권리가 주어집니다. 이는 개발을 위해 파악을 하는 단계로 팀원, 리드들은 이에 최선을 다해 도와줘야하는 것이 의무라고 생각합니다. 아키텍쳐같은 부분에 대한 질문은 관성 때문에 결정이 내려지고 나면 의문을 제기하기 위해서는 다소 용기가 필요합니다.
왜냐하면 아키텍쳐가 결정될 당시 최선을 다하지 않았거나 지식이 부족했다는 점을 인정하는 것처럼 보일 수 있고 굳이 위험을 감수할 이유가 없기 때문입니다. 이러한 기술 부채는 시간이 지날수록 파급력이 커지고 고치기도 그만큼 어려워집니다. 따라서 새로운 멤버가 들어왔을 때 기존 아키텍쳐 결정에 책임이 없음과 동시에 모든 질문이 환영되는 상황에서 기술부채, 아키텍처에 대한 논의를 하는 것이 좋다고 생각합니다.
기존 아키텍처를 선택했던 근거자료
새로운 아키텍쳐를 도입한다는 것은 기존의 아키텍쳐의 한계점을 인정하는 부분도 있다고 생각합니다. 뛰어난 사람은 자신의 부족을 인정할 수 있지만, 개인적으로 이는 쉽지 않다고 생각합니다. 따라서 새로운 아키텍처를 제안할 때 기존의 아키텍쳐를 선택할 수밖에 없었던, 혹은 선택했던 합리적인 이유도 같이 제공해주는 것이 좋다고 생각합니다. 주로 현재 아키텍쳐 논의를 같이 하는 사람이 기존의 아키텍쳐를 짰기 때문에, 상대방의 동의를 얻어내는 데에 도움이 된다고 생각합니다.
위의 사례에서는 퍼포먼스 비교분석 자료를 통해서 데이터 정합성 문제를 발견하기 전까지는 성능이 가장 좋은 직접 통신을 하는 것을 어느정도 정당화 할 수 있습니다. 따라서 새로운 아키텍처를 제안할 때 새 아키텍쳐의 장점 뿐만 아니라 기존 아키텍처를 선택할 수밖에 없었던 이유도 제시하면 커뮤니케이션 측면에서 매끄럽게 동의를 얻어낼 수 있다고 생각합니다.
마무리
대학생때 첫번째 웹개발 사이드프로젝트에서 팀리드를 맡아 바닐라 자바스크립트로 개발을 진행했습니다. 개발 도중 팀원으로부터 리액트 프레임워크를 도입하자는 아이디어를 받았습니다. 당시에는 리액트에 대한 지식도 없었고 개발 일정에 치여서 해당 아이디어를 발전시키지 못했습니다. 팀원에게는 해당 결정이 작은 불만이 될 수 있었고 뒤돌아 보면 리액트를 도입하는 것이 좋은 결정이었던 것 같습니다.
이상적인 팀리드는 제안 받은 아이디어를 면밀히 검토하고 도입을 고민할 것 같습니다. 하지만 때로는 이상적으로만 진행될 수 없는 것이 현실입니다. 아이디어를 제안하는 것은 본인의 지식과 상황 판단, 창의력을 뽐낼 수 있는 기회입니다. 이를 채택하고 적용하는 것은 큰 기여입니다. 개발자분들의 소중한 아이디어가 제안되고 채택되는 데에 저의 경험이 조금이나마 도움이 됐으면 하는 것이 저의 바램입니다.
댓글