2023 점핏 개취콘에서 인상 깊었던 부분에 대해서 정리를 해보았다.
1부
Session 1. 중요한 건 인터페이스야!
백엔드 개발자가 API를 뚝딱 만들었다.
하지만 프론트엔드 개발자는 다음과 같이 말한다.
이렇게 하면 괜찮은 API겠군! 하고 짠 건데,
프론트엔드 입장에선 그렇지 않은 API인 경우가 종종 있다.
이 경우엔 다음과 같은 문제점이 있다.
바쁘다보니 무작정 만들어주고 API를 넘기는 경우가 있는데,
"이거 어떻게 만들어 주면 쓰기 편하세요?" 또는 "어떻게 만들어지길 원하세요?" 라고 물어보면서,
프론트엔드와 어느 정도의 '틀', 혹은 '약속'이 만들 필요가 있다는 것이다.
그래서 세션 1의 주제는 '중요한 건 인터페이스야!' 이다.
그렇다면 이 문제를 어떤 식으로 해결해볼 수 있을까?
여러 가지 방법이 있지만 그 중 하나는 프론트엔드와 함께 API 설계를 하는 것이다.
API 설계는 백엔드가 할 일이지! 하고 혼자 열심히 붙들고 작성한 다음에 넘겨주는 게 맞다고 생각할 수도 있다.
하지만 그동안 프론트엔드는 API 개발 때까지 기다리는 수밖에 없다.
또한 나중에 다 만들고서 API를 변경하려고 한다면, 그만큼의 추가적인 비용이 발생할 것이다.
그렇기 때문에 개발하기 전에 프론트엔드 개발자와 같이 API를 설계하는 과정을 가지면 좋다고 한다. 일종의 약속을 한 상태에서 개발하기 때문에 나중에 변경될 가능성이 낮아질 것이다.
또한 이미 약속된 상태이므로 병렬적으로 작업이 가능하다.
그래서 API 설계를 프론트엔드랑 같이 하게 되었다면, 문제 없이 술술 풀릴까?
아마 다음과 같은 또 다른 문제가 발생할 것이다.
이는 '무엇을 만들 것인가'를 명확하게 확인하지 않았기 때문에 생기는 문제다.
예를 들어 개발자가 너무 일이 바쁘다고 디자이너 분이 알아서 기획과 디자인을 알아서 하고 문서로 딱 정리해서 전달해야겠다~!
→ 이러면 안된다는 이야기...!
문서로 전달해주는 것은 한계가 있기 때문에, 꼭 소통을 해야한다.
이 문제로 인해 나중에 변경한다면 마찬가지로 비용이 많이 발생하기 때문에,
꼭 초반의 기획 단계에서 개발자는 물론이고 모든 관계 구성원이 참여를 해야한다.
그래서 강연자 분은 강남 언니 조직에 있을 시절에, 일단 빠르게 와이어 프레임을 공유해서 여기에 모든 구성원이 달라붙어 아주 빠르게 피드백을 했다고 한다.
"여기는 개발이 어려울 것 같다.",
"그렇게 하면 사용자가 이해를 못할 것 같다",
"여기 좀만 바꾸면 개발하는 기간이 줄어들 것 같다."
등등...
서로의 의견에 대해서 주고 받고, 내가 모르는 것에 대해서는 이야기하고,
서로 열심히 소통해야 그 제품에 대한 이해도가 높아지고, 그 맥락을 파악할 수 있다.
그렇게 된다면 변경될 가능성도 낮아질 것이다.
좋아! 함께 기획하면서 제품에 대한 높은 이해도를 가지고 완성했다.
이제 출시해서 고객들의 뜨거운 반응을 봐볼까?!
...라고 하면 또 다음과 같은 문제를 마주할 것이다.
이 경우엔 다음과 같은 문제점들이 있다.
이에 대한 하나의 방법으로는 MVP가 있다.
생존할 수 있는 가장 작은 제품을 만들어서 고객에게 일단 빨리 전달해서 반응을 보는 것이다.
물론 이것도 실제 만드는 거라 비용이 많이 드는 편이긴하다.
그래서 프리토타입(Pretotyping)이라는 개념이 있다.
프로토타입(Prototyping)이 실제로 아주 적은 기능으로 만들어 보는 거라면,
프리토타입(Pretotyping)은 그것보다 앞서서 제품을 아예 만들지 않으면서 고객이 이걸 원하는지 확인해 보는 것이다.
예를 들어 '파밀라'라는 제품은 나무 모형에 화면에 붙을 종류들을 그리고,
나무 젓가락으로 스타일러스 펜을 만들어서 이걸 회의 때마다 가지고 다니면서
스케줄로 조정하거나 메모하는 흉내를 내보곤 했다고 한다.
이런 식으로 직접 계속 써보면서 고객들의 반응에 대한 정보를 추측했다.
마찬가지로 '드롭박스'의 경우, 제품을 만들기 전에 제품 컨셉을 유튜브 영상으로 만들어서 올려서 얼마나 많은 사람들이 사전신청을 하는지 체크했다.
실제로 만들려면 기술적으로 오래걸리는 제품이기 때문에, 이런 식으로 미리 검증을 해본 것이다.
또한 강연자님의 경우엔 '숙면'과 관련된 제품을 만들고자 했다고 한다.
사실상 이 제품의 핵심은 '숙면에 도움이 되는 정보를 주기적으로 전달'하는 것이기 때문에, 만들기 전에 고객들의 확인을 받고자 간단하게 카카오톡으로 숙면에 도움되는 정보를 주는 '숙면 플랜'이라는 설문 폼을 받았다고 한다.
그래서 7일 정도 이 플랜을 실행했는데, 재미있게도 고객이 원하고 원하지 않고 문제보다, 숙면과 관련된 콘텐츠를 주기적으로 제공하기엔 역량이 부족하다는 것을 깨달았다고 한다.
일을 하게 되면 우리는 주로 어떤 사용자를 대상으로 어떤 서비스를 제공하는 일을 하게 된다.
예를 들면 내가 서버 개발자로 일한다면 클라이언트 개발자를 사용자 대상으로 API를 제공을 하게 되고,
내가 클라이언트 개발자라면 디자이너라는 사용자의 대해서 그 사람의 디자인을 구현해주는 서비스를 제공하게 된다.
그리고 디자이너는 고객을 대상으로 제품을 디자인하고 만들어서 서비스를 제공하는 일을 하게 된다.
이처럼 우리는 다양한 사용자들을 대상으로 다양한 서비스를 제공하면서 일을 하는데, 이 때 사람들은 본능적으로 자신이 잘하고 잘 아는 것 먼저 하고 싶어하는 욕구가 있다.
그래서 우선순위와 진행방향을 고려하지 않고, 원하는 것 먼저 하다보면 인터페이스에서 문제가 생기게 되거나 추후에 문제가 생겨 점점 더 많은 비용을 지불하게 된다.
그렇기 때문에 이왕이면 위의 사진처럼 반대 방향으로 진행하는 것이 좋다고 한다.
내가 모르겠는 것부터 검증하면 더 적은 비용으로 그때그때 수정할 수 있는 가능성이 높아진다.
따라서...
고칠 때 비용이 많이 드는 거부터 약속을 하자.
그 약속이라는 결과가 바로 '인터페이스'다.
물론 위의 그림과 같은 순서대로 일을 했는데, 뜻대로 가지 않는 케이스가 있을 것이다.
개발해야하는 것 중에서 이게 개발이 될까 안 될까 싶은 게 있다거나,
근데 그게 내가 직접 해 보기 전까진 모르겠다거나...
그래서 나중에 가서 했는데 결국 개발이 안되서 수정을 해야한다거나...ㅠ
그래서 우리는 이처럼 불확실성이 높은 것부터 약속을 해야 한다.
왜냐하면 우리가 주로 불확실성이 높은 것을 미루고 싶어하고,
이에 따라 필연적으로 나중에 고칠 때 비용이 높아지기 때문이다.
따라서 우리가 가장 불확실하게 생각하는 것이 무엇이고,
어떤 걸 마주보기를 가장 피하고 있는지,
오히려 그 불확실하고 피하고 있는 것들을 먼저 보고 약속해야 한다.
물론 항상 케바케를 염두해야 한다.
하지만 대부분 상황에서 이 원리를 적용하면서 돌이켜 생각해 보자는 것.
따라서 불확실한 것, 미루고 싶은 것부터 '약속'을 하자.
그 약속이 바로 '인터페이스'다.
Session 2. 내게 맞는 성장 환경 찾기
세션 2는 간단하게 요약!
- 책과 인강을 보며 이론을 공부하는 것도 좋지만, 직접 '실험'하는 정신도 중요
- MSA 환경으로의 전환에 대하여
MSA는 일하는 조직의 일하는 방식과 엮여진다고 보면 된다.
굉장히 작은 규모이면 모놀로식 환경으로 잘 만들면 된다.
하지만 여러 팀이 생기고 여러 사람들이 서로 작업하는 것을 파악하기 어려워진다?
그러면 MSA 전환을 적극적으로 시도해야 한다.
또한 추후에 확장을 할 수 있는 구조, 또한 늘어나는 트래픽을 받을 수 있는 환경이 갖춰져 있어야 한다.
따라서 MSA로 빠르게 바꿀 수 있는 구조를 초창기에 미리 염두하고 만들어둔다면, 작은 트래픽을 가지고 있는 초반에는 모놀로식이어도 상관없다.
중요한 것은 '나중에 MSA로 바꾸려고 한다면 그때 무엇이 필요한지'
'트래픽이 터지기 시작했을 때 어떤 액션을 할 것인지' 대비가 되어있어야 한다.
Q. MSA를 도입할 때 전환하기 용이한 방식이 멀티모듈 방식이라고 알고 있는데, 서비스가 작아도 커질 것을 예상해서 멀티모듈 방식으로 처음부터 개발하는 것은 어떤지?
→ 좋다고 생각한다.
그 방식이 잘 싱크가 되어있으면 MSA를 적극 추천하지만, 만약 당장 생산성이 좋은 방안이 MSA가 아닌 다른 방안이라면 그쪽으로 하는 편이 낫다.
3. 서버 개발자도 인프라 쪽 지식을 쌓거나 데브 옵스 쪽 경험을 쌓아야 할까요?
백엔드도 점점 더 그런 영역에 대한 이해가 필요해지고 있다.
필요한 순간들이 점점 생길 것이다.
물론 지금은 비즈니스 로직을 잘 짜서 구현하는 게 중요한 시점일 수 있지만,
트래픽이 늘어나는 걸 감안해서 분산환경을 빠르게 대응해야 한다면 이걸 모를 수 없다.
그래서 데브 옵스 경험을 하기보다는 지금 만드는 서비스가 올라가는 환경에 대해서 공부하라.
예를 들어 지금 서비스가 올라가는 환경이 쿠버네티스면 쿠버네티스에 대해서 이해할 것. 앞단부터 내려오는 흐름부터... 어디서 어떻게 응답을 받고 트래픽을 받는지 등 알 필요가 있다.
4. 마지막 주니어 개발자에게 한 마디.
각자 생각하는 것과 이렇게 구현하면 되겠다는 논리적인 흐름들이 있을 것이다.
그 논리적으로 맞다고 생각하면 여러분들의 의견이 맞는 것이다.
당신의 생각을 사람들에게 많이 설득하고 주장해라.
기타 참고해볼 자료
2023 점핏 추천 도서
https://event.kyobobook.co.kr/detail/211493
2022 점핏 개취콘
https://www.jumpit.co.kr/book-concert
2부는 시간이 난다면 언젠가 정리...
