탐색적 논문 읽기
이 글은 퍼듀대학교에서 HCI 연구를 하시는 이지수님의 페이스북 글에 제가 댓글로 달았던 것입니다. 블로그에서 소개하면 좋을 것 같아서 여기에 옮깁니다.

이 방식을 저는 논문 분류하기(Paper Triage)나 탐색적 논문 읽기(Exploratory Paper Reading)라고 부릅니다. (애자일 방법론, 탐색적 테스팅 등의 원칙 등을 응용했다고 보시면 됩니다)

제가 회사에서 연구할 때 우리 팀에서 썼던 방식과 비슷하네요.

1) 팀이 5명이라고 하고.. 우리가 리서치 하고 싶은 주제가 있겠죠. 처음에 시간을 정합니다. 예컨대 1시간(이 시간은 우리가 전체 프로세스에 투자하고 싶은 시간에 맞게 조절할 수 있습니다). 그러면 각자 흩어져서 1시간 동안 개인별로 논문 검색을 합니다(이 부분이 중요, 집단 사고를 피하기 위함). 뭔가 눈에 띄는 논문이다 싶으면 무조건 프린터로 찍습니다.

2) 시간이 다 되면 다 같이 한 자리에 자기가 찾은 논문 인쇄물을 갖고 모입니다. 각 논문은 스테이플러로 찍어옵니다. 테이블 한 가운데에 그 논문들을 다 모읍니다. 당연히 각자 논문검색을 했으니 중복인쇄된 논문도 있을 겁니다(이 게 사실 좋은 메커니즘임 -- 발견될 확률을 높여줍니다).

3) 이제는 테이블 위에 논문을 쌓아둘 세 군데의 자리를 정합니다. 하나는 "다시 한 번 제대로 봐야 한다", 하나는 "시간 되면 다시 보자", 마지막은 "볼 필요 없을 것 같다". 5명이 테이블 주위에 둘러앉아(마치 가운데 불이 있는 캠프파이어처럼) 가운데 무더기에서 논문 하나씩을 집어들어 간략하게 읽고 빨리 판단해서 세 개의 무더기 중 하나로 옮깁니다(triage). 보통 논문 하나에 1분 이내의 시간을 들이면 적당합니다.

4) 테이블 가운데의 논문(미분류된 것)을 모두 분류했다면 이제는 다음 단계입니다. "다시 한 번 제대로 봐야 한다"에 해당 하는 논문 뭉탱이만 두고 나머지는 모두 테이블에서 치웁니다(만약 남은 시간에 비해 그 논문 숫자가 적다면 "시간 되면 다시 보자" 그룹도 넣습니다). 이렇게 해서 논문 숫자가 너무 많다면 앞의 3) 단계를 다시 한 번 반복합니다. 아니면 다음 단계로 진행합니다.

5) 이렇게 추려진 논문들의 숫자가 적당하다면 이번에는 좀 더 세밀하게 갑니다. 각자 테이블에 남은 논문을 대략 읽고(맘에 드는 것은 좀 꼼꼼히 읽고 아니면 대충 읽어도 됨) 읽었으면 논문 첫장 우상단에 자기 싸인을 합니다(서로 다른 색깔 펜을 쓰면 좋음). 그리고 논문 텍스트 중에서 우리에게 중요하다 싶은 부분에 커멘트를 달거나 줄을 긋거나 하고 자기 싸인을 거기에도 붙입니다. 테이블에 올려진 논문들 모두에 모든 사람의 싸인이 붙는 걸 목표로 합니다.

6) 마지막으로는 논문 하나씩 뽑아서 각자 의견, 소감 등을 나누며 정리합니다.

이렇게 한 번 하면 다섯명이 반나절이면 수백편도 소화합니다. 해당 주제에 대해서 대략적 지형도를 갖게 되죠.


이 방식의 핵심은 다음과 같습니다:
  • 여러명이 동시에 논문 읽기를 협동적으로 할 수 있다
  • 빠른 시간에 엄청난 양의 논문을 분류하고 중요한 것을 발견할 수 있다
  • 회의를 하지 않고(집단사고를 피함) 각자 병렬로 하면서도(시간 효율성과 의견 다양성) 의견을 주고 받는 효과(상호 교류에서 새로운 발견)가 난다
  • 논문을 읽는 행위를 다양한 층위로 할 수 있다(제목만 보기, 초록도 보기, 도표나 테이블 중심으로 보기, 특정 부분 꼼꼼히 보기 등)
  • 끝나면 해당 주제/분야에 대한 대략적 지형도가 생긴다
여러명이 하는 경우를 예로 들었는데, 사실 혼자서도 가능합니다. 한번 해보시면 재미도 있고 효과도 높다는 것에 놀라실 겁니다. 저에게 AC2 과정을 하면서 이런 연구 논문 읽기를 주제로 코칭 받으신 팀장님이 있는데, 이전에는 팀에서 리서치할 때 각자 며칠에 걸쳐 따로 조사를 했고 지루하고 재미도 없었는데 이 방법을 배운 이후로 다같이 모여앉아 피자 먹으면서 게임하듯 즐겁게 리서치하게 되었고 시간도 훨씬 짧고 효율적이 되었다고 하시더군요. 특히 문헌 조사라는 일을 개인 활동이 아니라 팀 활동으로 할 수 있게 되어 좋았다고 하셨습니다. ^^

--김창준
by 애자일컨설팅 | 2014/11/26 14:24 | 트랙백 | 덧글(0)
개발 기간 추정이 엉망이 되게 하는 비결
개발자들은 자신이 작업할 일에 대해 추정해야 할 기회가 많습니다. 쉽게 말해 "이거 개발하는 데에 얼마나 걸리겠어?"에 대답하는 겁니다. 사업의 성패가 이 추정에 크게 의존하는 경우가 흔합니다.

소프트웨어공학에서는 수십년의 연구를 통해 이 개발자 추정의 정확도에 영향을 미치는 요소들을 찾아내었습니다. 이 주제 하나만으로 AC2의 하루 워크숍 꺼리이긴 한데, 그 중 추정이 엉망이 되게 하는 비결 몇가지를 소개해 볼까 합니다.
  • 요구사항 문서의 폰트 크기를 줄여라
  • 기간이 별로 없다고 알려줘라 (심지어는 간접적으로 넌지시 해도 효과가 있다)
  • 기준치를 제공하라(언제 안에 해야한다거나)
  • 새로운 기능이라고 하지 말고 사소한 확장이라고 말해줘라
  • 리스크 분석을 하라
  • 외부 평가자를 두지 말라
연구를 통해 위 방법을 사용하면 개발자 추정이 지나치게 낙관적으로 나오며(개발자 추정은 대부분의 경우 낙관적이라고 분석됨) 따라서 정확도가 떨어진다는 발견이 나왔습니다.

보시다시피 아주 사소해 보이는 것들에도 영향을 받습니다.좀 어처구니가 없다 싶죠. 흥미로운 부분은 요구사항명세서(SRS)의 내용이 어떤가와 상관 없이 추정에 영향을 미치는 요소가 많다는 점이죠 -- 좋은 SRS에 대한 환상(즉, SRS를 논리적으로 잘 쓰면 소프트웨어 개발이 잘 될거야)이 있는데 이게 고전 경제학에서 보는 이성적 인간에 대한 환상과 겹치는 부분이 있습니다. 행동경제학에서도 말하듯이 사람이라는 것이 사실 그렇게 논리적, 이성적인 존재가 아니거든요.

예를 들어 위에서 폰트 크기 같은 경우, 완전히 동일한 요구사항 문서를 폰트 크기를 줄여서 전체 페이지 수가 줄어들게 하면 사람들은 요구사항이 비교적 간단하다고 착각을 해서 추정치가 줄어들게 됩니다.

그리고 아무리 시간이 없고 바쁘다고 하더라도 그걸 티내면 개발자들은 상대를 기쁘게 해주기 위해(혹은 상대를 기분 나쁘게 하지 않기 위해) 추정치를 무의식적으로 낮추게 됩니다. 그걸 간접적으로 하더라도(지나가는 말로 넌지시 언급하거나) 효과가 있습니다. 비슷한 것으로 기준치를 제공하는 것도 그렇습니다. 남들은 얼마라고 한다는 걸 미리 알면 사람들은 거기에서 시작해서 추정치를 조정하는 경향이 있습니다. 또 사소한 확장이라고 말하면 실제로 추정할 때 사소하게 생각해서 더 작게 추정합니다. 상대의 말에 영향을 받는 것이죠.

리스크 분석을 하게 되면 실제로 리스크가 주는 것은 아니지만 리스크가 줄었다고 착각하게 되어 마치 해결이 된 것처럼 생각하고 추정치를 많이 줄이게 됩니다. 리스크를 많이 나열한 것으로 리스크가 없어졌다고 생각하고 자신의 추정에 대한 확신도도 높아져 버립니다.

외부 평가자 없이 내부 평가로만 해도 추정치가 낮아집니다. 아무래도 내부자들만 아는 불완전한 지식/정보에 영향을 받고, 또 우리가 하니까 성공해야해, 혹은 성공할거라는 내부인들의 기대에 맞추려는 마음 등이 작용하게 되는 거지요.

이 비결들을 사실 마음 먹기에 따라 역이용할 수도 있습니다. 개발자들이 추정을 지나치게 낙관적으로 하게 해서 스스로 함정에 빠지게 하고 싶은 경우 -- 예컨대 예전에 추정한 것을 들이밀고 책임지라고 하거나, 야근하라고 하거나 -- 이 방법을 악의적으로 쓸 수 있습니다.

당연히 제가 기대하는 것은 이 방법들을 반대로 쓰는 겁니다. 본인이 개발자에게 일을 맡기는 사람이라면 이런 요소들을 고려해서 주의를 하고, 스스로 개발자라면 이런 요소에 영향을 받을 수 있다는 것을 인식하고 조심해야겠죠. 개발자 개인이 할 수 있는 방법이 여러가지가 있는데 이건 다음 기회에... ^^;

--김창준
by 애자일컨설팅 | 2014/11/25 13:41 | 트랙백 | 덧글(0)
누구에게 일을 시켜야 하나
본인이 소프트웨어 개발 외주를 줘야 하는 일이 생겼다고 칩시다. 프로젝트는 데이터베이스 기반의 웹 서비스이고 PHP, 자바스크립트, HTML/CSS, SQL 등의 보편적인 기술을 사용합니다. 요구사항 명세서(스펙)를 공지하고 입찰을 하게 했습니다. 총 16곳으로부터 제안이 들어왔습니다. 이 중에서 예전에 완료한 프로젝트들에 대한 고객 만족도가 높고(10점 만점 중 평점 9.5 이상) 과거 프로젝트 경험이 충분하고, 적절한 방법론과 기술을 제안하고 그에 대한 역량이 있는 6곳을 1차 선정했습니다.

이 여섯곳에 대한 고객 만족도나 프로젝트 제안서, 개발자 이력서의 품질 등은 큰 차이가 없는 것으로 평가되었습니다. 여러분들은 다음 비교표를 보시고 어떤 회사를 선택하시겠습니까? (참고로 아래 사례는 실제 돈을 주고 진행되었던 연구입니다)

회사가격
(달러)
고객만족도과거 프로젝트 수추정 개발시간
(사람*시간)
A41210.0643
B7999.969665
C12509.90124136
D21779.8432340
E517710.04180
F56849.6544334


실제로 이 6곳에 모두 원하는 금액을 주고 프로젝트를 진행하게 했습니다. 각 개발사에 동일한 수준의 정보를 주고 동일한 정도의 지원을 해주려고 노력을 했습니다. 그렇게 해서 프로젝트를 완료할 때까지 가본 겁니다. 완료의 기준은 고객사가 미리 준비해 두었던 승인 테스트를 모두 통과하는 것이었습니다.

먼저 자신이라면 어느 회사를 고를지 꼭 마음을 정하신 다음에 계속 읽어주세요. ^^;















결과는 다음과 같았습니다.

회사실 개발시간
(사람*시간)
라인수승인테스트시
중대결함수
코드 복잡도
(CC per LOC)
코드 가독성
A29260040.09좋음
B842900130.09중간
C187280070.17중간
D242580070.13중간
E52719000160.14매우 나쁨
F474240050.16나쁨



A와 E를 비교하면 개발 시간만 따졌을 때 약 20배입니다. 당연히 라인수도 차이가 크고, 코드 복잡도(숨겨진 버그 개수, 유지 보수 비용, 디버깅할 때 버그를 삽입할 확률 등과 관련성이 높다고 밝혀진)도 차이가 크고요. 가독성도 차이가 큽니다. 이뿐만이 아닙니다. 추가적으로 개발이 종료된 시점에 각 회사에게 새로운 특정 요구사항을 반영하려면 얼마의 추가 개발시간이 필요하겠냐고 물었습니다.A회사는 2시간이라고 했고, E회사는 54시간이라고 답했습니다.

결과를 보고나서 생각은 어떻습니까? 미리 알았더라면 어느 회사를 골랐겠습니까?

어떤 분들은 자신이 처음부터 A회사를 골랐다고 기뻐하고 계실지도 모르겠습니다. "가장 저렴하고 가장 빠르다고 하니까 당연히 A를 골랐어야지"라고 하면서 자신이 정답을 골랐다고 생각하고 계실 겁니다.

사실 여기에는 정답이 존재하지 않습니다. 사후적으로 보면 A회사가 가장 좋은 선택이었기는 했지만 사전에 어느 회사가 좋은 회사인 걸 안다는 것 자체가 쉽지 않습니다. 가격이나 일정 기준으로 A회사를 골랐는데, 실제로도 A회사가 좋기는 했지만 그것은 운이 좋았던 겁니다.

연구에 따르면 전통적으로 외주 개발사를 선택하는 기준들이 효과적이지 않습니다. 다 뛰어나서 서로 큰 차이가 없다 싶은 회사들을 골랐는데, 실제로 동일한 요구사항 명세서를 주고 똑같이 일을 시켜보니 압도적인 차이가 벌어지는 겁니다. 이 프로젝트에 장기적으로 들어가는 비용면에서 보면 수십배 이상의 차이가 생기는 셈입니다.

예컨대 많이들 보는 "성공 사례" 경우 편향의 위험이 있습니다. 전체 몇 건 중에서 몇 건이 성공했다는 정보가 없이 성공한 사례만 소개되는 선택적 표본 선택의 문제가 있기 때문이죠. 온라인에 많이 광고하는 성형수술 비포어/애프터 사진들이나, 우리 병원에서 누가 수술해서 성공했다는 사례들이 그러합니다. 그래서 "근거 기반"(evidence-based)이 중요하다고들 하는 것이죠.

8천여개 프로젝트를 분석해 본 결과, 예를 들어 해당 외주업체의 경력(과거 얼마나 많은 프로젝트를 진행해 봤는가)은 프로젝트의 성공과 실패 여부에 영향력이 없었습니다. 하지만 8만여개의 입찰건을 함께 분석해서 나온 것은, 해당 입찰 업체의 프로젝트 수행 건수가 입찰한 업체들 중 평균보다 많으면 선택될 확률이 3배 가량 높았습니다. 성공과 실패에 영향력을 미치지 못하는 의미없는 노이즈에 신경을 쓴다는 말입니다.

가격(및 기간 -- 통상 기간과 가격은 비례)부분은 어떨까요? 앞에서 A회사를 고른 분들은 이걸 보고 골랐다고 하신 분들이 많을텐데요. 같은 연구에서 나온 결론은, 입찰 업체들 중 평균보다 낮은 가격의 업체를 선정하면 프로젝트 실패 확률은 24% 가량 높아집니다. 또한 가격이 낮은 업체를 주로 선정하는 고객들은 실제 스킬이 떨어지는 업체를 고르는 경향이 강하다는 분석도 나왔습니다. 더닝-크루거 효과(음의 생산성 참고)에 따르면, 실력이 떨어지는 사람들일수록 자신의 실력에 대해 지나치게 낙관적인 평가를 하는데, 마찬가지로 실력이 떨어지는 회사가 프로젝트 추정도 지나치게 낙관적일 수 있다는 말입니다.

그 외에 재미있는 부분은, 78만개 프로젝트에 대한 분석을 보면, 외주업체와 상관 없이, 이전 외주 프로젝트에서 성공 경험이 많은 고객사가 이번 프로젝트에 대해서도 성공할 확률이 높다는 결과가 나왔습니다. 확률로 보면 실패를 적게 경험한 고객사는 이번 프로젝트에서 실패할 확률이 그렇지 않은 고객사에 비해 51%나 낮았습니다. 실패 확률이 절반인 것이죠. 해석하자면, 소프트웨어 외주 프로젝트의 성공 실패에는 고객사의 역할(얼마나 잘 고르느냐, 어떻게 관리하느냐 등)이 중요하다는 것입니다.

자, 그러면 외주 프로젝트의 성공과 실패에 가장 영향이 큰 변수는 무엇이었을까요? 이전에 같이 협력해 본 적이 있느냐 하는 변수입니다. 이전에 협력을 해본 외주업체와 다시 일하는 경우, 실패 확률은 17%로 떨어집니다(78만개 프로젝트에 대한 연구 경우). 그렇지 않은 경우에 비해 약 6분의 일이 되는 셈입니다. 이건 무슨 뜻일까요? 보통 예전에 일해 보고 다시 일하는 경우는 만족할 경우입니다. 다시 말해, 한 번 일해보는 것 만큼 좋은 테스트가 없다는 것이죠. 앞서 말한 가격 요소를 무시해도 될 만큼 훨씬 더 영향력이 큰 요소입니다.

이런 결과들을 통합해 볼 때, 위 연구들에서 외주 업체 선정시 추천하는 방법은 "시험 외주"(trialsourcing)입니다. 시험 외주란 여러 입찰업체와 실질적으로 일을 하기 전에 업체를 평가하기 위해 일을 줘서 함께 일해보는 걸 말합니다. 시험 외주는 그냥 테스트만 하는 것이 아니라 외주라는 측면이 있어서, 실제로 우리에게 가치있는 일을 외주 주는 것이고, 따라서 시험 외주 참가에 대한 지불도 이루어 집니다. 이 시험 외주는 크게 보면 3가지 종류가 있습니다.

  1. 동일 작업 : 우리가 실제 프로젝트에서 하게 될 일 중 작은 부분 하나를 여러 입찰업체에게 주는 것입니다. 동일한 작업을 복수 진행하는 것이죠. 이 경우 금전적 부담이 늘어나게 되지만 가장 신뢰할만한 비교가 가능하다는 장점이 있습니다.
  2. 유사 작업 : 실제 프로젝트에서 하게 될 일 중에 유사하지만 다른 일들을 입찰업체에 나눠줍니다. 참고로 관련 논문에서는 모 텔레콤 회사에서 이 시험 외주 방식을 성공적으로 사용한 사례를 소개합니다.
  3. 상이 작업 : 전혀 다른 일들을 업체들에 나눠줍니다. 이 경우 비교가 쉽지 않지만, 그래도 논문에서는 분석에 따르면 안하는 것보다는 훨씬 낫다고 합니다.
이런 시험 외주를 통해, 우리와 업체간의 협력 과정(얼마나 그쪽에서 협력을 잘 해줬는지), 전달된 소프트웨어의 결함 숫자와 심각도, 코드의 품질(제삼자의 코드 리뷰 등), 생산성 등을 비교 평가합니다. 그 결과 여러 업체 중 하나를 선정하는 것이죠.

사실 이 시험 외주는 애자일 방법론과 비슷한 면이 많이 있습니다. 폭포수 방식으로 프로젝트를 쪼갰을 때, 즉, 제안, 분석, 설계, 구현, 테스트, 전개 등으로 쪼갰을 때 어느 한 단계에 대한 피드백/평가로 다음 단계를 예측하기가 어렵기 때문에, 이것을 프랙탈 적으로 다 섞어서 반복 주기로 나누면, 하나의 반복 주기로 다음 반복 주기 예측이 비교적 유의미해진다는 것이 애자일의 주장입니다. 애자일은 쉽게 말해, 하나의 프로젝트를 마치 여러개의 프로젝트인 것처럼 만들어 각각의 프로젝트에서 배운 교훈을 다음 프로젝트에 적용하여 성공률을 높이는 것입니다.

분명 시험 외주가 추가적 비용이 들 수는 있지만, 업체 선정을 잘했을 때와 못했을 때의 차이가 엄청나다는 점을 고려한다면 투자할만한 가치가 있지 않나 생각이 듭니다. (이 때 원 프로젝트에서 어떤 부분을 쪼개어서 시험 외주 작업으로 선정하느냐와 평가시 무엇을 보는가가 전문성이 필요하고 또 차이가 큰 부분이긴 합니다)

그리고 꼭 시험 외주 방식을 적용할 수는 없더라도 이런 애자일적 접근법을 프로젝트에 어떻게 적용해 볼 수 있을까 고민하면 도움이 되지 않을까 싶네요.

제가 이 글을 쓰면서 참고한 논문은 다음과 같습니다. 정확성을 위해 몇 몇 부분은 원저자와 서신 교환을 통해 알아보고 확인했습니다.
  • Better Selection of Software Providers Through Trialsourcing
  • Failure Factors of Software Projects at a Global Outsourcing Marketplace
  • When is a low bid price a thread and when an opportunity for your project? Analyzing projects in an online marketplace for outsourcing software development
  • A Strong Focus on Low Price When Selecting Software Providers Increases the Likelihood of Failure in Software Outsourcing Projects
--김창준
by 애자일컨설팅 | 2014/11/14 09:00 | 트랙백 | 덧글(5)
< 이전페이지 다음페이지 >


Site Meter