[카테고리:] Oh! 반면교사

프로그래머가 돈 많이 버는 방법은 상속이라고 하죠….

흠흠….

기존 클래스로부터 속성이랑 동작 이어받아서 다양하게 이용하고자 하는 것은 좋아. 그래 그러려고 클래스 쓰고 하는 거니깐…

근데 지금 부모 클래스에 자식 클래스 재정의하면 그게 부모 하는 일 그대로 한다고 착각하냐?! 지 스스로 전혀 다른 코드 짜놓으려고 여러 시도 다 해놨으면서 정작 중요한 녀석은 그냥 그대로 갖다쓰고 있고….

아우 썅….

아무리 대학교 중간고사 시험때 리스코프 원칙 같은 거 출제하고 해봐야 뭔 소용있어! 지들이 실제로 그렇게 안쓰는데!!!

죽음의 다이아몬드? 썅 그런 거 이전에 상속 숫자나 적당히 줄이라고! 상속 미친듯이 누가 4~5번씩 당연하게 때려박으래!!! 게다가 위에 클래스들 보면 어디서 쓰는 곳도 없어! (7번 넘게 한 S모군보단 니가 낫..긴 개뿔… 그래도 S모군은 유명해져서 강의뛰고 신자도 생겼더라. ㅡㅅㅡ)

게다가 중요하게 자식이 똑같이 써야 하는 함수들은 죄다 private 남용….

그러면서 안에서 새로 수식 계산을 또 하고 있어…

그러면서 부모 상속하면서 똑같이 쓰는 거라고는 디비에서 불러오는 키값 딱 하나….

……아 발암걸린다 진짜….ㅠㅠ

그래서 자식은 아예 그냥 이거 기반으로 새로 구현하는 게 낫겠다 싶어서 새로 구현함… 그게 더 빠르고 쉽게 해결됨.

코드 꼬아쓰다가 별 쑈를 다하는듯 하다 진짜…

여기에 하나 더.

이렇게 부모 코드 죄다 끌어쓰지도 못하는 거면 불러와서도 문제인 거 당연한 거 아닌가요라고 묻겠죠….

그렇게 해서 만들어지지 못한 값들….

죄다 null 체크로 해결하고 있었습니다. 그리고 이전 글에서 적었듯… null도 제대로 처리 못하는 친구입니다.

가만 보면 뭐 알고쓰는 것도 아님….

오씨…. 대단한 녀석입니다….

나보다 나이도 많다는데… 이런 실력으로 뭐하고 살려고요?

Create(생성), Read(읽기), Update(갱신), Delete(삭제)

….제일 간단한 일이다.

사실 데이터를 요구대로 만들어내서, 그걸 그대로 저장하고, 그걸 그대로 읽고, 그리고 저장한 내용 업글하고….

가장 간단한 프로그램의 가장 단순한 원칙이다만….

그리고 그걸 위해서 파일 시스템을 쓰던, 데이터베이스를 쓰던, 블록체인을 쓰던 하는 건데….

데이터 하나 그냥 그대로 저장하고 불러오고 하는 짓을 못하는데….!!!!!!!!

변수값을 저장했다가 필요할 때 그 변수값 불러서 일일이 계산해서 화면에 뿌리는 걸 CRUD 해놨다고 지랄해놨어…

게다가 화면마다 계산하는 방식이 달라서 똑같은 값 불러다가 똑같은 거 보여주는 곳들인데도 화면마다 작성한 코드 공식이 죄다 달라….

그것도 돈 계산하는 프로그램이…!!!!

하 미친…..

내가 진짜로 오씨 프로그래머로 인정 안하는 부분이다.

소스코드 짜는 데 기교부리는 것만 배웠다고 욕쳐먹는 큰 이유 중 하나… (앞으로도 쓸 글 많다…)

이런 놈이 미국에서 프로그래머로 일하려고 할 때에도 한국에서 경력있다고 하는 짓거리도 하고… 이런 놈이 한국으로 쫓겨날(…) 때에도 미국에서 경력 있었다고 지껄이겠지….

하 나 진짜…..

어려운 거 이야기 하는 것, 어려운 거 요구하는 코드도 아니었을텐데….

내 노가다의 이유 중 하나가 이딴 코드라는 것이 싫다 진짜….

p.s. 정말 어려운 버그도 있었지만… 솔직히 이런 것들이 더 열받는다…

null값 자체에 대해서는 뭐… 생길 수 있는 값이다. 당연한 거다. 특히 C 프로그래밍을 주로 하는 내가 포인터 초기화 할 때부터 null 쓰는 건 당연한 건데….

근데 문제는….

1. 숨었다가 튀어나오는 null
   코드 디자인 할 때에 생성자쪽에다가 필요한 변수는 마구잡이로 때려놓으면서 정작 쓰진 않아서 죄다 null 쓰면서 선언하게 만드는 이상한 클래스들이 너무 많다… 이건 전적으로 오씨의 설계 실력.
   
2. 대량의 null
   필요한 클래스, 인터페이스, 추상 클래스들을 막 만들어서 내 딴에는 구조 잘 잡았어! 하고 시작했겠지 하면서 상속의 상속의 상속의 상속의 상속을 반복하니 그냥 필요하다 싶어서 하나 둘 내부 값들이 막 많이 만들고 신나게 써먹으려고 해놨는데….
   
   정작 재사용은 할 필요도 없이 걍 하나하나 따로 구현해야 하는 형식인데 아냐! 코드 재사용 할꺼야! 뿌뿌! 하면서 억지로 끼워 넣으려니 자연스럽게 대량의 null을 만들고 있음. 그리고 잊지 말자. 앞 문단에 적은 상속의 숫자를… 도중에 꼬이면 이상한 값 튀어나오기 일쑤다.
   
3. null체크 없는 코드
   지딴에 필요한 값 제외하고는 null 체크를 안해놨다가 나중에 기능 늘리려 하면 null 에러가 뜨는데 1,2번 문제로 인해서 어디서 튀어나오는지는 모르고 하니 그냥 “못해요!” 하고 던진 케이스…
   
   이거 때문에 새로운 기능 넣는 데 개고생한다. 근데 문제는 기존에 설꼐에는 있던 기능을 만들려고 하는데 그때를 위해 만든 디비 테이블하고는 또 호환이 안맞아서 그냥 null값으로 때려박혀진 필드들도 있…. 이게 다시 1,2번의 null로 만들어진다.
   
4. null과 0을 똑같은 걸로 생각하고 짠 코드가 있다.
   ………….구라같죠? 이게 경력 있다던 개발자가 짰다고 생각이 될 거 같으냐…?! 앙! (버럭!)

……..후…..

…..적고 나니 혈압 올라서 일단 스톱. ㅡㅅㅡ

참 오랜만에 글을 남깁니다. 우리의 이 망할 반면교사 오씨….

회사 일 외에도 요즘 강의자료 만드는 걸 좀 도와달라고 해서 그거 좀 같이 해주고 있다가 오랜만에 글쓰네요….ㅠㅠ 시작할께요.

오씨의 코드에서는 여러 치명적인 단점들이 엄청나게 있는데… 오늘은 코드 쪼개기, 모듈화에 대해서 이야기를 하려고 한다. 제대로 병신같은 형태로 과도하게 쪼개고 이상한 형태로 모아두면서 재사용성 강조한다면서 해놓은 짓이….

본인 스스로의 가독성을 떨어뜨려서 어디다가 구현했는지도 모르고 어떻게 수정해야 되는지도 모른다는 것이 말이 되냐?!!!?!!?!?!?

이런 쓰레기 구조를 일주일만에 싹 다 정리했다만… 여전히 이해는 안되는 코드 구조였다. 아니, 구조 설계 자체를 아예 못하는 놈이다.

근데 이 내용에 대해서는 욕은 최대한 삼가려고 한다. 왜냐면 이 오씨는 expert beginner, 즉 초심자라고 생각하면 아주 정확하게 납득되는 실수를 했기 때문이다. 그러니 어딘가에서 이 글 보고 내 이야기인가 하고 찔리는 분이 있다면 경력자라고 나대지 마시길 제발….

객체지향 좀 배우고 과제용으로 코드 좀 짜고 하다보면 이제 코드 짜는 양이 제법 좀 많아지게 된다. 그렇게 되면서 많은 사람들이 코드 설계에 대한 이야기나 디자인 패턴, 그리고 클린 코드 관련된 내용들을 열심히 공부하는데…. 문제는 이걸 제대로 적용하는 법에 대해서 계속 생각하고 계속 연구해야 하는데 그걸 안한다. 왜 안할까? 공부를 중간에 끊어서? 설마… 그런 식으로 해서 살아남는 프로그래머가 얼마나 된다고요….ㅡㅅㅡ

저 내용들에 대해서 가르치려고 적어놓은 책들도 첨에 가르치는 내용들은 심플하다. 이렇게 해라 이렇게 해라라는 내용들이 사실 명확하게 되어 있다. 하지만 그 후에 나오는 내용들은 상당히 추상적이다. 왜냐면 프로그래밍 언어론이나 방법론 관련되어 나오는 이야기들이 상당히 추상적인 내용들이고 그걸 이해하는 추상적 사람들의 이야기를 그나마 구체화해놓은 게 우리가 보는 책들이기 때문이다. 그래서 솔직히 머릿속에 바로 안그려지고…. 그게 정상입니다.

정의는 상당히 간단한 내용들이다. 일전에 강의자료들 만들어주는 작업 하다가 나왔던 내용들인데 그 중에서 기억 남는 것들만 좀 적어보자면 “특정 목적을 달성하는 방법은 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다. 명확하며 최소로 줄였다. 때로는 명확하게 드러내기 어려우므로 언어에 따라 문학적 표현도 필요하다” (실용주의 프로그래머인가…? 기억나는대로만 적었다..), “깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.” (이건 아마 객체지향 대가인 그래디 부티씨 말일껍니다.), “깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 아마 모든 사항을 고려했으므로 고칠 궁리를 하다보면 언제나 제자리로 돌아온다.” (이건 마이클 페더즈씨의 책이었는데… working effectively with legacy code인가 하던 책이었을 겁니다.), “중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기. 내게는 이 세 가지가 깨끗한 코드를 만드는 비결이다.” (이건 최근에 자료 참고용으로 뭐 있나 봤던 extreme programming installed에서 봤었습니다.) 등등 여러 자료들에서 많이 말 합니다…

내용 보면 참 추상적입니다. 그리고 이분들의 책들 또한 엄청나게 추상적이죠. 그리고 이걸로 학창시절에 머리 좀 싸메는데…. 다들 골때리는 상황들이 벌어집니다.

강의때 들은 내용하고 그 내용에 나온 예시대로 열심히 암기 잘 하고 이해 잘 하고 해서 난 A+도 받았었던 인간인데 왜 실무에서 개고생을 하는거지? 경험이 없어서? 삽질 안해도 우리는 충분히 요구를 이상화 할 수 있는데? 라고 생각하실 수 있겠죠….

근데 죄송하지만 현실의 어느 시스템도 이상적인 방식으로 개발되지 않고, 앞으로도 이상적인 것에 정확하게 맞아 떨어지는 시스템은 없을 겁니다.

심지어 여러분이 열심히 학창시절에 보시고 보신 교과서나 논문에 적힌 프로그램들조차도 이상화에만 매달린 코드입니다. 이상적인 내용에 대해서 계속 개선되고 그에 맞게 수정되는 과정을 처리면서 저자가 바라는 바를 보여주는 좋은 예시, 좋은 설명, 좋은 이해방법이 들어있지 현실적으로 어떤 걸 어떻게 개발해야 할지도 그리고 그에 따른 어떠한 과정도 보여주지 않습니다.

즉, 인생은 실전이다입니다!!!!

그래서 여려모로 노력해서 자신만의 노하우, 아니면 자기 팀만의, 자기 회사만의 노하우들이 공유되고 하면서 발전하는 것입니다. (그래서 오픈소스들이 대단한 것이죠.)

이게 코드 개발하면서 벌어지는 코드 구조에도 솔직히 엄청난 영향을 줍니다. 그 중에서도 코드 분량을 줄이고 재사용을 잘 하기 위해서 여러모로 쪼개놓는데….

어디서는 단 한번만 쓰이고 버려지는 코드까지도 쪼개놓습니다! 그리고 그걸 뒤지는 데 몇십단계를 거쳐야지만 겨우 찾습니다!! 근데 아무 동작도 안하는 쓸데없는 녀석입니다!!! 필요없어서 지워버리니깐 다른 곳에서도 쓰인다는 걸 확인합니다!!!!! 다른 코드들도 싹 다 건드립니다!!!!!!!! 그리고 또 다른 곳에서 터집니다!!!!!!!! (반복)

이 짓 땜에 쓸데없이 만들어놓기만 했는데 정작 기능에는 아예 쓰이지 않는 클래스, 인터페이스들만 해서 300개가 넘었습니다. ㅡㅅㅡ

이쯤되면 미친거죠.

저걸 싹 다 고쳐서 정리하느라 3일을 버렸습니다. 근데 진짜 저것들 없어도 본 기능에 아무 문제도 없습니다.

그리고 프레임워크, 라이브러리, API에서 표준으로 제공해주는 걸 최소한으로 이용해 보겠답시고 본인만의 코드들을 중간에 막 집어넣는데 이것도 또 쪼개고 쪼갰는데….

문제는 이 쪼개고 쪼갠 것들이 싹 다 꼬였습니다. ㅡㅅㅡ 이것들도 고칠만큼 고쳤는데… 나머진 진짜 시간이 진득하게 필요합니다.

그리고 이렇게 쪼개고 쪼갠 녀석들은 해당 기능에 대한 단위 테스트를 할 수 있어야 하는데… 쪼갠 녀석들이 결합도는 절차지향의 대명사인 C 코드 저리가라 할 정도로 강합니다. (…..)

그러니 밑에서 오류가 나서 이상을 하나 수정하면 그 위에 이상도 수정해야 되는 루프의 만남이….

미친겁니다.

전 팩토리, IoC, DI를 써보겠답시고 코드에 덕지덕지 썼으면서도 이런 분리 제대로 안되면서 파일하고 디렉터리만 몇십개 단위로 쓸데없이 쪼개서 코드 만들어내는 오씨한테 진짜 깊은 빡침과 깊은 반면교사를 배웠습니다.

설계 제대로 된 코드 정말 중요한 코드입니다…. 설계 아예 안된 코드보단 좋아요….

회사에서 코드로 협박하고 하던 녀석이 이런 걸로 협박을 하는 거였나요……

하 진짜….

뭐… 이 친구의 뭣같은 이야기도 조금씩 쓰다보니 뭐 여러모로 많다만…. 이건 좀 아주 제대로 초짜짓을 해놓고 나간지라 맘 속 깊이 우러나는 맘으로 욕을 적고 시작한다.

코드 재사용… 좋은 이야기다. OOP 배우면서 누구나 다 들은 이야기이다. 맞는 이야기이기도 하고… 근데 이놈의 코드 재사용 관련된 이야기로 내 개발자 인생에서 미친듯이 욕을 하는 인간이 둘이 있는데, 지금 글쓰는 반면교사 녀석이랑 커스텀 컨트롤러 개발하면서 여러 관련된 컨트롤을 전부 상속 7번을 해서 7개의 각각의 컨트롤을 만들었는데, 중간에 이상한 논리로 만들어서 3번째 이하의 모든 컨트롤러들이 다 꼬였는데 전체적인 디자인상으로 맞는 코드인데 오류가 난다고 나한테 박박 우겨먹다가 나랑 대판 싸웠던 S군이 있다. (S군은 내가 온라인으로는 이번에 처음 이야기한다. 오프라인 사석에 있을 때 어쩌다가 연관된 이야기 나오면 이야기 많이 하는 편이다. 근데 이 친구 아이러니하게도 한국에선 지금 유명한 개발자 중 하나다.)

개발하면서 새로운 클래스나 커스텀한 클래스들을 만들어서 이용하는 경우가 많이 있다. 당연한 것이기도 하다. 근데 이게 분석상에 여러모로 문제가 있어서 제대로 된 재사용 가능한 코드를 만들어내지 못하는 경우가 많다.

이 오씨 친구의 경우에는 그냥 한 화면에 하나의 테이블 구조만 가지고 이용하면서 CRUD를 할 것이니깐, 이 테이블을 간단하게 보여주면서 CRUD의 서브 동작을 하는 하는 Detail 도큐먼트, 딱 두개만 이용하는 구조로 프로그램 뷰 모델 구조를 짜면 되겠지? 라고 해서 프로그램을 개발했다. 실제로도 고객 정보 관리하는 곳에 고객의 정보를 간략하게 보여주는 리스트 형태의 뷰와 CRUD 동작에 필요한 테이블 내용을 보여주면서 이용할 Detail 화면이 한 쌍으로 동작한다. 그리고 다른 관리, 예를 들어 직원 관리에도 이런 식으로 작업을 했고, 아이템 관리에도 이런 식으로 작업을 했다.

문제는 다른 화면들에서는 더 이상 이런 구조로 이용되는 곳이 설계상에 한곳도 없었다. 심지어 기본적으로 이용하는 고객조차도 고객과 연관된 다른 포인트 정보라던가 또 다른 정보가 있을 경우에는 여러 테이블이 당연하게 엮이게 되었다. 그런데도 불구하고 그런 걸 신경 안쓰고 그냥 테이블 개체 하나만 끌고와서 이용하는 식으로 개발을 했다. 요구사항에도 기본적으로 있던 작업인데 그걸 나중에 확인하고는 이렇게 개발했으니 수정 못한다 이러고 배짱질을 부렸다.

그리고 이런 식의 구조 프로그램이 여러 곳에 있었다.

개발 사항에 열전사 프린터(흔히 말하는 영수능 프린터) 장비가 몇 대나 지원 될 예정이었는데도 불구하고 출력할 내용에 대해서 공통화 하는 작업을 진행하고 그걸 프린터별로 하나하나 다 구현하는 멍청한 짓을 해놨는데 자기는 출력 내용에 대해서 공통적으로 했으니 이게 최선이라고 지랄한다. 어디서든 똑같은 환경으로 재사용성이 되어있는 운영체제 라이브러리를 갖다 버리고는 말이지…. 아주 그냥 전 세계 모든 열전사 프린터들을 전부 일일이 하나하나 전부 다 SDK 맞춰서 다 구현할 패기가 있었나봄. ㅡㅅㅡ

UI 모듈화도 요즘 추세이긴 하다만 한번 쓰고 다른 곳에서 똑같이 안쓰이는 모듈화는 해봤자 노가다인 작업일 수 있다. 그 모듈이 다른 곳에서 똑같이 쓰인다는 보장이 있어야지만 모듈화를 하는 것이지 그렇지 않다면 그냥 UI 이쁜 컨트롤만 알아서 만들어서 이용하는 거 외에는 그냥 시간만 버리는 짓이기 때문이다. 실제로 재사용성 하나도 없는 코드인데도 불구하고 그놈의 재사용성에 틀에 맞춰서 처음 요구사항과 다르게 나온 코드를 가지고 “그냥 다른 곳에서도 이렇게 하니깐 이렇게 해봤어요.” 라고 하면 대체 뭐하잔 건지….

이러다가 한곳 터지거나 요구사항과 다른 부분들이라서 수정하려고 건들면 다른 곳에서도 막 다 터지고 아주 개난리 부르스가 나서 오씨가 수정 못한다고 빡빡 우기는 바람에 회사 사람들이 그냥 포기해야 되나 싶었다고 했다고…… (그리고 그걸 내가 다 수정하고..ㅠㅠ)

그리고 이 병신짓 땜에 요구사항을 바꿔야 했던 미친 이야기를 듣고 말도 안되는 짓이라 내가 다시 원래대로 돌려놨다는 건 안비밀…..

아우 씨….

뭐… 재사용성이라는 말에 꼬여서 실제로 사용 되지도 않을 재사용성을 강조한 코드 만들고, 나중에는 거기에 눌려서 수정 못한다고 만들어 버리고, 나중에 다시 개발해야 되는 그런 경우 진짜 많다. 근데 그걸 충분히 알려주지 않은 윗분들이나 요구사항 잘못이라고 하면… 책임론 물고 싸우자는 거지.

재사용성의 강조는 솔직히 해야 한다. 해서 나쁠 거 없는 이야기다만… 제대로 모르는 상태에서 막연하게 이렇게 설계하면 재사용성 OK임 이렇게 하면 진짜 미친 짓이다. 엄청 무모하다. 특히 어디로 가야 할 지도 모르는 백지상태에서의 초기 개발에서는 그냥 짜놓고 나서 나중에 리펙토링 하는 게 낫다고 말할 수 있다.

그리고 의외로 신입 개발자들이나 아직 학생 단계에서 못벗어나는 개발자들이 많이 하는 짓이기도 한데, 자기들이 수업시간에 배운 디자인들의 경우에는 이게 이론 배운 거 생각하고 그냥 들어보니 아 이거네 하고 단순하게 생각하는 경우가 많다. 실제로 하나하나 제대로 요구된 내용을 생각해 보면서 오랜 경험이 있는 개발자와 이야기를 나누다 보면서 일반적인 디자인에 가깝게 가는 것이지 그냥 몇 안되는 예시로만 대충 배워놓은 거 그대로 적용하면 되겠지 하고 하다가 이러는 경우 무지 많은데….

쉬운 거 아니다. 그렇게 막연하게 만든 코드 나중에 재사용이고 나발이고 그냥 버그 버그 코드다.

그리고 이런 똥질 지랄같이 해보고 나서 나중에 자신만의 코드들이 하나 하나 만들어지는 건데…. 어정쩡하게 자신이 만든 코드 안버리고 그러면 진짜 죽어난다.

p.s. ….오늘 글 제대로 썼는지 모르겠다.. 이놈의 오씨가 재사용성 강조하면서 나온 이야기들 중에 재사용성하고 거리가 엄청 먼데도 불구하고 재사용 재사용 강조한 녀석의 예시가 너무 많아서 진짜….

하… 이 글 아직 쓸 거 많은데 도중에 삐걱거리는 거 같다 진짜…ㅠㅠ

오씨 이 친구의 진짜 짜증나는 점은 지식의 편중성이다. 지식이 편중되어서 진짜 쓰잘데기 없는 신기술만 쫓기 바쁘고 실제로 제대로 알아둬야 할 기본 기술에 대해서는 전혀 모르거나 그냥 대충 프레임워크로 때려박자 수준의 저레벨 게발자다. 개발자의 실력 향상에 대해서 이야기 할 때 항상 되지 말아야 하는 Expert Beginner에 정확하게 들어맞는다. 이게 뭔지 모르는 분들을 위해 링크도 걸었지만, 신기술들을 위해 여러모로 구현된 프레임워크만 죽어라 파고는 자기는 이 기술 쓸 줄 알아 하는 학생 기분의 개발자도 내가보기엔 저 부류에 들어간다고 본다.

데이터베이스야 여러모로 중요하게 여겨지면서 어딜가나 한번씩은 제대로 배우는 이론이다. 그러다보니 좋건 나쁘건 본인 스스로 한번 설계라는 걸 해본 적도 있을 것이고, 실제로 프로젝트를 진행하다보면 데이터베이스를 안쓰는 특수한 상황이 아닌 이상 한번씩은 꼭 써봤을 것이다. 그리고 꼭 골머리를 썩히는 것이기도 하고…. 몇 년 굴러보면 익숙해진다.

근데 여기서 문제가 발생한다.

데이터가 보이면 코드가 보이기 때문에 데이터베이스와 관련된 부분을 보다보니 EF로 해놨다. 근데 동시성 제어가 안된다. 여러 곳에서 한 DB로 동시에 갖다붙을 수 있는 환경에서 이 짓을 안해놨….

사실 데이터베이스가 진짜로 어려운 건 교재 뒤에 있는 내용들 때문이다. 의외로 ACID 규칙과 트랜잭션과 동시성 제어 이런 부분들은 여러모로 골때리는 상황을 연출하는 데 있어서 최고의 내용들이다.

근데 코드를 보면 이런 부분들을 전혀 이해를 못하고 그냥 짰다.

뭐 그러면 얼마나 좋을까…. 그거야 뭐 데이터베이스 전문가인 기술이사님과 같이 진행하면 금방 끝나는 걸….

근데…..

Relation도 몰라.

게다가 관계도를 몰라서 그냥 m:n 관계로 막 물린 테이블들이 수두룩……

ㅎㅎ………….

ㅆ……..

그 덕에 EF 복습하면서 데이터베이스 구조를 정리했다.

한국에서 경력직이라고 하지 마라 오씨….

ㅎㅎ… 이때 이건 진짜 생각하면 할수록 열받네…..

인수인계 할 자료 하나도 없고, 소스코드 버전관리는 안되어 있고 그런 상태에서 압축 풀고 시작할 때, 프로그램 실행만 하면 된다고 해서 해봤는데 죽었다고 했었다. 그리고 그게 오라클 DBMS가 없어서 죽은 거라는 걸 실행하고 나서 있던 P군에게 들었다.

이 상황에서 P군에세 그냥 말로 대충 말하고 넘어간 것도 열받는데 더 열받는 일이 있다.

자, 그넘의 오라클을 설치하고 나서 다시 실행을 하는 데 또 멎었다. 이번엔 코드 상에서 멎은 데다가 왜 오류가 나는지도 좀 알겠으니 이젠 코드를 좀 보자 했는데….

뭔가 변수로 만들어지지도 않은 값을 가져다가 불러오는 것이었다.

ㅎㅎ…?

게다가 이게 왠지 모르게 프로그램 실행에 필요한 값인 걸로 보이는데….

좀만 뒤져보니 윈도우의 레지스터 값을 설정해서 그걸 불러오는 것이었다.

뭐, 좋아…

레지스터 쓴다고 욕할 인간은 아니니깐…..

근데 이게 어딜 봐도 초기에 설정하는 곳이 없다.

그래서 P군에게 프로그램 레지스터에 대한 걸 물었다. 혹시나 몰라서…

아니나 다를까….

그전에 테스트용으로 만들었던 인스톨러를 통해서 설치하면 해당 레지스터가 만들어진다고 한다.

….

이 미친 오씨께서 이걸 인스톨러에서 만든 레지스터를 그냥 가져와서 쓰는구나….

왜 이런 내용을 썅 문서로 안만들어 놓는데?!

실행 환경이잖아!

레지스터에 너놨다는 건 어디다가 써먹겠단 거잖아!!!!!

나중에서야 기술팀 담당하는 이사님과 사장님께 들었는데, 프로그램이 초기 설치할 때 선택한 환경에 따라서 실행 환경을 다르게 하고 싶었는데 그걸 그냥 레지스터에 때려박고는 설치 후에 레지스터를 건드리는 방식으로 했다고 한다.

………이 무지하게 중요한 내용을 가지고 어디다가 적어두지도 않아… 문서화도 안해놔…. 그걸 대충 설치하면 알아서 생긴다고 구두 설명만 하고 튀어….

…..그걸 말로 단 한 번 이야기 하고 끝내고 튀었다는 것에서 진짜 오씨에게 살의가 느껴졌었다.

인스톨러 만드는 법 모르겠으면 그냥 모르겠다고 하던가 진짜…. 그걸 개발하면서 말하는 게 그렇게 부끄러워서 저런 지랄을 해두고는 저 내용에 대한 아무 언급도 없이 튀었…

하….. (더 이상 쓰면 욕밖에 못쓸 거 같아서 일단 이 글은 여기까지…)

지금 우리회사에서 개발하는 프로그램은 몇몇 하드웨어를 이용해야 한다. 그래서 필요한 대표적인 것이 바로 시리얼 포트! USB로 나오는 장비들 널리고 널렸지만 아직 시리얼 포트로 이용해야 하는 그런 장비들도 진짜 많다. (의외로 미국에서는 산업현장, 근로현장에서 새로운 하드웨어 도입하는 것을 극도로 꺼려한다.)

근데 요즘 컴퓨터들은 당연하게도 시리얼 포트를 탑제하지 않은 메인보드들이 엄청나게 많다. 거기에 보드가 좀 싸면 USB도 한정되어 있으니…

이럴 땐 어쩔 수 없다. 확장카드 사야된다.

여기서 우리의 반면교사인 오씨(실제 성씨 아님.)는 미국에 올 때 자기 컴퓨터를 가져왔다고 한다. 그리고 회사에서 그 컴퓨터로 작업을 했다고 한다. 아주 별 지랄을 한다 진짜….

그리고 그 컴퓨터도 당연하게 시리얼 포트가 없다. 그래서 1:8 시리얼 카드를 샀다고 하는데….

산 기록이 분명 회계에는 남아있는데…. 1:8 시리얼 연결하는 문얻다리도 있는데…

카드가 없다.

미친듯 찾았다.

없다. 졸라 쓸데없는 140mm 케이스 쿨러 안쓴 건 졸라 많았다.

알고보니 회사 나갈 때 그 카드를 안빼고 나간 거다.

그리고 만에 하나를 위해서 USB to Serial이 오씨의 컴퓨터에 4개 물려있었다고 한다.

그리고 내가 뒤지면서 찾은 건 0개….

그리고 회사 돈으로 산 4TB 하드 두개….

이걸 전부 자기 컴퓨터에 끼워 쓰다가 퇴사할 때 안빼고 나갔다.

그래서 난 회사 입사하고 얼마 안되어서 이걸 또 구매 청구하고 기술 책임자인 이사분과 회계 겸 디자이너 담당인 여자 팀장님에게 이 사실을 보고했다.

당연히 두 분은 어이없어 했고… 뒷담이 미친 듯 나왔다.

회사 컴 맞춰서 개발하고 회사 컴에다가 꼽아 쓰고 나올 땐 다 두고 나와야지 저게 뭐하는 짓이야 진짜…..

규링이 대학원에서 석사 과정 중에 여러모로 TA(수업조교)를 했었다. 그거라도 좀 벌어서 연구실 친구들하고 밥먹고 그랬다. 그 돈 모아봤자 뭐 얼마나 된다고… (그때 외주돌리던 게 좀 더 벌렸었다 솔직히..)

뭐 일단, 조교를 하는 과목 중에 모바일 앱 개발을 한번도 안해본 친구들이나 해보고 싶은 친구들을 위해 열린 강의에서 버전관리 솔루션인 git을 알려주고 해보길 권장했었다. 사실 수업으로 알려주기 전까지 git을 못쓰고 했던 친구들이라면 솔직히 했어도 좀 개판으로 했다. 그거 안다. 당연히 안다. 그래도 한번 알고 해보길 원했었다. 학부생 레벨의 코드야 구현환경 알아보고 해당 환경 구축방법과 도큐먼트 한번 쭉 보고 나서 학생 코드 눈으로 쭉 훓어보면 대략 95%는 머릿속에서 컴파일 되고 하는 그런 코드들이 대부분이니깐 이런 것이라도 더 알고 몸에 익히면 좋겠다는 생각으로 했다… (학회나 동아리 활동 등으로 배워온 예외도 있다. 근데 그런 친구들은 이런 수업 잘 안들어서…)

그들에게는 다른 거 요구 안한다. 그냥 지속적으로 어떤 작업을 하나 했으면 그 작업에 대한 커밋만 해달라고만 한다. 브랜치 따고 뭐 하고 하는 거 첨에 하면 어려운 개념으로 들어오니깐… 그러면 16주 강의수업중에 짜는 코드라 그렇게 많은 커밋은 없어도 각 기능마다 커밋 잘 따라오는 친구들은 따라온다. 계중에는 그냥 그날그날 커밋하는 친구도 있고… 과제 몰아서 했는지 며칠만에 커밋이 쫙 쌓인 경우도 있고 아예 안한 경우도 있고…. 하다보면 어떤 식으로 과제를 했는지에 대한 게 보인다. 그리고 그건 아무래도 그 학생의 과제 하는 방식과도 관련이 있다.

하물며 학생도 좀 시켜보면 어떤 식으로 개발하고 얼마나 개발하고 도중에 기능 바뀌거나 수정해야 하면 어떤 방식으로 했는지도 몇 안되는 커밋으로도 보이는데 이걸 실부 개발자들이 안했다? 미친거죠? 장난해요?

개발하는 데 있어서 여러모로 자산들이 있다. 그 중에서도 소프트웨어 코드는 엄청난 자산이다. 죽어라 관리해도 모자란 판에 소스코드를 버전관리 안해? 미쳤어?!

게다가 이전 글에서도 적었지만, 진짜로 소스코드는 P군에게 압축파일로 대강 받은 게 전부다. 소스코드를 뭐 날짜별로 압축파일을 만들었다던가 시디에라도 구워뒀다라던가 라도 해놓았으면 별 상관이 없었지만 그것도 안했다. github? gitlab? bitbucket? 이런 건 진짜 날초보 개발자인 P군은 학교 다닐 때 동아리에서 들어본 게 전부란다. 이전 개발자 사수님은 그런 거 안썼단다. (이녀석은 진짜 초보 개발자인데 이녀석 이야기는 좀 나중에 적겠다. 지금은 아니지만 옛날에는 오씨의 작품 중 하나다.)

(ㅡㅅㅡ^)=3

이게 얼마나 위험한 짓인지 모르는 분들에게 부가 설명을 하자면, 만에 하나 오씨가 회사 때려친 시기와 내가 입국해서 회사 입사하는 시기 사이에 만에 하나라도 P군의 PC가 작살나기라도 했으면 소스코드 전부 싹 다 날려먹는 판국이 벌어지는 것이었다.

(X~X);;;

그리고 내가 소스코드 건네받고 환경 설정과 각종 자료 뒤지기를 위해서 일주일을 소비하던 때에 실제로 P군의 PC는 스스디가 작살났다. (그리고 새로 맞췄다.)

(………………)

신경질이 났다.

근데 이걸 위의 개발을 담당하는 총괄자 분이 몰랐을까? 여기 사장님도 옛날에 국책연구소에서 임베디드랑 백본 네트워크 솔루션 개발하던 분이었고, 여기 기술팀 담당하는 이사분도 웹 솔루션과 대용량 DB 시스템 구축하는 데 일가견 있는 분이다. 이런 분들이 버전 관리의 중요성을 모를 리가 없다. git이 아니라 svn이던 뭐던 이용했을 분들이었다. 근데 그분들에게 들은 이야기는 진짜 가관이었다.

“자기는 완벽한 관리를 하고 있기 때문에 소스코드가 날아가는 상황은 있을 수 없다라고 하면서 우리가 모르게 관리하고 있었다.”

“이런 이야기 하면 신경질을 내면서 자기 못믿냐고 했다.”

………………………………윗분들의 손으로 뭐 어떻게 할 수 있는 그런 오씨가 아니었던 거다. (이 이야기는 나중에 할 꺼임. 할 말 진짜 많음. 반면교사의 본보기임.)

그 말 듣고 소스코드 파일을 열었다. git 폴더가 있다. git을 만들기는 했네.

그리고 git log를 당연하게 쳤는데….

커밋이 총 9개 되어있다. 그것도 커밋한 시점이 이 프로젝트 시작할 시점인 3년 전 날짜이며 커밋 메시지가 “first commit”, “AA 구현”, “BB 구현”, “CC 구현”, “BB 수정”, “commit”, “커밋”, “오늘 커밋”, “commit” 이다. 정확하게 9개 다 기억한다.

리모트? 그런 게 있을 거 같나요? 커밋을 저딴 식으로 하는 새끼가 소스코드를 리모트 서버에 관리를 한다????!? ㅎㅎㅎ… 그런 거 없음. 진짜로….

그리고 자기 부하인 P군에게도 이런 걸 하나도 가르치지 않았다.

git이나 svn 못써서 개발자 아니라고 하는 거 아니다. 나도 처음 할 때에는 저런 거 잘 몰라서 소스코드 압축파일 날짜별로 만들고 해당 날짜에 뭐 개발하고 했는지 워드파일로 만들어서 안에 넣어두고 DVD로 굽고 했던 시기가 있었다. git과 svn 같은 버전관리 솔루션들을 알고나서부터 소스코드 관리하는 난이도가 미친듯이 쉬워진거지….

그래도 어려운 거고, 그래도 중요한 거다. 날려먹고 복구 못하면 그게 뭔 짓이야!!!! 니가 그러고도 경력 있는 개발자냐!!!!

그래서 내가 코드 사이에 스페이스 바 하나 추가해서 기존까지 오씨가 자기 이메일주소와 자기 영문이름으로 커밋한 것 뒤에 내 git 정보를 이용해서 커밋하고 이 시점부터 미친듯한 커밋을 하고 미친 분량의 브랜치를 만들어 작업을 했다.

또한 사내에서만 쓰는 용도로 gitlab-ce를 빈 서버 하드웨어에 구축했다. 적당한 제온 4코어 쌈마이와 램 16기가, 하드 2테라 4개가 RAID-5로 묶인 델 타워서버가 걍 굴러다녀서 그걸로 잘 쓰는중…. 하드야 날려도 된다고 했고, 어차피 우리에겐 만능의 리눅스인 우분투가 존재하잖아…? 내 옆자리에 갖다놓고 우분투 서버 구축해두고 gitlab-ce며 redmine이며 뭐며 미친듯 설치하고 손에 좀 놀려보니 이런 거 안해본 P군을 위해서는 종합선물세트 같은 gitlab이 더 나을 꺼 같아서 gitlab으로 잘 쓰고 있다. 그리고 P군에게도 git 사용법을 가르치면서 열심히 체크하고 갈구고 습관 만들고 한 결과 P군은 지금 버전관리와 이슈 관리와 위키 채우기에 맛들려서 조금씩 무럭무럭 개발하고 있다.