"현장에서 사용하는Software production"라는 주제로 강의했던 내용을 공유합니다.

1. 현장에서 사용하는
Software production
유진호

2. 만약 여러분 친구가
여의도에서
이런식으로 통닭집
장사하면?
뭐라 조언해 주실거에요?

3. 한류 치킨집은 가능할 것인가?
• “1000명 중국 관광객이 여의도 공원에서 치맥을 한다고 해서 입찰
했어요. 시험삼아 튀겨오래요.”
• 돈은 있으니 우선 통닭 튀길 주방장 초빙, 시험으로 튀김.
• 주방장 도망. 다음 주방장을 못구해서 아는 한정식 집 찬모 모셔옴.
• 그런데 앞의 주방장이랑 똑같이 튀겨 달라 함. 비법노트 1도 없음.
• 이걸 왜… -.-;; 찬모 나감.
• What the hell!!!!
• 우리는 중국 관광객들 치맥 계약을 따낼 수 있을까요?

4. 실제 있던 사례
조금 극화 + 호러호러~~
다른 회사 이야기들도 있으니 걸러 들어주세요.

5. “급한 프로젝트인데 다음
주까지만 데모할꺼에요.”
좀 코드좀 받아서 관리해 주세요.

6. 답: ”안돼요”
문서도 없고, 설계도 없고, Unit test도 없고…. 이걸로 뭐해요?

7. “아니, 당장 일을 따내야….”
솔직히 말해서 이 이후 한 마디도 안들렸음.

8. 빌드를 해보자.
되는 군- 이건 문서가 있었음.

9. 내 컴퓨터에서 돌려보자
돌아가네

10. 이제 외부 서버에
올려보려는데…
이거 어떻게 올려요?

11. “개발한 사람이 퇴사해서
몰라요”
뭐, 뭐라고요?

12. 그러고 3일이 지났다
털어보고, 코드 보고, ….. 2일째 지나서 결국 만든 사람에게
물어봐서 알려줘서 서버에 올려보는데…..

13. 그것도 ‘손으로’
서버 배포를 손으로 하는게 몇년만인가!

14. 실수가 연발~ 품질이 엉망~
• 7대 이상에 같은 파일이 배포된건가 확인해야 되?
• 손으로 하다보니 급 피로감이….
• 좀 험한 테스트 하니까 마구 죽는데… 어디서 죽은거지?

15. 알 수가 없다….
메모 1장만 있어도 되는 것을……..

16. 결국….
왜 슬픈 예감은 틀린적이 없냐..

17. 그게 뭐?
”개발일이 늘 그렇게 되는 거 아니었나요?”

18. 실제 있던 사례 2.
이건 진짜 호러

19. “새로 입사했습니다”
이쁘게 봐주세요.

20. “새로 입사했습니다”
이쁘게 봐주세요.

21. Git에서 받아서 Eclipse로
빌드하고
코드를 열어볼까?

22. 같은 일을 하는 Class가
세개야…..
”이건 마치 시어머니가 셋인 집안에 시집온 느낌….”

23. “역시 배포는 손으로
해야 제 맛!”
배포하기 귀찮아서 소프트웨어
변경을 못합니다.

24. 그게 뭐?
”머리 돌아가게 손 자주 움직이면 좋잖아?”

25. 실제 있던 사례 3.
좀 극화 쎄게 들어갔습니다.

26. ”이제 자동 빌드해서 매일
배포 가능하겠군요!”
회사에 드디어 Continuous delivery전문가가 입사하셨습니다.

27. “한번도 돌아가질 않네요”
실행하면 하얀화면이 곱게 접어~
다음 테스트를 한 줄도 못해

28. “아, 그거 제가 빌드할께요”
여기저기서 이 파일 저 파일 수정하더니 빌드…
수정한 파일은 Git에 안올림.
빌드는 너님만 할꺼임?

29. 원래 그러는거 아니에요?
”지난번 프로젝트까지 계속 이래왔는데?”

30. 공포를 느끼시지
못한 분들 손~

31. 2015년 CHAOS Report – Standish group
소프트웨어 프로젝트는 거의 성공하지 못하는 확률이 거의 70%

32. 치킨집 폐업률 22%
http://www.fnnews.com/news/201510051150150892

33. 뭘 더 신경써야 겠어요?
망할 확률
70%
망할 확률
22%VS

34. 한번 고민해봅시다.
그런데 치킨집 창업만큼이나
신경써서 우린 서비스나
소프트웨어를 기획하고 만드나?

35. Software production
이 뭘까요?

36. 그 전에 Production?

37. Disney studio의
제작 프로세스

38. 영화 제작에서 Production단계
DEVELOPMENT:
아이디어 짜고,
대본쓰고, 투자
받아오고
PRE-PRODUCTION:
촬영들어가기전에
배우랑 촬영 담당자
섭외하고, 찍을 장소
찾고
PRODUCTION: 촬영
고고
POST-
PRODUCTION:편집하
고 이상한거 지우고
음악깔고
DISTRIBUTION:
요즘은
넷플릭스라죠?

39. Software production
실제 소프트웨어가 제작되는 과정

40. Software production
그런데 영화랑 다른게, 저 5개 과정이 동시에 일어납니다.

41. 목표:“지속적으로 안정적인
소프트웨어를 만들어서 고객의
문제를 해결해나갈 수 있느냐?”
이걸 못하는 회사는 망한겁니다.

42. 알겠는데, 도대체 어쩌라고요?
• 뭘 어떻게 해야 하는지는 알려줘야 하지 않나요?

43. 소프트웨어 개발의 본질 – 실패 관리
• 성공 관리가 아니다
• 조금이라도 덜 실수하고 덜 사
고 나고 문제 생기면 수습할
수 있는 상태로 개발해야 한다.
• 그런데 어떤 방식으로도 절대
적인 방법이 없다.
• 단 한번도, 절대 같은 일을
반복하는 경우는 절대 없
다.

44. 맨먼스 신화
• [프로젝트 중간에] 인력을 더 많이 투입하고 일
정을 짧게 잡는 일정 계획은 결코 성공할 수 없
다. 일정이 모자라서 실패한 소프트웨어 프로
젝트는 다른 이유로 실패한 소프트웨어 프로젝
트 수를 다 합친 것보다 더 많다.

45. 폭포수 모델
• 이대로 하면 되나요?

46. 애자일 모델
• 그나마 낫기는 합니다.
• 은탄환이 없다는 것을 다시
생각 해보세요.

47. 프로젝트의
성공률 : 폭포수 vs
애자일
• https://vitalitychicago.com/
blog/agile-projects-are-more-
successful-traditional-
projects/

48. 프로젝트의
성공률 : 폭포수 vs
애자일
• https://vitalitychicago.com/
blog/agile-projects-are-more-
successful-traditional-
projects/

49. Software 개발은 반복/반복/반복
• 각 반복주기마다 완결된 제품
이 나와야 합니다.

50. 한번 만들고 던져버리는 소프트웨어는 없
습니다.
• ＇이번만 하고 말거야..’없어요.
• 결국 버그 생기고 문제 생
기는 거 해결해달라고 하
면 누가 가겠어요?
• 고객들 중에 유지보수 관
련 이야기 안하는 경우 없
어요.
• 개발이 더 진행되지 않는 프로
젝트는
• 고객이 더 없거나
• 가져다 쓸 일이 없거나
• 오래 있으면 내 연봉이 곧
날아갈 수도 있다는 의미(?)

51. 여러분 프로젝트에서 이 사이클이 빠르게
되게 하려면?
• Requirement
• Design
• Develop
• Test
• Deploy
• Review

52. 쉬는 시간
쉬는 동안에 한번 생각해보세요.

53. Feedback loop
Input OutputX

54. 이렇게 하려면 어떻게 해야 되나요?
1. 해결하려는 문제가 무엇인지 명확하게 정의된다면?
2. 만들려고 하는 소프트웨어를 ‘빨리’돌려볼 수 있으려면?
3. 올라간 서비스나 돌아가는 소프트웨어가 제대로 도는지 바로 볼
수 있다면?
4. 고객들이 어떤 식으로 소프트웨어를 이용하는지 추적해 볼 수
있다면?
5. 이것을 가지고 다시 제품을 개선할 수 있다면?

55. 1. 해결하려는 문제가 무엇인지 명확하게 정의
된다면?
• 요구사항이란 명칭보다는 ‘문제정의’가 맞습니다.
• 고객이 지금 어떠한 문제를 해결하고 싶은지를 찾아야 합니다.
• 어떤 방법으로 하면 될까요?

56. 디자인 챌린지 : Design
challenge
• 프로세스를 위해 사람의 관점에서 명확하고 구체적으로
정리된 계획적인 문제
• Ex) 맥도날드의 밀크셰이크
• ＂밀크셰이크는 디저트야”라 생각하고 경쟁사
검토, 인구 통계학적으로 분석한 후 밀크셰이크
의 품질을 향상=> 매출은 그대로.
• “무슨 일(역할)을 시키려고 밀크셰이크를 고용
(구입)했나요? 라고 고객에게 물어보자
• 고객은 지루한 출근길에 부스러기 없고 입이 심
심하지 않으려고 구매
• 더 걸쭉한 스무디로 바꾸거나 출근시간에 빨리
살 수 있게 선불카드 발매 등의 방법
클레이튼 크리스텐슨, 하버드 경영대학원 석좌교수
- 배성환, 처음부터 다시 배우는 서비스 디자인 씽킹, 한빛미디어, 2018

57. 여러분이 하는 질문의 질이
답의 질을 결정합니다.
알겠는데 어떻게 질문해요?

58. 방법1: HMW
• “우리가 어떻게 하면 ~할 수 있을까?”라는 질문을 던져봅니다.
• HOW - 어떻게
• 어딘가에 해결책이 있음을 암시해서 잠재 수요를 발견하고 해결하는 데
필요한 창의에 대한 자신감을 얻게 한다.
• Might – 해볼까
• 아이디어를 마구 꺼낼 수 있다는 의미다. 좋은 아이디어일 수도, 아닐 수
도 있으니 꺼내놓고 가치 있는 무언가를 배운다.
• We – 우리가
• 창의적인 해결책을 찾기 위해 서로의 아이디어를 쌓아 나가본다.
- 배성환, 처음부터 다시 배우는 서비스 디자인 씽킹, 한빛미디어, 2018

60. 방법2: Lean canvas

61. 방법3: Working backwards
• 정말 ‘거꾸로 제품을 만드는’방법
1. 제품의 보도자료를 만든다.
2. 자주 물어보는 질문(FAQ)문서를
만든다.
3. 고객의 경험을 정의한다.
4. 사용자 매뉴얼을 적는다.
https://www.allthingsdistributed.com/2006/11/working_backwards.html

62. 특별히 보도
자료는,
• 제목 : 독자(대상 고객)가 이해할 방법으로의 제품 이름을 지어주세요.
• 부제 : 상품에 대한 수요자가 누구이고, 그들이 얻을 혜택을 설명해야 합
니다.. 타이틀 아래에 오직 한 문장으로만 하세요.
• 요약 : 제품과 그 혜택을 요약해주세요. 독자가 이 아래로 안 읽을게 뻔하
니 정말 잘 적으셔야 돼요.
• 문제점 : 무엇을 해결하려고 이 제품을 만들었나요?
• 해결법 : 위의 문제를 어떻게 멋지게 풀어냈어요? .
• 인용 : 회사 대변인으로부터의 인용문을 넣는다. 보통 “~~ 사내 관계자에
의하면~~~~라고 한다"라고 하는 거 있잖아요.
• 시작하기 : 처음에 어떻게 쓰는 지를 설명합니다. ‘시작하기 쉬워요!’라는
것을 잘 말해야 됩니다.
• 고객 인용 : 가상 고객이 어떤 혜택을 경험했는지 표현하는 인용 합니다.
“제가 ~~ 을 써보니 정말 좋더라고요~~~~.” 같은 문장 들어가는 겁니다.
• 맺음말과 해야 할 것 : 앞의 내용들 요약정리하고 그다음에 뭘 해야 할지
알려줍니다. 네이버에 검색을 하든지, 홈쇼핑 채널을 보라든지, 전화번
호를 주고 전화를 해달라든지 이야기해줍니다.

63. 보도자료 쓸 때, 숨은 ‘킥’이 있어요.
• 모든 문서는 가능하면 A4지 안에 다 적어보세요.
• 문단은 3~4문장으로 제한하세요.
• 혼자 쓰지 말고 관련된 모든 분들이 같이 쓰세요.
• 사업부분 담당자 / 개발 담당자 모두가 같이
• 반복적으로 쓰세요.
• 제품에 대한 시나리오입니다. 그걸 생각해보세요.

64. 이걸로도 정리가 안된다면 ＇컨퍼런스 발
표자료’를 만들어 보세요.
• 제품을 발표하고자 하는 자리
를 상상해보고
• 실제 어떤 제품을 만들었다고
말을 하려고 하는지 슬라이드
를 만들어보세요.

65. 이 모든 것들은 콘텍스트를 고려해야 합니
다.
• ＂저는 이런게 필요해요＂라고
고객이 말해도 실제 원하는 것
은 그게 아닐 수도 있습니다.
• 이를 찾아내는 과정자체가 힘
들지만 해야 하는 일들입니다.
언어로
표현
행동으로
확인가능
스스로 알지 못해
겉으로 드러낼
수 없음
인터뷰 및
관찰활동
CDM과
같은 인지
분석 활동

66. 이 과정에서 꼭 염두에 두실 것들이 있어
요.
• ＇인류학자’가 되어 ‘탐구’하세요.
• 새로운 것을 자꾸 발견할 수 있어야
합니다.
• 초기 단계일 수록 문서는 일부러 짧게 쓰
세요.
• 생각을 단순하게 만들기 좋습니다.
• 페이지 수를 제한하던지 작성하는 시
간을 제한하세요.
• 대신 자료수집은 많이
• ＇주장’하지 말고 ‘관찰’하시길.
• 더 진도가 안 나간다고 하면, 이제 다음 단
계로 가길 제안합니다.

67. 2. 만들려고 하는 소프트웨어를 ‘빨리’ 돌려
보려면?
• 소프트웨어를 만들지 마세요.
• 제일 빠르게 만들 수 있는 언어/도구
/Cloud의 Managed service를 이용하세요.
• 마세라티 문제

68. 소프트웨어 만들지 마세요.
• 코드는 빚입니다.
• 무엇을 하든, 코딩을 먼저 하지 마세요.
• 이 제품이 뭐다라는 것을 설명하기에는,
• 티저 페이지
• 슬라이드로 만든 화면들
• Axure같은 도구로 만든 Prototype
• 지금 우리에게 필요한 건 ‘고객에게 빨리’갈 수 있는 무언가.
• 고객의 피드백을 받고 다시 돌아오면 됩니다.
• 답 없는 고객들의 피드백을 ‘쪼아’내는 방법은 앞서 이미 이야기 했습니다.

69. 제일 빠르게 만들 수 있는 언어/도구/Cloud
의 managed service를 이용하세요.
• 결국 만들어야 한다면 빨리 만들
어야 한다.
• 언어/도구
• 자기 손에 익은 게 제일 좋다.
• 만약에 본인이 C++, Java로만 코딩할
줄 안다면 Python을 한번 배워 보길
진심으로 추천
• Front-end부터 짜보세요.
• Cloud의 Managed service의 적극적
인 이용
• DB/인증 등은 이미 많이 나와 있다.

70. 실제 사례
• 모 스타트업의 초기 제품의 기술스택은 무조건 Node.js +
MongoDB Atlas + React로 만들고 배포는 Google app engine이용.
• 빠르게 구현하되 Cloud비용 등은 그냥 지불
• NoOps할 수 있는 방식으로 개발해야 비용을 줄인다.
• 고객의 피드백을 빠르게 받는게 중요하기 때문.
• loopchain의 경우
• 잠시 C#이나 Java를 고려했다가 Python + gRPC + Docker로 개발
• Python의 유연함과 효율성 덕에 빠르게 제품을 개발할 수 있었다.

71. “마세라티 문제”는 생각 안한다.
• “마세라티를 탈 때가 되서야 할 고민”이란
의미.
• 정말 성공한 소프트웨어 제품이 되어서야
할 고민들을 하지 않는다.
• Ex) 초기 트위터는 Ruby on Rails위에 MySQL로
시작했다. 지금은?
• Ex) Facebook은 LAMP(Linux, Apache, MySQL, PHP)
로 시작했다. 지금은?
• 성공하고 나서 생각해야 하는 ‘기술문제’
가 있다.
• Scale up의 문제는 돈 벌리면 고민해도 늦지 않
다.
• 먼저 고객을 만나야 한다.

72. 3. 올라간 서비스나 돌아가는 소프트웨어가 제
대로 도는지 바로 볼 수 있다면?
• 처음부터 Continuous Integration,
Continuous Distribution/Deployment를 만
든다.
• Jenkins나 Travis CI는 무조건 쓰세요. 두 번 쓰
세요.
• Git flow와 같이 Branch를 이용한 기능개발
관리를 이용하고 Merge가 될 때마다 C/I,
C/D를 돌아가게 해야 한다.
• 무조건 자동 빌드
• Unit test / Integration test는 반드시 있어야 한
다. 단 적당히.

73. 몇가지 알아두어야 할 도구들/방법들
• App은
• iOS: TestFlight
• Android: Google play console - Open/Close
test
• Web service는
• Docker image로 배포
• Staging server를 구축해서 Blue/Green
deployment전략을 이용해서 배포/테스
트

74. 긴급 점수 측정– Joel test (각 1점씩)
• Source Control(소스 컨트롤)을 사용하십니
까?
• 한번에 빌드를 만들어낼 수 있습니까?
• daily build(일별 빌드)를 만드십니까?
• 버그 데이타베이스를 가지고 있습니까?
• 새로운 코드를 작성하기 전에 버그들을 잡
습니까?
• up-to-date(최신) 스케줄을 가지고 있습니까?
• spec(설계서)를 가지고 있습니까?
• 프로그래머들이 조용한 작업환경을 가지고
있습니까?
• 돈이 허락하는 한도내의 최고의 툴들을 사
용하고 있습니까?
• 테스터들을 고용하고 있습니까?
• 신입사원들은 면접때 코드를 직접 짜는 실
기시험을 봅니까?
• hallway usability testing(무작위 사용성 테스
팅)을 하십니까?

75. 4. 고객들이 어떤 식으로 소프트웨어를 이
용하는지 추적해 볼 수 있다면?
• 사용자들이 어떤 식으로 여러분의 앱이나 서비스를 이용하는지
관찰할 수 있어야 합니다.
• Google analytics
• 첫 시작은 역시
• Web뿐 아니라 Mobile app에서도 됩니다.
• 자체적인 로그 수집
• 서비스가 돌아가는 로그들을 원격으로 수집/분석할 수 있어야 합니다.
• 어떠한 지표를 측정할지를 결정해서
• ELK Stack같은 도구들을 통해서 수집/분석하고 있어야 합니다.
• 요사이는 이 사용자 경험 데이터 자체가 자산입니다. 꼭 수집해야 합니다.

76. Flash build

77. 5. 이것을 가지고 다시 제품을 개선할 수 있
다면?
• 구성원들 전체가 다 같이 현재 진행
상황을 인지할 수 있어야 합니다.
• 칸반이나 스크럼 보드를 운영하셔야
합니다.
• 매 일정 주기마다 일을 마치고 회고
를 해야 합니다.
• 회고를 잘하면 혈액순환과 섭생이 좋
아지고, 혈압이 떨어진다는데 사실인
가요?
• 그래서 다음 버전이 ‘빨리’나와야
합니다.
• 한달-> 1주-> 1일까지도 될 수 있게 하
려면 ?

78. 이제 잘 될 거 같으세요?
1. 해결하려는 문제가 무엇인지 명확하게 정의된다면?
2. 만들려고 하는 소프트웨어를 ‘빨리’돌려볼 수 있으려면?
3. 올라간 서비스나 돌아가는 소프트웨어가 제대로 도는지 바로 볼
수 있다면?
4. 고객들이 어떤 식으로 소프트웨어를 이용하는지 추적해 볼 수
있다면?
5. 이것을 가지고 다시 제품을 개선할 수 있다면?

79. 그런데 왜 안되죠?
그게 안되니까 저 같은 사람들이 벌어먹고 살겠죠?

80. 하도 답답해서 먼일이
있나보니….
자주 이런 비극에 대한
고해성사를 받습니다.

81. “저도 잘하고 싶죠, 그런데
시간이 늘 문제죠.”
• 어느 개발 팀장

82. “저 서비스 처음
기획해봐서 몰라요.어디서
배운적도 없고….”
• 어느 기획자 분….

83. “이번만 제발 이렇게 우선 하자 ….
다음번에는 말고…. ”
• 그 이야기 한번만 더 들으면 100번 넘는다며
우는 분들을 위해 산 술이..…..

84. “에이 아시잖아요….”
• 난 모르겠는데? -.-;;

85. 서로 신뢰를 하고
있어야 합니다. 그리고
지켜줘야 합니다.
서로 믿어야 무언가 개선을 하겠다 해도 됩니다.
그리고 그 믿음을 배신하면 안됩니다.

86. Gerald Weinberg 가라사대
• 경영자가 약속 이행을 아무
리 강하게 요구한다 해도 진
정으로 원하는 것은 결과물
자체다.
• 팀 전체가 참여하여 설정한
목표를 추구한다면 결과물
을 훨씬 더 쉽게 얻을 수 있
다.

87. 뭘 새로운걸
만들때 보통
하는 실수 –
Weinberg
said…
• 일정이나 예산을 비슷한거
해보지도 않고 확정한다.
• 비슷한데 더 작은 프로젝트
의 경험을 가지고 큰 프로
젝트의 추산을 확정한다.
• 모르는 경쟁자를 씹거나 최
적화하기 위해서 요구사항
을 확장한다.
• 뻔히 보이는 실패의 징후를
못보거나 일정을 늘리고 요
구사항을 줄인다.
• 뜻하지 않게 바꿔야 할 수
도 있는 프로세스나 환경
제약을 알아채지 못한다.
• 쉽게 동시에 너무 많은 동
시 작업들을 숨겨놓고 아
무것도 못 끝낼 때
• 새로운 기술이 가져다 주
는 기회나 변화 둘 다 못 알
아챌 때
• 고객에게 겁나서 못 물어
보거나 고객 대리인이 없
을 때
• 누군가에 물어보기 겁날
때

88. 애자일 소프
트웨어 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도
와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있
다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
• 공정과 도구보다 개인과 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협력을
• 계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지
만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것
이다.
• http://www.agilemanifesto.org/iso/ko/

89. ”서비스를 제대로 만들려면
Git을 쓰고 자동화를 하고…..”
그게 아니에요 긴급성 중독에 걸린 조직,
비일치적 행동을 하는 조직은 소프트웨어를 안정적으로
유지발전시키지 못해요. 서로 믿고 일치된 행동을 하고
공통의 목표를 설정하고 학습하는게 중요해요.

90. 지속적인 소프트웨어 개발은
마치 연인들의 꽁냥꽁냥
같은거에요
상대방을 존중하면서 의사소통을
지속적으로 해나가는게 핵심
절차를 지키거나 도구를 쓰는게
핵심이 아닙니다.

91. 인간은 목적이지
자원이 아니다.
인간관이 바뀌어야 합니다. 결국 사람들이
협력하지 않으면 어떤 일도 될 수 없습니다.

92. 실수를 인정하고
받아주고
새로운 시도를 해보다 실수할 때 그걸로 욕을 안먹는
‘안정적인’ 조직이어야 새로운 시도를 해볼수 있습니다.