1. Business Driven Development
부제 : 스타트업에서 개발자로 살아남기

2. 목차
• 만약 이런 상황에 처했다면?
• 엔지니어링 중심 개발
• 비즈니스 중심 개발
• A vs B, 상황에 따른 선택
• 성과
• 논의거리
• 비즈니스 중심 개발의 장점
• 개발 시간을 단축시키는 팁 10가지
• 결론

3. 만약 당신이 이러한 상황에 처했다면?
• 이직 전, 예정된 날짜보다 빨리 와줄 수 없냐는 대표의 카톡. 뭔가
느낌이 쎄하다..
• 새로운 회사에 출근을 했다.
• 바로 회사 신사업 개발 프로젝트에 투입.
• 출근해보니, 바쁘게 움직이는 사람들.. 연말인데?
• 뭘 만들어야 할 지는 모르는 상태에서, 일단 CI/CD 환경부터
구축하라는 동료의 말..
• PPT로 구성된 화면설계서와 기능명세서, 그마저도 영업팀원이
만듦..
• 근데 마감 일정이 일주일 남았다고..?

4. 만약 당신이 이러한 상황에 처했다면?
• 크리스마스, 연말, 1월1일, 전부 회사에서.
• 어쨌든 비즈니슨 돌아가야 하므로, 12월 19일부터 1월 19일까지
2개의 사이트 론칭.
• B2B 펫샵 동물등록 사이트
• https://kocapeopet.com/
• B2B 어드민 사이트
• https://web-admin.peopet.co.kr/
• B2B 펫 경매 사이트
• https://auctionpeopet.com/
• 1월 31일까지 1개 사이트 추가 론칭
• 2월 중순까지 안정화 작업

5. 만약 당신이 이러한 상황에 처했다면?
• 숨을 돌리며 드는 생각.
• “고생은 했지만 배운 건 많았다.”
• “고생을 덜 하는 방법이 분명 있었다.”
• “내가 개발할 때, 고집스러운 부분이 많았구나.”
• “그래도 개발자로서 한번은 이렇게 개발해봐도 괜찮다. 두번은 하기 싫음.”
• “주니어 레벨은 이제 아니지 않나.. 이제 미들급으론 온 듯.”
• 두 가지 상반된 주제를 갖고 의논해봤으면 한다는 생각.
• 엔지니어 중심 개발 vs 비즈니스 중심 개발
• 또 이번에 배운 걸 바탕으로 스타트업에서 일하는 개발 방식에 대한
생각이 조금 바뀌었는데, 다른 동료분들에게 도움이 될 것이라 생각.

6. 엔지니어링 중심 개발
• 확장성 있는 아키텍처 설계
• 디자인 패턴
• 반복이 없는 코드 구조
• 역할이 독립적이고 구분된 클래스, 컴포넌트들
• 테스트 자동화
• 클린 아키텍처, 클린 코드, TDD 등
• 배포/빌드 자동화 : CI/CD
• 테스트/스테이징/프로덕션 서버 구축
• 무중단배포
• 모니터링 시스템

7. 비즈니스 중심 개발
• 아키텍처? 모놀리식 아키텍처.
• 클린코드? 그냥 Ctrl+C, Ctrl+V.
• 독립된 컴포넌트/클래스? 역할 구분이 모호하고 여러
기능이 결합됨.
• 테스트코드? 그냥 웹페이지에서 통합테스트.
• ORM? 쓰긴 함.
• QueryDSL? 그냥 순수 SQL.
• CI/CD? 그래도 이건 양보 못함.
• 모니터링? 에러 로그로 간단히.

8. 회바회, 부바부, 상황by상황
• 하지만 급박한 상황이 주어졌고 이를 꼭 달성해야, 회사에 이익을
안겨줄 수 있다면.. 비즈니스 중심 개발을 고려해보자. 아니
그렇게 할 수 밖에 없다.
• 그렇게 하는 이유는? 닥쳐보면 안다.
• 차라리 노코드로 만드는게 나을 수도 있음. 근데 이것마저도
따져보고 고민하는데, 시간(비용)이 듦.

9. 비즈니스 (잠재) 성과
• 2달 간 B2B 동물등록 건수
• 총 3845건. 동기간 B2C 등록건수 1500건.
• 그 중 잠재 고객 수 : 3845명 중 마케팅 동의를 한 3500명.
• 커머스몰 가입 전환을 위해, 퍼널 개발 중.
• 퍼널이란? 깔때기. 잠재 유저를 자사몰에서 결제까지 하도록.
• 개발팀이 사이트를 만듦으로써, 잠재 고객 확보. 추후 가입 전환되면
결제까지 이뤄나, 실제 매출에 기여할 수 있음.
• 컬쳐팀에선 IR 상 스토리에 대한 근거 마련, 데이터 마련.
• 우린 펫 생애주기 앱을 향해 간다.
• 분양 시점부터 펫 데이터 확보. 즉, 펫 시장의 가장 앞단을 점유하는 기업.

10. 논의거리
1.개발자가 바라보는 개발 vs 비개발자가 바라보는 개발
2.클라이언트가 바라는 제품과 개발자가 바라는 제품

11. 만약 비즈니스 중심 개발을 해야 한다면..
• 일단, 돌아가게 만들자. 그리고 리팩토링 한다.
• 이게 가장 중요. 나머지는 절대 안중요.
• 비즈니스가 돌아가게 하는 것이 우선. 개발이 회사 업무의
병목을 일으키는 요인이 되면 안됨. 늦어지면 계약 파기까지
있음. 최소 몇천만원에서 몇억짜리 프로젝트. 금전적인 부분은
개발자가 책임 못짐.
• 그리고 그 외에 이번 경험으로 얻은 팁을 더 공유하자면…

12. 팁
• 코드 안짤 수 있으면 더 좋음. 노코드 개꿀.
• 우선순위 명확히. 이거 하려면 기획 잘 알아야 함.
• 그리고 우선순위 대로 개발.
• 여기서 밀리기 시작하면 한도 끝도 없음. 고객/동료로부터의 압박은 점점
심해짐.
• 작업에 쉼이 없어야 한다. 명확한 것부터 개발하는게 좋음.
• 예를 들어, 화면 설계가 나오면 프론트부터 개발
• 구현 가능한 확실한 방법을 활용.
• 복잡한 쿼리 다룬다고 QueryDSL 쓰다, 에러 나고 애먹을바엔. 그냥 생 SQL
쓰자.
• ORM 어려우면 SQL Mapper 쓰면 됨.
• 프론트도 마찬가지겠지만. UI? 그냥 UI Framework 갖다 쓰고.
• 적당히 기능 어려우면, 검색 및 ChatGPT 활용하면 다 구현됨.

13. 결론
• 이직하면 개고생이다.
• 프론트에서 풀스택가면 개고생이다.
• 백엔드에서 인프라까지 건들면 더 개고생이다.
• 외주 개발사랑 협력한다면? 이 역시, 개고생이 눈 앞에 보인다.
• 기간 안에 안되면 안된다고 솔직하게 이야기하고 타협점을
논의해야 함.
• 괜히 된다고 했다가 개고생.
• 그게 바로 나.