Hitonaru

7월 중순에 시작했던 프로젝트가 이번 12월 20일에 끝났다. 프로젝트만 시작하면 시간이 정말 빠르게 지나가는 것 같다. 이번 프로덕트의 이름은 Hitonaru(ひとなる)로 "사람이 된다."라는 의미를 갖고 있다. 이 뜻 말고도 몇 가지 다른 의미를 풀이해줬는데, 일본어가 부족해서 모두 알아 듣진 못했다. 고객사가 운영하는 고등학교의 시스템이기 때문에 잘 어울리는 이름이라고 생각된다.

프로젝트가 끝났으니 이번에도 내가 배운 것들을 글로 정리한다.

Japanese

올해 초에 혼다 프로젝트를 경험하면서 일본어 공부의 중요성을 크게 느꼈다. 이전 프로젝트에선 한국 랩스 피봇(pivot)들과 일본 고객들이 한 팀을 이뤘기 때문에 대부분의 대화가 영어로 이뤄졌다. 나도 영어를 잘하는 편은 아니지만, 나보다 더 영어를 어려워하는 일본 쪽 고객들이 영어로 대화하려고 노력하는 모습을 보면 불평할 수 없었다.

혼다 프로젝트에선 PM, 디자이너가 일본어를 잘하는 캐나다인, 대만인이었다. 다행히 개발자 한 분은 한국인이었다. 나 빼고 모든 피봇들이 영어와 일본어를 잘 했다. 고객분들은 영어를 대부분 못 했기 때문에 모든 대화가 일본어로 이뤄졌다. 당시엔 피봇들이 나를 위해 영어나 한국어로 다시 설명해주는 수고스러움이 정말 미안했다. 특히 IPM(iteration planning meeting)은 기능 개발에 필요한 요구사항, 제약사항들에 대한 대화가 오고 가는데, 나 때문에 대화의 흐름이 끊기는 것이 부담스러웠다.

프로젝트가 끝나자마자 4월에 일본어 학원을 등록했다. 한달 속성 반으로 공부를 시작했다. 짧은 시간이었기 때문에 실력이 크게 늘진 않았지만, 기초적인 문법에 대한 이해나 히라가나, 가타카나로 글을 읽고 쓰는 것 정도는 어느 정도 할 수 있게 됐다. 업무 시간에 일본어 학원을 다닐 수 있는 시간을 배려주신 매니저님께 너무 감사하다. 일본어 학원뿐만 아니라 일본 개발자와 1 on 1 멘토링 할 수 있는 자리를 마련해주셔서 꾸준히 일본어를 해야하는 환경에 나를 노출시킬 수 있었다.

이 프로젝트가 본격적으로 시작한 7월쯤엔 일상적인 주제의 대화는 여전히 어려웠지만, 짧은 대화나 내가 설명하고 싶은 기술적 컨셉에 대한 이야기는 할 수 있는 수준까지 올라와 있었다. 그리고 프로젝트 기간 내내 일본어를 사용했다. 고객뿐만 아니라 피봇들과 대화할 때도 일본어를 사용했다. 영어와 일본어를 번갈아 가면서 이야기하는 스위칭이 내게는 아직 너무 어려운 영향도 있었다.

일본어를 듣고 말할 수 있게 되면서 이전과 다르게 조금 더 프로젝트에 깊숙히 참여할 수 있게 되었다. 스테이크홀더(stakeholder)에게 의견을 직접 전달한다든지, 외부 조직과 미팅을 할 때 필요한 의견을 직접 전달할 수 있게 되었다든지, 일본 고객분들과 페어 프로그래밍이 더 원할해졌다든지 조금 더 팀에 기여할 수 있는 부분이 많아졌다. 나로 인해 발생하는 비용 부담 요소들을 스스로 덜어낼 수 있게 되어 굉장히 기쁘고 뿌듯했다.

의사 결정은 사람과 사람 사이의 대화와 상호작용을 통해 이뤄진다. 거기에 필요한 도구를 이번 프로젝트를 통해 하나 얻게된 것 같은 기분이다. 프로젝트가 끝난 후 일본어를 사용하는 시간이 제로(0)로 줄었다. 회사 일뿐만 아니라 이래저래 처리할 것들이 많아 따로 공부할 시간을 갖기 어려웠기 때문이지만, 계속 의식하고 있다. 앞으로도 계속 일본쪽 일을 할 것 같고 아직 부족한 것이 많기 때문에 일본어는 쉬지 않고 정진해 나갈 예정이다.

DynamoDB

AWS DynamoDB가 이번 프로젝트의 가장 큰 복병이었다. NoSQL 기술을 메인 스토리지로 사용한 프로젝트 경험은 이번이 처음이었다. 기술이 익숙하지 않은 것은 문제가 되지 않았다. 소프트웨어 엔지니어는 언제나 가장 잘하는 기술 셋만으로 일할 수는 없기 때문에 새로운 것을 배우는 것에 열린 마음을 갖고 있어야 한다고 생각한다. 다만 아쉬운 점은 해결하고 싶은 문제(= 프로덕트)에 가장 적합하다고 팀 스스로가 판단하여 선택한 기술이 아니라 외부에 의해 어쩔 수 없이 사용하게 되었다는 것이다.

DynamoDB는 높은 수준의 퍼포먼스가 필요한 시스템에서 균일한 데이터 접근 속도와 무한대의 스케일(scale)이 가능하도록 만든 기술이다. 이런 기술적 특성을 만족하기 위해 유연한 도메인 설계보단 구체적인 요구사항에 맞게 최적화 된 데이터 액세스를 지원하는 솔루션이다. 특정 상황에 맞는 최적화를 수행해서인지 우리 팀의 플랙티스(practice)와 잘 맞지 않았다.

린 XP 플랙티스는 주기적인 릴리즈와 검증을 통해 배운 내용들을 프로덕트에 계속 반영해 나가기 때문에 유연한 설계가 필요하다. 필요하다면 데이터 액세스 패턴과 필요한 데이터의 스킴(scheme)이 언제든지 변경될 수 있어야 한다. 하지만 DynamoDB는 이런 시스템 요구사항에는 맞지 않았다고 생각된다. 예상치 못한 기능(feature)이 추가될 때마다 다음과 같은 것들을 고려해야만 했다.

• 기존 데이터 접근 패턴을 활용할 수 있는가? 없다면 글로벌 세컨더리 인덱스(global secondary index)로 해결할 수 있는가?
• 신규 필드가 추가할 때 사전에 저장된 데이터들을 변경하지 않더라도 문제가 되지 않는가?
• 신규 기능을 위한 데이터 마이그레이션(migration)이 필요한가?

익숙하지 않은 사고의 흐름이 필요했기 때문에 피로감이 더 컸던 것 같다. 그렇다고 마냥 나쁜 것들만 있진 않았다. 새로운 것을 배우는 것에 대한 몰입, 새로운 패러다임에 대한 사고 확장 등이 올해 내 성장의 밑거름이 되어줬다고 생각한다.

E2E Tests

E2E(end-to-end) 테스트를 십분 활용했다. E2E 테스트를 프로젝트 초반부터 함께 빌드해 나간 것은 이번이 처음이다. 함께 프로젝트에 참여한 개발자 피봇이 E2E 테스트를 적극 권장했기 때문이다. 나는 선호에 따라 E2E 테스트를 선택적으로 사용하는 것이라는 의견을 갖고 있었기 때문에 필요성을 느끼는 시점이 올 때까지 작성하질 않았다. 테스트 피라미드를 살펴봐도 E2E 테스트의 비중은 상당히 작다. 그래서 이전 프로젝트들은 프로젝트가 한참 진행되고 나서야 E2E 테스트를 셋업하고 해피 패스(happy path)에 대한 테스트들을 몇 개 작성했었다.

문제는 프로젝트 도중에 E2E 테스트를 작성하는 것이 쉽지만은 않다는 것이다. TDD(test driven development) 실천에는 여러가지 장점들이 있지만, 기능 코드를 작성하기 이전에 테스트 코드를 작성하는 것을 강제하기 때문에 테스트 코드를 위한 유지 보수 시간이 별도로 들이지 않아도 된다는 것이 큰 장점인 것 같다. 이번엔 프로젝트 초반부터 E2E 테스트들을 함께 빌드하다보니 별도 유지보수 시간이 필요하지 않았고 프로젝트 중간에 E2E 테스트를 작성할 때처럼 거북한 감정도 없었다.

보통 무슨 일이든 장단점이 있듯이 초반부터 E2E 테스트를 함께 빌드하면 안 좋은 점도 있었다. E2E 테스트는 중요한 해피 패스들에 대해서만 검증하는 것이 좋다고 생각한다. 프로젝트 초반엔 간단한 기능들 뿐이기 때문에 E2E 테스트가 단위 테스트에서 검증했던 부분까지 중복된 검증을 했다. 프로젝트가 진행될수록 중복되는 검증 코드들이 쌓이면서 테스트 코드를 점점 난해하게 만들었다. 가뜩이나 느린 E2E 테스트를 더 느리게 만드는 원인이 되기도 했다. 주기적으로 중복된 검증들은 삭제하고, 중요한 사용자 시나리오를 확인할 수 있는 코드로 리팩토링하는 시간이 필요했다.

프로젝트 초반부터 E2E 테스트를 작성하는 경험을 통해 E2E 테스트의 이점과 도입 시점에 따른 장단점을 몸소 느낄 수 있어서 좋았다. 지금 E2E 테스트에 대한 내 의견은 프로젝트 초반부터 E2E 테스트를 함께 셋업해나가는 것이 더 좋다는 쪽으로 기울었다. 더불어 E2E 테스트가 주는 피로감이 좀 더 와닿기도 했다. 예를 들어, 데이터가 꼬여 있거나 시스템의 외부 의존성 때문에 거짓 양성(false positve)이 잦아지면서 실패 원인에 대해 한번 더 확인하는 작업이 많아졌다. 나중엔 테스트 실패에 둔감해졌던 것 같다. 외부 시스템에 대한 의존성은 어쩔 수 없더라도 데이터가 꼬이는 문제는 논리적으로 분리하여 해결했다. 앞으로 E2E 테스트를 적극 활용한다면 거짓 양성 문제를 완화하는 것이 새로운 숙제가 될 것 같다.

Terraform for AWS

23년쯤 프로젝트에서 테라폼(terraform)이 필요해서 처음 공부했던 것 같다. 이후 정말 오랜만에 다시 접한 것 같다. 인프라(infra)는 주로 담당하는 팀에서 직접 작업해주기 때문에 자주 수정할 일이 없었지만, 이번엔 각 프로덕트 팀에서 직접 인프라를 관리하도록 방침이 바뀐 것 같다.

매번 웹 콘솔에서 새로운 리소스들을 만들 때마다 의존 관계가 있는 다른 리소스들을 추적하는 것이 어려웠는데 테라폼은 이런 불편함을 많이 덜어줬다. 프로젝트 초반에 인프라를 셋업하면 자주 변경될 일이 없을 것이라 예상했었는데, DynamoDB 데이터 마이그레이션이나 KMS 암호화 등의 작업으로 생각보다 자주 인프라를 변경했다. 잦은 인프라 변경에 테라폼이 큰 도움이 됐다.

예전에도 느낀 점이지만, 테라폼은 어디까지나 도구일 뿐 결국 클라우드 제공자(cloud provider)의 특성을 잘 이해해야 한다. 아이러니하게도 인프라 구성에 대한 내용을 코드로 작성하면서 AWS 클라우드에 대해 더 잘 이해하게 된 것 같다.

• 리소스의 필수, 옵셔널 값에 대한 판단이 쉽다.
• 리소스마다 연관된 의존 관계들이 한 눈에 파악된다.

리소스 생성 시 필수 값과 의존 관계 파악이 쉽다보니 내가 구성한 인프라의 모습이 머리 속에서 상상하는 것이 더 쉬웠다. 사용할 기회가 더 많아지면 좋겠다.

Need to complement

어떤 부분들이 부족했을까? 보완이 필요한 점들을 떠올려봤다.

System log

로깅과 모니터링은 정말 중요하다. 시스템의 문제가 있는지 여부를 판단할 수 있는 힌트가 되기 때문이다. 첫 회사에서 MES를 운영할 땐 로그와 서버의 메트릭을 확인하는 습관이 몸에 베어있었다. 새로운 기능을 배포하면 무슨 문제가 없을지 몇 시간이고 로그를 살펴봤다.

현재 회사로 이직 후 시스템 운영을 안 하다보니 로그 보는 습관이 사라졌다. 좋은 습관을 잃어버렸다. 반성이 필요한 부분이다. 로그를 확인하지 않은 탓에 똑같은 문제를 두번이나 겪었다. 여러 사용자들이 입력한 데이터를 동시에 저장할 때 실패한다는 리포트를 받았다. 학교 내부 네트워크가 느리기 때문에 통신이 원할하지 않아서 실패한 것 같다는 팀원의 말을 믿고 로그를 확인하지 않았다. 로그만 확인했다면 금새 해결했을 간단한 문제였지만, 로그를 보지 않은 탓에 같은 문제를 다시 겪었다.

좋은 소프트웨어 엔지니어가 되기 위한 좋은 습관을 지킬 수 있도록 의식적인 노력이 필요하다고 느꼈다.

Feedback

이번엔 주기적으로 팀원들 간의 피드백 시간을 가졌다. 내가 받은 피드백 중 공통된 내용이 있었다.

의견을 내는 것을 주저하거나 양보한다는 인상

이전에도 비슷한 피드백을 받았었다. 나는 딱히 의견을 많이 내지 않는 편인 것 같다. 영어나 일본어이기 때문에 말하기를 주저하는 것은 아니라고 생각한다. 한국어를 사용할 때도 의견이 그리 많지 않았다. 우리는 팀으로 일하기 때문에 나는 누군가 좋은 의견을 냈을 때 딱히 이견이 없다면 추가적인 멘트는 하지 않는다. 그 편이 불필요한 대화를 줄일 수도 있다고 생각하기 때문이다. 물론 내 생각에 이상하거나 이해되지 않을 땐 거침없이 질문을 던지기도 한다. 어찌됐든 절대적인 멘트량이 적기 때문에 이런 모습이 조금 소극적으로 보이기도 한 것 같다.

좋은 피드백이라고 생각하지만, 나는 여전히 다른 사람들의 의견을 잘 듣는 것을 중요하게 생각하고 불필요한 추가 멘트를 더하고 싶진 않다. 내가 어떤 부분을 어떻게 개선할 수 있을지 고민해봐야겠다.