개발사 기술 미팅, 제안한 기술이 우리 서비스에 맞는지 어떻게 확인할까요?

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 기술 이름보다 그 기술을 선택하게 만든 서비스의 조건을 먼저 확인합니다.

• 다른 선택지는 무엇이었는지, 지금 제안의 단점은 무엇인지 함께 들어봅니다.

• 미팅이 끝난 뒤 결정한 내용과 아직 확인하지 못한 내용을 나눠 기록합니다.

개발사 제안서를 받아보면 낯선 기술 이름이 한 페이지에 빼곡하게 적혀 있는 경우가 있습니다.

어떤 기술이 더 좋은지, 이 기술이 정말 우리 서비스에 필요한지 판단하기가 쉽지 않죠. 설명을 들어도 "요즘 많이 사용하는 기술입니다", "확장성이 좋습니다" 정도로 끝나면 결국 어느 개발사의 제안이 더 적합한지 비교하기도 어렵습니다.

그렇다고 발주 담당자가 미팅 전에 모든 기술을 공부해야 하는 것도 아닙니다.

기술 미팅에서 꼭 확인해야 하는 것은 기술 자체보다 왜 우리 서비스에 이 기술을 선택했는지인데요. 같은 기술이라도 서비스의 규모나 출시 일정, 기존 시스템, 운영할 사람에 따라 선택 이유가 달라질 수 있습니다.

오늘은 개발사와 기술 미팅을 할 때 어떤 질문을 해야 제안의 차이를 이해할 수 있는지 정리해보겠습니다.

1. 이 기술을 고른 이유부터 물어봅니다

기술 설명을 들을 때 가장 먼저 확인할 것은 "이 기술이 무엇인가요?"가 아닙니다.

"우리 서비스의 어떤 조건 때문에 이 기술을 선택하셨나요?"라고 물어보는 편이 좋습니다.

서비스에서 중요하게 생각하는 조건에 따라 기술 선택이 달라지기 때문입니다.

고객이 사용하는 화면을 자주 변경해야 하는 서비스인지, 기존 사내 시스템과 데이터를 주고받아야 하는지, 특정 시간에 사용자가 한꺼번에 몰리는지에 따라 개발사가 먼저 살펴봐야 할 부분도 달라집니다.

가상의 예약 서비스를 생각해보겠습니다.

예약 건수가 아주 많지 않더라도 같은 시간대에 여러 사람이 동시에 예약할 수 있다면 중복 예약을 막는 것이 중요한 조건이 될 수 있습니다. 반대로 예약보다는 상품이나 일정을 조회하는 사용자가 훨씬 많다면 빠른 조회와 데이터 처리 방식을 먼저 살펴볼 수도 있습니다.

두 서비스에 같은 기술을 사용하더라도 선택한 이유는 달라질 수 있습니다.

그래서 "빠릅니다", "확장하기 좋습니다", "많이 사용하는 기술입니다"라는 설명만 듣고 넘어가기보다는 우리 서비스의 어떤 조건을 기준으로 판단했는지를 물어보는 것이 좋습니다.

기술 용어가 어렵다면 사용자와 운영자의 관점으로 다시 설명해달라고 요청해도 괜찮습니다.

예를 들어 "이 기술을 사용하면 서비스 운영에서 달라지는 점이 무엇인가요?", "개발이 끝난 뒤 우리 팀이 추가로 관리해야 하는 것은 무엇인가요?"처럼 질문해보는 것입니다.

이렇게 들으면 기술의 장단점을 모두 이해하지 못하더라도 내가 실제로 무엇을 감수하고 무엇을 얻는 선택인지는 파악할 수 있습니다.

아직 확정되지 않은 조건도 구분해둘 필요가 있습니다.

예상 사용자 수나 기존 시스템과의 연동 방식처럼 아직 확인하지 않은 정보가 있다면 이를 확정된 조건처럼 놓고 기술을 결정해서는 안 됩니다. 무엇이 확인되어야 최종적으로 선택할 수 있는지까지 물어보면 이후 제안이 바뀌었을 때 그 이유도 이해하기 쉬워집니다.

2. 다른 방법은 없었는지, 단점은 무엇인지 물어봅니다

개발사가 하나의 기술을 제안했다면 "다른 방법도 검토했나요?"라고 물어보는 것도 좋습니다.

모든 대안을 상세하게 설명해달라는 의미는 아닙니다.

중요한 기술 선택 몇 가지만 골라서 "다른 방식과 비교했을 때 이 방법을 선택한 이유가 무엇인가요?" 정도를 확인하면 됩니다.

예를 들어 여러 기능을 하나의 시스템으로 묶어서 개발할지, 기능별로 나눠 운영할지를 고민한다고 해보겠습니다.

시스템을 나누면 기능별로 독립적으로 변경하거나 배포하기 편해질 수 있습니다. 대신 시스템 사이의 통신을 관리해야 하고 운영해야 할 부분도 늘어납니다.

반대로 하나의 시스템으로 시작하면 초기에는 관리할 대상이 적을 수 있지만, 나중에 특정 기능만 크게 변경하고 싶을 때 제약이 생길 수 있습니다.

어느 쪽이 무조건 좋은 것은 아닙니다.

중요한 것은 우리 서비스의 규모와 개발 이후 운영 방식까지 고려해서 선택했는지입니다.

그래서 장점만 듣기보다는 불리한 조건도 같이 물어보는 것이 좋습니다.

"사용자가 늘어나면 어떤 부분을 다시 검토해야 하나요?"

"운영 담당자가 바뀌면 어려워지는 부분이 있나요?"

"외부 서비스를 사용한다면 요금이나 정책이 바뀌었을 때 어떤 영향을 받나요?"

이런 질문은 미래의 상황을 정확하게 예측해달라는 의미가 아닙니다. 지금 제안이 어떤 조건을 전제로 하고 있고, 어디까지 감수해야 하는지를 확인하기 위한 질문입니다.

개발사를 여러 곳에서 만나고 있다면 같은 질문을 하는 것도 중요합니다.

A 개발사에는 비용을 물어보고 B 개발사에는 개발 기간을 물어보는 식이면 두 제안을 제대로 비교하기 어렵습니다. 같은 서비스 조건과 같은 질문을 기준으로 답변을 받아야 차이가 보입니다.

물론 모든 질문에 바로 답을 내놓는 개발사가 반드시 좋은 것도 아닙니다.

현재 정보만으로 판단하기 어렵다면 그 이유를 설명하고, 무엇을 확인하면 판단할 수 있는지 알려주는 것도 중요한 답변입니다.

오히려 모르는 부분을 모른다고 말하고 확인 방법을 제시하는지를 보는 것이 기술 미팅에서 꽤 중요한 기준이 될 수 있습니다.

3. 미팅이 끝나면 '왜 이렇게 결정했는지'를 남겨야합니다.

기술 미팅이 끝난 뒤 가장 쉽게 놓치는 것이 기록입니다.

회의록에 "A 기술 사용하기로 함"이라고만 적어두면 몇 달 뒤에는 왜 A 기술을 선택했는지 알 수 없습니다.

기술 선택의 배경과 결정 내용을 기록해두는 방법으로 ADR(Architecture Decision Record)을 활용할 수도 있습니다. AWS도 ADR에 결정의 배경과 선택한 내용, 그 결과 등을 기록하는 방식으로 설명하고 있습니다. AWS 공식 가이드

처음부터 거창한 문서를 만들 필요는 없습니다.

미팅에서 논의한 내용을 아래 정도로만 정리해도 충분합니다.

• 어떤 문제를 해결하려고 했는지

• 어떤 선택지를 검토했는지

• 최종적으로 무엇을 선택했는지

• 왜 그 방법을 선택했는지

• 그 선택으로 감수해야 하는 부분은 무엇인지

• 아직 확인하지 못한 내용은 무엇인지

특히 결정된 내용과 검토 중인 내용을 섞지 않는 것이 중요합니다.

"이 방식으로 구현하기로 했다"와 "이 방식을 우선 검토한다"는 전혀 다른 이야기입니다.

아직 개발사 선정 단계라면 실제 구현까지 무료로 검증해달라고 요청하기보다는, 추가 검증이 필요한 부분을 따로 정리하고 그 범위와 비용을 먼저 협의하는 편이 좋습니다.

예를 들어 기존 시스템에서 데이터를 가져오는 방식이 아직 확실하지 않다면, 어떤 자료를 추가로 확인해야 하는지와 실제 연동 테스트가 필요한지를 구분할 수 있습니다.

그리고 담당자가 바뀌거나 요구사항이 달라졌을 때를 위해 결정을 다시 검토해야 하는 조건도 함께 남겨두면 좋습니다.

예상했던 사용자 수가 크게 늘었거나 기존 시스템의 연동 조건이 달라졌다면 처음의 기술 선택을 다시 살펴봐야 할 수 있습니다.

이때 "처음 결정이 잘못됐다"고 보기보다 당시와 지금의 조건 중 무엇이 달라졌는지를 확인할 수 있으면 논의가 훨씬 수월해집니다.

마지막으로 미팅이 끝난 뒤 담당자가 내용을 자기 말로 한번 정리해보는 것도 도움이 됩니다.

"그러니까 이 기술을 선택한 이유는 기존 시스템과의 연동 때문이고, 대신 운영 부담은 이 정도라는 거죠?"

이렇게 요약했을 때 개발사의 설명과 다르다면 그 부분은 아직 제대로 합의되지 않은 것입니다.

모르는 기술을 무작정 검색하는 것보다 개발사와 내가 같은 내용을 이해하고 있는지 먼저 맞춰보는 것이 다음 미팅을 훨씬 수월하게 만들어줍니다.

좋은 기술 제안은 사업과 운영까지 함께 설명합니다

기술 미팅을 개발사의 기술력을 시험하는 자리라고만 생각할 필요는 없습니다.

오히려 우리 서비스에서 무엇이 중요한지 설명하고, 개발사가 그 조건을 어떤 방식으로 풀어내는지 확인하는 자리라고 보는 편이 좋습니다.

제안된 기술의 장점만 듣는 것이 아니라 다른 선택지와 비교했을 때의 차이, 운영하면서 감수해야 할 부분, 앞으로 다시 검토해야 할 조건까지 이해했다면 이후 개발 범위와 비용을 협의할 때도 훨씬 구체적으로 이야기할 수 있습니다.

똑똑한개발자는 웹·앱부터 관리자 시스템과 SaaS까지 다양한 프로덕트를 직접 기획하고 디자인하고 개발해왔습니다.

그래서 기술을 선택할 때도 단순히 어떤 기술을 사용할지에서 끝내지 않고, 서비스의 비즈니스 조건과 기존 시스템, 개발 이후의 운영 방식까지 함께 살펴보는 것을 중요하게 생각합니다.

개발이 끝난 뒤 실제로 누가 서비스를 관리하고 어떤 방식으로 기능을 추가할지도 개발 과정에서 함께 고민해야 할 부분이기 때문입니다.

개발사를 선택하는 과정에서 기술 제안이 우리 서비스에 적합한지 판단하기 어렵거나, 기획 단계부터 개발·운영까지 함께 검토할 파트너가 필요하다면 아래 링크에서 똑똑한개발자와 이야기 나눠보세요. :)