Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie AKC2020 인썸니아 이성훈
Ähnlich wie AKC2020 인썸니아 이성훈 (20)
Mehr von AgileKoreaConference Alliance
Mehr von AgileKoreaConference Alliance (15)
AKC2020 인썸니아 이성훈
- 1. 스타트업 플랫폼을 적은 비용으로 안전하게 개발하는 애자일한 방법 -- 스타트업 플랫폼 전문 개발사, 인썸니아 insomenia.com 이성훈 대표 1
- 2. 스타트업, 애자일, 개발에 대해 잘 아는 사람인가요? 연세대 컴퓨터 전공, 16년 차 개발자 8년 간 6개 스타트업에서 신입부터 CTO까지 근무 2013년에 인썸니아 창업해 스타트업 개발업 8년 차 2007년부터 애자일 서적 30권을 스터디하며 애자일을 실험/적용 https://brunch.co.kr/@jamess 스타트업, 개발, 애자일 글 연재중 2
- 3. 인썸니아는 스타트업 플랫폼 전문 개발사 포스코, 제일기획, 패스트캠퍼스, 롯데 등 대기업/중견기업 고객사 펫트너, 리트니스, 겟차, 클링크, 세이 등 스타트업 초창기 플랫폼 구축 캐시노트, 피플펀드, 펀다, 헬로네이처 등 대형 스타트업의 신규 프로젝트 담당 풀스택 개발자 20명으로 구성 월매출 1.5억, 연매출 20억 200개+ 스타트업 프로젝트를 애자일한 방식으로 완수 3
- 4. 스타트업 프로젝트는 뭐가 다른가요? 4
- 5. 예산의 크기가 다름 초기 스타트업은 예산이 한정적 (대게 5천만 원 이하) 출시 후에는 투자유치나 매출 발생 등으로 자금사정이 좋아지지만 출시 전에는 그것이 어렵기 때문에 가성비 좋은 개발이 중요 정부 창업지원사업 비용을 집행하는 경우가 많음 (고객사 중 50%) 5
- 6. 예산 비교 대형 SI: 수억 ~ 수백억 스타트업: 3천 ~ 1억 홈페이지/쇼핑몰: 500만 ~ 2천만 6
- 7. 복잡도의 크기가 다름 플랫폼이 단순하지도 않지만 그렇다고 아주 복잡하지도 않음 아주 단순하거나 아주 복잡하면 확정적인 기획과 워터폴이 적합할 수 있음 7
- 8. 복잡도 및 리스크 비교 대형 SI > 스타트업 플랫폼 > 홈페이지/쇼핑몰(호스팅) 8
- 9. 기획의 불확실성 기획이 불확실하거나 개발 과정에서 변경 가능성이 큼 고객사는 개발 관련 경험과 지식이 부족함 사용자의 니즈를 발굴해나가야 하는 스타트업 특성상 기획의 변경과 기능의 추가/보완을 제약하는 것이 아닌 허락하고 장려하는 개발 방식이 필요해짐 9
- 10. 지속적인 개선이 필요 출시 후 프로젝트 종료가 아니라 운영 과정에서 기능 개선이 필수 장기적인 유지보수를 보장하지 못하면 스타트업 입장에서는 재개발 리스크 개발 완료 후 인수인계, 코드리뷰 등 고객사의 개발 내재화를 지원해야 함 10
- 11. 효율적인 의사결정 고객사 측 이해관계자가 소수이므로 소통과 의사결정이 빠름 개발 사이클이 1주~2주 정도로 짧아도 고객사가 바로 확인하고 피드백을 줄 수 있고 개발자과 고객사의 논의도 빠르게 진행 가능 11
- 12. 우리의 과제 애자일을 도입하는 것 (X) 고객사와 개발자를 동시에 만족시키면서도 이익을 내는 것 (O) 12
- 13. 어떤 방식으로 개발해야 프로젝트가 안전하게 성공할까? 스타트업 규모에 가장 쓸모 있는 애자일 실천방안은 무엇일까 13
- 14. 결과물을 최대한 빨리 보여주기 프로젝트 착수 후 1~2주 차부터는 동작하는 구현 결과물을 고객사에게 공유 디테일한 기획은 불명확해도 핵심 사용자 로직은 대부분 결정된 상태 확정된 핵심 플로우를 간단하게 구현해서 동작하는 모습을 고객사가 보게 되면 원했던 세부사항이 무엇이고 어떤 방향으로 가야 하는지 가닥을 잡기 쉬움 최종 결과물까지의 구현 흐름을 계속 지켜보면서 고객사도 개발 과정을 학습하게 됨 결과물에 대한 피드백을 주면서 최초 사용자로서의 사용 피드백도 반영하게 됨 14
- 15. 핵심적인 부분부터 개발하기 필수적으로 우선 구현되어야 하는 것부터 구현 차후에 구현되어도 되는 것은 개발 예산/기간 상황에 따라 나중에 판단 구현이 되어도 되고 안 되어도 되는 것은 위의 사항이 구현된 후에 판단 요구사항은 있지만 꼭 기획된 방식이 아니어도 되는 것은 개발 효율적인 방식을 선택 예산과 기간이 한정되어 있기 때문에 선택과 집중을 하도록 유도 이때 기능별 예상 견적을 제시하는 것이 빠른 의사결정에 도움 15
- 16. 투입 인원과 직군이 많아지면 비용이 증가합니다 16
- 17. 업무 분장 지옥 저는 프론트엔드만 하는데요? 백엔드만 하는데요? 퍼블리싱이 나와야 제가 손댈 수 있어요, 그 부분은 프론트에서 고쳐줘야 돼요 API 개발자랑 협의해야 하는데 연락이 안 돼요 프로젝트 매니저가 일정을 너무 빠듯하게 잡았네요 아직 기획서가 업데이트가 안 되었어요 디자이너가 시안을 줘야 진행할 수 있어요 17
- 18. 일반적인 프로젝트 진행 상황이겠지만 저희는 이런 상황을 피해보기로 했습니다 18
- 19. 프로젝트 매니저의 역할을 개발자가 담당 프로젝트 개발을 위해 필요한 인원을 최소화 인썸니아는 PM 역할을 메인 개발자 담당하여 PM직군이 따로 없음 메인 개발자가 직접 고객사와 소통하고 개발하고 개별 기능의 공수 및 일정 파악 PM이라는 중간 과정이 없어서 소통이 간결하고 중복 및 소통 오류가 사라져 효율성 3배 개발자의 적극적이고 친절한 커뮤니케이션 태도가 중요함 사실 PM 직군의 경력에서 비개발자로서 어깨너머로 배우는 개발지식의 비중이 높음 19
- 20. 개발자가 소통을 잘 못하면요? 소통을 잘한다는 것은 능력이나 지식보다는 태도의 측면 개발자의 커뮤니케이션 태도는 애자일에서의 핵심 전제 개발자 채용 과정부터 소통의 태도를 가장 중요하게 고려 자신의 생각을 개발 관련, 비개발 관련 모두 조리 있게 표현하는가, 표현하려고 하는가 혼자 똑똑한 천재보다는 적극적으로 소통하고 다른 사람과 원활하게 협업하는 진득한 사람 고객사에 대한 개발자의 태도가 좋으려면 소속 개발사에 대한 개발자의 태도가 좋아야 함 좋은 개발자를 채용하고 개발자와 개발사가 장기적으로 좋은 관계를 맺어야 가능함 20
- 21. 회사와 임직원의 장기적으로 좋은 관계란 좋은 태도는 안정적이고 장기적인 관계에서 온다 보상과 동기부여, 커리어 성장, 문화 등 HR까지 포괄하는 영역 애자일의 근본으로 올라가면 회사와 임직원, 임직원과 임직원 간의 신뢰가 전제 21
- 22. 개발 파트의 업무 분장을 제거하려면? 22
- 23. 풀스택 개발자 서버 개발자가 퍼블리싱이 끝나기를 기다리지 않아도 되고 프론트엔드 수정이 필요하면 본인이 직접 해결함 구현 공수와 개발 일정, 적용 가능 여부 등을 바로 판단 프로젝트 개발 전반적인 사항을 모두 알고 있어 의사결정, 고객사와 소통, 구현 완료 후 공유 등을 바로 진행 23
- 24. 풀스택 개발자를 찾는 게 아니라 신입을 풀스택 개발자로 양성 24
- 25. 신입 개발자 트레이닝 모든 개발자를 프론트엔드/백엔드 풀스택으로 트레이닝 2개월간 급여를 지급하면서 트레이닝에 집중 수 백만 원 가치의 부트캠프 수준의 교육 구현 방식을 표준화하고 필수 지식부터 단계적으로 교육 25
- 26. 루비온레일즈에 집중 루비온레일즈 자체가 프론트/벡엔드 통합이 쉽고 교육과 학습이 빠른 웹개발 프레임워크 애자일 창시자들이 애용한 대표적인 애자일 개발 프레임워크 풀스택 개발이 용이하고, 적은 코드만으로 기능 구현 당근마켓, 마이리얼트립, 카카오, 리멤버, 왓차 등 빠른 개발 대응으로 급성장하는 스타트업이 사용 단일 프레임워크를 전 직원이 구사하므로 누구든 인수인계 가능 26
- 27. 비용이 어떻게 낮아질 수 있나요? 메인 개발자가 PM 역할, 루비온레일즈, 풀스택로 개발/소통 시간 단축 개발자 숙련도에 맞추어 난이도/리스크별 업무를 분산 개발비를 프로젝트/기능 단위로 청구하지 않고 시간 단위로 청구 기능구현이 끝난 후에 디자인 개선 작업을 선택적으로 진행 자주 구축하는 기능을 사전 구축 또는 코드 라이브러리, 도큐먼트로 재사용 27
- 28. 숙련도별 개발자의 역할 분산 숙련도에 따라 백업, 메인, 서브 개발자로 나누어 프로젝트에서의 역할을 분산 테스크를 병렬적으로 나누는 것이 아니라 숙련도에 맞는 역할을 나누는 것 대게 프로젝트별로 백업 1, 메인 1, 서브 1 투입 28
- 29. 백업 개발자 많은 프로젝트 경험과 높은 숙련도를 가진 개발자 리스크가 높은 프로젝트 착수, 프로젝트 설계 기술적 난이도가 높거나 담당 메인 개발자가 경험이 부족한 부분을 백업 백업을 맡은 개발자는 시간당 비용 책정이 높으므로 프로젝트별로 적은 시간만 투입 29
- 30. 메인 개발자 메인 개발자가 프로젝트 전반적인 기능을 책임지고 고객사와 직접 커뮤니케이션 가장 많은 시간을 프로젝트에 투입하고 프로젝트를 관리하는 핵심적인 역할 30
- 31. 서브 개발자 서브 개발자는 메인 개발자가 중요 부분을 구현할 수 있도록 UI나 낮이도 낮은 기능을 개발 UI 등은 시니어이든 쥬니어이든 구현 시간이 오래 걸리는 부분 상대적으로 시간당 비용이 낮은 개발자가 해당 부분을 담당 신입이 서브로 시작해 메인, 백업까지 성장하는 장기적인 커리어 관리 31
- 32. 개발비를 시간 단위로 청구 프로젝트 계약 금액을 확정하지 않고 대략적인 예상 견적만 안내 실제 개발 비용은 개발자들의 작업 시간에 따라 청구 예상 견적이 넘지 않도록 개발자들이 비용 상황을 신경쓰면서 진행 고객사와 계약 전 개발비 협상을 할 필요 없고 예산에 맞추어 구현 가능한 기능을 논의 대기업이나 스타트업이나 일관된 방식과 동일한 시간당 금액으로 비용 청구 작업 시간을 줄이면 고객사의 비용이 절감되니 개발 효율성을 고려한 의사결정을 함께 내림 32
- 33. 디자인을 나중에 하는 이유 33
- 34. 디자인의 일반적인 순서 홈페이지, 쇼핑몰은 디자인이 중요하여 시안 과정이 필수 일반적인 워터폴에서는 기획 -> 디자인 -> 퍼블리싱(프론트엔드) -> 서버개발(백엔드) 34
- 35. 스타트업 프로젝트에서는 리스크가 높아짐 디자인이 끝나기 전에는 중요한 개발이 시작조차 되지 않는 방식 디자인만 먼저 보이면 디자인 단계에서 너무 많은 선호와 피드백을 반영 개발을 고려하지 않은 디자인이 나오고 않아 디자인에 맞추느라 비용 증가 35
- 36. 스타트업 플랫폼에서 디자인이란 초기 스타트업에게는 디자인이 적당한 수준이면 충분 크리에이티브함보다는 말끔하고 단조로운 디자인이 트렌드에 맞고 사용성 높음 스타트업 프로젝트가 실패하는 이유는 디자인 때문이 아니라 개발 때문이고 개발 비용의 대부분을 심미성보다는 플랫폼의 기능 구축에 투입해야 함 36
- 37. 기능구현이 끝나고 나서 디자인하기 인썸니아는 개발자가 사전에 준비된 기능/디자인 컴포넌트로 기능을 먼저 개발 개발자 선에서는 디자인의 완성도가 높지는 않지만 출시 가능한 수준 선택적으로 디자이너와 퍼블리셔가 프로젝트 후반부에 투입 구동되는 기능에 디자인을 입히는 방식으로 진행되어 소통이 쉽고 안전함 37
- 38. 이렇게 해서 이익을 낼 수 있나요? 38
- 39. 지속가능한 개발 비즈니스를 위해 현재 영업이익율 40% 향후 교육 과정을 온라인/자동화하여 초기 트레이닝 비용을 낮추고 앱/웹 빌더 및 사전 구축 기능으로 개발 시간 더욱 단축 개발 비용을 유지하고 이익율을 높이거나 개발 비용을 낮추고 점유율을 높일 수 있는 선택지 이익을 내야 지속 가능한 사업을 할 수 있음 고객사 입장에서도 담당했던 개발사가 업을 지속하는 것이 중요 39
- 40. 개발자만 고생하는 것은 아닌가요? 매월 시급 천 원 인상, 신입 입사 후 20개월 근무 시 연봉 6천 신입 -> 팀원 -> 팀장 -> 본부장급으로 커리어 성장 관리 야근/초과근무/주말근무 없고 근무 시간과 비례하여 급여 지급 재택 근무, 자율 근무 장려 40
- 41. 고객사가 이런 개발 방식에 동의하나요? 41
- 42. 동의하는 고객사 프로젝트만 수주 이런 방식이어야 모두가 행복하다는 경험과 확신 프로젝트가 실패하지 않고 모두 성공적으로 완수되고 있어 평판 유지 기존 고객사의 추천으로 새로운 고객사들도 방식에 대해 이해함 SNS 등을 통해 이런 진행 방식의 장점에 대해 설명하다 보니 이런 진행 방식 자체를 신뢰하여 의뢰하는 고객사가 늘고 있음 42
- 43. 대기업/중견기업 프로젝트도 이런 방식이 가능할까? 대기업 고객사도 사내벤처, 신규사업을 의뢰하여 결재 라인이 단순하고 의사결정이 빠른 경우에 진행 43
- 44. 애자일을 억지로 사용하지는 않습니다 44
- 45. 애자일 원칙에 가까운 방법들을 위주로 사용 반복적인 개발 사이클 문서 작성보다는 동작하는 소프트웨어 고객사가 직접 사용해보도록 하는 것 단순한 구현부터 점진적으로 발전시켜나감 자주 소통하며 의사 결정을 개발자와 고객사와 함께 내림 45
- 46. 스타트업 규모에 맞지 않은 방법들은 제외하거나 간소화 수백 만 원부터 수백 억 원 규모까지 커버하는 다양한 애자일 프랙티스 인셉션 덱, 사용자 스토리, 플래닝 포커, 데일리 스크럼 등은 생략하거나 단순화 프로젝트 리스크 파악, 핵심 사용자 플로우만 정리, 주요 기능별 공수 산정 리팩토링은 개발 진행 중에 부분적으로 진행, 페어 프로그래밍 대신 코드 리뷰 등 46
- 47. 오늘도 실험하고 개선하고 있습니다 47