반응형

그냥 반말로 하는 것 이해해줘...디씨잖아..

오늘도 시스템 작업 하고 있거든... 큰놈 하나 돌려놓고 모니터링하다가 지겨워서 여기다 글써...

사실 엔터프라이즈 레벨에서 프로그래머.. 그것도 아키텍트 레벨이 아닌 그냥 어플리케이션 프로그래머는 고급기술이 많이 필요하지 않아.

좀 실력있는 놈이 프레임웍 하나 잘 만들면 그냥 붙여넣기지..

처음부터 DBA일을 한게 아니고 처음에는 남들처럼 비베나 델파이 이런것 갖고 놀다가 파빌하다가 때로는 알피지도 하고 코볼도하고... 나중에는 자바도 작업하고 이것저것 유행인 아키텍쳐 갖고 놀다가 어찌어찌 하다보니 남보다 디비좀 잘안다고 DBA일 시작했거든. 그래도 어디 좀 DB쪽에 내공을 가진 컨설팅 업체하고 맞짱뜨는데는 그다지 무리는 없어. 뭐 그래도 그들이 더 고수야. 한 사이트에 묻혀 사는 놈하고 필드를 돌아다니면서 다양한 레퍼런스를 가진 놈하고 아무래도 다르지.
그렇지만 온리 디비만 알고 있는 친구들보다 여러모로 좀 편하더라구.

어플리케이션이 사실 비즈니스별로 특성이 워낙 다양하잖아. 엔터프라이즈급이라고 해도 그냥 전표처리 시스템이 있고, 똑같은 시스템이라고 해도 클라이언트가 몇대냐에 따라서 전혀 다른 내공이 필요하고...

그래도 십여년 넘은 짬밥으로 대충 얘기하자면...
아무리 아키텍쳐가 예뻐도 프레임웍이 개판이면 쓰레기 되는 거구 프레임웍이 아무리 예뻐도 성능 고려안하면 쓰레기 되는 것 순식간이야.
나도 처음에 자바보고 참 코드 예쁘다 그런 생각 많이 했거든. 뭐 CDB가 좋다, MVC모델이 어떻다 말을 많이 하는데 참 예뻐. 그런 아키텍쳐 말야.
그런데 실제로 밥벌이 하려다 보면 성능 빼고는 생각할 수 없어. 그런데 요즘 엔터프라이즈에서 대세는 웹이잖아.

DBA랍시고 성능튜닝한다고 사이트 헤집고 돌아다니면 참 답답할 때가 많아.
어쩔 때는 EJB도 다 들어내고, 그냥 JSP로 짜라고 권할 때도 있고(사실 DBA가 이렇게 말하는 건 오버야. 나와바리를 침해하는거지. 실력이 있든 없든 개발자들이 기분 나빠하고 그게 정상이야. 그걸 극복하려면 DB만 아는게 아니라 어느정도 자바같은 어플리케이션 프레임웍도 나름대로 내공을 쌓아야 해. 최소한 서로 말이 통할 수 있을 정도로 말야) 어쩔때는 콘트롤러를 프로시져로 모두 올려버릴 때도 있고...
사실 제일 답답한 것은 SQL이야. 개발자들이 그렇게 머리가 나쁜 편은 아니거든.
필드에서 그럭저럭 밥값하는 개발자들치고 머리나쁜 놈 없어. 하지만 시간에 쫓기고 월급도 못받고 그러다보면 대충대충 테스트할 때나 제대로 나올정도로만 짜지. 뭐 이해해. 그렇지만 기능테스트 통과하고 성능테스트도 그럭저럭 통과해도 오픈하는 순간 뻣는 시스템들이 아직도 숱하게 많아.

그런데서 고수대접받고 다음 프로젝트에 이름 지명받아가며 일하는 놈들도 있어. 이런 놈들이 다른 애들보다 실력이 정말 탁월하게 뛰어나냐하면.. 사실 코딩 레벨에서는 별차이 없어. 왜냐고? 앞에서 말했지만 엔터프라이즈급의 비즈니스 어플리케이션이라는게 그렇게 고급 코딩 기술이 필요없거든.
그런데 이런 애들은 아키텍쳐나 프레임웍 레벨에서는 좀 틀려.. 쉽게 말해서 나무만 보는게 아니라 숲을 보거든.
화면 하나 짜도 대충 만들면 금방 예쁘게 나올 수 있는 것도 어떻게 하면 이런 화면 여러개 만들 때 쉽게 만들까 고민하고 짜거든. 즉, 화면을 만드는게 아니라 연탄공장을 만들 생각을 해. 화면은 연탄공장에서 찍어내면 된다 이거지... 이런 짓 몇번 하다 보니 나름대로 라이브러리도 갖고 있고 노하우도 좋아. 사실 여기서 실력이 판가름나.
예를 들면 이런거야.
기업용 비즈니스 화면이라는게 사실 패턴이 몇개 안되. 크게는 입력화면과 조회화면 두개고 그게 몇가지 UI타입에 따라서 패턴이 서너개로 분류되거든. 혹시라도 해본 사람은 기억 더듬어봐. 포지션이 다를 뿐이지 기능적으로는 유사한 놈이 많거든. 이런 놈들은 이런 걸 패턴화해서 연탄공장으로 만드는거야. 그리고 그냥 연탄공장 찍어내는거지.
그런데 이렇게 하면 갑이란 놈이 불만이거든. 이렇게도 해보고 싶고, 저렇게도 해보고 싶고... 처음에는 요구사항이라는 것이 별것 없다가도 프로젝트 진행하다보면 눈높이가 높아져서 요구사항도 장난 아니게 변하거든.
얘네들은 이런 걸 잘 콘트롤해. 갑이 깡패긴 하지만 잘 구워삶아서 패턴에 맞게 요구사항을 바꿔버리거든.
그러니 PM이 이런 애들 얼마나 귀여워 하겠어.
그리고 정말 어려운 콘트롤이 몇개 있어. 진짜 고수는 직접 해결하지만 그렇지 않은 애들이라고 해도 해결할 수 있는 네트웍이 있어. 뭐 그러면서 자기걸로 만드는거지.
내가 자바 프로젝트와 DBA일 하면서 벌써 7~8년 지났는데 그와중에 거의 이런 일만 프로젝트 옮겨 가면서 하는 친구가 몇 있거든. 이친구들은 연봉이 일억이야. 하지만 스스로 인정하듯이 그렇게 코딩 실력이 뛰어난 편은 아냐. 단지 속도는 빨라. 하지만 아웃풋은 그냥 평범한 코더 수준이야. 이해하기도 쉽고...
그리고 얘네들 입김 때문에 개발업체가 달라져. 그정도로 파워를 발휘해.
어떻게 보면 사실상의 아키텍트지.

그리고 이친구들의 특징이 뭐냐하면 SQL을 아주 잘짜. 그래서 성능이 좋아. 이 친구들과 딱한번 붙은 적이 있는데 게시판때문이야.
게시판이 별것 아닌 것 처럼 보이지만 사실 이거 DB입장에서는 굉장히 어려운 분야거든. 얘기하자면 길어지니까 딱 두개만 말하면 lock하고 wait 문제야. 평범한 테이블 구조로는 그냥 몇백명이 쓰는 게시판은 별문제 없지만 동시사용자가 천단위를 넘어가면 심각한 장애를 불러오거든.
프로그램이야 능력껏 발휘하면 되지만 DB는 만든 걸 쓰잖아? 아무리 성능좋은 DB라고 해도, 아무리 메모리나 씨퓨가 빵빵해도 이부분은 평범한 설계로는 해결 못해.
거기다가 단일한 게시판이 아니라 하나의 테이블에 카테고리나 권한 문제까지 복합되면 상황은 더 악화되지. 하지만 모델 입장에선는 이런 설계를 굉장히 좋아해. 한방에 여러개를 해결할 수 있는 그런 모델이거든.

개발자와 모델러, DBA가 셋이 붙었어. 사실 개발자의 프로그램이 나쁜 것도 아니고 모델이 안좋은 것도 아냐. 단지 그런 모델, 그런 코드로는 어느 볼륨 이상이 될 경우 발생하는 지체현상을 막지 못할 뿐이지.
얘네들은 그걸 이해해줘. 평범한 개발자는 입이 한발이나 나오고 코드 다 뜯어고쳐야 한다는데 불만이지만 얘네들은 그런 비즈니스 리퀘스트를 이해하고 더 좋은 대안을 찾아주거든. 그리고 밤새서 고치고 테스트하지.

솔직히 이런 애들이 개발자라면 안이뻐할 PM어디있겠어?
현업들도 좋아하지.

그리고 얘네들이 몇년 짬밥 차니까 비즈니스를 이해하는거야. 일반적인 개발자라면 그냥 요구사항에 맞춰서 코딩하잖아? 얘네들은 안그래.. 현업의 비즈니스를 아니까 오히려 역공을 해. 그리고 처음 하는 비즈니스라고 하더라도 아키텍쳐나 프레임웍을 얘기하기전에 비즈니스를 얘기해.  그리고 그걸 공부하고 그다음에 개발이야. 이거 기업시스템에서는 굉장히 중요하거든.

나도 PM할때 신규 개발자 인터뷰하면 개발경력보고 그쪽 관련 질문을 해. 아무리 회계시스템 짜본 놈이라고 해도 예전과 달리 워낙 업이 분화가 되어 있다 보니 그냥 UI나 개발하다 온 놈이 많거든.
요즘은 PM하고 나하고 같이 들어가. 왜냐하면 단순 코더가 아니라 SQL에 대한 능력치도 중요하고 비즈니스도 굉장히 중요하거든. 그러다 보니 같이 인터뷰하면 사실 30분 정도면 대충 밑천이 파악되거든.

여기 게시판 보다 보니까 많은 얘기가 있는데... 뭐 난 게임쪽은 잘 몰라. DB만 가지고 다룬다면 얘기해줄 수 있겠지만 자바나 닷넷도 그냥 중간이나 중하수준이고 씨같은 것은 다 잊어 먹었어. 비즈니스 어플리케이션에서 씨로 할일이 많지 않거든. 몇몇 리얼타임으로 NONDB 데이터 통신할 때나 좀 필요하니까... 그건 정말 돈주고 전문업체 부르면 되거든. 그리고 비즈니스에 3D게임 만드는 능력이 필요한 것도 아니고... 그리고 이정도 아는 것도 예전에 개발한 짬밥하고, 이정도는 알아야 개발자와 얘기가 되니까 배운 정도야. 뭐 사실 DBA가 이정도 알면 되지 뭐 그이상 알려면 개발로 보직 바꿔야지 뭐.

아마도 구인사이트 가면 대부분 SI쪽 인력을 많이 모집할거야. 이쪽이 3D이긴 해. 말도안되는 프로젝트를 밤새서 하고 월급도 작고 가끔은 업체가 넘어져서 월급도 못받고... 그래도 선수는 있거든.

내가 아는 분야만 얘기해서 그런데...
혹시라도 SI쪽에 관심이 많다면... 상업부기 정도는 이해하는게 좋아. 만약 원가쪽에 대해서 제대로 공부한 친구라면 장담하는데 이쪽방면에서 신입으로는 거의 패스야. 농담아냐. 아까 말했잖아 SI쪽에서는 높은 수준의 언어 구사력이 필요없어. 90%이상은 정말 학원에서 서너달 공부한 수준이면 되. 하지만 비즈니스는 그게 아니거든.
SI쪽에 입사하고 싶다면 한번 경리학원같은데 서너달 다녀봐. 그리고 입사할 때 개발능력이상으로 비즈니스를 이해하기 위해 공부했다고 한마디만 해봐. 장담하는데 100%야. 그리고 고참한테 귀여움 받을거야. 현업에게는 쟤는 좀 경험있는 놈이다 라고 인식할 테고. 어차피 현업은 코드볼줄 모르잖아. 작은 하우스 같은데는 신입이라고 해도 명함은 대리 줄거야.
그리고 말야. 더 어필하고 싶다면 SQL공부 제대로 해봐. 경력 3~5년 된 개발자들도 SQL제대로 구사못하는 애들 굉장히 많거든.
극단적으로 말해서 잘 프레임웍된 프로젝트에서는 SQL구사능력이 핵심이야.
고참하고 신삥하고 차이가 뭔지 알아? 언어 구사능력이 아냐. 오히려 요즘은 신입이 더 언어능력이 좋을 때가 많아. 하지만 고참을 선호하는 것은 엔터프라이즈 프로젝트에서는 시스템을 만드는 거지 화면 하나 만드는게 아니기 때문이고, 그 시스템은 만든놈이 쓰는 게 아니라 돈준 놈이 쓰는 것이기 때문이야.

내가 만일 지금 신입으로 돌아간다면 자바나 뭐 이런 것은 중간정도만 하고 나머지 시간에는 앞에서 말한 경리/회계/원가 공부하고 SQL공부를 할거야. 근데 OCP는 안중요하거든. 우리 회사에서는 OCP가 뭐냐면 OCB야. "오라클 인증 비기너"라고 말야. 나도 OCP자격증 없거든. 내가 외국갈 것도 아니고... 설사 외국간다 하더라도 영어가 문제가 될지언정 자격증이 문제된적은 없어. (농담아냐 심지어 한국 오라클도 OCP자격증은 안봐) 내가 있는 전산실에 OCP 가진 놈이 한 1/3되. (전체 인원이 2백명 정도 되거든)

내가 하고 싶은 말은 다른게 아냐.
학원이나 학교에서 가르쳐 주는 것은 누구나 다 해. 하지만 신입을 뽑고 싶다면 그보다 한두가지가 더 필요하거든. 혹시라도 가고 싶은데가 있다면 거기에 맞는 것을 채워놔봐. 요즘 웬만한 규모의 업체에서는 OCP있어봐야 덤프보고 딴거라고 인정도 잘 안해. 차라리 자기소개서에 기업전산능력을 갖추기 위해 경리공부도 하고 SQL을 별도로 공부해서 나름대로 잘할 수 있다라고 써봐. 농담아니라 분명 물어볼거구 거기서 어필하면 패스는 장담해. 물론 이건 SI쪽 얘기야. 그리고 그룹으로 뽑는 데 말고 단일 회사 전산실이나 SI업체에서 직접 채용하는데라면 장담해. 이거 100%야.
어차피 신입들은 나름대로 개발언어 공부좀 할거아냐? SI짬밥 있는 간부들은 JAVA든 닷넷이든 "그까이꺼"하거든. 왜냐하면 워낙 레퍼런스도 많고 탄탄한 실력자도 있기 때문에 신입들에게 별로 기대 안하거든.
극단적으로 말해서 신입들은 프로젝트 투입해서 파워포인트 작성 잘하고 회의록 작성 잘하는 것만으로도 만족하는 경우도 많아. 그리고 나중에 구현단계 가서 화면이나 몇개 던져주면 시키는데로 코딩만 잘하면 되지. 거기서 거기거든.

하지만 그들에게도 벽이 있는게 어떤 비즈니스도 현업보다 잘 알 수 없다는거지.

혹시라도 SI쪽에 도전하고 싶다면 한번 해봐. 웰빙하고 거리가 많지만 그래도 나름대로 일가를 이룰 수 있는데거든. 하지만 정말로 자신은 프로그램 개발의 고수가 되고 싶다면 SI는 좀 거리가 있지. 프로젝트의 고수가 되고 싶다면 도전해볼만 해. 시스템 개발은 단지 언어 잘짠다고 되는게 아니거든.


ps.수학얘기가 나와서 그런데 기업시스템에서 수학은 정말 사칙연산정도면 되. 하지만 조금 깊이 들어가면 통계학은 꼭 필요하더라. 하다못해 산술평균과 기하평균정도는 구분할정도는 되야 뭐 답이 나오더라구. 그렇다고 아주 깊이있게 필요한 것은 아냐.
ps.그리고 원가회계를 잘하면 ERP쪽으로도 진출 가능해. SAP나 오라클 어플리케이션 같은 것 솔직히 학원에서 돈주고 배우려면 졸라 비싸잖아? 그런데 ERP컨설팅 쪽은 기본을 중시하거든. 내가 왜 이런 얘기하냐면 나도 초기에 원가쪽 개발을 주로 했어.MRP에서 원가쪽 말야. 뭐 제조나 금융,유통 이 모두 원가 개념이 많이 틀리지만 본질은 같거든. 예전 부터 생각하는게 SI쪽은 전산쪽보다 경상계열 쪽이 더 적성이 맞을 것 같아. 특히 ERP쪽은 말야...

출처 : 디씨 프겔 - 단무지


반응형

'DB' 카테고리의 다른 글

DB개발툴종류가 무엇이며 장단점은 뭔가요?  (0) 2007.06.27
튜플(Tuple), 트랜잭션(Transaction) 정의  (0) 2007.03.20
후보 키  (0) 2007.03.14
Posted by Real_G