안녕하세요. 인증 스쿼드(Authentication Squad)의 엔지니어링 매니저(Engineering Manager) 하조은입니다.

아래의 글은 마이데이터 프로젝트를 회고한 제 블로그의 글을 옮겨온 것입니다. 프로젝트를 진행하며 했던 고민과 행동 그리고 아쉬웠던 점을 솔직하게 정리한 글입니다. 마이데이터라는 도메인에 국한되지 않은 내용이니 많은 분이 공감하실 수 있으리라 생각합니다. 재밌게 읽어주시면 감사하겠습니다.

마이데이터 프로젝트

21년 4월, 새로운 프로젝트에 참여했다. 뱅크샐러드 자체 인증서인 ‘뱅크샐러드 인증서’와 여러 곳에 흩어진 유저의 데이터를 뱅크샐러드로 연결하는 ‘데이터 연결 기능’을 개발하는 일이었다. 스크래핑(Scraping)으로 데이터를 연결하던 환경을 API로 전환하는 대규모 프로젝트였다. (스크래핑이 API로 대체될 수 있었던 이유는 마이데이터 사업 덕분이다. 마이데이터에 대한 자세한 설명은 이번 글에선 생략하겠다)

이번 프로젝트는 여러 팀이 하나의 TFT(Task Force Team)를 이뤄 일했다. 나는 인증 스쿼드 소속이었다. 개발자 6명을 포함해 총 10명으로 구성된 팀이었다. 나는 인증 스쿼드에서 엔지니어링 매니저와 웹 프론트엔드 개발을 겸했다.

프로젝트 중에 했던 고민과 행동

1. 뭣이 중헌디?

내가 합류하기 전부터 마이데이터 서비스의 기획안이 존재했다. 유저의 편의를 고려해 섬세하게 준비되어 있었다. 첫 번째 마일스톤을 기준으로 역산해보니 모든 기능을 만들기엔 시간이 매우 부족했다. 기획을 쪼갤 필요가 있었다. 정말 중요하고 우선순위 높은 기능을 골라야 했다.

기획 담당자분에게 Pn 커뮤니케이션을 제안했다. 중요한 업무를 P0, P1, P2 순서로 매겨달라는 것. 판단의 기준이 되는 질문은 “해당 기능이 유저에게 핵심 가치를 전달하는가?”이다. “그렇다”는 답변이 나온다면 P0에 해당한다. “그렇지 않다”는 답변이 나왔더라도 해당 기능이 핵심 가치를 조금 더 잘 느낄 수 있다면 P1이 되는 식이다.

분류된 기능을 개발팀과 함께 한 번 더 논의한 뒤 P0, P1으로 분류되는 우선순위 높은 기능 개발에 집중했다. 첫 번째 마일스톤까지 해당 기능을 구현하고 나머지 P2, P3에 해당하는 기능은 점진적으로 구현하기로 했다.

2. 어떤 방법으로 구현할 것인가?

우선순위 높은 기능을 정했다면 구체적으로 어떤 동작이 필요한지 정의해야 했다. 예를 들면 ‘모달(Modal) 컴포넌트가 데이터를 어디까지 수정할 수 있는지’, ‘모달과 다이얼로그(Dialog)는 어떤 상관관계를 가질 수 있는지’ 같은 부분까지 확인하고 정의해야 한다. 이 과정을 통해 요구 사항을 더 분명하게 했다.

다음엔 요구 사항을 어떤 기술로 빠르고 쉽게 구현할 수 있을지 확인했다. 이 과정에서 Next.js와 뱅크샐러드에서 사용하는 웹 - 네이티브 통신 인터페이스인 WNI(WebViewNativeInterface)가 새롭게 도입하는 기술로 꼽혔다.

요구 사항에 맞는 동작을 수행할 수 있는지 확인하기 위해 새로운 기술을 미리 적용해보는 POC(Proof Of Concept)를 시도했다. 요구 사항에 맞는 상황을 연출하고 컴포넌트, 페이지 구성을 샘플로 만들었다. 이 과정에서 우리의 요구 사항을 만족하지 못하는 점을 발견했고 이를 미리 담당 팀에 부탁해서 개선을 요청해두고 다른 작업을 진행했다.

3. 어떻게 해야 협업을 잘 할 수 있을까?

POC를 통해 발견한 이슈나 스쿼드 자체 역량으로 해결하지 못하는 문제를 만났을 때는 다른 팀과의 협업이 필요했다. 분명한 요구 사항을 문서로 간단하게 정리하는 게 협업의 시작이었다. 이 문서가 뱅크샐러드에서 1 Pager라고 부르는 회의 문서다.

1Pager는 요약, 목표, 목표가 아닌 것, 계획, 마일스톤으로 구성된다. 그 중 ‘목표가 아닌 것’은 보통 곁다리로 함께 해결하고 싶은 욕구가 드는 문제를 적었다. 살짝 얹어가도 될 것 같은 작은 문제처럼 보이지만 사실 본질(목표)에 집중하는 데 방해만 되는 경우가 많기 때문이다.

이렇게 분명하게 요구 사항, 목표가 아닌 것을 정리한 뒤 협업을 해야 하는 담당자와 회의를 통해 구체적인 계획을 논의했다. 회의에서 담당자를 분명하게 정했다. 일의 순서와 대략적인 마감 일자도 정하면 완벽. 회의는 가능하면 30분 안으로 끝냈다. 모두의 시간은 소중하니까.

1Pager로 정리된 계획을 바탕으로 지라(Jira)에서 티켓을 생성했다. 티켓을 하나 만들고 작성한 문서의 링크를 걸어둔 뒤 하위 티켓으로 회의에서 나온 계획을 티켓으로 만든다. 담당자, 순서, 마감 일자도 정해졌으니 모두 입력. 개발자들은 지라 티켓 번호를 기반으로 브랜치를 생성하고 업무가 진행됐다.

프로젝트 중 아쉬웠던 행동에 대한 회고

1. 더 나은 방식에 대해 질문하지 않았던 것

Next.js와 WNI 도입은 점점 고도화되고 늘어나는 웹 뷰 서비스 개발을 위한 불가피한 선택이었다. Next.js 도입은 패턴을 통일해서 여러 팀 간의 코드 리뷰 용이성을 높이고 레포 설정 시간을 단축하는 게 목표였다. WNI는 범용적인 인터페이스를 구현해 웹과 네이티브의 경계를 허물고 사용성 좋은 웹 뷰 서비스를 구현하는 게 목표였다.

하지만 목표가 아닌 것에 시간을 쏟는 경우가 잦아졌다. 신기술을 도입하는 과정에 예상치 못한 이슈를 만들어 일정이 지연되는가 하면 당장의 문제만 해결하는 방식으로 인터페이스를 구현해 유지보수가 어려운 상황을 만들기도 했다.

생각해보면 새로운 기능을 추가할 때는 목표와 목표가 아닌 것을 구분 지으면서 새로운 기술을 채택할 때는 그 기준이 낮았던 거 같다. 무엇보다 지금 하는 방식보다 나은 방식이 없는지 한 번 더 질문하지 못했다.

서비스 개발에선 신기술을 배우는 즐거움보다 약속한 시각에 제품을 만드는 게 중요하다. 한편으론 당장 빠르게 문제를 해결하는 방법보다 나중에도 높은 생산성을 유지할 방법을 고민해야 한다. 늘 더 나은 방식에 대해 한 번 더 물어보자.

2. 초과 근무가 당연한 상황을 만든 것

프로젝트를 진행하며 야근, 주말 근무 등의 초과 근무가 잦았다. 물론 소프트웨어를 개발하는 회사에선 초과 근무가 잦은 편이다. 그럼에도 초과 근무를 당연한 선택지로 생각한 건 잘못된 판단이었다. 이로 인해 육체가 상하고 정신적으로도 많이 지쳤다.

초과 근무를 통해 목표를 달성하는 방식은 최후의 선택지가 되어야 한다. 초과 근무 없이 일정을 달성할 방법을 먼저 생각해야 한다. 일을 줄이거나 생산성을 끌어올릴 수 있는 툴을 도입해보자. 그래도 안 된다면 추가 인력을 투입할 수 없을지 확인해보자. 소프트웨어를 개발하는 일은 단거리 달리기가 아니라 장거리 마라톤이다. 오래 꾸준히 일할 방법을 늘 고민하자.

3. 회사 프로젝트에 너무 많은 의미를 부여한 것

예전 발표에서 회사의 성과와 개인의 성과를 구분 지어 생각할 수 있어야 한다고 했는데 정작 스스로 그러지 못했다. 다시 한번 스스로 말하자면 회사의 성과가 곧 개인의 성과가 아니다. 회사 프로젝트의 성과는 너무 많은 변수의 영향을 받는다.

결국 그 변수를 모두 통제하고 성과를 내는 게 역량이지 않냐며 강경한 자아가 날카롭게 노려본다. 그래, 역량 부족이다. 하지만 내 역량이 부족하다고 너무 자책하지 말자. (회사가 잘했다고 내가 잘한 것도 아니다) 내가 잘하는 일을 찾고 역량을 키울 방향을 고민해야 한다. 그래야 지치지 않는다. 회사에서 한걸음 물러나야 한다.

내가 여전히 잘하고 더 잘할 수 있는 일을 발견하기 위해 별도의 작은 사이드 프로젝트가 필요하다. 프로젝트라고 해서 거창할 필요도 없다. 글쓰기, 운동과 같은 소소한 성취감을 주는 일이면 족하다. 그래서 올해는 더 꾸준히 글을 쓰고, 달리고 자주 휴가를 쓸 계획이다.

새로운 가능성과 갈증

1. 엔지니어링 매니저로서의 가능성

서두에서 밝힌 것처럼 인증 스쿼드는 ‘뱅크샐러드 인증서’와 ‘데이터 연결 기능’을 운영하고 있다. 21년 4월에 첫 삽을 뜬 서비스가 22년 2월에는 뱅크샐러드의 온보딩 과정을 책임지는 주요한 서비스가 된 것이다. 두 가지 서비스를 안정적으로 관리해서 지금까지 왔다.

강경한 자아가 다시 고개를 들어 네가 한 게 뭐가 있냐고 내 부족함을 말하기 시작하면 끝이 없다. 하지만 또 인정할 건 인정하자. 가능성이 있다. 프로젝트를 관리하고 개발자들 간의 업무를 조율하는 능력이 있다. 앞으로 기대가 되는 점이다.

2. 깊이에 대한 갈증

굳이 강경한 자아의 목소리를 듣지 않더라도 개발자로서 역량이 부족한 건 사실이다. 매년 평가에서 기술적으로 부족하다고 인정하고 있다. 일이 되게 만드느라 바빠서 공부할 시간이 부족했다고 더는 핑계 대고 싶진 않다.

올해는 일찍 퇴근해서 공부하는 시간을 확보하자. 이미 알고 있던 것(함수형 프로그래밍, 웹)을 더 알아보자. 그리고 지금 맡은 인증에 대해서도 꾸준히 공부하자. 솔직히 말해 인증 방식에 대해 너무 모른다.

물론 이 일을 관두는 순간까지 끊임없이 부족함을 느낄 것 같다. 연차가 쌓일수록 부끄러움도 함께 쌓여간다. 적당한 부끄러움을 유지하기 위해서라도 꾸준히 노력하고 공부하자.

---

출처: 하조은의 블로그 - 2021년 프로젝트에서 배운 것들