Frontiers
위키피디아(wikipedia)엔 프론티어(frontier)라는 단어가 다음과 같이 정의되어 있다.
Frontier
미국 남북 전쟁 이후 개척이 본격화된 시기를 서부개척시대라고 한다. 이를 지지하는 것이 개척 정신인 ‘프런티어 정신’이다.
개척하고자 하는 의지라는 의미를 가진 이 단어는 이번 프로젝트의 팀 이름이기도 하다. 함께 일한 고객사 분들에게는 상당히 도전적인 과제이기도 했고, 전체 시스템의 대문을 책임지고 있는 서비스를 개발하는 우리에겐 너무 잘 어울리는 팀 이름이라 생각했다. 이번 회고 글의 주제는 최근 마무리 한 프로젝트 회고이다. 프로젝트 경험이 미화되거나 풍화되기 전 생생한 나의 생각과 감정을 기록했다.
Agile Manifesto
탄주 랩스에 합류한 후 처음 맡은 프로젝트에선 소프트웨어 엔지니어라는 역할에만 충실했다. 나를 팀에 소개한 친구에게 폐가 되지 않도록, 프로젝트가 나로 인해 지체되지 않도록 프로덕트를 만드는 데 힘을 쏟았다. 사실 나에겐 소프트웨어 엔지니어 말고도 애자일 코치라는 역할이 함께 주어졌다. 애자일 코치로써 첫 프로젝트에 참여한 나는 애자일을 몰랐기에 프로젝트 흐름에 자연스럽게 나를 맡겼다. 첫 프로젝트를 마친 나의 경험 위에 팀원들과 프로젝트 회고, 조직의 시니어(senior) PM, 매니저님으로부터 받은 워크샵 경험들이 쌓이면서 나의 새로운 가치관이 싹을 틔였다.
난
애자일이라는 고급스런 단어와 겉으로 보이는 플랙티스(practice)의 화려함에 눈이 멀었구나
이 글을 쓰기 전 첫 프로젝트 in Tanzu Labs 회고 글을 다시 읽어보니 나의 의식은 딱 그 수준이었던 것 같다. 지금까지 쌓인 내 인사이트(insight)가 최고로 훌륭하진 않지만, 이전보다 성장했다는 느낌은 많이 받았다. 나는 10월에 시작한 프로젝트에서 다시 애자일 코치라는 타이틀을 달게 되었다. 난 내가 배운 것들을 자연스럽게 팀원들에게 알려주고 싶었다. 운 좋게 애자일 매니페스토(agile manifesto) 워크샵을 내가 맡게 되면서 그들에게 내가 얻은 인사이트를 설명할 시간이 주어졌다. 워크샵 내용은 다음과 같이 요약할 수 있다.
- 우리가 주로 듣는 스크럼(scrum), 칸반(kanban) 그리고 탄주 랩스가 수행하는
XP는 애자일을 실천하는 방법이다. - 나도 마찬가지였지만, 많은 사람들이 겉으로 보이는 실천 방법에만 눈이 멀어 정작 중요한 것을 놓치고 있다.
- 애자일은 내면에 중요하게 여기는 가치(value)에서부터 시작해야 한다.
- 일은 사람이 하기 때문에 일에 참여하는 사람들의 태도, 마인드 셋(mind set)이 제일 중요하다.
- 애자일은 성공적인 소프트웨어를 만들기 위해 다음과 같은 가치관들을 더 소중히 여기는 철학이라고 생각하면 된다.
- 공정과 도구보다
개인과 상호작용을 - 포괄적인 문서보다
작동하는 소프트웨어를 - 계약 협상보다
고객과의 협력을 - 계획을 따르기보다
변화에 대응하기를
- 공정과 도구보다
- 애자일을 만든 사람들은 소중히 여기는 가치들을 지킬 수 있도록 12가지 원칙들을 정의했고, 우리 탄주 랩스는 이를 따르려고 노력하고 움직인다.
- 원칙이란 쉽게 지켜지지 않기 때문에 팀원들이 자연스럽게 애자일의 소중한 가치를 지키고, 원칙들을 따를 수 있도록
XP라는 실천 방법을 사용한다.
이 워크샵을 통해 함께 일할 사람들에게 랩스가 일하는 방식은 다르다는 인식을 심어주고 싶었다. 언젠가 매니저님이 나에게 “애자일이라는 종교에 빠지셨군요.”라고 하셨는데, 그렇다. 난 애자일 전도사가 되어 버린 듯 하다.
Professional
다들 나를 열정맨이라고 불러주지만, 반쯤은 틀린 말이다. 난 성실, 성의, 진심이라는 의미를 지닌 단어인 sincerity를 좋아한다. 누군가 나의 가치를 샀으니 맡은 일에 진실된 마음으로 임할 뿐이다. 난 항상 돈 받고 일하면 프로라는 생각을 가지고 있다. 이번 프로젝트에서도 나는 모든 역량을 쏟아냈고, 그만큼 많은 것들을 얻었다.
지난번 프로젝트와 같은 실수를 반복하지 않기 위해 이전에 느낀 부족한 점을 채우려 움직였다. 수시로 다음에 만날 수 있는 문제 상황들을 예측하고, 해결 방법을 고민했다. 난 내부망(private network) 개발을 준비하는데 얼마나 많은 시간이 뺏기는지 지난 프로젝트를 통해 알고 있었다. 한번에 제대로 처리되지 않을 뿐더러 내부 프로세스가 느리기 때문에 계속 필요한 내용들을 확인했다. 협조 부서에서 완료됐다는 이야기를 들으면 정말 잘 준비됐는지 눈으로 확인하고, 다시 요청하기를 반복했다.
도메인 지식은 정말 중요하다. 소프트웨어의 본질은 비즈니스로부터 나온다. 현장 용어들을 얼만큼 이해할 수 있는지에 대한 중요함과 현 시스템 사용자와 운영자의 목소리에 귀 기울여야 할 필요성을 첫 프로젝트 때 배웠다. 내 경험상 이런 현상은 독특한 비즈니스를 다루는 곳에서 더 두드러지게 나타난다. 이번 프로젝트도 굉장히 특이한 비즈니스 도메인이었기에 D&F(discovery and framing) 기간 동안 궁금증이 풀릴 때까지 질문했다. 질문 요정이라는 소리도 들었지만, 개편하려는 현재 시스템과 비즈니스를 정확히 이해하지 못하면 개발을 제대로 할 수 없다고 판단했다. 필요하다면 레거시 코드를 요구해서 살펴봤다. 여기 저기서 겪었던 프로젝트들의 더러운 코드들을 디버깅했던 경험 덕분인지 언어가 Java라면 필요한 정보를 얻어 내는데 몇 시간이 채 안 걸렸다.
원활한 프로젝트 진행을 위해 개발자 세션도 수시로 진행했다. 프로젝트에 함께 참여한 고객사 개발자분들의 경험치가 다소 적었기에 내가 요청하는 것이 무엇인지, 왜 원하는지를 이해시키고, 나아갈 방향은 무엇인지 알려주고자 부단히 노력했다. 서버의 세션을 통한 사용자 인증 프로세스에서 만날 수 있는 문제점들과 보안 이슈 등에 관련된 내용도 준비했지만, 설명할 시간을 갖지 못해 조금 아쉬웠다. 프로젝트 기간 동안 다음과 같은 내용들을 다뤘다.
- Test Driven Development, SOLID 개념을 쉽게 이해할 수 있는 간단한 코드 구현하기
- 현 레거시의 인증 프로세스와 웹 기반 SSO 인증 프로세스에 대한 차이점을 설명하고, 신규 서비스에 인증 프로세스를 적용하려면 필요한 요소들이 무엇인지
- 웹 기반 어플리케이션 개발의 기초적인 지식에 대해 설명하고, 개발 초반에 만날 수 있는 문제들은 무엇인지
- 추후 신규 비즈니스 확장을 고려하여 설계한 패키지와 도메인의 구조는 어떻게 구성되었는지
- 글로벌 서비스를 제공하기 위해 필요한 타임존 개념과 사용할만한 라이브러리들은 무엇이 있는지
- 중앙 세션 관리, 메세징, 캐싱을 위해 사용하는 레디스(redis)의 고가용성(HA, high availabilty)을 고려한 인프라 아키텍처는 무엇이 있는지
나는 프로젝트 기간 동안 균일한 속도를 내고자 노력했다. 균일한 속도는 팀이 다음 계획을 세우기 위한 밑거름이 되어주기 때문에 매우 중요하다. 우리가 XP를 통해 얻고자 하는 것도 초반 빠른 속도가 아닌 개발 속도의 지속성과 균일함이다. 마지막 날까지 내가 할 수 있는 일들에 집중했다. 프론티어즈 서비스를 개발하는 엔지니어로써, 고객의 성장을 돕는 컨설턴트로써 허튼 시간을 보내고 싶지 않았다. 누군가에겐 배울 점이 많은 선배, 누군가에겐 챙겨주고 싶은 후배, 팀원들에겐 신뢰를 줄 수 있는 동료로 남고자 했다.
Weakness
완벽한 것은 없다. 이번 프로젝트에서도 부족한 부분들이 있었기에 기록하고 다음에 개선해야겠다.
Bugs
지난 프로젝트에 비해 자잘한 버그들이 많았다. 서비스는 일단 배포되면 돌이킬 수 없다. 스타일 관련된 코드더라도 어플리케이션을 구성하는 코드 한 줄, 한 줄이 모두 치명적이다. 아직 개발 단계일지라도 서비스 배포를 우습게 여겨선 안 된다. 습관은 무서운 것이기에 테스트가 통과하더라도 작성한 코드에 문제가 없는지 꼼꼼히 살펴봐야겠다. 반드시 구현체가 동작하는 모습을 눈으로 확인하자.
E2E Test
파이프라인에 E2E 테스트 스테이지를 추가했는데, 상당한 말썽꾸러기였다. E2E 테스트 때문에 불필요한 시간을 뺏기기도 했다. 소프트웨어 개발은 시간과 인사이트 싸움이다. 시간을 허비하는 것은 상당히 비용이 크다. E2E 테스트를 잘 활용하기 위해서 베스트 플랙티스(best practice)를 조사하고, 프레임워크 사용 방법을 공부해야겠다.
Frontiers Colleagues
이번 프로젝트에 함께 참여하신 탄주 랩스의 PM, 디자이너 분들은 지난 프로젝트와 동일했다. 두 분께선 프로젝트 초반 사용자의 패인 포인트(paint point)를 탐색하고, 이를 해결할 수 있는 방법들을 도출해내는 D&F를 환상적인 호흡으로 이끌어주셨다. 내 일만 할 줄 아는 나와는 다르게 프로젝트 동안 맡으신 업무 외에도 이해 관계자들 사이를 조율하고, 프로젝트 팀의 건강을 계속 챙겨주셨다. 팀의 분위기와 건강을 챙겨주신 덕분에 모두 밝은 모습으로 일할 수 있었다.
이번엔 다른 탄주 랩스 엔지니어 분과 함께 일했다. 나와 다르게 프론트엔드 개발자 커리어를 오래 쌓아오신 만큼 내가 몰랐던 개념들에 대해 물꼬를 틔어주셨다. 있는지조차 몰라서 시작도 못하는 것들이 있지 않은가. 함께 일하면서 얻은 지식이나 인사이트들은 메모장에 공부할 주제로 적어뒀으니 틈틈히 정리해 나가야겠다. 덕분에 나 또한 성장의 씨앗을 새롭게 뿌릴 수 있었다.
프로젝트에 참여한 사람들 모두 좋은 서비스를 만들기라는 하나의 골을 향해 달렸다. 팀원 모두 능동적인 자세로 프로젝트에 임했다. 각자 자리에서 맡은 바를 다했다. 개발 프로세스에서 만날 수 있는 위험 요소들은 미리 감지하고, 정리했기 때문에 프로젝트가 원활히 돌아갔다. 방화벽, 데이터베이스, 인증 프로세스 신청, 인프라 자원 신청, 외부 팀 협조 요청 같은 궂은 일들을 맡아주신 팀원분들께 프로젝트 성공에 대한 공훈을 드리고 싶다.
너무 감사하게도 함께 일한 분께 GRIT이라는 책과 함께 감동적인 짧은 편지를 선물 받았다. 이미 한 권 갖고 있지만, 다음 프로젝트를 시작하기 전까지 선물 받은 책을 한번 더 읽어봐야겠다. 책이 두 권이 된 만큼 마음 속에 GRIT을 두 배 더 키워야겠다.
재능 X 노력 = 기술
기술 X 노력 = 성취
재능 X 노력 X 노력 = 성취
이번 개발자 분들도 이전 프로젝트처럼 참여도가 굉장히 높았다. 나와 같은 실수를 하지 않고, 더 많은 것들을 알고 시작하길 바랬다. 내가 개발자 커리어 초반에 버렸던 시간을 그들이 아꼈으면 좋겠다고 생각했다. 나의 에너지가 누군가에게 좋은 자극과 동기 부여가 되고, 나를 밑 거름으로 성장하는 모습을 옆에서 지켜볼 수 있어서 즐거웠다.
댓글남기기