[SI산업 가이드북④] SI에서 발전된 폭포수, 애자일 바로 알기

[IT 입문자를 위한 SI 산업 가이드북①] SI 회사는 가면 안되나요?

[IT입문자를 위한 SI산업 가이드북②] 스타트업, SI를 해도 되나요?

[IT 입문자를 위한 SI 산업 가이드북③] 갑은 SI 프로젝트를 어떻게 만들까?

[IT입문자를 위한 SI산업 가이드북④] SI에서 발전된 폭포수, 애자일 바로 알기

엇, 저 프로젝트라면 나도 할 수 있을 것 같은데, 그냥 한다고 하면 되는 건가?

프로젝트는 어떻게 하면 되는 거지, 만일 중간에 포기하면 어떻게 되는 걸까?

애자일이 좋다는데 왜 그걸로 안 하고 폭포수 개발방식으로 하는 거지?

블로그에 많은 팁들이 있는데 어떤 게 진짜 맞는 걸까?

초보자는 용기를 내기 힘듭니다. 할 수 있을 것 같은데 처음이라 어떻게 시작해야 할지 잘 모르겠습니다. 프로젝트를 하는 동안에도 긴가민가 합니다. 작은 SI 회사라면 더욱 물어볼 곳이  없습니다. 다른 회사가 가르쳐줄 리 없기 때문입니다.

“프로젝트는 어떻게 시작하고, 어떻게 끝내야 하는 걸까?”

초보자를 위해 이 이야기를 해보려고 합니다. 많은 친구들이 용기를 내어 도전할 수 있으면 좋겠습니다.

먼저 배경지식으로 “프로젝트 수행방법”의 변천사를 알아봅니다. 케이스마다 현장 상황이 다르니 배경을 이해하고 대응해야 하기 때문입니다.

프로젝트의 시대

프로젝트는 개인이 할 수도 있습니다. 그냥 혼자 시작하면 되죠. 여러 명이 하면 그룹 프로젝트, 팀이 하면 팀 프로젝트가 됩니다. 목표를 달성하기 위해 일정을 세워서 하는 작업들을 모두 “프로젝트”라고 부릅니다. 위키피디아에서만 나오는 이야기 같지만, 회사에서도 똑같습니다. 

IT 회사에 오면 프로젝트를 밥 먹듯이 합니다.

왜 “프로젝트”를 할까? 신입사원들은 생소할 수 있습니다. 학생들은 “스스로에게 발전 동기를 부여하기 위해서”라고도 합니다. 하지만 기업들은 아닙니다. 기업은 적절한 비용으로 적절한 목표를 달성하기 위해 프로젝트를 합니다.

“프로젝트 팀”은 보통 새로운 걸 만들고자 할 때 구성됩니다. 미션은 도전적이고 어떻게 해야 할지는  모호한 상태입니다. 프로젝트에 “이름”을 붙이고 “기한”을 정합니다. 여기서 “이름”은 목표를 뚜렷하게 하기 위해서이고, “기한”은 적절할 때 포기하기 위한 장치로 사용됩니다. 무한정 길어지면 안 되거든요.

기업들은 가능한 사람을 찾아 적당한 기간, 적당한 예산을 투입합니다. 충분한 돈, 넉넉한 시간, 최고의 사람들이 있으면 좋긴 합니다. 하지만, 대부분 충분한 돈과 시간이 없고, 구성원들도 최고가 아닙니다.

최고의 조건이 갖추어졌다 하더라도 “프로젝트”는 실패할 수 있습니다. ‘평타’를 맞추기 위한 안전장치가 필요합니다. 그게 바로 표준화된 공정, “프로젝트 수행 방법”입니다.

개인 개발의 시대

에니악(ENIAC)이 처음 탄생했을 때, 코딩을 한다는 건 곧 개인 개발의 시대가 도래했음을 의미했습니다. 입력장치가 하나였기 때문입니다. 수학자 두 명이 협력할 수 있었지만, 코딩은 한 사람이 했어야 했습니다. 컴퓨터 회로가 그렇게 밖에 처리를 못했기 때문입니다.

처음 태어난 소프트웨어도 그랬습니다. 컴파일러가 기계어로 쉽게 변환할 수 있도록, 위에서 아래로 하나의 흐름으로 코드를 작성했습니다. 흐름을 바꿔야 할 땐 GO TO 문을 쓰는 게 전부였습니다.

프로그래머의 중요한 능력 중 하나는 여러 가지 요건을 듣고 하나의 흐름으로 정리하는 것이었습니다.

그러나 사람들은 더 복잡한 걸 만들고 싶어 했습니다. 하나의 프로그램에서 두 개의 흐름을 만들 수 있게 컴파일러에 기능을 추가합니다. Thread 라는 개념입니다. 프로그래머는 이제 하나의 흐름이 아니라 두 개 이상의 흐름으로 처리할 수 있게 됩니다.

이제 세상을 투영하기 시작합니다. 다자 간의 관계를 만들고 싶어 합니다. 하나의 흐름이 아니라 여러 명의 주인공이 각각의 흐름으로 스토리를 만들 수 있게 합니다. “객체지향 프로그래밍”입니다.

변화의 시작은 소프트웨어였지만, 하드웨어도 거기에 맞게끔 발전합니다. “시분할 시스템”에서 “병렬처리 프로세서”로, 다시 “멀티 코어”의 시대로 넘어갔죠. 복잡해지기 시작합니다.

팀 개발의 시대

“객체지향”이 등장하자 “프로그램”의 복잡도는 기하급수적으로 증가합니다. 은행이 컴퓨터를  도입하면서 “프로그램”의 사이즈도 엄청 커집니다. 하나의 시스템에 다 담을 수 없게 됩니다. 여러 대의 “컴퓨터 시스템”으로 “기능”을 나눈 다음, 흐름을 합치는 방식으로 프로그램 구조가 변경됩니다. 결과물도 여러 개의 프로그램을 엮어 “예금업무”라는 하나의 기능을 처리하게 만들죠.

이제는 하나의 결과물을 위해 여러 명의 프로그래머가 함께 개발해야 하는 시대가 됩니다.

1990년대 중반부터였죠. 이때까지만 해도 시스템은 비쌌습니다. 하드웨어를 다루는 것부터 소프트웨어를 개발하는 것까지  극소수 전문가의 영역이었거든요. 아직 기술이 초기라 사람이 컴퓨터에 맞춰야 했습니다.

당연히 전문 회사에 일을 의뢰할 수밖에 없었습니다. 그 회사들이 소위 빅3라고 이야기하는 “삼성SDS”, “LG EDS(현 LG CNS의 전신)”, “현대정보기술*”이었죠. 

*현대정보기술은 현대 그룹 계열의 전산을 담당하는 곳으로 출범했으나 2011년 롯데그룹에 인수, 2016년에는 롯데정보통신과 합병됐다.

갑들은 투자금액이 크다 보니 보험 삼아 대기업을 선택했던 겁니다.  이유는 “설마 대기업이 일을 망치겠어?” 것보다는 “설마 일을 망치고 도망가겠어?”라는 게 더 컸습니다. (제가 당시 고객들에게 물어봤어요. 속닥속닥.)

이제 대형 SI 업체에게 숙제가 세 가지 생깁니다.

“어떻게 소프트웨어 결과물을 만들 것인가?”

“어떻게 이 프로젝트를 수행할 것인가?”

“어떻게 전문 회사임을 어필할 것인가?”

한 번 하고 말 게 아니기 때문에, 반복적으로 결과물을 만들어낼 수 있는 프로젝트의 틀과 프로세스가 필요했습니다. 그러나 당시엔 그런 게 없었죠. 국내 IT 회사만의 문제는 아니었습니다. HP, IBM 같은 글로벌 기업도 마찬가지였죠. 이 문제를 해결하기 위한 다양한 연구들이 미국에서도 진행됩니다. 1990년대 후반부터였죠.

소프트웨어 개발방법론

소프트웨어 개발방법론, 프로젝트 개발방법론, 프로젝트 관리방법론, 소프트웨어 공학.

여러 용어가 혼재되어 쓰입니다. 요즘은 대충 말하고 대충 알아듣습니다. 

그러다 보니 그게 그건지 몰라서 노하우가 체계적으로 계승되지 않고 잊혀 버립니다. 요즘 SI시장으로 진입하는 젊은 친구들은 대부분 이 차이도 알지 못하죠. 여기서 가볍게 정리하고 넘어가겠습니다.

[표1] 소프트웨어 개발방법론, 프로젝트 관리방법론

도표에서 위 칸에 위치한 개념이 그 아래의 개념에 포함됩니다. ‘소프트웨어 개발방법론 < 프로젝트 관리방법론 < 기업 역량 관리’ 이렇게 되는 거죠. 조금 더 정리해봅니다.

소프트웨어 개발방법론

전체 프로그램을 어떻게 개발할 건지 “개발방법”을 정합니다. 아래와 같은 숙제가 있습니다.

(1) 전체 그림을 그리고, 일을 어떻게 나눌 것인가? → 설계

(2) 개발된 소스를 어떻게 합칠 것인가? → 형상관리

(3) 잘못된 걸 언제 체크하고, 피드백, 수정할 것인가? → 테스트

(4) 기타 등등

목표는 “소프트웨어를 만드는 겁니다.” 요즘에는 개발자가 서버도 세팅하고 DB도 관리하지만, 옛날에는 정말 서버 상에서 실행되는 애플리케이션만 만들었습니다.

프로젝트 관리방법론

이 프로젝트가 어떻게 진행될지 결정합니다. 아래와 같은 숙제가 있습니다.

(1) 고객과 어떻게 소통하고, 숙제를 어떻게 확정지을 것인가

(2) 하드웨어 구매, 설치, 구성은 어떤 걸 어떻게 진행할 것인가

(3) 개발자가 언제 들어와서 언제 빠질 것인가

(4) 소프트웨어를 어떻게 개발할지 등등 → 소프트웨어 개발방법론

목표는 “프로젝트를 끝내는 것”입니다. 계약을 만족하는 최종 결과물을 납품합니다. 소프트웨어가 잘 만들어지도록 관리도 해주지만, 여러 대의 PC를 납품하기도 하고, 비싼 소프트웨어를 사서 납품해주기도 합니다. “프로젝트 수행방법론”이라고도 부릅니다. 

일반적으로 “프로젝트 = 외주사업”이므로 “사업관리”라고도 표현합니다. 책임을 지기 위한 프로젝트 관리팀을 만듭니다. PMO(Project Management Office)라고도 합니다.

기업 역량 관리

‘우리 회사가 소프트웨어 잘 만드는 회사’라고 외부에 자랑을 해야 합니다. 그래야 일거리가 들어오니까요. 공인 기관이 보증, 인증해주기를 바랍니다. 그러려면 공인기관이 있어야 하고 인증기준이 있어야 합니다. ISO라는 국제표준화기구가 생깁니다.

이 기구는 1946년 제2차 세계대전이 종료되면서 만들어졌습니다. 무기 수출, 협력 때문에 부품이 호환되어야 했거든요. “산업표준”을 만들어야 했습니다. 당장 전기 콘센트부터 말이죠.

이후 세계 무역의 시대가 열리자 ISO는 더 바빠집니다. 공산품 수출까지 커버하게 되었거든요. 다양한 호환 규격과 품질 검증 과정이 필요해졌죠.

2,000년대 IT가 뜨자 컴퓨터 호환 문제가 생깁니다. 소프트웨어 규격의 호환 여부도 중요해지고요. SI 기업들은 이런 문제를 잘 해결하고 있음을 증명해야 했습니다. “개발 프로세스”와 “프로젝트 관리방법”을 이용해서 말이죠. “품질경영”이라고 불렀습니다.

정리하자면, 소프트웨어 개발 방법은 프로젝트 관리 방법에 포함됩니다. 프로젝트 관리 방법의 하위 개념이죠. 프로젝트의 목표는 '소프트웨어'만 만드는 게 아니니까요. “소프트웨어 공학”에서는 이 모든 걸 다룹니다만, 여기서는 그냥 넘어갑니다. 꽤 학문적 영역이고, 여기까지 들어가면 너무 복잡해져요.

프로젝트 관리방법론: ‘폭포수’가 90년대를 지배한 이유

프로젝트는 옛날부터 했습니다. 피라미드 같은 걸 혼자 만들 수 있는 게 아니니까요. 일도 복잡하고 기간도 길었죠. 기본적으로 10년 이상 했습니다.

현대적인 체계화는 1940년대 미국의 “방위산업”에서 시작되었습니다. 미사일을 쏘아 올려야 했거든요. 당시 로켓에 사용되는 부품이 15만 개 정도였습니다. 누군가 관리하지 않으면 그 많은 부품을 제때 모으고 조립할 수도 없었죠. 계속 미사일을 만들 수도 없었고요. 핵폭탄을 만들었던 “맨해튼 프로젝트”만 해도 5년짜리였습니다. 사람들이 가장 많았을 때는 13만 명이나 되었고, 보안을 위해 30개 지역으로 나누어 일했습니다. 제대로 관리하지 않으면 절대로 결과물을 만들 수 없었죠.

‘일을 어떻게 분해, 처리, 조립할 것인가?’ 일이 크고 복잡해질수록 이 요령이 중요해졌습니다. 그래서 WBS(Work Breakdown Structure), 업무분해 구성도가 만들어집니다. 1962년이었습니다. 옛날부터 이런 걸 했었지만 체계화, 표준화시켜 매뉴얼로 만든 건 이때가 처음이었습니다.

세부 업무가 늘면 전체 일정 속에 어떻게 넣고 조율할지가 중요해집니다. 다른 일정을 미루든지, 전체 일정을 늘리든지 결정해야 하죠. 이렇게 통합, 관리하려면 일의 흐름을 가시화시킬 방법이 필요해집니다. 관계자들끼리 회의를 해야 하니까요.

PERT 차트가 만들어집니다. 이정표를 수립하고 소요 기간을 넣어 일의 순서를 조정했죠. 처음 이 방법을 만든 곳은 1958년 미국, 잠수함 미사일(SLBM)을 만드는 프로젝트였습니다.

바닷속에서 미사일을 쏘아올린다는 건, 수압 문제, 점화 문제 등으로 불투명한 것들이 많았습니다. 세계 최초로 만들다 보니 방법도 불투명했죠. 업무를 작게 나누고, 차트를 통해 선택과 포기를 반복했습니다. 결국 “폴라리스”라는 미사일이 만들어졌고, 세계 최초로 “핵탄두”를 탑재하기도 했습니다. 이 방법은 다른 산업에서도 널리 사용됩니다.

“일정관리”의 대명사로 불리는 “간트차트”는 1919년 탄생했습니다. 다만 초기에는 이걸 모두  손으로 그려야 했습니다. 잘 안 썼죠. 1980년대 PC가 보급되면서 이걸 프로그램으로 관리할 수 있게 됩니다. 비로소 대중적으로 사용되기 시작하죠.

컴퓨터로 관리되기 시작하면서 다양한 도구들이 통합됩니다. Task Name으로 불리는 업무 목록은 WBS에 기재된 걸 옮겨 적은 것이고, Task 끼리 이어지는 화살표는 PERT 나 CPM 기법을 참조했습니다.

“프로젝트 관리”가 편리해지자 “프로젝트 관리방법”은 전 산업분야로 확대됩니다. 업무가 많고  복잡했던 건설 현장이 적극적으로 도입을 하죠.

노하우를 축적. 발전시키기 위해 PMI라는 협회가 만들어집니다. 1996년 “PMBOK”이라는 제목으로 매뉴얼까지 발간되죠. 비교적 현대입니다. 나름 복잡한 전문분야이므로 어깨너머로 익히는 것만으로는 한계가 있습니다. “PMP”라는 자격증까지 만들어지죠.

※ PMBOK: Project Management Body Of Knowledge의 약어, PMP: Project Management Professional (프로젝트에 관한 아주 짧은 역사)

PMBOK에 담긴 내용은 비교적 일반화된 내용이지만 국방과 제조업의 관점입니다. 이후 건설 쪽까지 빠르게 받아들이게 되죠. 1990년대 대형 IT 프로젝트들이 등장하게 되자 빠르게 IT산업까지 확장됩니다. 이후 SI 산업의 부흥기를 이끌게 되죠. 이때부터 “폭포수 개발 방법론”이 SI 프로젝트의 바이블처럼 받아들여지게 됩니다.

SI에서 시작된 애자일 방법론

2001.2.11일 17명의 베테랑 엔지니어들이 “스노우버드”라는 미국 스키장에 모입니다. 애자일 선언문이란 걸 만들죠.

주로 40, 50대 베테랑 엔지니어들로, IT컨설턴트이거나 IT 프로젝트의 책임자들이었습니다. 이들은 SI 현장과 자기 회사에서 벌어지는 아래 같은 상황을 개선하고 싶어 했죠. 참여자였던 제프 서덜랜드가 <애자일 개발과 스크럼>이라는 책에서 이렇게 말했습니다.

당시 개발팀의 연봉은 충분히 높았지만, 소프트웨어를 잘 만든다고 할 수는 없었습니다. 항상 납품일정이  지연되었고, 납품된 소프트웨어의 품질은 문제가 있었습니다. 그 결과 끊임없이 관리직에게 압력을 받으며 벌레 취급을 당했습니다. 

 

“개발자들의 삶이 좋아지려면 도대체 무얼 바꿔야 할까?”

이 질문이 내가 “소프트웨어 개발방법론”을 바꿔야겠다고 생각한 계기가 되었습니다.

(애자일 개발과 스크럼, 2014 - 출처: 애자일 방법론의 등장배경)

고민의 계기는 C3 프로젝트라고 불리는 “크라이슬러 급여 통합 프로젝트”였습니다. 1995년부터 1998년까지 진행되었죠. 당시 크라이슬러는 급여 및 상여 처리를 위한 오래된 코볼 시스템을 여러 대 가지고 있었는데, 이게 너무 느려 제때 급여를 지급할 수 없었습니다. 직원이 8.7만 명 정도였거든요. 당시 CIO는 새로운 시스템으로 이 문제를 해결하고 싶어 했습니다.

기획의 시작은 1993년부터, 개발구축은 1995년부터 1999년까지 진행되는 전형적인 대형 SI 프로젝트였습니다. 애자일 선언에 참여했던 대부분의 멤버들은 이 프로젝트에 참여했던 핵심멤버들이었죠. ※ 참고글: C3 프로젝트에 대하여(마틴 파울러, 애자일 선언문 멤버)

그런데 프로젝트가 시작되고 1년이 지나도록 진전이 없었습니다. 위에서 말한 저런 상황이었던 거죠. 고객은 계속해서 클레임을 걸고 개발팀은 갖은 비난을 참아가며 일하고 있었습니다.

1996년 켄트 벡이 소방수로 투입됩니다. 문제를 관찰하고 원인을 찾아내죠.

“폭포수 개발방식”으로 진행되던 터라 코드가 통합, 배포될 때까지 고객이 동작하는 모습을 볼 수 없었습니다. 꽤 큰 단위를 납품받고 난 후에야 원하는 게 아님을 알 수 있었죠.

개발팀이 일하는 방식을 바꿉니다. 기능을 잘게 쪼갠 후 완성시킨 후 매번 고객에게 보여주었습니다. 잘못되었다는 걸 금방 알 수 있었고, 계속 교정되었으니 최종 결과물의 완성도까지  높았습니다. 비로소 실패가 줄어들기 시작했죠. 이런 과정을 “익스트림 프로그래밍”이라고 부르게 되었으며, “애자일”로 일하는 핵심적인 방법이 됩니다.

덕분에 2년 만에 동작하는 시스템이 나왔고, 크라이슬러는 이 시스템을 이용해 1만 명의 직원들에게 급여처리를 할 수 있게 되었습니다. 처리시간이 1,000시간 이상 걸릴 것으로 예상했는데 오픈 시점에는 9시간까지 줄었습니다. 성능 개선까지 엄청나게 이루어진 겁니다. 아쉽게도 이 프로젝트는 1998년 클라이슬러가 매각되면서 중단됩니다.

하지만 이때의 성공 경험은 당시 멤버들에게 큰 경험 자산이 됩니다. 핵심 멤버들은 각자 자기 회사로 돌아와 이 경험을 이어서 발전시키죠. 계속 만나면서 경험들을  교류합니다. 그 결과물로 정리되어 나온 것이 “애자일 선언문”입니다. 과정을 보면 5년 정도 현장에서 검증된 것이죠.

당시 켄트벡은 Three Rivers Institute라는 연구소를 만듭니다. 자기가 하는 일을 이렇게 소개하죠.

“우리는 아웃소싱 개발팀을 위해 전 세계 CEO들에게 캠페인을 합니다. 소프트웨어는 물건 구매하듯이 사는 게 아니라, 핵심 기업들과 좋은 협력관계를 만들어 가는 것이 더 중요합니다.”

“갑”들이 IT프로젝트를 어떻게 발주하고 완성시켜야 하는지 인식개선을 시키고 싶었던 겁니다.

콕번과 하이스미스는 “상호의존 선언문”이란 걸 만들기도 합니다.

“프로젝트 팀원들은 단순히 모여있는 개인의 집합이 아닙니다. 상호의존적으로 전체를 형성하고 있는 구성원들이죠. 이것은 프로젝트 팀이 외부의 고객이나 이해관계자들도 연결되어 있다는 걸 의미합니다. 이걸 제대로 인식해야 프로젝트를 성공시킬 수 있습니다.”

즉, SI 개발팀이 프로젝트에 임해야 할 때의 인식을 개선하고 싶었던 겁니다. PM와 PL을 대상으로 합니다.

※ PM: Project Manager, PL: Project Leader, Part Leader

즉, “애자일”의 시작은 “수주형 사업”이었습니다. 문제를 해결하고 싶은 시장도 SI 현장이었죠. 하지만, 애자일은 SI 현장보다 스타트업 현장에서 더 많이 사용되었습니다. 작은 팀에서 더 잘 작동했거든요. 엄격한 계획통제 방식이 아니라, 기한 없는 점진적 해결방식이었기 때문입니다.

하지만, SI 현장은 지켜야할 종료기한이 있고 비용도 강력하게 통제하고 싶어합니다. 유연한 상황이고 결론이 열려 있으면 임원에게 보고하기 불리하죠. 설명이 복잡해지고 보고시간이 길어집니다. 이해관계자가 많아질수록 상황은 더 어려워지죠.

애자일 vs 폭포수? 방법론 아닌 ‘목표 달성’이 핵심

“애자일 개발방식”이 이겼을까? 아닙니다.

“폭포수 개발방식”이 이겼을까? 아닙니다.

그러면 어떻게 되었다는 거야, 둘 다 쓰고 있다는 거야? 

음, 틀린 말은 아니지만, 알아야 할 핵심은 그게 아닙니다.

이 변천사가 주는 핵심은 이겁니다.

“방법론이 목표가 아니라 프로젝트 목적 달성이 핵심이다.”

프로젝트는 다양한 목적을 달성하기 위해 만들어집니다. 기간이 끝났을 땐 그 목적이 해결되어 있어야 하죠. 개발 방법론, 프로젝트 관리방법론은 분명히 중요한 요소입니다. 하지만, 프로젝트의 목적을 달성하지 못한다면 소용이 없게 되죠.

“애자일”을 통해 시장이 얻은 교훈, “방법론”이라는 고정관념에 사로잡혀 무한정 삽질을 반복하지 말자라는 겁니다. 문제가 발생되면 문제를 푸는 게 중요하고, 그걸 위해서는 폭넓게 상황을 인식하고, 유연하게 생각,  다양하게 대처해봐야 한다는 걸 알게 된거죠.

[표2] 프로젝트 현장의 다양한 고객 상황들

프로젝트를 시작할 때 가장 먼저 해야할 일은 “내가 어떤 고객을 만났는지” 확인하는 겁니다. 고객  상황을 알아야 문제를 정의할 수 있거든요. 그리고 고객 성향이 어떤지 알아야 문제를 풀어가는 순서를 정할 수 있습니다. 우선 순위가 성향에 따라 달라지거든요.

대형 프로젝트의 고객은 사업환경이 꽤 정형화되어 있습니다. 그래서 전문 PMO 분들이 항상 투입되죠. 스타트업도 상황은 비슷합니다. 훌륭한 CTO 분들이 상주를 하죠.

※ PMO: Project Management Office, 프로젝트 관리팀

하지만, 중.소형 프로젝트들은 생각보다 상황이 복잡합니다. 고객 유형도 다양하고요. 규격 외의 이야기들이 많아 일반화하기도 어렵습니다. 그래서 도움을 얻기도 어렵고, 정리된 내용도 없습니다. 저도 모든 걸 다 이야기할 수는 없지만, 제 경험을 빌어 이야기를 다음회차에 풀어 보겠습니다.

※ 읽어볼만한 글

SI 프로젝트에도 애자일은 가능하다 (구글그룹스, 2008)

SI 프로젝트에 애자일을 적용할 수 있는가? (휴벗, 2021.08)

우리회사는 왜 애자일 전환에 실패했을까? (서점직원, 2021.08)

소프트웨어 개발방법론 선정(김병호, 2021.01)

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.