2019.02.08

익명 기고 | 컴퓨터 전공자만으로는 개발팀을 꾸리면 안되는 이유

Anonymous | CIO

컴퓨터와 과학이라는 두 단어를 생각해보라. 첫 번째는 인류에게 아주 큰 선물을 줬다. 그 범위도 생명을 살리는 전자 의료 기록(EMR)의 보편화부터 ‘시간에 구애받지 않는 트위터의 가상 싸움’까지 아주 광범위하다. 두 번째 단어인 과학은 소아마비 백신, 달 탐사 등 큰 ‘발전’을 전달한 ‘지성’의 변화와 발전을 대변한다. 그렇다면 프로그래밍 팀을 꾸릴 때, 이 두 단어를 결합한 ‘컴퓨터과학’ 전공자만으로는 ‘부족’한 이유가 무엇일까?

이 분야가 전달하는 발전과 성과가 미흡해서가 아니다. 지금 세상에는 새로운 프로그래밍 언어, 매우 영리한 검색 알고리즘, 머신 비전 알고리즘 같은 새로운 것들이 가득 들어 있는 페타바이트급 레이텍(LaTeX) 파일과 수많은 개념이 존재한다. 멋진 것들이 아주 많다.

그러나 문제는 이 수많은 것들을 정말 필요로 하는 사람이 극소수에 불과하다는 것이다. 한 친구의 고백에 따르면 CS(컴퓨터과학) 전공자는 채용하지 않고 물리, 회계, 기타 수학에 정통한 인재들만 채용해 큰 성과를 일궈낸 개발팀이 있다. 이런 신입 직원들은 훨씬 더 ‘실무적’이다. 머신이 결과를 전달하도록 만드는 데에만 집중한다. 아마 대부분 기업이 원하는 인재일 것이다.
 

ⓒCredit: GettyImages


CS 학위가 나쁘다는 이야기는 아니다. 대부분 사람이 풀고 싶어 하는 문제에 대해 이야기하지 않을 뿐이다. 지금부터 CS 학위 소지자보다 다른 전공자가 더 나은 몇 가지 이유를 설명한다.

이론이 오히려 시장을 혼탁하게 하고 헷갈리게 한다
본질적으로 수학자 같은 컴퓨터 과학자가 많다. 이론에 사로잡힌 사고방식이 체화되어 있다. 한 ‘이론가’는 모든 수학적 증명이 프로그램이고, 프로그램도 수학 증명이라고 생각한다고 말한 적이 있다. 그는 실제 작동하는 코드를 전달하는 것에는 큰 관심이 없다. 그보다는 코드 증명이 적절하다는 것에 더 큰 관심을 둔다. 좋다.

NP-완전 문제(NP-completeness)튜링 머신(Turing machines)을 충분히 이해하지 않은 상태에서 졸업하게 되는 CS 전공자는 많지 않다. NP-완전 문제와 튜링 머신은 ‘나쁜 행동 성향’이 초래되지 않았다면 유익할 수 있는 2개 이론 분야다. 한 생물학자가 필자에게 DNA 염기 순서 매칭 문제 하나를 해결해 달라고 요청했다. 필자는 이를 푸는 데 아주 많은 시간이 소요될 수 있는 NP-완전 문제라고 말했다. 그는 개의치 않았다. 어떻게든 풀어야 하는 문제였다. 사실 대부분 경우, 대부분 NP-완전 문제를 아주 쉽게 해결할 수 있다는 점이 밝혀졌다. 알고리즘을 망치는 병리학적 인스턴스는 소수에 불과하다. 그러나 ‘이론가’들은 일상에서 관측되는 경우가 거의 없고, 단순한 알고리즘을 방해하는 빈약한 세트에 강박적으로 매달린다.

튜링 머신과 관련해서도 동일한 문제가 발생한다. 본분을 지키는 CS 전공자는 우리가 컴퓨터 알고리즘을 전혀 분석할 수 없다고 말하는 라이스의 정리(Rice’s Theorem) 같은 ‘허무주의적’ 결과를 학습한다. 그러나 튜링 머신은 보통의 머신이 작동하는 방식에서는 매우 나쁜 모델이다. 또 코드로 스마트한 일을 하는 소프트웨어를 쉽게 개발할 수 있는 경우가 많다. 이론적 결과를 유익하게 수용하지 않는 CS 전공자는 완벽하게 사용할 수 있는 해답이 가까이 있는 경우에도 포기하는 위험을 초래할 수도 있다.

학교에서 사용하는 ‘언어’가 실제로 쓰이는 경우는 드물다
학교는 ‘속물근성’을 키우고, ‘불가해한 해법’을 좋아하도록 만든다. 우리는 이를 부인하기 어렵다. 모든 분야에서 이렇다. 필자는 한 MIT 졸업생에게 선호하는 프로그래밍 언어를 물은 적이 있다. 그는 CLU라고 답하며 필자가 무슨 의미인지 모를 것이라고 말했다. 그 졸업생이 맞았다. 필자는 CLU가 뭔지 모른다. 

언어에 강박 관념을 가진 사람들이 내놓은 좋은 아이디어들이 무수히 많다. 그러나 때때로 이런 아이디어가 혼란과 혼동을 초래하는 경우도 있다. 한 팀원이 조금은 이상한 피처를 좋아해서, 코드 기반에 이를 포함하기 시작했다고 가정하자. 나머지 사람들도 이를 배워야만 할 것이다. 모든 사람이 이런 식으로 일을 하면, 모두가 보조를 맞추는 데 많은 시간을 낭비하게 될 것이다.

구글이 고(Go)를 구현하면서 ‘로우 로드(경제적이고 단순한)’ 방식을 선택한 이유가 여기에 있다. 개발자는 언어에 포함된 구성 요소가 소수여야 하며, 가능한 짧은 시간에 학습할 수 있을 만큼 단순해야 한다고 강조했다. 이런 단순성은 모든 사람을 도왔다. 모든 사람이 핵심을 정확히 이해했기 때문이다.

많은 CS 교수들은 프로그래머가 아닌 수학자다
많은 컴퓨터 과학 전공 학부에 해당하는 ‘어두운 비밀’이 하나 있다. 많은 교수가 컴퓨터를 프로그래밍하지 못한다는 것이다. 교수가 하는 일은 강의와 그랜트(연구 보조금)를 놓고 벌이는 경쟁이다. 스프레드시트와 그랜트 제안서에 대해서는 잘 안다. 그러나 실제 제대로 연구를 수행하지 않는다. 신이 교수들에게 ‘대학원생’을 선물한 이유가 여기에 있다. 마지막으로 컴퓨터 프로그래밍을 실제 해본 시기가 대학원 재학 시절이었던 교수들이 많다. 이후 실력이 녹슬었을 것이고, 컴퓨터에 설치된 컴파일러는 작동조차 되지 않을 수도 있다.

실제 활용되는 경우가 드문 ‘필수 과목’들이 많다
데이터 구조는 컴퓨터과학 전공 학생들이 종종 2학년 때 배우는 주요 과목이다. 유감스럽게도 우리는 이제 데이터 구조를 많이 사용하지 않는다. 이제 우리를 위해 사고하는 데이터베이스에 집어넣거나, 객체 해시 테이블에 집어넣는다. 아직도 알고리즘 측면의 복잡성에 대해 생각해야 하는 사람들에게는 꽤 유용하다. 그러나 B-트리, 심지어 연결된 리스트에 대해 걱정해야 하는 사람들은 정말 극소수다. 그뿐만 아니라, 많은 사람이 데이터 구조를 직접 다루기보다 표준 라이브러리를 믿는 것이 더 낫다는 사실을 깨달았다. 쉽게 실수를 저지르기 때문이다. 많은 기업과 기관이 독자 개발한 데이터 구조 배포를 금지하고 있는데, 여기에는 그럴만한 이유가 있다.

이 밖에도, 더는 중요하지 않게 되어버린 ‘과목’들이 구식 커리큘럼에 많이 남아 있다. 컴파일러는 복잡하고 필수적이다. 그렇지만 실제 컴파일러를 작성하는 사람들은 학생들뿐이다. 한 학기 과정에서 강제로 ‘장난감 같은 버전’을 만든다. 심지어 애플조차 스위프트(Swift)용 컴파일러를 구현할 때 기본 오픈소스 도구들을 사용했다.

수학 모델이 잘못된 길로 인도할 수 있다
데이터베이스 이론을 배운 사람이라면 정교한 데이터 구조를 작은 테이블로 분해하는 방법인 보이스 코드 노멀 폼(Boyce–Codd Normal Form)의 ‘영리함’을 발견했을 것이다. 아주 명쾌하고 효율적이다. 그러나 문제가 있다. JOIN 명령으로 채워지는 SQL 쿼리에 대한 응답 시간이 정말 길다.

대부분의 개발팀은 데이터베이스를 ‘비정규화’해서 성능을 높이는 방법을 터득한다. 다시 말해, 모든 ‘영리함’을 없애버리고 데이터를 하나의 큰 테이블에 집어넣는다. 지저분하고 낭비적이지만, 놀랍도록 빠를 때가 많다. 그리고 디스크 공간이 저렴하다.

교육받은 내용을 실무에 적용하기 시작한 후, CS 과정에서 배운 수학적 ‘영리함’을 없애는 데 몇 년을 소비하게 되는 개발자들이 많다.

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2019.02.08

익명 기고 | 컴퓨터 전공자만으로는 개발팀을 꾸리면 안되는 이유

Anonymous | CIO

컴퓨터와 과학이라는 두 단어를 생각해보라. 첫 번째는 인류에게 아주 큰 선물을 줬다. 그 범위도 생명을 살리는 전자 의료 기록(EMR)의 보편화부터 ‘시간에 구애받지 않는 트위터의 가상 싸움’까지 아주 광범위하다. 두 번째 단어인 과학은 소아마비 백신, 달 탐사 등 큰 ‘발전’을 전달한 ‘지성’의 변화와 발전을 대변한다. 그렇다면 프로그래밍 팀을 꾸릴 때, 이 두 단어를 결합한 ‘컴퓨터과학’ 전공자만으로는 ‘부족’한 이유가 무엇일까?

이 분야가 전달하는 발전과 성과가 미흡해서가 아니다. 지금 세상에는 새로운 프로그래밍 언어, 매우 영리한 검색 알고리즘, 머신 비전 알고리즘 같은 새로운 것들이 가득 들어 있는 페타바이트급 레이텍(LaTeX) 파일과 수많은 개념이 존재한다. 멋진 것들이 아주 많다.

그러나 문제는 이 수많은 것들을 정말 필요로 하는 사람이 극소수에 불과하다는 것이다. 한 친구의 고백에 따르면 CS(컴퓨터과학) 전공자는 채용하지 않고 물리, 회계, 기타 수학에 정통한 인재들만 채용해 큰 성과를 일궈낸 개발팀이 있다. 이런 신입 직원들은 훨씬 더 ‘실무적’이다. 머신이 결과를 전달하도록 만드는 데에만 집중한다. 아마 대부분 기업이 원하는 인재일 것이다.
 

ⓒCredit: GettyImages


CS 학위가 나쁘다는 이야기는 아니다. 대부분 사람이 풀고 싶어 하는 문제에 대해 이야기하지 않을 뿐이다. 지금부터 CS 학위 소지자보다 다른 전공자가 더 나은 몇 가지 이유를 설명한다.

이론이 오히려 시장을 혼탁하게 하고 헷갈리게 한다
본질적으로 수학자 같은 컴퓨터 과학자가 많다. 이론에 사로잡힌 사고방식이 체화되어 있다. 한 ‘이론가’는 모든 수학적 증명이 프로그램이고, 프로그램도 수학 증명이라고 생각한다고 말한 적이 있다. 그는 실제 작동하는 코드를 전달하는 것에는 큰 관심이 없다. 그보다는 코드 증명이 적절하다는 것에 더 큰 관심을 둔다. 좋다.

NP-완전 문제(NP-completeness)튜링 머신(Turing machines)을 충분히 이해하지 않은 상태에서 졸업하게 되는 CS 전공자는 많지 않다. NP-완전 문제와 튜링 머신은 ‘나쁜 행동 성향’이 초래되지 않았다면 유익할 수 있는 2개 이론 분야다. 한 생물학자가 필자에게 DNA 염기 순서 매칭 문제 하나를 해결해 달라고 요청했다. 필자는 이를 푸는 데 아주 많은 시간이 소요될 수 있는 NP-완전 문제라고 말했다. 그는 개의치 않았다. 어떻게든 풀어야 하는 문제였다. 사실 대부분 경우, 대부분 NP-완전 문제를 아주 쉽게 해결할 수 있다는 점이 밝혀졌다. 알고리즘을 망치는 병리학적 인스턴스는 소수에 불과하다. 그러나 ‘이론가’들은 일상에서 관측되는 경우가 거의 없고, 단순한 알고리즘을 방해하는 빈약한 세트에 강박적으로 매달린다.

튜링 머신과 관련해서도 동일한 문제가 발생한다. 본분을 지키는 CS 전공자는 우리가 컴퓨터 알고리즘을 전혀 분석할 수 없다고 말하는 라이스의 정리(Rice’s Theorem) 같은 ‘허무주의적’ 결과를 학습한다. 그러나 튜링 머신은 보통의 머신이 작동하는 방식에서는 매우 나쁜 모델이다. 또 코드로 스마트한 일을 하는 소프트웨어를 쉽게 개발할 수 있는 경우가 많다. 이론적 결과를 유익하게 수용하지 않는 CS 전공자는 완벽하게 사용할 수 있는 해답이 가까이 있는 경우에도 포기하는 위험을 초래할 수도 있다.

학교에서 사용하는 ‘언어’가 실제로 쓰이는 경우는 드물다
학교는 ‘속물근성’을 키우고, ‘불가해한 해법’을 좋아하도록 만든다. 우리는 이를 부인하기 어렵다. 모든 분야에서 이렇다. 필자는 한 MIT 졸업생에게 선호하는 프로그래밍 언어를 물은 적이 있다. 그는 CLU라고 답하며 필자가 무슨 의미인지 모를 것이라고 말했다. 그 졸업생이 맞았다. 필자는 CLU가 뭔지 모른다. 

언어에 강박 관념을 가진 사람들이 내놓은 좋은 아이디어들이 무수히 많다. 그러나 때때로 이런 아이디어가 혼란과 혼동을 초래하는 경우도 있다. 한 팀원이 조금은 이상한 피처를 좋아해서, 코드 기반에 이를 포함하기 시작했다고 가정하자. 나머지 사람들도 이를 배워야만 할 것이다. 모든 사람이 이런 식으로 일을 하면, 모두가 보조를 맞추는 데 많은 시간을 낭비하게 될 것이다.

구글이 고(Go)를 구현하면서 ‘로우 로드(경제적이고 단순한)’ 방식을 선택한 이유가 여기에 있다. 개발자는 언어에 포함된 구성 요소가 소수여야 하며, 가능한 짧은 시간에 학습할 수 있을 만큼 단순해야 한다고 강조했다. 이런 단순성은 모든 사람을 도왔다. 모든 사람이 핵심을 정확히 이해했기 때문이다.

많은 CS 교수들은 프로그래머가 아닌 수학자다
많은 컴퓨터 과학 전공 학부에 해당하는 ‘어두운 비밀’이 하나 있다. 많은 교수가 컴퓨터를 프로그래밍하지 못한다는 것이다. 교수가 하는 일은 강의와 그랜트(연구 보조금)를 놓고 벌이는 경쟁이다. 스프레드시트와 그랜트 제안서에 대해서는 잘 안다. 그러나 실제 제대로 연구를 수행하지 않는다. 신이 교수들에게 ‘대학원생’을 선물한 이유가 여기에 있다. 마지막으로 컴퓨터 프로그래밍을 실제 해본 시기가 대학원 재학 시절이었던 교수들이 많다. 이후 실력이 녹슬었을 것이고, 컴퓨터에 설치된 컴파일러는 작동조차 되지 않을 수도 있다.

실제 활용되는 경우가 드문 ‘필수 과목’들이 많다
데이터 구조는 컴퓨터과학 전공 학생들이 종종 2학년 때 배우는 주요 과목이다. 유감스럽게도 우리는 이제 데이터 구조를 많이 사용하지 않는다. 이제 우리를 위해 사고하는 데이터베이스에 집어넣거나, 객체 해시 테이블에 집어넣는다. 아직도 알고리즘 측면의 복잡성에 대해 생각해야 하는 사람들에게는 꽤 유용하다. 그러나 B-트리, 심지어 연결된 리스트에 대해 걱정해야 하는 사람들은 정말 극소수다. 그뿐만 아니라, 많은 사람이 데이터 구조를 직접 다루기보다 표준 라이브러리를 믿는 것이 더 낫다는 사실을 깨달았다. 쉽게 실수를 저지르기 때문이다. 많은 기업과 기관이 독자 개발한 데이터 구조 배포를 금지하고 있는데, 여기에는 그럴만한 이유가 있다.

이 밖에도, 더는 중요하지 않게 되어버린 ‘과목’들이 구식 커리큘럼에 많이 남아 있다. 컴파일러는 복잡하고 필수적이다. 그렇지만 실제 컴파일러를 작성하는 사람들은 학생들뿐이다. 한 학기 과정에서 강제로 ‘장난감 같은 버전’을 만든다. 심지어 애플조차 스위프트(Swift)용 컴파일러를 구현할 때 기본 오픈소스 도구들을 사용했다.

수학 모델이 잘못된 길로 인도할 수 있다
데이터베이스 이론을 배운 사람이라면 정교한 데이터 구조를 작은 테이블로 분해하는 방법인 보이스 코드 노멀 폼(Boyce–Codd Normal Form)의 ‘영리함’을 발견했을 것이다. 아주 명쾌하고 효율적이다. 그러나 문제가 있다. JOIN 명령으로 채워지는 SQL 쿼리에 대한 응답 시간이 정말 길다.

대부분의 개발팀은 데이터베이스를 ‘비정규화’해서 성능을 높이는 방법을 터득한다. 다시 말해, 모든 ‘영리함’을 없애버리고 데이터를 하나의 큰 테이블에 집어넣는다. 지저분하고 낭비적이지만, 놀랍도록 빠를 때가 많다. 그리고 디스크 공간이 저렴하다.

교육받은 내용을 실무에 적용하기 시작한 후, CS 과정에서 배운 수학적 ‘영리함’을 없애는 데 몇 년을 소비하게 되는 개발자들이 많다.

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X