Category: Uncategorized

컴퓨터 영역이 너무 어려워 지고 있다.

컴퓨터 영역이 너무 어려워 지고 있다. 어찌보면 그런 수순으로 가고 있는게 당연한건지도 모르겠다. 과거에 등안시 했던 것들, 대표적으로 알고리즘 같은 것들을 요즘에는 중요하게 여기는 걸 보면 말이다.

과거나 지금이나 알고리즘은 중요하다. 하지만 유독 그것이 부각되고 나머지는 좀 덜한 중요도를 갖는것처럼 왜곡되고 있는게 문제가 되지 않을까 싶다. 그동안에 개인의 역량이란게 무엇으로 평가 되었는지는 모르겠지만, 요즘에는 코딩 알고리즘 문제가 기본이 되다보니 책방에 가서 보면 알고리즘 관련 서적들이 아주 많다.

거의 15년정도를 컴퓨터 분야에 있다보니, 요즘들어 그런 생각이 더 깊어지는 것 같다.  코딩으로 알고리즘을 구현하는 것도 중요하지만 그것보다 더 중요한 것이 ‘상황인식’ 그리고 ‘아이디어’가 아닐까 싶은데 나보다 어린 사람들을 보면 알고리즘은 잘 아는데 나머지는 모두 부족함으로 다가온다.

개인적으로 어떤 사람이 경력을 봤을때에 다음과 같은 질문을 먼저한다.

  • 문서 작성은 잘하는가? 그렇다면 어떻게 작성하나?
  • 협업을 할때에 주로 어떤걸로 하나? 메신저? E-메일?
  • Java 를 쓴다고 하는데 객체지향 프로그래밍이 뭔가?
  • 디자인 패턴을 잘 사용하나?
  • 코드 재사용성 고려에는 어떤게 있나?
  • 뭔가 관심을 넓히려고 하는가?

나는 문서 작성을 중요시 한다. 어느 회사에 잠깐 있었을때에 어떤 개발자는 ‘소스코드에 다 있다’ 라고 말했던게 기억난다. Jira 와 소스코드를 보라는 말만 되풀이했던 곳이 였다.

정작 소스코드를 보고 있자면 커다란 배치 프로그램을 보는 느낌이 들곤 한다. 하나의 메소드에서 여러가지 조건들을 처리하기 위해서 if 문이 수십게 있었던 기억들… 클래스 하나에 조건마다 메소드를 작성하다보니 1000 라인이 넘었던 클래스…..

알고리즘으로 뭘썻네 하기전에 객체지향 프로그래밍이라도 먼저 해줬으면 하는 바람이 요새는 더 크게 다가온다.

알고리즘은 대략 이런게 있다정도의 내용을 인지하고 있고 상황에 맞게 활용할수 있도록 떠올리는 정도면 그만이다. 현업에서 알고리즘을 온전히 내 머리속에서 생각해서 구현해보적은 별로 없었던게 이유이기도 했지만, 혼자 일하고 있다면 알고리즘만 생각하겠지만, 협업을 하는 경우에는 알고리즘 만큼이나 중요한 여러가지가 존재한다는 사실도 잊지 않았으면 좋으련만…  (사실 많은 사람들이 사용하는 킬러 애플리케이션들에서는 독창적인 알고리즘이 중요하다. OS를 제작한다던가, Office 와 같은 것들… 거대하기도 하지만 내부적인 기능들이 정교하면서도 깊이가 있는 것들은 알고리즘을 속속들이 알고 응용하고 독창적으로 개발하기도 해야한다.  하지만 지금 경력을 뒤돌아볼때에 그러한 정교한 것들을 만들어보긴 했지만 깊이가 있는 것들을 작성해본적은 거의 없다. 웹, 서버개발들을 했었지만 사실 주어진 알고리즘 라이브러리를 잘 활용해도 왠만한 안전한 프로그램은 나온다)

어떤 일을 하던간에 많은 고민을 하면서 했으면 하는 바람이 있다. 자바 프로그래밍을 할 경우에 java 8 로 프로젝트를 한다고 하더라도 미래에는 바꿀 수밖에 없는 운명일 거다. 그렇다면 호환성을 고려해 제작해야하는건 개발자라면 당연한 역량인데도 나중에 생각하자는 식..

지금은 모로가던 서울로 가기만 하자라는 식의 사고방식의 개발자들이 너무나 많아 보인다. 그런 사고방식을 하면서 결국에는 남탓, 환경탓을 하고 있는 사람들이 너무나 많아 보인다.

인생이란게 노력만으로는 안되는 거다.

요새 느끼는 거지만 인생은 노력만으로는 안되는 것 같다. 뭐랄까 잠깐 이나마 외모에 신경을 쓰는 연예인들의 기분을 이해할 수 있다라고 할까? 잠깐, 내 인생이 외모 때문이다라고 하는거 같은데 그건 아니다. 외모야 뭐.. 오징어지.. 찐따에 오징어면 뭐.. 그냥 혼자살 인생은 결정된거라 딱히 불만은 없다.

무슨 말을 하고 싶은거냐하면 IT 직업이란게 환경도 중요하다는 걸 말하고 싶다. 내가 개발자로서 입지를 다지고 싶다면 개발자로서 다양한 개발과 경험을 할 수 있는 곳이 좋다. 이왕이면 개발을 하는데 필요한 것들도 모두 경험할 수 있는 곳 말이다. 코딩만 잘한다고 개발을 잘한다고 할 수 있는가… 애자일이나 기타 개발을 위한 각종 기반이되는 지식도 중요한데 그런것까지 모두 경험할 수 있는 곳이면 좋다.

개인적으로 나는 인프라를 다루는 분야에서 일을 하고 있다. 좀 더 구체적으로는 AWS 인프라를 다룬다. AWS 를 하는 사람은 알겠지만 AWS 의 인프라는 정말 방대하고 각 종 서비스를 조합하는 방법도 천차만별이다.

그런데, 어떤 곳에서는 IAM 사용을 막아놓고 또 어떻곳에서는 Billing 을 막아놓는다. 또 어떻곳에서는 RDS 를 막아놓기도 한다. 이런식으로 사용에 제약을 받는 경우가 있는데 그런 환경은 별로 좋지 않다.

자신이 하는 분야에서 성공을 하고 싶다면 그러한 성공을 뒷받침해줄 환경 또한 중요하다는 것이다. 하지만 그 환경을 내 노력만으로 쉽게 구축을 되냐 이 말이지… 정책이다 보안이다 하면서 제약을 받기도 한다. 때로는 프로젝트의 세팅이 덜됐다면서 몇개월째 AWS 계정은 고사하고 Linux 시스템에 접근하는 것도 불가능했던 적도 있다. “꿀 빨고 좋았겠다” 라고 부러워하지 마라… 몇개월이 지난뒤에 나는 바보가 되어 있었으니까…

나이가 먹어감에 따라 지금까지 내가 쌓아올린 것을 현상유지하는 것도 벅차다. 불과 몇년전까지만 해도 이런 생각을 할거라는 걸 꿈에도 생각을 못했다. 죽을때까지 Fresh 할줄 알았지. ㅎㅎ. 점점 더 뭔가를 하고 싶어도 나이때문에 못하게 되는  것을 목격하기도 한다. 그런 모습을 지켜보면서 나도 곧 저렇게 될거 같다는 두려움에 휩싸이게 된다.

한국에서의 삶이 많이 고달프다. 나이때문에 안된다는 말을 들을 시기가 다가와가니 한국에서의 삶이 많이 고달프다. 누군가 내게 존댓말을 쓴다는 것도 이상하고… 한국이란 사회에서 내가 너무 이상한 놈인가 싶기도 하고.. 암튼 머리가 복잡하네..

내가 보기에 구조적인 문제의 시작은….

내가 보기에 한국 사회의 구조적인 문제의 시작은 ‘계급’ 인거 같다. 민주주의 한국에서 무슨 계급이냐고 하겠지만, 제도화되지 않은 계급은 엄연히 존재한다.

사회적인 직위도 어찌보면 사회적인 제도이기도 하지만, 내가 말하고자 하는 계급은 ‘내가 너보다는 잘났다’ 하는 의식구조를 말한다.

문제는 ‘내가 너보다 잘났다’ 라고 한다면 뭔가 현실을 바꿀수 있는 액션, 예를들어 번뜩이는 아이디어를 낸다던지 그 많은 사회생활과 자기분야의 경험을 기반으로 어려운 문제를 해결해나간다든지 하는 것이 있어야 한다. 쉽게말해서 자타공인 능력자소리는 들어야 그런 말쯤은 할 수 있지 않겠나?

하지만 한국 ‘내가 너보다 잘났다’ 는 것은 조선시대의 ‘양반’ 계급의식을 말한다. 양반이 고된 논밭일을 하는 걸 봤나? 망한 집안이 아니라면 절대로 그것은 양반이 할일이 아니다.

이 양반 계급의식은 나이나 성별을 뛰어넘어 어떤 상황이 발생하면 그 상황에서 ‘나는 양반이 되어야 해!’ 하는 일념으로 말과 행동을 하는 인간들이 사회전반에 넘쳐나는게 문제다. 이런 양반이 되기 위해서 그 상황에서 키를 잡고 있는 사람과 깊은 관계를 갖고 그들과 어울려 논다. 그러면서 그 권력자에게 주위사람들에 대해서 평가하기 시작한다. 얘는 어떻게 제는 어떻고….

대부분의 권력자는 주위 사람들에 대한 평가 이야기를 흥미로워하면서 귀담아 듣는다. 그러다보면 그 권력자조차도 그런 말을 하는 인간에게 감화되어 어떤 중요한 결정사항을 그와함께 의논하는 지경까지 이르게 된다.

소위 말만하는, 이빨만 까는 인간들이 한국 사회를 망치는 조선시대의 양반계급의식을 그대로 가지고 생활하는 놈들이다. 문제는 한국에서 이러한 사람들 주위에 사람들이 모인다는 거다. 서로 뒷담화를 안당하기 위해서 친하게 곁에 붙어있어야 하지 않겠나…

능력을 가지고 현실세계를 바꾸는 일을 하는 사람은 이 ‘양반’ 계급의 먹잇감이 된다. 이 양반 계급은 현실에서의 능력을 가진사람을 자신이 관리하려고 한다. 그래서 나온 말이 ‘사람 관리도 능력이다’ 아니겠나. 천하의 개소리다. 그런말 하는 사람치고 사람을 제대로 관리하는 인간 못봤다.

나는 지금까지 현실 능력을 갖추기 위해서 노력해왔다. 말보다는 행동 아니겠나…. 한국사회의 구조적인 문제를 알면서도 이렇게 하는대에는 내가 가진 신념때문이였다. 몰라서 그렇게 행동한게 아니였다.

하지만 이제는 바꾸기로 했다. 자꾸 양반같은 놈들이 내게 꼬인다. 이런게 해달라 저런거 해달라도 부족해 이제는 돈까지 빼갈려는 인간들… 매일 새벽 2시까지 컴퓨터 앞에 앉아서 키보드를 두드린 이유가 고작 그 쌍놈같은 양반들 인생 밑바닥 깔아줄려고 했던게 아니다. 그런데 이 쌍놈의 양반놈들은 날 호구로본건지…

신념은 버리지 않는다. 하지만 나도 사람을 대하는 방법을 교체할 필요는 느낀다. 이제는 그렇게 해야 겠다. 자꾸자꾸 뭘 해주면 그걸 권리인줄 아는지… 이제는 도장깨기를 해야지, 그래야 이놈들이 자신들이 양반이다 라는 소리를 안하지…

오랫동안 그래도 인간들인데,,, 인간들인데,,,, 했지만 이제는 털끝만큼도 그런 생각을 가지지 않기로 했다. 다들 자신들의 이익을 위해서 인생을 살지 않나… 남보다 내가족, 나가 최우선일뿐인데.. 그럼 나도 내 자신을 최우선두고 인생을 살아볼련다.. 겁나 악날하게..

우리은행 전산장애 관련해 드는 생각.

지난 5월 초. 5월 5일 어린이날에 주말이라 대체휴일로 월요일까지 쉬는때였는데, 우리은행에서 전산작업으로 인해서 카드결제외엔 아무것도 안된다고 문자가 왔다. 뭔가 큰 작업을 하는 거구나만 생각했는데, 다음날에 사람들 사이에서 우리은행 전산망이 작동하지 않는다고 말을 하더라. 그날 급여를 받아야 하는 사람들은 월급이 이체가 안되었다고 하면서 불만을 토로하기도 했다.

‘은행 전산’, 차세대만 하면 장애부터…

은행 전산망은 다른 전산과는 차원이 좀 다르다. 인간세상 돈이 매우 중요하지 않은가? 그런 돈을 관리를 전산화하는 리스크는 다른 전산시스템을 능가한다.

그런데, 이러한 은행/증권 전산시스템 작업을 했다하면 장애부터 발생하고 시작하는게 문제가 아닐까?

우리나라의 IT 산업도 이제는 성숙기다. 2000년대 버블이 붕괴되면서 옥석이 가려졌고 그래서 살아남은 IT기업들이 지금까지 생종해 있다. 벌써 20년전일인데, 그동안 전산시스템 작업을 한두번 해본것도 아닐텐데 이런일이 반복되는게 안타갑다.

그 이유는 아주 명확하다. 은행/증권 전산시스템 작업은 아주 오래전 과거의 개발  프로세스를 그대로 가지고 가고 있기 때문이다. 기획-분석/설계-개발-테스트-오픈.

최근 소프트웨어 개발방법론이 바뀐지가 언제인데, 아직도 저러고 있나 싶다. 특히나 리스크가 아주 클수록 작게작게 코드를 수정하고 바로바로 적용하는 방법이야말로 한번에 업데이트를 하는 방법보다 리스크가 몇 배는 적다.

이미 우리은행 차세대 구축은 2월 오픈을 지키지 못하고 5월로 미뤘지만 장애는 피할 수 없었다.

IT 가 뭔지 모르는 사람들이 사업을하니…

다음은 우리은행 차세대 구축을 맡았던 회사 관계자의 말이다.

SK C&C 홍보실 관계자는 “(오류는)전산시스템 교체 초기 어디서든 발생하는 문제로 얼마나 빨리 수정하느냐가 관건이다”며 “(우리은행 위니에서는)그렇게 큰 오류가 발생한 것도 아니다”고 말했다.

얼마나 빨리 수정하느냐가 관건이 아니라 문제가 발생하지 않도록 사전에 개발 프로세스를 정립하고 오픈을 했어야 했다. 오픈을 하면 으레 장애는 발생하는것이 IT 개발 프로세스가 아니다.

IT를 하는 사업자 입에서 저런 소리가 나온다는게 이제는 놀랍지도 않다. 홍보실 관계자라는 사람이 과연 IT 개발의 실무경험을 해봤다면 저런 소리는 못한다.

이는 어찌보면 실무적 경험을 중시하지 않는데서 원인이 있을 수도 있다. SK C&C 회사에 다니는 사람들, 그중에서 사업적인 영향력을 행사하는 위치에 있는 부장급 이상들 중에 과연 개발 경력을 수년간 가진 사람이 존재하기는 할까?

IT 사업도 사업인지라, 경영을 잘하는 셀러리맨같은 사람들이 현실의 결정권을 가지는 경우가 있다. 사업의 특성을 책으로만 읽은 수준이고 사업은 돈을 벌어야하는 것이 목표이다보니 최대한 지출을 줄일려고 한다. 개발을 그져 Copy & Paste 수준으로 보고 이미 만들어진거 버전이나 좀 올리고 서버 시스템을 최신으로 교체하는 것이 차세대로 착각하는 사람들이 사업자 중역을 이끌고 있다는게 심각한 문제다.

내가 우리은행 전산책임자라면…

절대로 사업자에 책임을 맡은 사람들과 이야기 하지 않는다. 1000여명이 투입된 이 프로젝트에서 자세히 보면 군대에서 중대장 역할을 하는 개발자들이 아주 많다. 사실상 그들만큼 이 프로젝트의 규모와 비용을 정확하게 계산해낼 사람들은 드물다.

직급, 정규직, 비정규직이 대체 무슨 소용이란 말인가… 현실을 직시하고 바꿀수 있는 힘을 가진사람을 곁에 두는것이 리스크를 줄이는 길인데도 그놈의 사업자와 수주자… 그리고 R&R을 따지면서 일을 하다보니 이 모양인지도 모른다.

아무튼 이번 우리은행 차세대는 실패다. 오픈하고난 후에 장애를 해결했다고해서 그것이 성공해다고 평가하지 않는다. 2월달 오픈을 지키지도 못했고 오픈하고 난후에 장애는 그동안에 개발 프로세스가 어떠했는지를 단적으로 보여준다.

발전 없는 사람들…

안타까운 현실이다. IT 사업을 하면서 IT를 모른다. 장애는 날수 있지만 얼마나 빨리 수정하느냐?? 그 빠른 수정을 위해서 개발 코드가 걸레짝이 되어도 상관없다는 건가. Agile 이 다 무엇이며 DevOps 가 다 무슨 소용이란 말인가……..  그져 시대에 뒤쳐지고 있지 않다는 가면을 쓰기 위한 노력일 뿐이다.

DBA 직업군의 질이 떨어지고 있다.

내가 이러한 글을 쓰는 건 순전히 내 경험에 바탕을 둔 것이다. 나는 현재 SI 분야에서 프리랜서로 일하고 있다. 나의 임무는 TA이다. 인프라 담당이 주요한 업무이긴 하지만 단순하게 인프라를 담당하는 것을 넘어 설계분야까지가 나의 직업적인 업무의 영역이다.

인프라를 담당해서인지 개발자보다도 DBA와 부딪히는 일이 많았다. 별탈이 없었으면 좋았겠지만 문제가 지금도 지속되는 걸보면 내 개인적인 부분이라고 치부하기에는 뭔가 이상했다.

사람이 한번이나 두번정도는 상대방, 그러니까 나의 경우에는 DBA의 개인적인 일탈쯤으로 여길수도 있다. 하지만 프로젝트를 할때마다 DBA와 문제가 생긴다면 이거는 개인적인 일탈이 아니라 사회적인 제도와 같이 구조적인 문제로 봐야 한다.

제목이 너무 자극적인가? 이 구조적인 문제에 대한 결론이 바로 ‘DBA 직업군의 질이 떨어지고 있다’ 다. 사실이다. 그리고 DBA로서 직업을 가시는 사람들 대부분이라고 하고 싶지는 않다. 하지만 그들의 마인드가 과연 DBA로서의 직업윤리 의식이 있느냐하는 생각마져 드는게 사실이다.

인터넷을 검색하다 보면 DA와 DBA의 역할에 대한 글을 심심치 않게 보게 된다. 그리고 이 둘사이에서도 분쟁이 잦은 것을 볼수 있었다. 예를들어 다음과 같은 것이다.

SQL 튜닝은 누가 해야 하나?

이 질문이 DA, DBA 사이에 논쟁으로만 끝나면 좋은데, 이 결론으로 인해서 TA까지 피곤해지는 수가 있다는게 문제다.

사회생활을 하다보면 종종 듣게되는 소리가 있다.

가만이 있다고 해서 너에게 문제가 없다는 건 아니다. 뭔가 내게 부당한게 발생하지 않도록 끊임없이 주위를 살펴야 한다.

하지만 뒤집어서 생각해봐야 한다. 가만이 있는데, 누군가 자꾸 나를 걸고 넘어진다면  그건 그 사람만의 문제가 아니 구조적인 문제라는 걸 말이다.

DBA는 애시당초 TA 였다. IT가 크게 발달되지 않았던 과거에는 TA가 그야말로 인프라를 모두 관리했다. OS 부터해서 Web 서버, WAS 서버, Database 서버까지… 초창기 IT에서는 그져 개발자와 인프라만 구분이 되어 있었을 뿐이다.

하지만 IT산업이 크게 발전하면서 TA 라는 직업군에도 분화가 발생하게 된다. 특히나 Database 의 경우에는 그 중요성으로 인해서 분리 작업이 먼저 이루어진다. 예를들어, Web이나 WAS 는 최악의 상황이라고 하더라도 문제될거는 없다. 하지만 Database 의 경우 최악의 상황일 경우, 데이터가 삭제 된다거나 시스템 저장장치가 고장이 난다거나, 할 경우에는 사업을 접어야 한다.

또, 데이터를 다루는 분야이다보니까 개인정보와 같은 법적인 문제도 생겨났다. 아무나 시스템을 만지게 되면 그만큼 개인정보 보호가 되질 않는다.

그래서 Database 를 전담으로 할 엔지니어가 필요해졌고 TA에 분리해 DBA 가 생겨난다. 결국 DBA도 TA다.

Database 를 잘 운영하기 위한 지식은 아주 방대하다. 아무리 좋은 하드웨어를 가지고 있다고 하더라도 이 시스템을 어떻게 구성하느냐에 따라서 성능을 천차만별이다. 과거도 그렇고 현재도 그렇듯이 전체 애플리케이션의 병목구간을 체크해보면 Database 이 대부분이다.

성능.. 아주 중요한 지표다. TA의 경우에도 시스템을 설계할때에 성능부분을 고려한다. IT라는 것이 적은비용으로 많은 일을 처리하도록 하는게 목표이기 때문에 DBA도 마찬가지다. 문제는 이러한 성능을 보장하기 위한 노력에 어떤것들이 필요할까?

시스템 설계는 어려운 분야다. 뭐든 설계치고 쉬운게 있겠냐만은 시스템을 대상으로 할때에 어떤 것이 과연 좋은 설계인지에 대한 지표가 있을까? 이것도 사람마다, 그리고 어떤 시스템이냐에 따라서 다르다고 하는 원론적인 답변이 대부분일거다. 하지만 나의 오랜경험상.. 그리고 TA로서 일을 해온 경험을 비춰보면 다음과 같다고 할 수 있다.

유연하면서도 성능을 보장할 수 있는 설계

성능을 보장하기 위한 설계로 무엇이 필요할까? 이러한 고민을 끊임없이 하는 사람이 진정으로 IT를 하는 사람이다. 성능을 보장하기 위해서 라는 명제는 개발자, 엔지니어 모두에게 해당되는 명제다.

DBA의 질이 떨어진다고 진단하는 기준이기도 하다. 혹자는 ‘성능보장’ 이 기타 다른 것과 맞지 않는다고 할지도 모른다. 하지만 일을 해보면 알겠지만 한두가지만 가지고는 되질 않는다.

DBA에게 성능을 보장하기 위해서는 어떠한 것들을 알아야 하나?

  1. OS(Storage 포함)
  2. Database System
  3. SQL

하지만 내가 경험한 그리고 수많은 사람들과 이야기한 결과 DBA들은 3번만 하려고 한다. 이렇게 말하면 ‘적어도 2번은 해야지’ 할지도 모른다. 하지만 그것마져도 안할려고 하는 추세에 있다. 왜냐하면 Cloud 시스템이 나왔다는 이유로 2번을 제대로 하려하지 않는다.

성능보장을 위해서는 ‘융합적 사고체계’가 필요하다. 그래서 앞에서 1,2,3 세가지를 필수로 뽑은 것이다. TA의 경우에는 다음과 같다.

  1. OS
  2. WAS, WEB 서버
  3. Cloud Platform
  4. Java programming (한국의 SI 는 대부분 Java다)

예를들어 DBA 가 Database 시스템을 새로이 구축한다고 해보자. 이럴경우에 현장에서 어떤 일이 벌어지는가?

대부분 DBA는 TA 들에게 ‘업무협조’를 요청한다. 자신들은 OS를 전문으로 한 사람들이 아니니 TA에게 업무협조를 하는 것이다.

그리곤, Database 시스템을 설치할때즘 되면 자신들을 도와달라고 한다. OS 명령어에 익숙치않아서 설치할때만 도와달라는 거다. 하지만 도와줄게 있나… 이렇게 되면 DBA는 어디론가 전화를 건다. Database 시스템을 관리해주는 업체에 설치를 의뢰하는 것이다.

Database 설치가 어찌 잘되었다 하면 그때부터 이것저것 일을 하기 시작하는데, 과연 이 사람이 Database 성능을 보장할 수 있는 일을 한 것인가?

외부 업체에 Database 설치를 의뢰할 수는 있다. 하지만 그 의뢰할때에 요구사항들을 세밀히 작성해 건네주는 것을 단 한번도 본적이 없다. Disk I/O 는 어느정도이다, Memory 는 어느정도가 적당하다, Storage 크기는 어느정도 필요하고, 설치 Directory 구조는 이러했으면 좋겠다.. 하는 요구사항들이 너무나 많지만 절대로 그들은 그러한 요구사항을 요청하지 않는다.

대부분이 다 이러했다. 나 같은 경우에는 Database 설치조차도 TA가 해야했다. TA 의 경우에 Database 설치할 줄 모른다고, 설사 안다고 해서 TA 경력에 아무런 도움이 안된다. DBA라는 전문적인 직업을 가진 사람들이 존재하는데 TA가 그러한 경력을 가지고 있어봤자다.

하지만 DBA는 SQL 만 작성하는게 아주 중요한 일이고 그게 전부인냥 했다. SQL 작성이 중요하지 않다는게 아니다. 하지만 Database 시스템을 알려고도 하지 않았다. 어짜피 SQL 을 실행할때에 Index 를 잘 타는지 Join이 잘되고 있는지 정도만 따지면 되었지 Database 시스템이 그러한 SQL 문을 어떻게 처리하는지에는 아무런 관심이 없었다.

대표적인것이 Oracle 을 다뤘던 사람이 MySQL 을 다룰때다. Oracle 을 다뤘다고 해서 자존심을 치켜 세우지만 MySQL 을 다루라고 하면 그런 중소형 DB를 왜 만져야하는지 불만부터 나타낸다. 더 중요한 것은 MySQL 시스템에 대해서 절대로 공부를 하지 않는다. Oracle 을 다룰때부터가 외부 인력들에게 시스템 관리를 위임해온터라 MySQL 시스템에 문제가 발생하면 TA를 찾는다.

Oracle이던 MySQL 이든 OS 설치에서부터 튜닝이 필요하다. Kernel 파라메터 수정은 기본이고 Disk Raid 를 무엇으로 할건지, 백업과 복원을 고려한 디렉토리 구성등등이 전부 설치단계에서 결정된다.

그리고 운영을하게될 경우에는 Database 버전에 맞는 SQL을 작성해야 한다. MySQL 이나 Oracle 이나 독자적인 기능과 함수들을 제공한다. 거기다 Index 를 어떻게 구성하고 어떻게 동작하는지에 대해 모두 다르다.

하지만 대부분의 DBA 들은 시스템을 다뤄본 경험이 없다. 특히나 설치를 해본 사람을 찾기도 힘들지경이다. 최근에 Cloud 가 활성화되면서 OS가 필요없어지는 시대다. 그러다보니 SQL 만 작성할려고 든다.

SQL 를 작성하면 뭐하나… 그게 시스템에서 제대로 동작하는지 모르는데… 아아.. 결과물을 잘 뽑아내면 그게 잘 동작하는거다? 이런 DBA들이 넘쳐난다. MySQL 을 다루면서 InnoDB 에 대한 특징이 뭔지도 모르는 사람들이 SQL문을 작성하고 앉았고… MySQL 버전 패치작업을 TA와 공동으로 추진한다. 왜 TA를 걸고 넘어지나?

DBA도 TA다. Database 를 다룰려면 당연히 시스템을 알아야 한다. 단순하게 Database System 이라고 하면 Oracle, MySQL만을 지칭하는게 아니라 그것을 운영하기 위한 제반사항 전체를 말한다. 하지만 심지여 Oracle, MySQL 과 같은 Database 자체조차도 안 다루려고 한다.

구조적인 문제가 있다고 했다. 이러한 현상이 개개인의 생각만으로 끝나면 문제가 안될거지만 DBA들도 인간이다. 모든 인간은 이기심, 물욕이 있다. 될수 있으면 일을 적게하면서도 월급 받기를 원한다. 많은 일을 하게되면 여러사람과 또 인간관계도 형성해야하고 관리를 해줘야한다.

현재 DBA 라는 직업의 영역이 좁아지고 있다. 이것은 DBA들에게는 더 없이 좋은 일이다. 최근에 Database 설치조차 이제는 DBA가 할일 아니라고 말한다. 문제는 그러한 주장이 현장에서 그대로 반영이 되고 있다는 거다.

SQL을 잘 작성해서 원하는 결과를 뽑아주면 그만인 직업이 DBA 인 것으로 구조가 바뀌고 있다.

CentOS 6 버릴때가 됐다.

이제 CentOS6 은 버릴때가 됐다. 오늘 PHP 7 버전을 설치하려고 보니 crypto library 가 sodium 을 필요로 하는데 이게 버전이 1.0 이상 버전이다.

문제는 이 버전을 설치하기위해서는 autoconf, automake 를 별도로 설치해줘야 하며 libzip 의존성에서도 1.0 버전 이상을 요구해 의존성 패키지가 계속 생긴다. CentOS6 에서의 컴파일러 관련 패키지들이 버전이 낮은게 문제가 계속 되고 있다.

CentOS6 의 End of life 는 2020년 11월 30일까지로 아주 오랜기간동안 지원을 해왔다. 어떤 소프트웨어를 아주 오랜기간 지원을 한다는 것은 매우 어려운 일인데, 이렇게 오랬동안 지원해준데에 감사할 따름이다.

현 시점에서 가장 좋은 배포판으로는 Ubuntu 16.04 이다. CentOS7 은 커널 버전이 3.10 이지만 , 물론 비공식으로 4.x 버전을 사용할 수 있다,  Ubuntu 16.04 는 4.x 버전이다. 커널 버전에 따른 성능 향상도 무시못함으로 될 수 있으면 Ubuntu 16.04 를 사용하는 것이 좋다.

About me

용의주도한 전략가

윗자리에 있는 사람은 고독한 법, 전략적 사고에 뛰어나며 매우 극소수인 건축가형 사람은 이를 누구보다 뼈저리게 이해합니다. 전체 인구의 2%에 해당하는 이들은 유독 여성에게서는 더욱 찾아보기 힘든 유형으로, 인구의 단 0.8%를 차지합니다. 체스를 두는 듯한 정확하고 계산된 움직임과 풍부한 지식을 소유하고 있는 이들은 그들과 견줄 만한 비슷한 부류의 사람을 찾는 데 종종 어려움을 겪습니다. 건축가형 사람은 상상력이 풍부하면서도 결단력이 있으며, 야망이 있지만 대외적으로 표현하지 않으며, 놀랄 만큼 호기심이 많지만 쓸데없는 데 에너지를 낭비하는 법이 없습니다.

올곧은 태도로 계획 달성을 향한 돌진

이들의 지식을 향한 갈증은 어릴 적부터 두드러지게 나타나는데, 때문에 건축가형 사람은 어릴 때 ‘책벌레’라는 소리를 자주 듣습니다. 대개 친구들 사이에서는 놀림의 표현임에도 불구하고 전혀 개의치 않아 하며, 오히려 깊고 넓은 지식을 가지고 있는 그들 자신에게 남다른 자부심을 느낍니다. 이들은 또한 관심 있는 특정 분야에 대한 그들의 방대한 지식을 다른 이들과 공유하고 싶어 하기도 합니다. 반면, 일명 가십거리와 같이 별 볼 일 없는 주제에 대한 잡담거리보다는 그들 나름의 분야에서 용의주도하게 전략을 세우거나 이를 실행해 옮기는 일을 선호합니다.

대부분 사람 누가 봐도 이들은 지극히 모순적인 삶을 살아가는 것처럼 보이지만 이를 객관적이고 이성적으로 놓고 보면 사실 이해가 가기도 합니다. 예를 들면, 이들은 비현실적일 만큼 이상주의자이자인 동시에 매우 신랄한 조롱과 비판을 일삼는 냉소주의자로 이 둘이 같이 공존한다는 것 자체가 불가능해 보입니다. 또한, 기본적으로 지혜와 노력, 그리고 신중함만 있으며 못할 것이 없다고 믿는 한편, 사람들이 실질적으로 그러한 성취를 끌어내는 데 있어서는 게으르고 근시안적이며 자기 잇속만 차린다고 생각합니다. 그렇다고 이러한 냉소적인 태도가 성취하고자 하는 이들의 욕구를 꺾지는 못합니다.

돌부처와 같은 원칙주의자

확신에 찬 자신감과 함부로 범접할 수 없는 신비로운 아우라를 발산하는 건축가형 사람은 통찰력과 관찰력, 기발한 아이디어, 그리고 뛰어난 논리력에 강한 의지와 인격이 합쳐져 변화를 이끄는 데 앞장섭니다. 이따금 이들이 생각했던 아이디어나 계획을 뒤집고 재수립하는 과정을 거쳐 완벽함을 추구하고자 하거나 도덕적 잣대에 따라 재정비하는 시간을 가지기도 합니다. 건축가형 사람의 업무 스타일을 좇아오지 못하거나 심지어는 이들이 왜 그렇게 행동하는지 전혀 감을 잡지 못하는 사람은 단번에 신임을 잃거나 이들의 인정을 받지 못할 수도 있습니다.

건축가형 사람이 몸서리치게 싫어하는 것이 있다면 바로 질서, 한계, 그리고 전통과 같은 것들인데, 이들은 세상의 모든 것을 탐구와 발견의 대상으로 여기기 때문입니다. 만일 문제 해결을 위한 방안을 찾은 경우, 간혹 무모할 수 있으나 기술적으로 뛰어나며 언제나 그렇듯 비정통적인 기발한 방법이나 아이디어를 수립하기 위해 홀로 행동에 옮깁니다.

그렇다고 이들이 충동적이라는 말은 아닙니다. 얼마나 간절히 성취하기를 원하는지 상관없이 건축가형 사람은 기본적으로 이성적인 사고를 합니다. 내부에서 비롯되었든 아니면 외부 세계에서 기인하였든지, 매사 이들의 아이디어는 “실현 가능할까?”와 같은 ‘이성적 사고’라는 필터의 과정을 거칩니다. 이는 사람 혹은 아이디어에 항시 적용되는 기제로, 이 때문에 건축가형 사람은 종종 곤경에 빠지기도 합니다.

홀로 떠나는 여행, 깨달음의 시간

오랜 시간 방대한 지식을 쌓아 온 똑똑하고 자신감 넘치는 이들이지만, 인간관계만큼은 이들이 자신 있어 하는 분야가 아닙니다. 진리나 깊이 있는 지식을 좇는 이들에게 선의의 거짓말이나 가벼운 잡담은 그저 낯설기만 합니다. 그럼에도 불구하고 자신을 필요 이상으로 내몰아 부조리투성이인 사회적 관습을 경험하기도 합니다. 가장 좋은 것은 이들이 그들 자신 자체로 온전히 있을 수 있는 곳, 즉 스포트라이트 밖에 있는 것입니다. 건축가형 사람은 익숙하고 편안한 곳에서 본연의 모습으로 있을 때 비로소 연인 관계나 그 외 여러 상황에서 그들 나름의 빛을 발하며 사람들을 끌어들이기 때문입니다.

건축가형 사람의 성향을 정의하자면 이들은 인생을 마치 체스를 두듯이 새로운 계획이나 전술, 그리고 대책을 세워가며 상대방 머리 위에서 수를 두며 허를 찌르는 기술로 상황을 유리하게 몰고 가는 듯한 삶을 살아갑니다. 그렇다고 이들이 양심 없는 삶을 살아간다는 말은 아닙니다. 다만 감정에 치우치는 것을 싫어하는 이들의 성격상 타인의 눈에 그렇게 비추어질 수 있습니다. 이를 고려하면 왜 많은 허구 속 등장인물들(종종 오해를 받곤 하는 영화 속 영웅들)이 본 성격 유형으로 묘사되는지 이해할 수 있을 것입니다.

한국인의 정신적 질병.. 사람 관계 좋아=성격 좋아=밝아

2018년… 또 한해가 밝았다. 어쩌면 한 해를 시작할때마다, 오래전 부터, 뭔가 강도가 세지는 느낌을 받곤 했다. 뭔가 나를 옥죄어 온다는 그런 답답함, 불합리적인 무언가가 올 한 해도 나를 옥죌 거라는 힘든 생각이 한 해가 밝을때 마다 강하게 든다.

지금까지는 그것이 무엇인지를 모르는 상태에서 답답함이 나를 힘들게 하는 것중에 하나였다. 도대체 뭘까.. 실체도 없는데 밀려오는 올가미를 그냥 앉아서 참고 견뎌야 하나… 하는 어떤 답답함…

그런데, 35세를 지나면서 그것이 실체가 무엇인지를 대충 알것만 같다. 그리고 그러한 답답함을 제공하는 원인에는 한국인이라는 사고체계가 근본적인 문제이며 따라서 이것을 해결할 방법이 없다는 것도 알게 돼었다.

한국인의 정신적 질병.. 사람 관계 좋아=성격 좋아=밝아

한국인의 정신적 질병이라고 나는 진단하는 것중에 하나가 다음과 같은 말이다.

사람 관리 하나는 잘해

대표적인 병적인 증상이다

사람관리를 잘한다… 이 말 한마디로 인해서 한국 사회는 다음과 같은 사람이 사회적인 역활로서 최상이라고 판단한다.

밝고 활동적이며 창의적인 인재.

인간이란 참으로 신비로운 존재다. 나이를 먹어감에 따라 여러사람의 행동양식이나 사고체계에 대해서 면밀히 생각해보는 시간을 많이 가지게 된다. 저녁 먹고나서 할일 없이 멍때리고 있으면 지난 과거에 어떤일이 회상이 되면서 그 일에 개입된 인간들이 했던 말과 행동들을 관찰하게 되는 것이다. 그럴때마다 인간이란 존재가 저렇게 다양할 수가 있나… 그 무엇으로 제단할 수 없는 각각이 독립된 개체라는 사살에 감탄을 하곤 한다.

사회 생활이란 것이 과연 제도적 장치일까? 다시 말해서 인간이 집단생활을 영위하기 위해서 만들어진, 그래서 어떤 질서적인 체계가 사회일까….

그다지 밝아보이지도 않고 활동적이지도 않은 인간 유형을 많이 접하게 된다. 우선적으로 내가 그렇다 보니, 끼리끼리 논다고, 그런 사람들이 눈에 들어오는건 어쩔 수 없다. 밝아보이지도 않고 활동적이지도 않은 많은 사람들이 예민한 성격일 경우가 많았던 것도 우연일지도 모른다.

하지만 그렇게 예민한 성격은 어떤 일에 있어서 꼼꼼함과 창의적인 열정을 많이 보유한 사람들이였다. 그다지 밝아보이지도 않아서 그가 무슨일을 하는지 주위 사람들이 잘 알아보지는 못하지만 그런 사람들은 적어도 자신이 하는 일에 대해서 꼼꼼하게 처리하려고 애쓰는 모습을 많이 보게 된다.

꼼꼼하게 일을 처리하기 위해서는 자신이 하는 일에 대해서 많은 이론적 지식과 경험을 보유하고 있어야 하는데, 그러다보니 이런 부류의 사람들은 자신의 일에 대해서 많은 노력을 기울이고 그러한 노력을 위해서 끊임없이 자기 스스로 열정을 불러 일으킬려고 노력한다.

30대 중반 이후부터…. ‘세상 편하게 살 방법’

문제는 한국 사회에서는 대부분 30대 중반 이후가 되면 저러한 노력과 열정을 가진 인간이 되기를 꺼려 한다는데 있다.

30대 중후반에 여기저기 면접을 보러다니다보면 항상 하는 질문이 있다.

지금까지 어떤 팀을 이끌거나 프로젝트를 이끌어본 경험이 있는가?

30대 중후반까지 어떤 팀을 이끌거나 프로젝트를 이끌어본 경험은 없지만 어떤 문제를 근본적으로 해결해보고자 밤을 세워가며 많은 논문과 글을 읽고 되도 않는 C 코드를 해석하면서 문제를 해결해 본 경험은 있다.

하지만, 한국 사회에서 30대 중후반까지 어떤 걸 이끌어보지 못했다면 더 이상 그 분야에서 채용되기가 힘들다. 30대 중후반에쯤 되면 돈도 많이 줘야 할테고 그 돈에 비례해서 그에 해당하는 직급과 업무를 줄려고 한다. 그런한 자리는 어떤 팀을 책임지는 위치밖에 없다.

내 주변을 관찰해 보면 IT 판이 돌아가는걸 잘 아는 인간들이 적지 않다. AWS가 뭐고 어떤 프로젝트에서 무엇을 써야 하고 이럴땐 어떻게 하는게 좋은지 정도를 아는 사람들이다. 그들은 넓게 알지만 깊게는 잘 모르는 경우이고 대부분은 또 안타갑게도 이론적 배경이 없는 사람들도 상당수다.

이런 사람들이 술을 먹으면 항상 하는 이야기가 있다.

빨리 팀장 달고 싶다.

팀장을 달아야 더 이상 누군가로부터 지시를 받지 않고 문제 해결을 위해서 낑낑대며 노력하지 않아도 된다는 거다. 팀장이되면 그져 윗사람들과 이런저런 정책이나 세우고 문제가 생기면 아랫사람에게 ‘해결해놔’ 말 한마디면 되고… 아랫사람의 성과는 곧 나의 성과… 이렇게나 세상 편한게 어딧냐는 거다.

적어도 기술적인 열정과 문제해결을 위한 노력따위는 않해도 된다는 논리다.

다시 앞에 이야기를…

기업에서 원하는 인재상… 밝고 활동적이고 인간관계가 좋은 사람…. 그런 사람들은 하루 빨리 편한 생활을 위해 노력한 사람들이 대부분이란게 문제다.

그리고 그러한 인간들이 리더가 되면 어떻게 되나? 끼리끼리 논다라는 진리에 의해서 그들과 같은 부류의 인간유형을 유능한 인간으로 치부한다. 다시 말해서 그다지 밝지도 않고 활동적이지는 않지만 자신의 하는 일에 대해서 열정을 가지고 문제를 해결할려고 낑낑대는 인간을 ‘한심한 인간’ 으로 치부하는 거다.

야.. 언제까지 이러고 살거냐? 빨리 팀장 달고 해야지 ㅎㅎㅎㅎㅎ

내가 있는 곳도 여지 없이 그런 꼴이 되어가고 있다. 나는 현재 시스템을 주로 다룬다. 그런데 나와 같은 일을 하는 다른 시스템 엔지니어는 안타갑게도 능력이 없다. 자신의 직업에 대해 능력이 없는데도 그들이 지금까지 살아 남을 수 있었던 이유는?

회사의 이사와 매일 담배 피면서 어울리고 술을 마시고 이러다보니 살아남을 수 있었다. 하루는 이런 일이 있었다. 이사가 나를 불러 갔더니 나와 같은 나머지 두 사람(시스템 엔지니어)도 함께 있었다. 문제는 내가 담당하는 시스템은 아니였는데 그래도 시스템 엔지니어니까 문제 해결을 위해서 불렀다는 거다.

아주 간단한 문제였는데, 그걸 몰랐다는것에 처음 놀랐고 이사가 한 말이 나를 분노케 했다.

니가 애들보다 잘하니까 니가 처리줬으면 좋겠어..

밝고 활동적이고 인간관계가 좋은 인간들은 힘들고 고통스럽기까지 하는 자기분야의 문제해결을 위한 시간을 쏟지 않는다. 그런 인간들은 그러한 고통을 어떻게하면 회피할까 하는 궁리만 한다.

그러다보니 사람관리를 잘 해야한다. 자신이 못하는 일을 대신 처리해줄 호구를 잘 고르고 또 시켜먹어야 내가 편하니까… 그런데, 한국에서는 그런 인간유형을 ‘능력자’ 라고깢 치켜세우니 이 얼마나 기가막히는 일인가…

하루는 이사가 나를 부르더만, 잠깐 다른 프로젝트 할 수 있냐고 했다. 지금 급한 일이 생겨서 그걸 해줄 사람이 필요한데, 능력이야 니가 좋으니 니가 한 1년가서 해줬으면 한다는 거다. 출퇴근 거리만 2시간이고 막장으로 치닫는 프로젝트니 능력있는놈이 정리를 해야하니 내가 했으면 했단다….

밝지도 않고 그렇다고 인간관계가 넓지는 않지만 내가 하는 일에 열정을 다해 경력을 쌓기 희망하는 사람은 저런 병적인 인간에게 먹이감이 될뿐이다. 왜? 병적인 인간이 아니겠나… 남의 능력과 경력을 갈취해 자신의 삶을 편안하게 하는것이 과연 제대로된 인간 유형이라고 할 수 있나? 그걸 한국 사회에서는 ‘능력자’ 라고까지 하니… 미치광이 사회집단 그 이하도 아니다.

발표자들… 곱게는 안보인다.

요새 어떤 분야에서 기업들의 사례 발표를 많이 한다. 사례를 통해서 많은 것을 배울수 있는 기회라 자주 간다만, 갔다와서 한번씩 찾아보는 자료 하나가 있다. 발표자의 경력이다. 웃기게도 그 발표에 나타난 인간들이 ‘리더’ 라는게 놀랍다.

물론 그러한 아키텍쳐를 구축하고 적용하는데 리더의 역활도 중요하다. 하지만 그 큰 아키텍쳐를 그 발표자 혼자 다 이해한다고? 실무자는??

몇일이 자닌후에 뻔뻔하게도 경력에 ‘xxx 시스템 구축 책임’ 이라고 자랑스럽게 새겨넣는다. 이런 사람에게 기본 베이스부터해서 차근차근 따져 물어보면 제대로 답변하는 인간 못봤다.

아키텍쳐를 구축하는데 있어서 리더는 그야 말로 팀원들의 의견을 조율하고 필요한 자원을 제공하는데 있다. 어떤 프로젝트를 잘 관찰해보면 리더 빼고 그 프로젝트에 중심에 있는 사람들이 여럿있는데 이런 사람들이 핵심 인력이라고 봐야 한다. 잘 모르겠다면 일이 몰리는 사람이 핵심 인력이라고 보면된다.

그런데, 한국 사회는 그런 인력을 데리고 이래라 저래라 하는 인간들이 많다는게 문제라는 거다.

30대 초반에 사람들에게…

절대 열정을 가지고 일하지 말라… 그져 대충대충… 눈치보면서 살다가 ‘아.. 저 녀석과 친분을 맺으면 내 인생을 땡겨줄지도 몰라’ 하는 인간이 보이면 인맥을 잘 쌓아놔라…

뭔가 한 분야에게 소위 ‘덕후’가 되고자 한다고면 외국으로 탈출하라…. 적어도 거기에서는 한국의 정신병적인 인간유형이 당신의 리더가 될 가능성은 현저히 낮다.

올한해도… 저런 정신병적인 인간하고 힘겨루기…

나이가 먹어가면 갈수록 저런 인간들과 얼굴을 맞대야 하는 순간들이 많아진다는게 문제였다. 뭔가 모르는 옥죄오는 것들… 저런 인간들이 사방에 깔려 있다는게 문제다…

니네 인생 니네가 알아서 살아라… 인간관계 좋아? 술 처먹고 업무 조율하는게 능력이냐? 그래서 니들은 이사와 친분쌓아 능력좋은 사람에게 일 몰아주기 하는걸 능력으로 아는 모양인데… 올 한해 뚝배기 많이 깨줘야겠다고 다짐한다.

 

최근 알고리즘 논쟁을 보고 느낌점…

최근 인터넷에 난데 없이 알고리즘 논쟁이 있었던 모양이다. 뭐 인터넷이라는게 방대하고 거기다 한국이란 곳으로 국한한다고 하더라도 몇몇 커뮤니티를 타고 옥신각신 한 정도밖에 더 될까만은 매우 흥미롭게 지켜보게 됐다.

원래 성격상 흥미가 없으면 ‘별 시덥잖은 이야기’ 정도로 치부하는데, 알고리리즘 논쟁을 보고 흥미가 생긴 이유가 아주 근본적인 사고차이에서 비롯된 것이라 생각했기 때문이다.

발단은 다음의 글에서 출발 했다.

개인적으로 알고리즘 관련 논람에 민감한 이유

알고리즘이 더 이상 모든 분야의 기본 지식이 아니라고 생각하는 이유는 이미 그런 토론을 통해 충분히 이야기했기 때문에, 지금은 왜 제가 이런 문제를 특히 민감하게 느끼는지에 대해 적어볼까 합니다.

제 생각에 자바나 C#, 혹은 자바스크립트 개발자에게도 ‘기초 지식’으로 알고리즘이나 운영체제 등을 공부할 것을 주문하는 것은 대체로 그런 ‘기본’을 배우면 나머지 ‘응용분야’는 쉽게 익힐 수 있을 것이라는 가정에서 출발하는 것 같습니다.

그리고 경우에 따라선 한 걸음 더 나아가 자바 같은 고수준 언어로 다루는 분야는 모두 그런 ‘응용’에 해당하기 때문에 보다 근본적이고 깊이 있는 운영체제나 C언어 등만 제대로 하면 어렵지 않게 익힐 수 있을 것이라는 근거없는 자부심으로 표출되기도 합니다.

https://okky.kr/article/396435

전체적으로 댓글이 우호적으로 달리는데, 개인적으로 적지 않게 놀랐다. 도대체 저런 글에 저렇게 많은 공감을 얻은 이유는 무엇일까? 라는 의문이들게 되면서 이 논쟁을 지켜보게 되었다.

얼마 가지 않아 다른분이 반론글이 올라오기 시작했다.

저주스러운 대한민국의 SI와 6개월짜리 국비지원 학원들 때문에 우리나라는 개발자들에 대한 인식이 형편없어졌는데, 개발자는 노가다꾼이 아니고 공학자에 속하는 직종이다. 자신의 재능이 아무리 비천할지라도 언제나 높은 수준에 오르기 위해 공부하고 자신의 결과물이 완벽에 가까워지도록 노력해야 하는 종류의 사람들이라는 뜻이다. 그런데 지금 소개하는 주장은 대학교에서 배우는 CS Fundamental이 구시대적이기 때문에 대학교의 커리큘럼이 예비 개발자들에게 구현에 대해 능숙해지도록 좀 더 가이드해야 한다고 주장한다. (대학이 직업학교인가?) 그런데 재미있게도 이런 주장을 하는 사람들은 이른바 개발자 커뮤니티의 네임드라는 부류는 될지언정 누구나 인정하는 구글러나 페이스북 개발자, 스타개발자는 아니다. (사실, 그런 사람들은 그런 시시한 커뮤니티를 하지도 않는다. 나도 페친들 링크 타고 가게됐을 뿐이다) 오히려, 인터넷에서 이름을 보는 대가들은 자료구조와 알고리즘을 탄탄이 하기를 당부한다. 그런데 왜 많은 사람들이 이런 말도 안되는 주장에 동조하고 열광하는가?

https://medium.com/@ghilbut/%EC%8B%A4%EB%AC%B4-%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%97%90%EA%B2%8C-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98%EC%9D%80-%EB%8D%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-fcbab7f87074

많은 사람들이 이글을 보았을 텐데, 웃기게도 ‘글이 너무 격양되어 있다’, ‘논리적인 글보다 욕하는 글’이라는 씹선비질 하는데 웃음이 났다. ㅋㅋ 격양된 글이긴 하지만 나름대로 논지가 있었기 때문에 그 논지에 대한 말들은 없고 그져 글이 어떠내 저쪄네… ㅋㅋ

위 글은 1부, 2부로 나뉘는데 이 글을 쓴 사람의 논지는 ‘알고리즘은 문제를 해렬하기 위한 방법으로 기능적 유효성이 있다’ 정도로 보인다.

 

알고리즘=문제해결 능력

개발자도 아닌 나 같은 사람은 알고리즘을 몰라도 된다. 탐색트리가 어쪄네 뭐가 어쩌네 하는 골치아픈 것들은 개발자들이나 하는 것이지 나 같은 밑바닥 인생을 사는 사람과 거리가 먼 이야기다.

이렇게 말을 하면 첫번째 글에 동조하는 듯하지만, ‘알고리즘’ 이라는 전형적인 전산학이 의미를 버리고 ‘문재 해결 방법’ 이라는 의미를 부여하면 두번째 글이 더 설득력이 있게 된다. 나 또한 두번째 글쓴이에 말에 동의 하는 바이고 그가 주장하고 비토했던 것에 전적으로 동의한다.

개발이 아니라 시스템을 운영하다보면 별의별 사건사고가 발생한다. 흔히 ‘장애’ 가 발생하면 최대한 빠르게 문제를 해결해야 한다. 그렇지 않으면 고객으로부터 손해배상을 제기하겠다는 서슬퍼런 이야기를 듣게 될테니까.

전부 다 그렇게 일하는 것은 아니겠지만 시스템 운영측면에서 장애 발생하면 대부분의 사람들은 ‘경험’ 에 의존하게 된다. 과거에 유사한 장애가 발생한 경험을 기반으로 문제를 해결하는 것이 가장 빠른 방법이기 때문이다. 시간은 자꾸가는데 운영체제론이 어쩌고 컴퓨터이론이 어쩌고 떠들어대봤자 답이 안나온다.

문제는 이러한 경험을 문제를 해결하고 난 다음이 문제가 된다. 반드시 장애 처리 후에 복기를 해보는데, 이게 정말 제대로된 문제해결이였는지를 평가해 향후 같은 장애가 발생하지 않도록 하는 회의를 진행한다.

바로 이 회의에서 ‘알고리즘’ 이 나온다. 웽? 시스템 장애 대응 회의때에 개발자 알고리즘이 나온다고?

ㅋㅋㅋ 알고리즘을 문제해결 능력이라는 측면으로 본다면 시스템 장애 대응 회의는 알고리즘이 회의가 된다. 개발자들이라는 시각으로만 좁게 보다보니 알고리즘이라고 하면 전산학 이론의 알고리즘만을 생각하지만 그 시각을 좀 더 확대 해보면 알고리즘이라는 말 자체는 문제를 해결하는 방법론을 전부 총칭한다.

결국 알고리즘을 잘 하냐 못하냐는 문제를 해결할 능력이 있는냐 라는 말과 같은 것이다. 이렇게 보면 알고리즘이라는 것 자체는 우리가 살면서 매일매일 생각하고 해결하는 것들과 다를바 없다.

그래서 두번째 글의 글쓴이가 예를들었던 면접 관련 이야기가 알고리즘이 무엇인지를 정확하게 보여준거라 생각한다.

알고리즘 인터뷰가 시작되면, 면접관은 데이터와 해결해야 할 문제를 포함한 몇 가지 조건들을 준다. 다만, 이 조건들은 대부분 완벽하지 않다. 대부분은 필수 요소 몇 가지가 빠져있으며, 때로는 아무 쓸모없는 조건들이 함께 있을 때도 있다. 이 조건들을 질의응답을 통해 문제 정의 가능한 수준으로 정리해야 한다. 그리고 나면 그 문제를 해결하기 위해 어떤 전략을 사용할 것인지를 설명한다. 면접관과 문제 해결 전략과 솔루션의 공간복잡도 및 시간복잡도 등에 대해 토론한 뒤 정리가 되면 구현을 시작한다. 이 때, 면접관이 내가 생각하지 못한 예외 케이스들을 자꾸 제시해서 코드 수정이 잦아지면 인터뷰는 200% 망했다고 보면 된다. 합격하려면 일반적으로 코드가 한번에 완성되어야 하고, 그렇기 때문에 구현 전에 토론과 함께 주의 깊게 전략을 완성해야 한다. 일반적으로는 그렇게 문제 풀이가 끝나지만, 구글은 종종 해당 문제에서 데이터셋의 스케일이 매우 커졌을 때에 대한 질문을 던진다. 현재 솔루션으로 확장된 데이터 규모에 대응 가능한지, 그렇지 않다면 이유가 무엇인지, 그럼 어떤 방식으로 더 큰 규모의 데이터를 처리할 수 있는지에 대해 솔루션을 요청한다. 이 때, 인터뷰 내용은 구글 내부에서 실제로 처리하는 업무의 인터뷰 버전일 가능성도 있다. 다시 강조하지만, 알고리즘 인터뷰는 절대 당신이 얼마나 아름다운 알고리즘을 외우고 있는지 보려는 것이 아니라 당신의 커뮤니케이션 능력과 논리적 사고력을 보고 싶어하는 것이다.

구글이라는 회사의 예제인데, 당연히 구글은 컴퓨터 회사이고 우리가 알고 있는 전산학의 알고리즘쯤은 줄줄이 꽤고 있어야 하며 그것을 기반으로 구글이 문제를 풀어야 한다. 문제는 두번째 글쓴이가 예를든 글을 자세히 읽어보면 면접시에 단순하게 면접자에게 알아서 풀어봐식은 하지 않는다는 것이다.

개인적으로 외국계회사에 면접도 몇몇보고 느낀 것이 바로 두번째 글쓴이가 이야기한 구글의 면접과 비슷했다. 면접관이 문제를 주는데, 문제자체가 문제가 있는 경우가 많았다. 그것을 캐취해서 자신이 의견을 피력하고 면접관과 토론을 벌여야만 했다.

겁나, 아니 존나 힘들었다. 면접관가 토론을 한다고 ??? ㅅㅂ 그냥 화이트보드에 알고리즘 기술하고 ‘맞죠?’ 하고 말지… 면접관은 화이트보드에 마커를 집어들기 전까지 ‘니가 문제를 어떻게 할지 설명해봐~’ 를 계속 요구했다. 이미 내 머리는 김이나기 시작했고……

그런다음에 Python 으로 문제 해결을 구현해야하는데, 이때부터도 난제들이다 . Python 을 얼마나 알고 있는지를 테스트하기 위해서 코딩하는 내내 ‘이건 왜 일케 코딩했지?’ 라는 질문이 계속 쏟아졌다. ‘Python 은 글케 하면 비효율적이다’, ‘문자열 처리는 일케 하면 어케하냐?’ 식의 비난과 비판.. ㅋㅋ 물론 팁도 준다. ‘이건 이렇게 해야 더 좋아~’ 식인데, 문제는 그게 왜 좋은건지 모르면 답 없는 거지.. ㅋㅋㅋ (내가 그랬음.. ㅋㅋ 왜 글케 해야하는지 몰랐음.. ㅋㅋㅋ 그냥 면접관이 그게 좋다니까 그걸로 했지.. ㅋㅋ)

내가 봤던 외국회사에 면접에서는 전산학 알고리즘은 단 한줄도 나온적이 없다. 그렇다면 내가 그 면접에서 알고리즘을 사용한적이 없는가? 전혀 그렇지 않다. 면접관과 토론하고 문제에 어떤 문제가 있으며 조건을 어떻게 만족해야 하며 Python 이라는 언어적 특성을 살리고 이렇게 구현하면 컴퓨터의 Compute, Memory 를 적게 차지하면서도 많은 일을 하게 할 것인가? 이것을 풀어나가고 최종적인 완성품을 만든것이 모두 다 알고리즘 문제라고 보면 된다.

결국 알고리즘은 모든 것의 기본이라고 봐야 한다. 시스템 운영을 하던 개발을 하던 수많은 문제에 직면하게 되는데, 알고리즘이 없다? 자바스크립트를 배우는데 있어서 복잡 다단한 알고리즘보다는 라이브러리를 아는게 더 중요하다? 그런 다음에 수 많은 문제들을 어떻게 해결할 것인가? 라이브러리를 끼워 넣으면서 해결할 건가? 물론 이진트리, 정렬등을 다 알고 있어야 한다는 건 아니다. 그렇다 라이브러리를 많이 안다고 문제 해결 능력이 저절로 생겨나나?

시스템 운영이라는 직군에서 면접에서도 마찬가지다. 외국의 경우에 어떤 장애 발생시에 어떻게 문제를 해결했는지에서 관심이 있지 몇분만에 그것을 해결했는지에는 아무런 관심도 없다. 문제를 인식하고 니가 그 문제를 바라본 관점이 무엇인지를 설명하라고 하는데, 그 바라본 관점이란게 당연히 컴퓨터 이론을 기반으로 한 것이여야 했다. 그러다보면 당연히 컴퓨터 강의실의 토론처럼 변하는 경우가 많았다.

알고리즘이라는 말 자체가 ‘현실세계에서 발생한 문제를 컴퓨터라는 도구를 이용해서 어떻게 해결할 것인가?’ 라는 것 아닌가?

문제해결은 고사하고 검색하기 바쁨.

내가 왜 이런 글을 장황하게 쓰냐하면 SI 에서 밥벌이를 하다보니 느끼는게 많이 있었기 때문이다. 그중에 하나가 ‘문제 해결능력 없는 인간들이 너무나 많다’ 라는 거다.

내가 알고 있던 한 사람은 개발 경력만 15년정도 였는데, 그가 들고 다닌 컴퓨터에는 그가 그동안 했던 프로젝트의 소스코드들이 들어 있었다. 그는 그것을 자신이 프로젝트를 할때마다 활용한다고 자랑스럽게 이야기를 하곤 했다.

내가 보기에 그것은 자랑거리가 못된다. 그 사람은 구글를 이용한 검색을 하지 않을뿐, 자신이 했던 과거의 코드를 기반으로 모든 프로젝트를 수행하고 있는 것 뿐이다. 과거의 코드가 현 시점의 문제해결에 부합한다면 사용하는데 아무런 문제가 없겠지만 시간을 흐르고 문제해결의 관점도 바뀌는 경우가 많다.  과거의 코드를 재활용할 생각이 였다면 그것을 현시점의 문제해결에 적합한지 정도는 테스트해야 하는게 맞지만 뭐 그렇게 하는 인간을 본적이 없으니… 도대체 자신이 한 프로젝트의 소스 코드를 왜 들고 있는거냐? 그것도 이해 못할 일이다.

뭐가 문제냐? 문제 될 것은 없다. 문제는 이후에 벌어지는데, 적어도 구글이나 github 에서 따온 코드라면 적어도 그것을 이용할때에 테스트라도 한번 했어야 했다. 테스트 하는 인간 못봤다. 그냥 Copy&Paste 지.. ㅋㅋㅋ   그리고 문제 생기면 서버 안좋데.. -_-;;

구글 검색을 활용하는 것에 뭐라하는게 아니다. 활용을 잘 했으면 한다는 거다. 특히나 시스템 운영에서도 구글 검색을 많이 이용하는데, 구글 검색한 내용이 이미 10년전이나 몇년이 지난 내용들을 가져다 실무에 적용하는 인간들 적지 않다.

한국의 SI 산업에 가장 큰 문제는 문제 해결 능력이 없다는데 있다. 문제 해결 능력은 많은 프로젝트를 수행하고 경력이 많다고 쌓이는게 아니다. 문제 해결을 잘할려면 이론도 많이 알아야 하고 문제가 시사하는 관점을 정확하게 파악하고 문제 해결을 위한 기획, 설계를 잘 해야한다. 하지만 SI 산업에 그렇게 일을 하는 인간 없다고 봐야 한다.

이런 측면에서 알고리즘 논쟁은 흥미로운 것이다. 개발자만의 논쟁거리가 못된다. 알고리즘을 그져 트리, 정렬문제로만 축소해보면 답이 없다는 것이다. 그런 관점이 잘 들어난 것이 첫번째 글쓴이의 글로 보인다. 그나마 두번째 글쓴이 정도가 알고리즘의 대한 관점을 잘 제시했다고 본다.