팀 협업 특강 - 쏘카 지두현 개발자님

스타트업 아키텍처

• 스타트업도 모노리딩(?)부터 시작한다. 거기서 legacy가 만들어진다. 계속 챌린지를 해야한다.

• 모든 아키텍쳐는 그 조직이 소통하는 방식대로 이루어진다.
• 조직이 scale-out한 체계를 가져야 서비스 아키텍처가 만들어진다.
• scale-out = 장비를 추가해 계속 확장해 나가는 방식

• 구성원들이 보는 방향은 하나여야 한다.

• 추구하는 방향을 완성시키기 위해 로드맵을 리더십 레벨에서 작성한다.
• 이 방향성은 돌발상황이 있을 수 있기 때문에 무조건 100% 맞지않다.
• 하지만 분기마다 어떤 것을 해야할지 따져보고 집중할 수 있다.
• 분기마다 정해진 부분들을 각 개인에게 맡긴다.

스프린트

• 2주 ~ 3주 단위

• 스프린트는 그냥 단순한 단위로 생각하면 안된다. 끝나지 않는 마라톤을 달리는 건데 그 사이사이 달리는 단위를 스프린트라고 하는 것이다.

• 결과 없는 스프린트는 의미가 없다. 스프린트에서 가장 중요한 것은 DEMO다

• PM 등이 User Story를 결정하여 스프린트가 시작된다. 그 이후 User Story를 위한 기능들을 분해작업한다.
• task의 최대실행 단위는 2일이어야한다. 그것을 쪼개야한다.



• 팀은 스프린트를 하면서 발전해나가야한다.
⇒ 그래서 측정을 해야한다. 우리팀의 속도는 어느정도인지

User Story

• User Story A : 차를 만들기 위한 가장 기본적인 기능
• 바퀴 4개, 차체 , 엑셀 밟으면 시동 켜짐 등등이 있어야한다.
• 이런 기본 기능을 구현해서 demo작업을 하고 피드백을 받아야 한다.
• 또 어떤 조건들이 필요한지 추가하는 단계가 Planning이다.

MVP (Minimum Viable Product)

• MVP 를 찾고 그 제품의 중요한 가치를 찾고 피드백을 위한 데모를 한다.

• 사용자의 니즈(고객, 환경)도 얘기해야한다.

• User 스토리 ( 어떤 고객 관점에서 어떤 기능이나 동작을 제공하려고 한다 )를 바탕으로 개발을 시작한다.

• 2~3개 스프린트에서 MVP가 결정되고 그 뒤에 뼈대(Skeleton)이 나온다.

Demo (피드백)

• 고객의 반응이 가장 중요하다.

• 어떤 것을 보여줄지(Demo) 결정하고 시작하는 것이 좋다.

• Demo는 뭔가 동작하는 결과가 있어야한다. 물론 맨 처음에는 동작하는 결과가 아닌 MVP를 찾아가는 여정일 수 있다.

• performance 결과는 데모의 수치가 된다.

회고

• 스프린트 마다 회고 시간을 가지는 것이 좋다

• 잘하고 있는것 개선해야 하는것을 딱 하나만 찾아라. 그것을 다음 스프린트에 추가해라

스프린트 Ownership

• 스프린트 의사결정 담당자가 있어야 한다 ⇒ BO

• 스크럼 회의(공유할 점, 버그 이슈 등등) ⇒ TL이 시간안에 얘기할 수 있도록 이끈다

스프린트 목표

• 데모를 무조건해서 그 피드백을 통해서 개선점을 찾자

• 일주일단위 스프린트는 의미가 없다 ⇒ 일주일안에 동작가능한 앱을 만드는게 말이 안되기 때문이다

스프린트 최종 예시

• 배포할 날을 무조건 정해야한다. 배포할 날을 정하지 않으면 일이 밀린다!

• 미래 동료들을 위해 배포 관련 문서를 작성해놔야 한다.

• 투명하게 공개해야 한다.

인터뷰어 교육 참고 자료

• learning은 영.원.하.다

• 어떻게 성장을 해야 할까?
• 입사해서 1~2년차에는 많이 배운다.
• 현장의 어떤점을 제대로 배울 건지 배움의 기회를 포착해야 한다. ⇒ 경험치를 쌓아야한다.
• 배운 개념을 써먹을 기회를 찾아야 한다 ⇒ 토이프로젝트를 말하는 것이 아니다. 사용자의 traffic을 찾아서 개발하고 리팩토링해보는 프로젝트를 해야 한다.

• 다른사람을 성장시킬 수 있는 바탕이 없느냐가 신입이라는 계급을 떼어내는 것이다.

• 3~4년차 주니어 엔지니어
• 최소 2개의 언어를 해야한다.
• 서비스 환경을 이해해야 한다.
• 서비스의 구조를 설명할 수 있어야 한다. ⇒ class diagram, component diagram, sequence diagram 등등으로 그릴 수 있어야 한다.
• 마이크로 서비스 하나는 만들 수 있어야 한다 ⇒ 시니어로부터 피드백 받기

• 7~8년 정도 되면 Senior Engineer라고 한다.