[월:] 2017년 06월

개소리 오브 개소리 – CS Fundamental, 자료구조, 알고리즘 깊이 몰라도 된다는 개소리에서 적은 글이랑 성격은 비슷하지만, 좀 다른 이야기를 하고 싶다. 페이스북에다가도 똑같이 적었는데, 트위터로 날 접하는 사람들한테도 좀 들려주고 싶다.

알고리즘… 이게 언제부터 막 그렇게 거창한 거였나 싶었다.

그냥 단순 서비스 개발을 하면서도, 기술서에 나와있는 내용이나 기술 협의를 하면서 나온 내용에 대해서도 우리가 어떤 식으로 구현할 수 있을까를 머릿속에서 짜내는 것 또한 알고리즘이다. 그걸 수학적으로 풀어 써야지만 알고리즘이라고 한다면 프로그래머는 죄다 수학자여야만 하는 건가?

알고리즘을 공부하면서 생각의 폭이 넓어지는 것이지, 굳이 “정답은 하나입니다!”와 같이 정답만 찾아 헤메는 수능 공부를 하는 게 아니란 말이다. 별 것 아닌 생각으로도 상책을 내어 해결할 수 있다면, 굳이 복잡한 알고리즘 갖다 붙일 이유 또한 없는 거 현업에서 개발해본 사람이라면 누구나 다 안다. 오히려 조직 플레이를 잘 하라, 협업을 위한 기술들을 더 잘하자고 하면 더 하지. 근데, 뭔 문제 생겼을 때 해결하려는 수단 중 별 거 아닌 듯한 생각, 의외의 생각들이 있다. 그런 조금이나마 더 유연한 생각, 더 해볼려고 하는 노력에서 유연한 사고에서 나오는 거라는 것 정도는 이미 알고 있는 거 아닌가? 그거 땜에 조금이나마 더 오픈소스들을 보고 참고하고, 어느 정도의 구조적인 알고리즘까지 조금이나마 더 이해하려는 거 아닌가? 왜 그런 것 까지 싸잡아 무시하는 거지?

대학에서 알고리즘 수업을 수학적 증명이니 뭐 그딴 식으로 가르치는 건, 그냥 그 교수들이 그렇게 가르치는 것 뿐이다. (근데 그걸 맹신하는 일부 교수들이 있어서 문제.) 어차피 맨 첫 시간에 잠깐 이야기 한다. 아니면 알고리즘들 책 앞쪽 부분에도 똑같은 이야기들이 있다. “알고리즘은 문제 푸는 해결력을 높이는 데 필요합니다.”라고 적힌 책들 많다. 심지어 Art of computer programming에서도 나와있는 거지만 “프로그래밍 접근법에 대한 참고 내용입니다.”, “수학적 증명이 어려우면 그냥 넘기셔도 됩니다.”라고 나와있다. 단순히 생각 넓히기일 뿐이다.

근데 그걸 프로그래밍에 대한 일종의 종교적 믿음? 거기에 대한 불편함? 하. 그런 믿음, 그런 불편함. 인공지능 기술 이전에 이미 미친듯이 진행된 프로그래밍 자동화 기술들 갖다 들이밀면 단 한방에 무너질 믿음이다. “그럼 당신보다 이 자동화 기술이 더 발전하는 게 효율적이겠네요?”라고 하면 뭐라고 할 껀가? 그 툴 잘 쓰면 된다고 반박할껀가? 그런 레벨이면 이미 몸으로는 CRUD하고 있는 본인 스스로를 부정하고 있는 거나 마찬가지인 거다. 아니면 이야기가 너무 진행되었다는 식으로 회피하겠지.그런 불편함 또한 갖다 버릴 고정관념이다.

사실 알고리즘에 대한 경고는 일종의 미래에 대한 경고다. 생각이 굳어지는 그런 개발자들이 되지 말자는 거지 그게 뭐 “당신은 Art of computer programming에 나오는 문제 하나도 풀지 못하는 사람이니 개발 할 가치가 없습니다.” 라고 하는 그런 게 아니다. 그런 고차원적 수학을 요구하는 건 아니지만, 그렇다고 해서 그게 뭐 아예 수학을 못해도 된다고 직결되고 하는 그런 건 아니다.예상 외의 것일지도 모르지만, 이미 우리는 프로그래밍 언어를 공부할 때부터 필요에 의한 최소한의 수학적 사고를 같이 익히면서 시작한다. 그게 몇 년 단위로 계속 프로그래밍 언어 몇 가지를 써보고 하면서 본인 스스로가 모를 뿐이지. 그리고 그 정도의 사고도 못하면 다른 사람과의 협력 따윈 기대할 수도 없다.

알고리즘에 대해서 너무 극단적으로 몰고 가지 말자.

스크립트 언어 뿐만 아니라 요즘 언어들의 공통적인 것이 있다면, 바로바로 결과 떠서 보여줄 수 있는 환경이라는 것이다. 언어를 배울 때 내가 쓴 코드가 바로바로 결과가 어떤 것인지를 보여줄 수 있으면서 하게 되면 재미를 더 붙이기 쉽게 된다. 게다가 디버깅이라는 개념 자체가 상당히 쉬워져서 금방금방 한다. 그게 당장 필요한 언어를 써보려고 할 때, 시간을 줄일 수 있는 장점이이 있다.

파이썬의 경우에는 파이썬 쉘 안에서 동작하다 보면 금방 금방 결과가 나오는데, 이런 방식이 신기한 방식은 아니다. 매스매티카나 매틀랩 같은 수식 연산에 최적화된, 흔히 사이언티픽 프로그래밍을 하다보면 그런 경우의 환경들이 상당히 많이 나와있다. 일반적인 프로그래머들의 환경에서는 그렇게 잘 쓰이는 환경이 아니어서 신기할 뿐인 것이다.

그러다 보니 교육용 언어에서는 이렇게 바로바로 보여줄 수 있는 기능들이 기본적으로 딸려오는 편이다. 스크래치도 본인이 구성한 코드가 거의 바로 실행될 수 있는 수준으로까지 되어있다. 그걸 통해 애들이 직접 코드를 구성하고 나서 바로 클레이 버튼으로 해당되는 부분만 줄줄 실행되거나 전체 실행을 시켜서 바로바로 볼 수 있게 되어있다. 다른 교육용 언어도 마찬가지고…

일반적인 개발에서 쓰일 정도면 그 코드를 연습할 수 있는 연습 공간을 제공하게 되는데, 애플의 스위프트의 경우, playground라는 코드 라인이 하나 하나 실행되어 볼 수 있는 환경이 존재한다. Xcode 안에도 존재하고, 아이패드 앱으로도 존재한다. 이걸 통해 스위프트를 배우는 튜토리얼까지 존재할 정도니, 이미 말은 다 했다고 본다. 이를 통해 스위프트 언어를 배우는 시간을 엄청 짧게 해주면서 동시에 코드 테스트용으로도 잘 써먹는 사람들이 있다.

내가 여기서 주목하는 것은 바로 교육적인 것이다.

아이패드의 Swift Playground에 있는 튜토리얼이다. 원하는 코드를 입력하면 이 코드가 실행되는 특정 게임을 만들었다. 요즘 이런 교육 프로그래밍이 엄청 많은데, 이런 교육을 진행하게 되면, 프로그래밍 배우는 데 필요한 최소한의 기술에 대해서 직접 입력하면서 배우기 때문에 정말 빠른 시간 안에 배운다.

근데, 이 방법이 참신하냐?

오래전부터 말 많이 했던 것들이다. 예제 좀 많이 해봐라. 코드 1만줄 넘게 해보면 금방 는다. 이런 이야기들이랑 별 차이 있나 싶을 정도로 똑같은 상황을 그대로 하고 있을 뿐이다. 근데 이게 사람들이 책 보고 하나하나 하다가 뭐가 문제인지 모르는 것이랑 더 쉽게 배울 수 있는 환경이랑의 차이일 뿐…

난 오히려 이런 거 보면 더더욱 확신이 든다. 절대 프로그래밍 언어는 길게 공부하면 안된다. 언어에서 지원하는 특수한 기술이나 프로그래밍 패러다임은 좀 공부해 둬야 하지만, 언어 자체에 대해서는 오래 걸릴 필요가 없는 것이다.

뭐, 그냥 잡소리다…ㅡㅅㅡ

요즘은 클라우드 환경에서 자신들의 서비스를 띄우는 곳들이 상당히 많다. 이들이 주로 띄우는 방식으로는 가상화를 통해 가상 머신을 띄우는 방식과 경량 컨테이너(일명 도커)를 띄우는 방식이 있다. 각각의 서로의 장단점이 있기 때문에 뭐가 더 좋다 안좋다를 따지고 싶지는 않다. 성능 차이로는 도커쪽이 덜 거치고 들어가는만큼 훨씬 가볍다는 결론이 난 지도 오래고…

가상 머신을 띄우는 곳의 경우라면, 가상머신을 띄워서 필요한 시스템을 그대로 옮겨가고자 할 것이다. 주로 오래된 레거시 서버를 그런 식으로 띄우는 경우가 많은 거 같다.

반면에 신규 개발 환경에서는 요즘은 도커를 이용하는 경우가 정말 많다. 컨테이너 기술 자체가 사실 개발환경 구성도 편한 데다가 어디나 잘 때려박고 돌리기도 편하고..

사실 어느 클라우드나 다 지원한다고 하는데….. 둘 다 지원이 잘 되는 건 애저밖에 못 본 거 같다. 얼마나 잘 지원해주는 클라우드가 나중에는 개발자들한테 사랑받는 클라우드 환경이 될 것이라는 것 하나만은 확실하게 짚고 넘어가고 싶다.

난 사실 OKKY 별로 안좋아한다. 옛날에 개발 공부할 때 대부분의 사람들이 하던 SI식 개발방법론을 많이 배웠던 곳이기도 해서 그런지 별로 좋지 않다. 회원들도 너무 폭이 넓어서 그런지 배울 게 많은 사람도 있는 반면에 배울 게 없는 사람들도 너무 많다.

근데 여기에 아주 폭탄 하나 떨궈놓은 글이 있다.

이런 거 떠들 수 있다는 거 자체는 그다지 좋은 게 아니다. 당사자들이 싸우거나 어이없게 논점 흐려지는 거랑은 전혀 다르게, 이런 걸 받아들일 주니어나 학생들 입장에서는 진짜 개판적인 사고를 심어준다. 결과적으로, 그 커뮤니티가 정체된다. 이런 이야기는 나중에 술마시고 적어야 하니 이쯤으로 하고…

저 글이 대체 뭐가 문제냐면, 고도의 추상화가 되고 있기 때문에 우리는 그것들을 쓰면서 구현을 하고, 그러면서 그에 해당하는 알고리즘을 익히고 한다는 것이다. 즉, [개발 경험이 풍부하다 = 고급 알고리즘을 알 수 있다]라는 개소리 오브 개소리다.

기술이 발전했으니까..? 그러면 그 기술을 발전시키는 사람들은 대체 어떤 곳에서 태어나는 것인지는 깊이 생각 안해보는 건가? 당연히 기본적인 CS 기본 지식들과 자료구조, 알고리즘을 엄청나게 학습한 상태에서 현재의 기술들에 문제점을 파악하고 그것을 발전시킨 사람들이다. 굳이 대학원이 아니어도 기업의 연구소, 국가 연구소, 개발 중 나온 신기술들 또한 그런 구조다. 구글이나 페이스북, MS, 애플은 뭐 그런 거 안하고 그냥 누가 만드는 수준으로만 대충 구현만 해서 기술 만드는 사람들인 줄 아나?

지금 당신들이 쓰는 컴퓨터의 메모리 관리 구조도, 멀티코어 관리 기술들도, 파일 시스템들도, 네트워크 기술도 죄다 기초적인 기술들이 모이고 모인 기술들이다. 그 중에서 그냥 제공되는 프레임워크와 API 쓸 줄 안다고 해서 그 안의 기술을 알 수 있다? 그리고는 게임 개발에 쓰이는 OpenGL이 20년전 유행기술이었지만 지금은 다른 기술들도 많다? 그들 또한 그 아에 있는 기본 기술들을 다른 식으로 응용한 거라는 건 모르겠나?

기술의 발전이라는 걸 무시하는 것이다. 특히나 특정 “계보”에 의해 진화된 기술들에 대해서 개무시하는 것이다. 선택받지 않은 기술은 다 죽은 기술인 것이다. 저들은 과거에 아이폰이 나왔을 때, 개발에 오브젝티브-C가 쓰였을 때에도 해당 언어 까기 바쁜 사람들이었다. 그리고는 C++로 할 수 있는 방법 없냐를 자주 물었다. (실제로 그런 사람들을 위한 책도 나왔었다.) 그러나, 다들 그냥 해당 언어를 빠르게 배워서 먼저 개발 싹 했고, 필요한 프레임워크나 기능들을 오브젝티브-C로 짜내기도 했다. 코드 연동 또한 잘 되는 편이라 기존부터 많이 이용되었던 알고리즘도 그대로 써보니 성능 잘 나와서 크게 바뀔고 할 것도 없던 것도 있고… 이런 응용의 모든 방식을 죄다 부정하는 것이나 마찬가지다.

이런 사람들이 주로 하는 소리는 여럿 있다. 수학 못해도 개발하는 데 지장 없다는 소리, 내가 해봐서 아는데 알고리즘 깊게 알 필요 없다는 소리 등등… 다 개소리 집합체다. 가뜩이나 그런 개소리 하는 사람 양성하는 곳들도 많은 상황에, 그것도 대학까지 거들고 있어서 병신소리 하는 마당에! 그냥 안드로이드 앱 개발, 윈도우 MFC 프로그래밍, 자바 어플리케이션 개발, 웹 개발 등 UI랑 엮인 응용 프로그램 개발자들이 저런 경우에 많이 빠진다. 저들은 그냥 오픈소스로 되어 있는 프레임워크 갖다가 쓰기만 하면 되니깐 별 생각을 안하게 된다. 그러다가 좀 더 접해보다보면 한정된 상황에서 어떻게 더 잘 할 수 있을까 아닐까를 고민할 때쯤에 저렇게 익힌 사람들은 “자원이 모자라요. 좀 더 좋은 하드웨어 쓰세요.” 같은 소리로 돈을 쓰는 개발을 하게 된다.

그럼 이제, 저들이 왜 저런 디자인 패턴, 코드 패턴 등에 저렇게 찬양을 하는 걸까? 실제로 보면 저런 거랑 아무 연도 없는 그런 개발을 하는 게 엄청나게 많은 사람들이?

“코드, 패턴 그리고 소프트웨어”를 읽어본 사람들은 알겠지만, 아니면 요즘 유행하는 클린 코드, 리펙토링, 디자인 패턴 등등에서도 말하는 것이지만, 언어론적인 이야기다. 설계 문제에 대한 이야기, 문제 해결법과 그 배경에 대한 이야기들, 그 해법 과정에서 생기는 협력 관계나 책임, 그리고 그로 인한 결과론… 즉, [프로그래밍 언어론 + 소프트웨어 엔지니어링]의 문제다. SI 개발을 하는 사람들한테는 저게 되게 중요한 문제가 된다. 구현만 잘 되는 입장에서는 그냥 남들이 봐도 문제 없는 코드, 남들도 다 잘 써먹을 수 있는 코드, 코드 제작에 있어서의 책임과 성과가 정확하게 나오는 구조가 좋은 구조이기 때문에 오히려 그쪽을 더 중요시 하는 것이다.

그리고 이런 건들은 일에 대한 내용이지 컴공의 이론과 관련된 내용과는 좀 많이 동떨어져 있다. (얼마나 이론적인 내용과 많이 떨어져 있으면 자신이 컴퓨터공학 대학원 박사과정이거나 석박 통합과정인데 어정쩡한 위치에서 쉽게 박사학위 논문 따고 싶으면 주제를 이쪽으로 하면 쉽게 딴다는 소문도 있다.) 그런고로 주로 관리자 입장에서 있던 사람들은 이런 이론에 빠삭한 사람들을 좋아한다. 이런 것이 이해되는 사람들이라는 것은 “이해가 되니 그대로 구현해라”라고 할 수 있는, 즉 앉아서 바로 일할 수 있는 사람인 것이다. 거기에 구조가 바뀌더라도 그 구조에 맞춰서 그대로 일만 할 수 있다면 그 사람이 일을 하던 다른 사람이 일을 하던 상관없는, 그런 환경에서 죻아한다.

마지막으로, 이런 환경이 아직도 정~~~말 많다. 대한민국의 SI 비율은 70% 이상은 된다고 한다.

그리고 그 정도 수준의 개발자들은 언제든지 만들어질 수 있고, 저연봉으로 일한다.

소수의 성공한 개발자가 되라고 말하는 게 아니다. 자신의 위치와 상황에 대해서 정확하게 알라는 것이다. 연봉 협상도 제대로 못해서 연봉 좀 더 올려달라고 하면 “너같은 수준의 개발자 많아”라면서 개찬밥 취급 당하거나 해고당하지 않는 것만으로도 다행이라고 생각하는 그런 하찮은 수준으로 앞으로를 살 것인가? 그렇게 있다가 신규 개발자들한테 안치이려고 그대로 “알고리즘 자료구조 그런 거 쓸모없어”라고 지껄일 껀가? 그리고 거기에 안주해서 모자란지식 있으면 “개발 못해요” 라고 할 것인가?

그냥 있는 API 갖다가 단순하게 뭐 만다는 건 일도 아닌 시대가 오는데… 아직도 이런 개소리가 나도는 게 참 한심하다. 그리고 거기에 동조하는 덧글들 또한… 그리고 이런 거에 놀아나는 대학들 또한 한심하다.

이미 아는 이야기이고, 아마 취업 상담할 때 여러 곳에서도 많이 하는 이야기지만, 아까 글 적다보니 좀 해야 할 거 같다.

학생들의 경우에는 자꾸 어떤 기준을 만든다. 그 기준이 자격증으로 이어지기도 하고, 경진대회로 이어지기도 하고, 포트폴리오로 이어지기도 한다. 그 중에 제일 잘못 전달되어 가는 것이 있다.

“XXX 개발 경험자.”

뭐, 특정 기술에 대해서 경험자를 찾는다는 소식이 구인 공고에 보면 있다. 아니면 이런 글로도 적어놨다.

“안드로이드 앱 개발 경력 3년 이상”
“nodejs 개발 경험”

이럴 때, 학생들이 대부분이 여기에 맞추려고 “nodejs 써봤어요.” “안드로이드 앱 만들어봤어요.(근데 까보니 수준미달)” 이런 식으로 준비하고는 그냥 학점과 어학점수나 그런 것에 신경을 더 쓰는 걸 많이 봤다. 그리고 이걸 개발자 취업 설명회때도 예시라면서 그대로 이야기하는 곳이 있었다. 게다가 뭐 만들어 본 게 아니라, 스스로들 그냥 스터디 하면서 이런 저런 기능이 있더라로 외우는 친구들도 있는데, 현업에서 있는 사람들 뭐 새로운 기술 익히는 데 들어가는 시간은 아무리 오래 걸려도 2~3주다. (그 이상은 넘어갈래야 넘어 갈 수도 없다.)  학생들 수준으로 주에 1~2번 만나면서 느긋하게 진도 나가는 것 가지고 떠들어봤자란 것이다. 다 뽀록난다.

그리고 그에 대한 배경지식 쌓는다면서 일반인들 대충 이해하도록 만들어진 포스트나 블로그 글 보고는 그걸 쫙 외워서는 “나 이거 기술 알아요.”라고 떠드는 사람도 있는데, 이것도 다 뽀록난다. 원하는 게 그런 게 아니다. 진짜다.

하고싶은 결론은 학생들이 생각하는 사고는 시야가 엄청 좁기 때문에 절대로 그대로만 생각하면 안된다. 절대 좋지않다. 저 기준들은 “실제로 회사 업무에 써봤으며, 업무를 통해 사용해보면서 익힌 기술 및 특정 이상의 경험을 요구한다”는 것이지, 그냥 이력서상으로 좀 해봤다 할 정도의 몇 라인 추가하는 정도로는 전혀 쓸모 없다. 오히려 다 뽀록난다.

어디까지의 수준이나 내용을 맞춰놓고 공부하면 쉽게 한다. 그 습관이 들어서 이젠 그런 경계가 거의 없는 분야를 뛰어들려 하니 답이 없는 거다. 그러면 뭘 해야 하는지, 뭐 하나라도 해보던지 해서 조금씩 쌓아야 하는데, 그건 안한다. 그러니 뭐… 답은 정해졌다.

학부생들한테 참 많이 듣는 질문이다. 아니면 취업 준비생들한텐도 엄청나게 많이 나오는 질문이 있다면 이거라고 당당하게 말할 수 있을 거 같다.

사실 현업에 계신 분들은 이 질문을 상당히 싫어하신다. 이와 유사한 질문으로는 “자격증은 뭘 따야 할까요?” “꼭 컴공 나와야지만 개발자 되나요?” 랑 같은 류의 질문이다. 정형화된 기준을 알고 싶어서 질문하는 것인데… 정형화된 기준 따윈 없는 게 개발자란 존재들이다.

개발자들은 흔히 평생 공부를 한다고 하는데, 맞는 말이다. 나도 그렇고, 내 앞 세대에서 개발했던 형님들도 지금도 여러 기술들 공부하면서 “아, 이건 이전에 이런 거랑 비슷한 개념이구나.” “오, 이건 또 다른데? 저기 쓰면 편하겠다”라는 식으로 계속 신기술을 접하고 계속 습득한다. 그렇게 하면서 자기 프로젝트에 필요한 것인지 아닌지를 파악한 다음에 그 기술을 이용한다.

근데 학생들은 반대로 행동한다. “이 프레임워크는 어떤 환경에서의 GUI 인터페이스를 만드는 거래” “이걸로 딥 러닝을 공부하니 이걸로 졸업하고 나서도 쓰겠지?” “안드로이드는 무조건 안드로이드 스튜디오에서 개발해야 한대.” “유니티가 게임 개발하기 쉽다고 하니 우리 유니티 공부하면 되는거지?” 이런 식이다. 진심으로 말하면, 되게 편협한 생각이다.

그렇기 때문에 이런 사람들이 개발자가 되면 개발이 힘들어진다. 단기적인 기술에 대해서는 이야기 하는 게 쉬운데, 정작 그 안에 들어가있는 프로젝트의 전체적인 구조라던가, 프로젝트를 위해 필요로 하는 최소한의 기술적 이해보다는 우선 아는 대로 뭐 할 수 있는지 없는지만 보고, 그게 만약 안된다면 거기에 맞는 환경 혹은 기술이 뭐가 있는지를 맞춰보는 데 급급해진다. 즉, 해결 방법에 대해서 상당히 좁은 시야를 가지게 된다. 프로젝트 완성을 할 수 있음에도 불구하고 못하는 상황도 발생한다.

개발자가 된다는 상태에서는, 기본적으로 뭐만 따로 꼬집어서 공부한다는 거 자체를 이야기 할 수 는 없다. 단, 최소한의 지식들은 컴공과에서 다 배웠을 것이다. 그리고 프로젝트를 하면서, 아니면 자기가 원하는 프로그램 뭐 하나 만들어본다면서 이것저것 익혔던 언어나 기술들까지 합쳐져서 뭔가 딱 보여줄 것이 있는, 마지막으로 그 보여줄 거 하나 만들어보겠다면서 이런 저런 생고생 했던 경험들. 이거면 된다고 본다.

p.s. 단, 대학원생들의 연구실 프로젝트는 될 수 잇으면 포함 안시키는 것으로 하겠다. 이건 별도로 이유를 적어주겠다.

요즘 하는 기술에 대해서도 글을 좀 써달라는 리퀘가 왔다.

쌓인 글도 많긴 한데….

몇 분 안되는 분이지만 블로그에 적힌 메일로 피드백을 주셔서 고맙다. ㅠㅠ

p.s. 워드프레스 닷컴은 덧글 시스템이 한국 사람들한텐 그닥 편리한 기능은 아닌듯.

아까 밥먹고 잠깐 잠이 들었었는데… 옛날 기억이 떠올랐다. ㅡㅅㅡ 이미 완성은 커녕 준비 단계도 진행 안된 말만 나온 기획 가지고 기능을 대충 막 넣고는 미리 브로슈어 만들고 영업맨들한테 죄다 들려줘서 밖에다가 홍보한다. 그리고는 실제로 사람들이 써보려고 앱 깔면 “왜 이 기능 없어요?” “아, 그건 지금 거의 다 만들어서 업뎃 준비중이에요.” 이라고 사기로 입 털고…

그러다가 문제 생겨서 일정 늦어지고, 영업쪽에서 개발팀에 욕 미친듯이 퍼붓기 시작하고, 그리고 개발 도중에 여러 문제 터지는 것까지 죄다 개발자들이 뒤집어 쓰는 탓에 서비스 되는 데까지는 이전 보다 더 걸렸다.

이걸 가지고 이제 죄다 개발자들이 욕먹고 피해 뒤집어 쓰고 해서 억울해서 한 소리 했었다. 그런 식으로 주먹구구식으로 일을 하냐고.. 그러고 나서 들었던 소리.

“니가 한 번 영업 뛰어봐.”

저런 거 없으면 안된다는 개소리였다. 근데…. 지금 보면 그때 그 삽질은 죄다 거품이었다. ㅡㅅㅡ 그때 잠깐 반짝이로 영업 실적 오르는 건 있지만, 그 외에는 약빨 금방 떨어진다. 그러면 또 다른 아이디어 내놓고…(반복)…(반복)…

근데 정작 저런 거 아니어도 영업 실적 무지 잘나오는 다른 영업팀이 있었다. 결국은 영업맨의 자질 문제…ㅡㅅㅡ

p.s. 써보니 진짜 잡소리네….