Category: Uncategorized

AWS 를 국내 기업도 다 하고 있다고???

국내기업과 세계적인 글로벌 기업인 AWS 와 기술력 별 차이가 없다고??? 기술력에 별차이가 없다라….

AWS 의 경우 가상화기술인 Xen 에 많은 기술적인 기여를 하고 있는데, 기술력으로 별차이가 없다는 국내기업은 무엇을 하고 있나? NoSQL 로 유명한 DynamoDB 를 만들었고 MySQL 코어를 수정해 Auroa DB 를 제작.. PostgreSQL 기반으로 RedShift 도 만들었다.

기술력에 별차이가 없다는 국내 기업은 과연 무엇을 만들 수 있나?

AWS, MS가 제공하는 서비스를 제공하고 있다고?? AutoScaling 서비스를 제공하는 업체가 있는가? ALB(Application ELB) 를 제공하고 Web Console 에서 제어가 가능한가?

국내 어디 업체냐? 구경이나 해보자.. 무료 1달 이용권 같은,, 아니 있으면 저렴한 가격 결제해서 사용해 본다.. 거기 어디냐?

기사출처: ‘AWS 서버장애’에…韓클라우드 산업 “자체 글로벌 경쟁력 키워야”

[펌,수정]기업이 좋은 직원을 잃는 과정… ㄷㄷㄷㄷㄷㄷ

사원 A 입사 (9월)

사원 B 입사 (12월)

3개월 정도 차이지만 A 는 코딩자체에 흥미도 없고 프로젝트 이해력도 떨어지고 심지어 노력도 안함.

문서 제한일이 다가와서 다들 야근 할 때도 자기가 할 일은 다 하지도 않은 채 자기는 칼퇴주의라며 칼퇴.

결국 그 사람 일 다른 사람이 맡아서 하고 그러다보니 또 다른 팀원은 야근 ㅋ

B 는 코딩을 좋아하고 이해력이 좋음. 빨리 적응했고 그러다보니 출장 관련 업무도 다 함.

잦은 출장을 가게되고 조그마한 파트도 맡아서 진행. 팀장은 믿는다면서 여러 일을 더 맡김ㅋ 일이 나날이 많아짐.

이 친구도 정시퇴근을 초반에 계속 하다가 업무량이 많아지니 야근을 할 수밖에 없게됨..

2년 지났는데 A 는 여전히 일 못하지만 팀장은 그냥 쟤는 원래 못하니까 라고 놔둠.

B 는 업무량 다 못채우면 믿었는데 어떻게 그럴수 있냐며 서운함을 표함 ㅋㅋㅋㅋㅋㅋ

B 에게 조기진급으로 대리를 달아주겠다고 호언장담 하더니 윗선(임원)에서 아직 이르다고 거절먹음ㅋㅋ

연봉자체를 공개하면 안되는데 회사에서 올해는 공평하게도 연봉을 모두 5% 씩 올려주겠다고 공표함ㅋㅋ

B 는 좆같네 하면서 기업 퇴사하고 카카오 감…

A 는 5% 좆같네 하면서 다른 기업 갔다가 적응 못하고 (거긴 못한다고 안봐주나보지 ㅋ) 거기도 퇴사하고 돌아오겠다지만

받아주지 않음 절대 ㅋ

실화입니다. 기업이 좆같은 이유는 인재관리도 좆같이해서 그렇습니다.

http://www.ddanzi.com/free/539055230


실제로 내가 사회생활을 시작하면서 지금까지 거의 한평생을 겪었던 일이다. 나는 컴퓨터를 다루는걸 좋아한다. 다른게 있다면 엔지니어가 됐다는 것 뿐이다.

대학때부터도 그랬고 지금도 그렇지만 Linux 를 다루는걸 좋아라했고 자연스럽게 OpenSource 프로그램들을 주로 다루게 되었다. 그리고 인터넷을 움직이게하는 필수 프로그램들에 대해서도 경험을 쌓게됐다. 심지여 DB 까지 어느정도 다뤘으니까.

이력서를 내놓으면 여기저기서 연락이 온다. 그것도 그냥 오는게 아니라 자주 온다. 그러면서 다음과 같이 말한다.

꼭 찾던 인물이다. 함게 했으면 좋겠다.

그리고 입사를 하면 혼자서 Web Server, Was Server, System Monitoring 까지 하는건 좋다. 그런데 DB 작업(설치, Replica, 업그레이드), WAS Memory leak 분석, 프로그램상의 오류를 디버깅하라고 한다. 서버에서 오류가 났으니 그걸 분석하다보면 결국에는 Java 프로그램상의 오류가 대부분이다.

이렇게 일하면서 연봉을 많이 받느냐? DBA 가 있음에도 그 사람은 다음과 같이 당당하게 말한다.

MySQL 설치, Replica, 업그레이드를 해본적이 없어요. Toad 열고 쿼리 작업만 해봤습니다.

한국 SI 산업의 가장큰 병폐가 이런것이다. 경력 13년차를 뽑아놓고 보면 ‘안해봐서 모른다’ 라는 답변하는 하는 사람들이 많다. 하지만 정작 ‘안해봤지만 MySQL 도 DB 니까 대충 이론은 같을 거고 사용법을 익히면 될거 같다’ 라는 말을 하는 인간은 못봤다.

의지를 안가지는 자들 vs 해보겠다는 의지를 보이는 자들

정확하게 저렇게 나뉜다. 많은 프로젝트를 돌아다니다보면 저런 인간들로 다 분류 된다. 자신이 하는 일 외에는 안한다고 하지만 앞서말한 DBA 처럼 자신이 하는 일조차도 자기 스스로가 결정한 영역일 뿐이다.

하지만 해보겠다고 의지를 보이는 자들은 자신이 하는 일에 대한 영역이 산업계에서 요구하는 영역과 일치하는 경우가 많다.

문제는 저렇게 두분류의 사람을 함께 일하게하면 기업들은 결국에는 의지를 가지고 있는 사람에게만 일을 준다. 그렇다고 의지를 안가지는 사람을 자르거나 뭐라하거나 하지도 않는다.  그리고 결정적으로는 둘다 필요한 사람들이라고 하고 대우를 똑같이 한다.

오히려 ‘뭔 불만이 그리 많냐’, ‘너는 일 쉽게 할 수 있지 않냐?’ 이런 답변으로 더 일을 시킬려고 든다.

의지를 가지고 일을 하지 않는 자들이 같은일을 반복하는 것에 최적화된 자들이 변화하는 뭔가에 대응하고 아이디어를 내서 오래된 시스템을 바꾸는 일은 없다. 그냥 월급루팡에 최적화된 프로젝트만 남는거지..

 

다얼유 LK158 블루투스 겸용 LED 기계식 키보드

USB와 블루투스를 함께 지원하는 텐키리스 기계식 키보드가 필요했는데, 다얼유 에서 출시해서 구매하게 되었다.

다얼유 LK158 블루투스 겸용 LED 기계식 키보드

이 키보드는 맥(Mac) 도 지원한다. 맥을 지원한다는 것은 맥에서 사용가능한 펑션키가 있다는 것이며 이는 편리성을 제공한다는 것이다.

내가 구매한 모델은 적축 모델이다. 다음은 블루투스 설정방법을 스크랩한 것이다.

블루투스모드, 유선모드 전환

다얼유 블루투스-USB 전환

블루투스 멀티페어링 전환

다얼유 멀티 페어링

 

블루투스 페어링 방법

다얼유 페어링 방법

LED 효과

다얼유 LED 효과
사용 후기

집에서 아주 만족해 하면서 사용하고 있다.  집에서는 Windows 10 에는 USB 로 연결하고 Mac Mini 를 블루투스로 연결해서 사용하고 있다. 하나의 키보드로 두개의 OS를 번갈아가면서 사용할 수 있어 너무 편하다. 특히나 맥용 키보드 맵핑이 되어 있어서 별도의 노력없이 바로 사용이 가능하다.

거기다 적축이라서 키압도 그리 높지도 않고 사무실에서 사용도 가능할 정도로 소리가 없다.

 

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

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

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

거의 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 를 사용하는 것이 좋다.