센스 있게 일하는 BE (백엔드) 개발자 되기
[점핏] 백엔드 개발자 이야기 - 중요한건 인터페이스야 강연을 듣고 제 경험을 빗대어 정리한 글입니다.
중요한건 인터페이스야
🥰 강의 중요 포인트: 개발을 잘하는데에는 도움이 된다.
본론으로 들어가기 전에 제목을 보고 개발에서 사용하는 인터페이스를 생각했으나, 프로젝트 (제품) 에 대한 이야기가
주가 된 이야기를 들으면서 리드 개발자분은 어떤 생각을 하면서 업무에 임하는구나를 새삼 느끼게 되었습니다.
🤝 커뮤니케이션
- 프로젝트를 진행하면서 혼자가 아닌 팀 단위일 때 서로 커뮤니케이션이 중요한데 강연자님께서 경험을 빗대어 해결 과정들을
제시를 해주었습니다.
서버 개발자의 사례로 예를 들어보자면
A (서버 개발자) / B (클라이언트 개발자) 가 있는데 회원가입 API를 진행하기로 했는데 진행하기로만 하고
A 가 혼자서 개발을 진행을 완료하였습니다. 그 후 B에게 회원가입 API가 완료되었다. 라고 공유해주는데
이 때 B 입장에서는 `이거 클라이언트에서는 처리하기가 어렵게 되어있는데요.`
필자도 서버 개발자로써 클라이언트 팀과 상의 없이 일정에 쫓겨 API를 금방 만들고 전달하면
곧장 돌아오는 대답이였습니다.
강연자님께서는 이 때 해결 과정으로 커뮤니케이션을 꼭 집어서 이야기해주셨습니다.
서버 개발을 하기 전에 클라이언트 개발자와 같이 API를 설계한다.
정말 중요한 내용이라고 생각합니다. 서버 개발을 하기 전에 클라이언트 개발자와 사전에
API 명세서 규칙 / 파라미터 규칙만 정해져도 아래와 같이 큰 생산성으로 이어지게 됩니다.
1. 각자 병렬적으로 작업이 가능
2. 이미 정한 규칙이 있기 때문에 최소한의 변경해야할 가능성이 생긴다.
또 다른 예로 디자이너 / 기획자로 들자면
당시 어떤 어떤 기능이다. 라고 듣고 만들기 전에 무엇을 만들 것인지 명확하게 확인하지 않고 개발을 진행하게 되면
결과물을 디자이너 / 기획자에게 전달이 됐을 때
`제가 원하던 거랑 동작이 좀 다른 것 같은데요?`
강연자님께서도 언급하시는 부분이지만 무엇을 만들 것인지 정하는데 개발자들이 솔선수범 참여하지 않는다. 라는 말에
정곡이 많이 찔렸습니다.
필자도 업무가 많이 미숙하던 시절, 무언가 기능을 만들 때 이런 생각을 줄곧 해왔습니다.
나보다는 저 분들이 전문가니까. 나는 개발자니까 개발만 하면 되지.
이런 마음가짐을 가지면서 개발에 임하게 되면 기능 자체는 돌아갈 수도 있겠지만 보통 작업하면서
당시에는 보이지 않던 부분들이 벽에 부딪혀 개발이 진전이 되지 않는 일들이 빈번하게 일어나게 됩니다.
이 때문에 개발자라면 '개발 중심적인 사고가 아닌 비즈니스 마인드' 라는 마인드를 함께 임하는게 좋다고 생각합니다.
이걸로 유명한 영상이 하나 있는데 시간이 괜찮다면 영상 시청하는걸 추천합니다.
종합적으로 개발자도 어떤 비즈니스적인 문제를 해결해나가는 사람으로 생각이 듭니다.
개발자가 비즈너스적인 마인드를 가지게 되면 실무에서 이러한 효과들이 나타난다고 생각합니다.
1. 함께 제품을 기획함으로써 모든 구성원이 제품에 대한 이해도가 높아진다.
2. 모든 구성원이 자신의 전문성을 함께 활용하면서 기획을 하기 때문에 좋은 결과물이 나온다.
마지막으로 고객의 사례로 예롤 들어봅시다.
이렇게 함께 기획하면서 제품에 대한 높은 이해도를 가지고 따끈따근하게 출시를 해서 고객들의 반응을 확인해봅니다.
`이건 제가 원하는 것이 아닌데요?`
필자도 여러 서비스를 개발하고 런칭을 하면서 사내에서는 무조건 성공하겠다. 라고 생각했던 서비스들이 실제로
출시가 되면 고객의 평가는 냉담했습니다.
보통 프로젝트를 시작할 때 정말 좋은 아이디어다. 시작해보자하고 진행하는 부분이 많아,
실제로 고객이 원하는 제품인지 미리 확인을 하지 않았고 고객의 생각에서는 이게 꼭 필요하지 않는 서비스일 수도 있기
때문에 우리와의 생각이 다른 상황들이 발생합니다.
이 때 고객의 생각을 미리 확인할 수 있는 방법이 무엇이 있을까 하는데 아래의 두 가지로 예를 들겠습니다.
🚗 MVP (minimum viable Product)
MVP는 생존하기 위한 최소한의 기능을 구현한 제품을 뜻하는데 고객에게 빨리 전달하고
고객의 반응을 확인할 수 있는 장점이 있는데 결국 제품을 만들어야 하기 때문에 비용이 든다는 부분이 있습니다.
그러면 실제 제품이 만들어지지 않아도 직접 검증할 수 있는 방법은 없을까? 라는 생각이 듭니다.
🦉 Pretotyping (Pre + Prototyping)
MVP와는 다르게 실제 제품을 만들지 않으면서 고객이 원하는건지 확인할 수 있는 방법입니다.
예시로 팜이라는 회사에서는 직접 메모장에 그림을 그려 일상생활 속에서 직접 흉내를 내보고
이러한 방법으로 사용할 수 있겠구나 등 정보를 얻을 수 있습니다.
MVP에 비해 굉장히 값싸게 검증을 할 수 있다는 장점이 있습니다.
서버로 예로 들자면 우리가 API를 설계할 때 바로 구현을 하는게 아니라 미리 상상을 해보거나 메모장에 적어서
여러 케이스들을 확인 해보는 방법이 있습니다.
필자는 API 설계를 할 때 패드나 메모장에 직접 상상하면서 유저들이 어떠한 행동들을 할지 적습니다.
결제 API 기준을 잡고 간단하게 적으면
구매가 가능한 제품인지 > 유저가 구매할려는 제품의 금액이 맞는지 (쿠폰, 할인 등) >
금액은 맞는데 이 제품의 정보가 변동된게 있는지 > 결제가 정상적으로 이루어진 건지 등
사람마다 각자 생각하는 부분들이 달라 완벽한 케이스를 잡을 수는 없지만,
고려하지 않고 설계하는 것과는 달리 사전에 미리 예방할 수 있는 장점이 있습니다.
🐳 Interface
사람들이 택하는 일하는 방식은 내가 잘하고 잘 알고 자신 있는 불안하지 않는 것부터 하고싶어하는 패턴이 있습니다.
이러한 이유들로 인해 나중에 어떤 interface에서 문제가 발생할 때 비용이 더 크게 발생된다는 문제점이 있습니다.
필자의 경험을 빗대어 말해보자면 개발할 떄 리스크가 있는 부분보다 리스크가 없는 개발을 하는게
심리적으로 더 하고 싶어하는 부분이 있습니다.
그러다 보니 어려운 기능들은 일정을 많이 뒤로 미루고 쉬운 것부터 빨리 빨리 처리를 하게 되었는데,
초반에는 회사에서 보기엔 진행률이 매 번 크게 크게 바뀌니 생산성이 되게 빠르구나라고 느껴질 수 있지만
일정이 마무리 되어가고 있는 후반부에서는 매우 저조한 진행률이 발생하게 됩니다.
불안하거나 잘 모르는 부분들을 먼저 검증을 시작하게 되면 일정을 계획하거나 어떻게 해결해 나갈건지
확인할 수 있어 사전에 방지가 가능합니다.
1. 불확실성이 높은 것 부터 약속하기
2. 미루고 싶은 것부터 약속하기
강연자님께서는 끝으로 case by case 라고 해주셔서 필자의 경우에도 이 부분은 상황에 따라서
유동적으로 정하는게 효율적이라고 생각한다.
