병렬처리의 한계와 가능성 – Minsky의 모순성

P개의 프로세서들을 사용한 병렬컴퓨터에서 프로세서들 간의 정보 교환에 따른 통신 오버헤드 때문에 시스템 성능은 P배가 아닌 log2P배까지밖에 개선되지 못한다는 주장이다.

이런 주장은 1960년대에 적은 수의 프로세서들로 구성된 병렬처리시스템들을 이용하여 연구한 결과에 근거한 것이었다. 그러한 시스템들은 근대적인 운영체제를 사용하였는데, 프로세서의 수가 조금만 증가하여도 그에 따른 오버헤드가 매우 높아졌다. 통신 오버헤드가 커지면 프로세서의 이용률이 떨어지고 그것이 성능 저하의 주요 요인이 되었다.

그러나, 이후에 프로세서의 이용률을 높일 수 있는 여러 가지 방법들이 개발되었다. 우선, 더 효율적인 병렬 알고리즘들과 상호연결망들이 개발되었다. 또한 어떤 한 프로그램이 시스템 내의 모든 프로세서들을 이용하지 않는 경우에는, 남아있는 프로세서들이 다른 프로그램들을 처리하도록 해주는 스케쥴링 기술도 개발되었다. 이러한 기술들은 Minsky가 고려하지 못한 것들이었다.

물론, 통신 오버헤드 때문에 P개의 프로세서들을 가진 시스템의 성능이 단일프로세서 시스템 성능의 P배는 되지 못한다. 그러나 최근에 개발되고 있는 시스템들의 성능이 Minsky가 예측한 것보다는 훨씬 더 높아진 것에 대해서는 사실이다. 그로 인해 이 비관적인 예측 또한 어느 정도 빗나가게 되었다.

병렬처리의 한계와 가능성 – Grosch의 법칙과 VLSI

다단일 프로세서의 계산 속도는 물리적인 특성에 의하여 한계점을 가지고 있다. 실리콘 칩 상에 전자 프름의 최대 속도는 및의 속도의 1/10 정도(3*10^7m/sec)이다. 따러서 지름이 3cm인 칩에서 전기 신호의 최대 전송시간은 10^-9sec가 된다. 한 번의 신호 전송에 의해 한 번의 부동소수점 연산이 가능하다고 가정하더라도 그러한 칩으로 만들어진 컴퓨터의 계산 능력은 10^9FLOPS = 1GFLOPS가 된다,. 즉, 초당 10억번의 부동소수점 연산 처리까지만 가능하다. 다만, 최근에는 프로세서 칩 내부에 여러 개의 명령어 실행 유니트들을 두는 슈퍼스칼라 기술을 이용함으로써 프로세서의 처리 속도를 좀 더 높여뒀지만(이미 적용되어 나오는 프로세서들이 대부분임), 명령어-수준 병렬성에 의해 한계를 가진다. 

이러한 물리적인 한계를 극복할 수 있는 기술이 병렬처리이다. 병렬처리 개념이 문헌에 처음 소개된 것은 1920년대였으나, 상당 기간 동안 구체적인 연구와 개발이 이루어지지는 못한 데는 몇 가지 비관적인 예측들이 있었기 때문이다. 이것들을 하나 하나 살펴볼 것이다.

우선 살펴볼 것은 프로세서의 성능이 가격의 제곱에 비례하여 높아질 것으로 예측한 Grosch의 법칙이다. (p.s. 이 이론 자체가 엄청난 고전이지만, 병렬컴퓨터 구조론에 있어서 한번 지나가야 하는 법칙이다.) 이 법칙은 n개의 프로세서들을 사용하면 최대 n배의 성능 향상을 얻을 수 있지만, 루트n배의 비용만 투자해도 n배 더 빠른 프로세서를 개발할 수 있을 것이므로 단일 프로세서의 시스템으로도 같은 수준(n배)의 성능을 얻을 수 있다는 주장이다. 만약 이 법칙이 사실이라면, 굳이 많은 비용을 들여서 다수의 프로세서들을 이용한 병렬처리 시스템을 구성하는 의미가 없어지는 것이다. 그래서 당시의 이러한 논리 때문에, 오래동안 병렬처리 기술은 비용보다도 신뢰도를 더 중요시하는 군사용 또는 항공우주용 컴퓨터에서만 사용되어 왔는데, 병렬처리 구조가 결함 허용을 위한 하드웨어 중복성을 구현하기가 용이하기 때문이었다. (망가져도 다른 코어 쓰면 되니깐)

그러나, VLSI 칩들이 등장하면서 상황이 완전히 바뀌게 되었다. VLSI 기술을 이용하여 개발한 프로세서들은 대량 생산이 가능하기 때문에 가격이 저렴해지고, 따라서 약간의 비용만 추가하면 많은 수의 프로세서들을 포함하는 시스템을 구성할 수 있게 된 것이다. 결과적으로 Grosch의 법칙은 VLSI 기술의 출현과 함께 더 이상 성립되지 않게 된 것이다.

최근에는 가격보다는 처리 속도를 더 중요시하는 경향이 있기 때문에 많은 비용을 투자하면서 더 빠른 프로세서를 개발하고, 그러한 프로세서들을 많이 사용하여 더 높은 성능의 시스템을 개발하고 있다.

병렬 프로그래밍과 시스템 의존성

병렬 프로그래밍을 하면서 대부분 일단 배우는 것이 쓰레드를 잘 이용하는 방법부터 시작하여 하나하나 공부해 나갑니다. 저도 그런 수업을 들어왔고요. 그러다 여러 병렬 프로그래밍 환경을 살펴보면 은근 의존성을 겪게 됩니다.

실제로 프로그래밍을 병렬화 작업을 진행하려면 해당 라이브러리를 이용하여 작성하는 경우가 많은데, 이 라이브러리들이 시스템 의존적인 라이브러리가 있고 그렇지 않은 라이브러리가 있습니다. 대표적으로 엔비디아틔 쿠다(CUDA)와 같이 프로세서 제조사에서 지원하는 라이브러리를 이용해야 하는 경우도 있고, 라이브러리에서 좀 더 자율적으로 처리해주는 OpenCL, MPI와 같은 경우도 있습니다. 또한 인텔처럼 자사의 페러럴 스튜디오를 통한 병렬 프로그래밍을 좀 더 최적화하여 진행하도록 컴파일러도 제공합니다. 언어 레벨에서 지원하는 라이브러리도 늘고 있어서 병렬화 작업이 많이 친숙하게 다가오고 있는 것은 확실합니다.

일단 이런 식으로 살펴는 봤는데, 그럼 이것들의 경우에는 직접 제어하는 프로세서, 시스템에 얼마나 의존적일수록 좋은 것일까라는 생각을 해봅니다만…

가장 단순한 사고를 해본다면, 저수준의 병렬화를 쉽게 구현할 수 있다면 확실히 빠릅니다. 라이브러리 함수 콜(API 함수 사용)을 통해 진행되는 병렬화에 의존하지 말고 직접 pthread를 능숙하게 제어하는 쪽이 퍼포먼스는 확실히 빠르게 나옵니다. 단, 저수준의 병렬화를 진행한다는 것은 정말 어려운 작업입니다.

그러나, 그렇게 하더라도 병렬화 작업을 위한 멀티코어 혹은 매니코어 제조사에서 제공하는 최적화된 API 라이브러리를 이길 수는 없습니다. 엔비디아의 쿠다만 하더라도, 쿠다에 최적화된 코딩 스타일이 존재합니다. (쿠다 프로그램밍을 해보시면 이게 어떤 뜻인지 대충은 아실 겁니다.) 인텔의 경우에도 CPU의 병렬화만 진행하더라도 패러럴 스튜디오에서의 병렬 최적화 튜닝 기법을 이용하면 일반 프로그램에서 쓰레드 제어를 잘 하는 것보다 훨씬 빠른 병렬화가 가능합니다.

이런 식으로 본다면 시스템에 상당히 의존적인 부분이 크게 느껴질 겁니다. 하지만, 응용 프로그램을 개발하는 사람들의 입장에서 보면 자신이 혹은 사용자가 어떤 시스템을 이용할 지 모르는데 시스템 의존적인 병렬 프로그래밍을 할 수는 없습니다. 상각해 보죠. 자신이 프로그램을 개발해야 하는 입장에서라면..? 여러 곳에서 이용하고 싶기 때문에 의존성이 최대한 낮은 쪽을 이용해야 여러 플랫폼, 여러 시스템에 상관 없이 이용할 수 있을 것입니다. (JVM 상에서 멀티쓰레드 제어에 침흘리는 사람들이 이런 입장일 겁니다.)

하지만 실제로 의존성을 무시할 수는 없습니다. 의존성에 의한 퍼포먼스 증가는 무시할 수 없는 수준입니다. 과학 실험을 위한 프로그램들은 대다수가 특정한 HPC를 정해놓고 이용하기 때문에 의존적인 프로그램으로 실험을 하여도 아무 문제가 없습니다. 과거에 제가 개발했던 열역학 시뮴레이터도 그랬고요. 하지만 응용 프로그램을 개발하는 입장에서 병렬 프로그램을 이용해야 한다면 특정한 시스템에 의존성을 가져야 되는지 아닌지에 대해서는 여러모로 고민하게 될 거 같습니다만, OpenCL이나 MPI를 보다보면 어느 정도의 해답은 있을 것 같습니다.

.ipDISK 파일 생성 안되도록 하는 방법

간단합니다. 폴더에 해당 서비스 지정을 해제하면 됩니다.

이 회사는 인터페이스는 죄다 똑같다는 건 좋네요. 저기 보시면 FTP(ipDISK)에 체크를 해제해 주시면 됩니다. 그리고 당연히 ipDISK 서비스가 동작하고 있다면 꺼주시고요. FTP는 안껐는데 FTP 서비스에는 영향은 없나 봅니다. ㅡㅅㅡ

이미 이렇게 폴더마다 다 생긴 건 어쩔 수 없네요. 그래도 혹시 몰라 궁금한지라, 노기자카 공사중 폴더를 만들어봤습니다. 그리고 파일도 좀 복사해서 넣어봅니다.

복사 다했는데 안생기네요. 서비스만 끄면 인덱싱을 안하나 봅니다.

그래도 아래처럼 파일 안지워지는 건 여전합니다. 시스템 끄고 재시작까지 했는데도 불구하고 저렇게 물고 늘어진 건 파일 자체의 권한 문제죠. ㅡㅅㅡ 저것 덕에 디렉토리 단위로 처리하는 건 포기중…

암걸리겠다 진짜…

p.s. 돈 아끼려고 싼 거 쓴 걸 후회하자.

p.s.2. 시놀로지나 다른 NAS에도 저런 건 있다고 할까봐 한소리 더 하면, 저런 썸네일 만들어도 그걸 저렇게 root가 물고 있으면 안되죠. 폴더 단위로는 만드는 거 외엔 하지 말라 이건가요?

.ipDISK 라는 ㅆㄹㄱ파일

제목 그대로 쓰레기입니다. iptime NAS 제품에 모바일 서비스를 위해 이미지 썸네일을 위해 만든 DB 파일인데 이것 덕분에 참 뭣같은 상황이 벌어져서 여러모로 찾아보고 있습니다만, 결론은 쓰레기입니다.

 이 파일은 “모든 폴더” 안에 생성됩니다. OS X 쓰는 사람들 보면 .DS_Store라고 되어 있는 파일 기억나시나요? 이게 폴더 내부의 인덱스 파일인데, 탐색기에서 파일 읽고 쓰는 걸 좀이나마 빨리 처리하려고 만든 관리 파일입니다.

.DS_Store 파일 까보면 어느정도의 정보가 저장되어 있습니다. 윈도우에서 까서 인코딩은 깨졌지만, 파인더에서 보여지는 설정 등에 대해서 적혀있고 합니다.

그러면 저 .ipDISK 파일은..? 권한 땜에 안열리는 거 같지만, 열립니다. 본인의 로그인 계정이 admin이라면 열립니다.

이것도 인코딩 문제며 뭐며 있겠지만, 앞에 나와줬네요. sqlite 디비파일입니다. 즉, 모든 폴더마다 sqlite 디비 파일을 만들어서 썸네일을 처리하는 겁니다. 게다가 권한이 시스템 권한입니다. 안드로이드 쓰는 사람이 많아져서 이젠 뭐라해도 다 이해를 할 수 있다는 전재로 이야기하겠습니다. 저 파일은 루트 권한으로 만들어진 파일이고, 루트 권한으로만 쓰기가 가능합니다. 그리고 이런 파일을 모든 폴더마다 다 만들었습니다.

그래서 이 파일 덕분에 iptime NAS에서 맥 또는 리눅스에서 폴더를 복사하면 폴더가 다 복사가 안됩니다. 권한을 가지고 있지 않은 파일을 복사하려 하기 때문에 오류를 내죠. 

……이게 대체 왜 그런가 진심으로 궁금했는데, ipDISK라는 앱을 지원하기 위해 FTP와 연동을 했고, 전 이 NAS에 이전부터 FTP를 썼다는 이유만으로 저 파일의 생성을 강요당했군요.

그래서 백업용으로 쓰던 FTP 내렸습니다. 다른 방법으로 백업할 수 있도록 하려고 하는데, 제일 좋은 방법은 NAS를 시놀로지로 갈아탄 담에 시놀로지 시스템에 맞춰서 바꿔 개발하는 게 제일인 거 같군요. 손 좀 덜타려고 산 NAS인데 업뎃 한번 했다고 이 꼴 나는 건 대체….

p.s. 돈없이 살면서 백업용으로 뭐 해보겠다고 한 것이 잘못이겠죠.

우분투의 Repository 서버를 만드는 방법 – 03

이전에 백업을 받는 장면까지는 제가 보여드렸습니다. 미러를 전부 백업받고 나서 아파치에서 http 프로토콜로 받기 위해 사이트 링크를 만들어 줘야 합니다. 아파치의 기본 디렉토리로 이동하겠습니다. 그 다음에 ln 명령어를 이용해 링크 파일을 생성해 줍니다. 지금 다운로드를 받은 위치는 기본 위치인 /var/spool/apt-mirror/mirror/archive.ubuntu.com/ubuntu에 있기 때문에 해당 디렉토리를 링크하여 연결해줍니다.

연결을 했으면 이제 브라우저에서 확인해 줍니다.

제대로 되었는지 확인해보겠습니다. 우선 패키지를 확인해 보고 싶어서 패키지 폴더를 탐색해 봤습니다. 그리고 gcc를 발견했습니다.

amd64 버전의 gcc가 버전별로 복제되어 있습니다.

그리고 나서 dists를 확인하고 싶어서 dists 폴더도 뒤져봤습니다.

trusty(14.04)에 대해서도 제대로 있습니다. amd64 버전으로요.

미러 서버는 이런 식으로 만들 수 있는 것을 확인했습니다. 이 서버를 이용하고자 하면 직접 /etc/apt/sources.list 파일을 수정하거나, 제어판에 있는 “소프트웨어 & 업데이트”에 있는 주소를 변경해 주면 되겠습니다. 그러면 알아서 읽어올 것입니다.

14.04 amd64만 받아오는 것은 지금 쓰는 서버의 시스템이 해당 시스템이어서 그랬습니다만, 만약 모든 버전에 대해서 모든 아키텍쳐를 전부 다 미러를 뜨겠다고 하면 미러 사이트에 있는 미러 주소를 추가해서 미러를 받아오면 되겠습니다. 대신, 용량은 엄청 먹긴 하니 각오는 해야 합니다. 캐시 기능만 필요하다면 캐시 서버를 직접 만들어 봐야 하는데 그건 다음에 기회되면 더 해보는 걸로..ㅇㅅㅇ

우분투의 Repository 서버를 만드는 방법 – 02

“일단 미러다, 미러를 만들어보자!”

저 구석에 설치만 해두고는 아무도 안쓰는 머신 하나를 발견했다. (하나는 내가 가끔 다른 플젝 한답시고 건드려서 조금씩 쓰는데 다른 한대는 아예 손도 안대고 있는 게 있어서..(사실 손 댈 생각도 안하고 있는 거 같다만.. 디스하기 시작하면 끝도 없겠다. 그냥 말자.))

그럼 여기서 내가 미러를 위해 뭘 설치하고 수정해야 하는지 확인해야 겠다.

우선 apt-mirror를 위해 필요한 패키지와 권장사양을 찾아봤다.

  • apt-mirror paackage(sudo aptitude install apt-mirror)
  • apache2 package(sudo aptitude install apache2)
  • roughly 15G of storage per release, per architecture

….스토리지는 넉넉하게 준비해 두세요. ㅇㅅㅇ; (역시 미러서버)

일단 저 둘의 패키지를 설치했다면 설정을 해줘야 합니다. /etc/apt/mirror.list 파일에 기본적인 설정과 설치된 패키지들이 어디에 위치할 지 등등의 정보를 설정하게 됩니다.

설정 파일을 까 보면 기본 경로와 미러 경로, 그리고 별도의 스크립트 작업들이 전부입니다. 그 외에는 어느 미러에서 복제해 올 것인지를 설정하는 곳인데, 이 부분은 /etc/apt/source.list에 있는 사이트 경로와 비슷합니다. 저 밑에 경로가 버전마다 다 적혀 있으면 버전마다 있는 대형 서버가 되는 것이겠군요. 근데 용량을 생각하면…/먼산

설정 안하고 그대로 실행해 보겠습니다.

apt-mirror

14.04만 하는데도 144.8GiB…..

이런 건 스토리지에 여유가 넘쳐나시는 분들이 아니라면 그냥 public repository 쓰세요..ㅇㅅㅇ;;

아, 참고로 저 [20], [19] 저것들 쓰레드 개수입니다. 용량이 용량이다보니 병렬로 받는군요. ㅇㅂㅇ;;

다 받아지면 apt-mirror를 통해 받은 패키지들을 다른 클라이언트들이 접속해서 쓸 수 있게 할 수 있는 방법에 대해서 보여드리겠습니다. ㅇㅅㅇ/

perl: warning: Please check that your locale settings:

우분투 사용 도중에 나오는 오류입니다. 로케일 셋팅이 잘못되어 있어서 나오는 오류더군요. ㅇㅅㅇ

해결책은 의외로 간단하더군요. 로케일을 셋팅해 주면 됩니다.

sudo locale-gen [로케일] [로케일] …

로케일은 물론 여럿 설정 가능합니다.

우분투의 Repository 서버를 만드는 방법 – 01

“왜 이짓을 하려 하냐…”

첨에 들었을 때 했던 소리다. 타음카카오나 네오위즈나 서버 빠른 데 갖다 쓰면 되잖아? 라고 나도 모르게 자동으로 반사적으로 말했다. 근데 떠들고 보니… 나도 궁금해졌다. ㅇㅅㅇ!

그러고 보니 어차피 귀찮으면 네트워크 설치를 해야 될 수도 있는데.. 그럴 꺼면 아예 내부에 미러 서버 있다고 해서 나쁠 껀 없잖아? 어차피 뭐 다른 곳에 있는 공개용 ftp와는 달리 매번 쓰는 것도 아니고..!

그래서 지금 시스템 백업하고 새로 설치해야 하는 시간도 있다 보니 검색 ㄱㄱㄱ!

방법이 두 가지가 존재한다. 그래서…. 다 실험해보려 한다! (이 글을 쓸 때는 지금 연구실 주분투 망가져서 백업중인 상황임을 알려드립니다. ㅇㅅㅇ!)

  • APT-MIRROR

이름 그대로 미러 서버를 만드는 것이다. (ㅇㅅㅇ!)

perl 기반의 유틸리티를 통해서 public repository의 모든 컨텐트를 다운로드와 미러링을 한다고 한다. 모든 걸 죄다 미러링 하게 되면 내가 필요로 하지 않는 것까지 전부 다 가지고 온다는 것이기도 하니 용량은 엄청 먹을 거 같긴 하다. 하지만 public repository의 모든 패키지를 다 갖고 있다는 것을 좋아하는 사람도 있을 것이다. (…)

  • APT-CACHE

이름 그대로 캐시 서버이다.

미러 서버의 모든 컨텐츠를 다 가져오는 apt-mirror와는 다르다. 그러나, 해당 네트워크에 접속한 클라이언트가 요구한 패키지에 대해서는 public repository에서 받아와서 저장하고 제공해주는 역할을 한다. 다시 말하면, public repository에서 중간에 받아와서 처리해주는 역할이다. 이 캐시 서버에 없는 컨텐츠에 대해서는 받아와야 할 시간이 필요하지만, 이미 있는 컨텐츠에 대해서는 캐시 서버에서 제공받으면 된다.서버의 용량을 아낄 수 있는 점에 있어서는 이쪽이 더 좋아보일지도 모르겠다. 동일한 설치를 하는 컴퓨터들이 다수 있다면 더더욱 서버의 용량은 아껴지겠지. 한곳에서 설치 작업하기 위해 받아놓은 데이터를 통해 다른 곳도 계속 쓸 테니깐.

그럼 한번 구현 해볼까. ㅇㅅㅇ;;

입기획자 발언에 많은 사람들이 상처입는군요.

페이스북에서 정말 논란이 많은 넛츠컴퍼니 내용입니다. 바로 입기획자에 대해서 말하고 있네요.

제가 뭐 그리 뛰어난 사람도 아닙니다. 단지 연구실에서 짱박혀서 가끔 칸코레 하다가 리눅스 커널에서 좀 필요한 부분 뜯어고치다가 뭔가 알 수 없는 수학을 좀 코딩하다가 집에서 잠자는 존재일 뿐이죠. 근데, 이 내용 땜에 제가 알던 수많은 사람들이 죄다 병신 취급 받는 거 같아서 저도 글 좀 써보려고요.

저기서 떠드는 에반젤리스트랑 입기획자를 동격으로 치는 수준이..“내가 해봐서 아는데”로 착각하는 거 아닌가 싶습니다. 아님 직업적으로도 여러모로 밖에서 활동하는 사람들도 걍 싸잡아서 “떠드는 사람”으로 취급하는 거 같은데… 의도를 모르겠군요.
 
그러면서 반박 예시로 든 것이 대기업 앱을 예시로 들었는데, 애당초 특정 시장에 소규모 기업이랑 대기업이 거의 비슷한 시기에 앱을 낼 정도면 애당초 어디서도 비슷한 거 내놓고 기획의 안정화 역시 다 되었다는 건데 그걸 갖고 실적이 있니 없니 그래봤자…. 중소기업, 스타트업들 자금력 딸리는 걸 대기업이 네임 벨류랑 마케팅 쓰는 걸로 기본 다운로드 숫자만 좀 더 상회하면 그전에 만든 사람은 뭐 진거라도 된다는 듯히 합리화 하는 저 예시가 참… 그럼 작은 곳은 다 대기업이 기획할 만하긴 한데 아직 개발 안한 건 기획하고 개발하면 안되는 거네요? 대기업이 자본으로 밀고 베끼면 그냥 끝인데? 기획 왜해요? 개발 왜 해요? 네?
 
이 게시물은 공유가 많이 되고 해서 계속 보다보니…. 팀장이 말하고자 하는 요점이 있다는 걸 알았습니다. 팀장님의 마인드가 바로 “기획자 == 이사 == 사업하는 사람” 입니다. 이사급 인재를 스카웃 하려고 하는 조건만 생각해서라면 저 팀장의 행동을 약간이나마(?) 변호할 수 있겠네요. 그렇기 때문에 누굴 뽑아야 되냐는 조건의 내용이 거의 “사장과 동일한 수준의 스트레스를 공유하면서 살아야 하는 사람”으로 묘사가 되어있는 겁니다. 
 
“기본적으로 시장이 원하는 게 무엇인지 알고
글로벌 서비스 트렌드를 정확히 꿰고 있는 사람”
“하나의 가설을 증명하기 위해
무수히 많은 땀을 흘릴 수 있는 사람”
 
이런 건 그냥 안정성을 원하는 한국의 엔젤로나 투자자들 마인드입니다. 이미 수익에 대한 검증이 되어 있기 때문에 안정적인 컨텐츠나 요소가 있어야지만 투자를 하고, 그에 대해서 빨리 어느정도의 돈을 뽑아내려는 겁니다. 이런 기획 마인드 가진 사람들… 모험 안합니다. (뭐에 투자하고 하는 사람들 마인드 보시면 어떤 이야기인지 감 올겁니다. 저도 돈 불릴 땐 모험 안합니다.)
 
“프론트 페이지(서비스 화면)에 노출된
버그 하나에 안절부절 못하는 사람”
“이용자가 불편할 것을 생각하면
잠을 이룰 수 없는 사람”
두 말 할 필요 없죠? 사장님들 대표적인 마인드입니다. 개발자가, 디자이너가 다 열심히 해도 회사에서 QA 제대로 안지원해주고 하면 날 수 있는 당연한 버그도 있을 수 있고, 이용자의 불편함 또한 QA에 대한 마인드나 그와 비슷한 것에 대한 마인드가 그대로 나타나겠죠. (근데 QA 아낀다는 사장님들 이야기는 많이 못들어봤네요. 사장님이 직접 QA 하는데 QA 실력 좋은 건 많이 들어보고 겪어봤지만) 여튼 이건 개발만의 문제도, 기획만의 문제도 아닙니다. 요구 하면 안되죠. 요구하는 시점에서부터 이미 이것저것 죄다 주고있을 수준의 고수준이라면 모를까…
“수단방법 가리지 않고
일단 서비스를 띄우겠다는 사람”
해보세요. ㅡㅅㅡ

“때로는 어르고 달래고
때로는 드잡이를 불사하며
개발자, 디자이너를 컨트롤하는 사람”

경영진으로 들어오니깐 당연히 이런 건 있어야겠죠. 근데 그전의 요구사항을 봐선 제대로 된 마인드로 이걸 컨트롤 할 꺼라고는 생각하지 않습니다.

“이미 여러 차례 성공경험을 통해
어느 시점에 스케일업(규모확장)하고
어떻게 머니타이징(수익화)하는지
명확히 아는 사람”

기획자로써는 당연한 결과입니다만, 기획자들이 처음 기획자가 되었을때부터 이런 걸 다 알고 들어오진 않죠? 당연히 선배들한태 배웁니다. 동업자한테 배웁니다. 이런 노하우 또한 귀중한 경험입니다. 근데 그럼 그 선배나 동업자도 저 팀장 입장에서는 입기획자군요. 만약 이런 걸 전부 경험으로 알았다면 투자비 날려먹는 기획이었어도 사장이나 이사진들이 뭐 “용서하마. 다음엔 덜 날려라.” 라면서 죄다 면책해주고 그럴까요? 경험 있는 사람들이 죄다 좋은 경험만 가지고 나올 순 없잖아요. 그래도 그나마 좀 더 나을 걸 할 수 있느냐 마냐의 것 뿐이지…

“의사결정권을 확보하기 위해
자신의 커리어를 걸고 베팅할 줄 아는 사람”

 

해보세요. 이런 거 함부로 막 했다간 제대로 나가리 나거나 제대로 묵살되어서 원래 나오던 것만 나오는 게 한국 기업들이라고 배웠습니다. 이런 거 제일 엿먹인 케이스가 바로 귀뚜라미 그룹이죠. (모르면 검색해보세요. 귀뚜라미 회장은 내세울 게 기술에 대한 자기 생각밖에 없는 사람이라 학력이나 그런 걸로 부장달고 올라온 사람들 기획 어정쩡하게 내놓고 하면 대놓고 엿먹이는 거 보면 참 대단한 분이라고 생각합니다.) 그리고 자신의 커리어를 걸고 배팅하려는 것 또한 커리어의 명성이 있어야 하는데, 그건 어디서 자신이 기획하고 개발하고 한 내용들 외부에 발표 안하고 있으면 알아서 명성이 쌓입니까? 어디 무슨 일랜시아 접속시간 길어지면 명성 주고 하는 그런 시스템도 아니고… 앉아서 가만히 있다가 뭐 좀 제대로 수정했는데 나만 알고 나만 쓰는 거에 무슨놈의 명성…

정말 막 바빠지고 그러면 어디서 술마실 시간도 없고, 사람 만날 시간도 없고 그러겠죠. 근데 그런 게 꼭 당연하다 싶어서 그냥 짱박혀서 자기한테 틀어박혀 있는 걸 당연하게 보는 것도 그렇고, 말로 하는 사람들이라고 해서 죄다 싸잡아 무시하고 하는 그런 거… 진짜 보기 안좋습니다. 게시글에 있던 덧글들도 다 지우고 있는 거 같던데… 대단하네요.