소프트웨어 인문학(Software Humanities)

최근 '소프트웨어 인문학(Software Humanities)'에 대한 이야기가 종종 들린다. '인문학'은 인문학인데 소프트웨어 인문학은 또 뭘까? 정확하게 말하면 필자도 모른다. 영문 Wikipedia에서 '디지털 인문학(Digital Humanities)'에 대한 내용은 있는데 소프트웨어 인문학에 대한 정의는 찾아볼 없었다. 아직까지 '소프트웨어 인문학'에 대해 다수가 공감하는 정의가 없다고 보는 게 옳은 것 같다.

필자가 인문과 전공도 아니므로 인문학이 뭔지도 제대로 모른다. 국문 Wikipedia에서 '인문학(人文學)' 인문학에 대한 정의를 볼 수 있다. 국문 Wikipedia에서 인문학에 대해서 다음과 같이 정의를 한다.

인문학의 분야로써 '고전', '역사', '언어', '법', '문학', '철학', '종교', '역사' 등이 있다고 정의되어 있다. 그리고 이 인문학을 과학적으로 규명하기 위한 연구가 '사회 과학'과 매우 밀접하게 연관되어 있어 보인다. [1]

결국 탐구하는 학문...

소프트웨어는 사람이 만든다. 콩 심은 데 콩 나고, 팥 심은 데 팥 나듯, 그 소프트웨어를 보면 그 기업이 추구하는 가치관을 어느 부분 읽을 수 있다. 하물며 소프트웨어의 속의 하나 하나 벗겨 코드 까보면 그 코드를 만든 사람이 추구하는 생각을 읽을 수 있다. 결국 소프트웨어는 사람에 의해 만들어진 하나의 인격적인 집합, 또는 인격체라고 정의하고 싶다. '소프트웨어 인문학'은 소프트웨어의 가치를 탐구하는 활동이 그 시작이라고 생각한다.

최근의 소프트웨어 개발은 애자일과 린 소프트웨어의 영향을 많이 받았다. 소프트웨어를 잘 만드는 방법은 이론적인 방법보다 실용성에 초점을 맞추고 있다. 과거부터 지금까지 소프트웨어 개발 방법론에 대해서 많은 발전을 이루어왔다. 전반적인 모든 것을 포괄하는 '소프트웨어 공학'은 소프트웨어를 정의하고 소프트웨어를 개발하는 모든 것을 정의하고 있다. 단지, 개발 영역 뿐만 아니라 '소프트웨어 테스트'와 '소프트웨어 운영'에 대한 효과적인 방법을 제시한다. 우리가 알고 있는 개발 프로세스나 방법론 등은 '소프트웨어 공학'의 일부이다.

그리고 아무리 이론이나 실용적인 부분을 적용하더라도 개발 툴이나 개발 플랫폼이 받쳐주지 않으면 실용적이라고 할 수 없다. 최근의 객체지향 프로그래밍 언어를 지원하는 개발 툴은 도구가 없이 개발하는 것이 상상하기 힘들다. (일부 리눅스 계열의 개발자들은 개발 통합 툴(IDE)보다 vi 또는 vim 을 사용하는 것이 더 편하다고 한다. 분명 툴이 만능은 아니다.)

실용성을 추구하는 애자일 소프트웨어

최근 애자일(Agile)과 린(Lean) 소프트웨어 개발 방법 및 프로세스가 소프트웨어 개발 문화를 많이 바꾸어 놓았다. 최근의 이런 애자일리티(Agility)한 방법들은 실질적으로 실용성을 높이기 위해 사람을 탐구한다. 반대로 사람을 탐구하여 실용성과 낭비를 제거하고자 한다는 것이다.

낭비에 대표적인 두 가지가 있다. 문맥 전환(Context Switching)과 성능(Performance), 커뮤니케이션(Communication)이다.

  1. 문맥 전환(Context Switching)이 얼마나 리소스를 잡아먹는지에 대한 실험이 있었다. 사무업무는 가장 집중할 때 가장 높은 퍼포먼스를 낸다. 소프트웨어를 만드는 개발자들도 마찬가지며, 공부하는 학생도 마찬가지다. 이 집중력을 수치로 100이라고 가정하자. 집중하는 그 시간에 업무에 의해, 또는 친구들의 전화가 와서 전화를 받는다고 가정하자. 전화를 끊고 나서 그 사람이 이전 상태의 100의 집중력 상태로 다시 진입하기 위해 약 15분이라는 시간이 필요하다고 한다. 더군다나 신체적인 움직임이 필요한 문맥 전환인 경우, 다시 원상태로 돌아와 다시 안정된 심박수로 돌아가는 것 마저 5분 정도의 시간이 소요된다.

  2. 성능(Performance)을 보자. 비싼 연봉을 주고 그 사람을 100% 활용하지 못하면 무능한 팀장, 무능한 조직으로 오해 받기 쉽다. 더 나아가 120%의 퍼포먼스를 내길 원한다. 그리고 평가는 이런 식으로 등급을 매기지는 않는가?

    120%=S, 100%=A, 80%=B, 60%~=C

'린 소프트웨어 개발(Lean Software Development)'을 출간한 Mary Poppendieck와 Tom Poppendieck는 이를 컴퓨터의 CPU에 비유하기도 했다. 컴퓨터의 CPU를 잘 활용하는 것은 CPU를 항상 100% 성능을 끌어내는 것이 아니다. 그러다간 CPU의 수명이 짧아지고, CPU가 열 받는다. 120%의 성능을 내기 위해 오버클럭(Overclocking-CPU의 권장 클럭을 의도적으로 높이는 조작 행위)을 하게 되면 컴퓨터는 이유 없이 꺼지기를 반복하다가, 언젠가 CPU가 쪼개진다.

즉, 높은 성능을 요구하고, 문맥 전환도 자주 발생한다면, 컴퓨터는 이도 저도 모두 다 제시간이 마치지 못한다. 이 비유가 사람에게도 마찬가지로 적용된다는 것이다.

커뮤니케이션(Communication) 또한 잘 알려진 실화가 많다. IBM 출신의 운영체제를 만들던 프레더릭 브룩스(Frederick Brooks)는 전설이라고 일컫는 유명한 'The Mythical Man-Month' 저서가 있다. 우리가 개발할 때 익히 듣던 맨먼스(Man Month)라는 용어가 여기에서 나오게 되었다. 'Man Month(M/M)'는 번역하면 인월(人月), 풀어서 얘기하면 '한 사람이 한 달 동안 할 수 있는 일' 이다. 초기 소프트웨어 공학에서는 사람을 하나의 '객체의 하나(a Unit of Object)' 인 물질적인 존재로 다루어 졌다. 사람 한명 한명 '리소스'이자 '비용'이다. 현재까지도 우리나라에서는 프로젝트에 투입되는 인력의 수를 산정하는 기준은 바로 이 'Man Month(M/M)'이다.

포토샵(Photoshop) 같은 이미지 편집 소프트웨어를 12개월에 만들어야 한다면, 12 M/M(Man Month)가 되고, 한 사람을 12개월 동안 개발시키면 된다. 그런데 한 달 만에 끝내고 싶다면, 12개월치 일정과 업무량을 12조각으로 나누어 12명의 개발자를 투입시켜 배당한다면, 과연 한 달 만에 끝날까? 모든 소프트웨어 공학자가 '그렇다' 또는 '그렇지 않을까' 란 대답에 브룩스는 전혀 다른 답을 했다.

이것이 바로 '브룩스의 법칙'이다.

즉, '1 * 12 = 12 * 1 은 성립되지 않는다. ' 개발자(1명) * 개발기간(12개월) = 개발자(12명) * 개발기간(1개월) '

12명이 프로젝트에 투입되게 되면 이메일 소통, 상호간의 인터페이스 합의, 미팅 등 커뮤니케이션 비용이 곱하기(*)가 아닌 제곱(^) 만큼 복잡해진다고 정의하였다. 이 '브룩스의 법칙'이 오늘날 사실임을 말해주는 다양한 공학적인 실험이 있으니 찾아보는 것도 재미있을 것이다.


[이미지 출처는 여기]

'브룩스'의 원서는 '이 링크에서' 번역서를 찾을 수 있다. 필자도 아직 읽어보지는 않았지만, 지금 읽는 책을 다 읽으면 조만간 볼 계획이다.

널린 게 한 번에 한 가지 일을 할 수 있는 사람이다.

자신의 능력 100% 중에 60~70%를 발휘할 수 있는 사람은 널려있다. 5천만원 연봉의 과장급 개발자 한 명 데리고 있는 것보다 3천만원 연봉의 신입이나 대리 한 명이 같은 결과를 내지만, 양적인 면에서 생산성이 좋다는 이치이다.

문맥 전환(Context Switching) 논리를 가져다 대는 것은 쉽다. 그럼에도 불구하고 한 번에 두 가지 일을 할 수 있는 사람이 더 가치 있는 사람으로 대우 받는다. PM(Project Manager) 한 명이 2~3개 프로젝트를 잘 수행하는 것도 능력이다. 이것이 특별한 슈퍼맨의 기운이 필요한 것은 아니다. 그렇다고 2~3개의 프로젝트가 전부 어중간 하다고 결론 지을 수도 없다.

개발자에게 명세서를 던져주고 일을 제시간에 완료하는 것은 기본 중의 기본이다. 당연히 할 수 있어야 하는 것을 못하는 사람이 문제다. 명세서가 부실하다고 탓해도 잘 하는 사람은 한다. 못하는 사람이 부실하다고 불평한다. 어쩌면 개발자가 두 개의 프로젝트에 투입하여 일을 잘 해내는 것은 아무나 할 수 없다. 그렇다고 매일 철야에 야근을 하지도 않는다.

이렇게 일을 잘 하는 사람들이 많다. 주변을 살펴봐라. 온갖 애자일 법칙을 추구하며 존중 받기를 원한다면, 기본적인 자기 관리 능력이 있어야 한다. 자기 관리를 잘 하려면 옆의 동료보다는 내가 더 나은 실력을 갖추어야 한다. 하향 평준화에 맞추지 말고 냉정하게 스스로를 평가할 수 있어야 한다.

자신의 성능을 100%, 그리고 120%를 끌어내보지 못한 사람은 자신의 능력과 성능을 모른다. 그 와중에 일을 멀티쓰레딩(Multi-Threading)과 멀테테스킹(Multi-Tasking)으로 한다고 상상해 보자. 이렇게 하는 사람들이 없을 것 같지만, 필자는 .NET 컨설팅 회사를 다니면서 많이 봐왔다. 정말 실용적으로 낭비를 제거하고 일을 잘 한다.

소프트웨어 공학을 들여다 보면, 기본적으로 개발에 필요한 기술적인 테크닉과 소프트웨어와 개발에 대한 이해, 그리고 개발에 필요한 충분한 능력을 기본 전제로 하고 있다. 그 전제를 바탕으로 소프트웨어를 개발하는 방법론을 지향한다. 애자일도 마찬가지다. 소프트웨어를 사랑하고 개발을 즐기는 애정이 없다면 그 사람에겐 무효인 방법론에 불과하다. 그러므로 기본 전제에 해당되지 않는 사람들이라면 애자일은 매우 비효율적일 것이다.

애자일이 그저 허울 좋은 면죄부가 아니란 점을 확실하게 인식해야 할 때이다.

이 부분에 동의할 수 없는 사람도 있겠지만, 일어날 수 있을 법한 예이고, 실제로 겪어 본 일이다. 그래서 필자가 다양한 시각으로 역설하지 못한 부족한 부분도 있으니 이점 양해 바란다.

애자일은 맞춤복처럼 딱 맞지 않더라..

최근 필자와 같은 생각을 하는 사람들이 많이 늘었다. 애자일 개발 방법과 프로세스를 우리나라에 그대로 적용시키기 무리이다. 서양 사람이 서양 사람을 탐구하여 만든 방법론이 우리나라 사람에게 적용하기에 문화적인 차이와 생각이나 관념이 다르기 때문에 애자일을 적용하는 사람이나 적용 받는 사람이나 서로 불편하다.

  • 개발 업무 자체를 거의 개인(혼자)할 수 있도록 쪼개서 주는데, 짝 프로그래밍(Pair Programming)이 무슨 필요가 있겠냐. 언제부터 우리가 몸 비비며 일했다고...
  • 프로젝트 기간이 짧고, 비용이 낮아야 프로젝트를 수주할 수 있는데, TDD(Test Driven Development), 즉, 테스트 코드부터 만들라고 하니 이게 왠 봉창 두드리는 소리냐.
  • 미국은 테러리스트와 협상하지 않으며, 고객은 왕이요, 고객은 '을병정'을 위해 화합, 협력하지 않아...
  • 가치 있는 소프트웨어? 5년 후 차세대 프로젝트, 그 5년 후 차세대 프로젝트, 또 5년 후 차세대 프로젝트… 가치가 있으면 가치를 덧붙이겠지, 갈아 엎을 필요는 없겠지...

모든 소프트웨어 기업이 그렇단 말은 아니다. 주로 SI 프로젝트에서 발생한다. 그리고 우리나라 SI 소프트웨어 산업의 규모는 80% 이다. (수치적인 출처). 80%에 육박하니 거의 대부분이라고 말해도 되겠다.

  • 동료나 상사에게 속마음을 터놓는 것은 자신의 약점을 오픈하는 것이므로 꺼려하며,
  • 자신의 치부를 놓고 토론하듯 내 코드를 보며 코드 리뷰를 하는 것을 꺼리며,
  • 품앗이처럼 서로 돕는 공동체 사회에서 서구화된 팽배한 개인주의를 선호하며,
  • 전문직 직종이란 말이 무색할 정도로 산업 전반적으로 하향 평준화된 개발자나 기술자

이런 우리나라의 문화와 특성에 맞는 소프트웨어 방법론이 필요하다. '애자일 성공 사례' 들을 들어보면 하나 같이 책에서나 나올 법한 뻔한 얘기들 뿐이다. 성공이란 기준이 기한 내에 합의된 비용으로 프로젝트를 마친 경우를 성공이라고 하나, 모든 팀원이 '애자일'을 성공적으로 적용하여 성공했다는 것에 동의할 지는 의문이다.

’진정성'이 없는 롤러코스터와 같은 프로세스와 기법들...

이렇게 쓰고 보니, 뭐라고 결론을 내야 할 지 본인도 모르겠다. 넓은 범위로 애자일에 대한 사상과 그것이 추구하는 가치는 필자도 매우 공감한다. 물론 지금도 마찬가지다. 그리고 애자일을 잘 알고, 잘 하고 싶다.


[이미지 출처는 여기]

애자일(Agile)과 린(Lean) 방법론(?)은 결국 일본의 도요타 자동차 공장의 프로세스와 사상을 소프트웨어라는 분야에 적용시킨 것이다. 과거에 미국 등 많은 자동차 생산 기업들이 일본의 도요타 자동차의 생산 기법을 적용하였는데, 왜 실패하는지 모르겠다고 했다. 모든 기법과 프로세스를 그대로 적용했는데도 말이다.

'짝퉁'과 '명품'의 차이는 '장인 정신'이 아닌가. 모두가 S+급 짝퉁을 가리켜 명품이라고 하지만 1~2년 써보면 짝퉁은 역시나 짝퉁이다.

왜 많은 자동차 기업들이 도요타 자동차의 생산 방식에 실패했을까? 독자들이 생각하는.. 목구멍까지 올라오는 무언가가 있을 것이다. 정답은 바로 그것이 없기 때문에 모조리 실패했다.

신고
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 박중석 2013.01.25 08:15 신고 Address Modify/Delete Reply

    좋은글 잘보고 갑니다. 장인정신하니 학생 때 교과서에 배운 방망이 깍던 노인 소설이 떠오르네요.

  2. 짜두 2013.01.25 08:41 신고 Address Modify/Delete Reply

    일정부분은 동의하고 어떤부분은 공감할 수 없기도 하지만 이 글에서 가장 공감하는건 EX-회사의 경험은 정말 좋은 경험이었음~ 구정오기전에 함 봅시다~ 레알~ㅎ

  3. kevin 2013.01.25 09:45 신고 Address Modify/Delete Reply

    글의 주제와는 벗어나지만. ^^ Turbo C에 대한 평가는 지금 세대에서 하면 안될 것 같습니다. 그 당시에 실제로 제가 써 본 기억에 의하면, IDE 환경 내에서 편집/컴파일하고 디버깅까지 할 수 있었다는 것 자체가 편리했었습니다. 인텔리센스 같은 것은 그 당시에는 어떤 IDE에서도 구현하지 않았으므로 비교해서 우울해질만한 것도 없었다는. ^^