김성렬 개발 블로그

나는 국비 지원 교육이  지금의 개발자에 대한 안좋은 인식과  갑을병정식 한국의 곪아터진 si 산업을 부추겼다고 생각한다

코딩하다가 막히면 치킨집 사장한테 물어보라는 농담은 

2000년 초 it 붐이 일어서 수많은 개발자를 양산 했던 그때 그 시절의 개발자들의 이야기다.

지금의 한국에는 아키텍트 급 고급인력이 턱 없이 부족하다 라는 이야기는 그 시절 개발자 분들이 

전부 죽었기 때문일 것이다. 

한국과 일본의 소프트웨어 엔지니어라는 직업의 인식이 낮아지고 직업의 질이 낮아진 것은

국비 지원을 통해  실력이 낮은  신입 개발자들을 과잉 공급 한것이 문제다 .

국비 지원의 현 실태는 

학원이 정부 돈 타먹기 식의 si 좀비 기업 들과  별반 다를 바가 없으며

이건 개발자를 양성하는 것이 아니라 나라돈 돌려먹기가 되었다

요 근래 상황은 점입가경이다

 1년 정도기간의 양성 과정 커리큘럼들은 최근에 와서 6달 3달 까지 교육기간을 단축해서

신입 개발자라는 칭호를 붙여서 실무에 투입하고있다 

현재의 국비 지원 정책은 개발자 죽이기다.

내가 비판하고싶은 것은 취업을 하고싶어서 학원에서 프로그래밍을 배우는 그들에게

"어디 천한것들이 프로그래밍 같은 전문적인 일을 하려고 들어?" 이게 아니다.

깊게 알지못하고 코딩을 해서 만들어진 소스코드는 폭탄이다.

물리적으로 보이는 제품 개발에는 다수의 신입으로 구성된 팀을 조직 하지 않으면서

소프트웨어는 다수의 비전공 학원출신 개발자들로 구성된 팀을 조직하여 개발을 하는 소기업 중소기업은 많다.

경험이 부족하고 설계능력이 떨어진다면 그들을 주도 해줄 사수가 필요하지만 저런 팀은 폭탄을 만든다. 

틀린 방식의 프로그래밍을 배운 저런 상황에서 경력을 쌓고

그 경력으로 꼰대 질을 한다. 

"잘돌아 가는데  왜 건들여?"(이 문장은 나중에 얘기하고싶은게 많다)

"이 기술로도 충분한데 뭔 신기술을 공부해?"

"이 방식이 맞어 이렇게 하면 되는거야"

이러한 사상을 후배들에게 전파한다.

이건 사실  비전공 학원출신 개발자에게만 해당 되는 내용이 아니다.

4년 동안 뭘 공부한건지 모르겠는 전공자들에게도 생기는 시나리오다.

소프트웨어의 이해도가 떨어져서 전통 산업과 동일시 여기는 경영진들은

10명이 있으면 10명분의 생산량을 기대하며 

경험과 OOP에대한 이해도가 떨어지는 학원출신 개발자를

싼값에 고용한다.

(경영진들은 A친구가 생산력이 더디다고 그쪽 모듈 개발을 도우라고 했을때

그 도움을 주기위해서는 소스코드를 이해할 시간이 필요하다 말하면 

그것을 이해하지 못한다.

삽으로 땅을파는 전문가에게  두명이서 같이 땅을 파라고 하는데

땅을 파는 일을 전문적으로 하는 사람이  땅파는 법에대해 이해가 필요하니

지금 당장 땅을 팔수없다는 것은 경영진에게는 이해할수 없는 일 일것다.  )

그들은(학습량이 부족한 신입들) 돌아가는 소프트웨어를 생산하지만 사람이 이해할수없게 소스코드를 짠다.

이러한 소스코드는 버튼하나 옮겨달라는 수정사항에도 힘겨워할수 있으며

개발자들은 폭탄이 되버린 소스코드를 그 누구도 리펙토링 하려 하지않는다.

더 이상 버틸수 없는 기점에 이르렀을때 소프트웨어는 동작조차 안해버릴수있다.

경영진은 이런 것을 모른다. 

어느날 잘 돌아가던 소프트웨어가 안 돌아가면 개발자를 욕한다.

개발자라면 그 상황을 충분히 예상했을 것이다. 

더러운 소스코드 , 리소스 관리따윈 없는 프로그래밍, trycatch를 남발하는 에러 처리...

'이건 언젠가는 터진다...'

이건 회사입장의 손해뿐 만이 아니다. 

그러한 소프트웨어를 만들어내면서 신입 개발자들은 아무런 배움을 얻을수 없으며

지식이 있는 개발자들은 그들이 만들어 놓은 소스코드가 폭탄임을 알고

리펙토링을 하거나 전부 새로 다시 짜면서 그들의 똥을 치울것이다.

아니면 폭탄임을 눈치 채는 동시에 도망간다.

 구글링을하면 지금당장 필요한 소프트웨어 기능들에 관련된 소스코드를 구할수있다.

문제는 그 소스코드들에 대한 처리다.

3~4개월 남짓 코딩을 배워서 객체 지향적 개념을 적용하여 그 소스코드를 추상화하고 분리하는것은 힘들다.

구글링을 통해 복붙으로 만들어진 소스코드는 장기적 보았을때 굉장히 위험하다.

소위 학원충이라고 비하받는 3~4개월 학원 교육후 취업시장에 진입하는 비전공자들은

상식적으로 생각한다면 4년간 전공 공부를 한 전공자들에게 밀려서 사라져야 정상이다.

그러나 현실을 그렇지 않다.

사실 4년동안 뭘 배운지 모르겠는 전공자들이 널렸다.

4년의 전공지식공부에 소홀히 한 그들을 본다면

학원 자체가 잘못된 것은아니다.

다만 문제는 소프트웨어를 바라보는 오늘날 사회의 시선은 너무나 저급하다는 것이다.

책에 쓰여있는 명령어를 따라치면 멋진 결과물이 나오니 그게 다인줄 아는것이다.

기계가 이해할수 있는 코드를 짜는일을 누구나 할수있다

프로그래머는 사람이 이해할수 있는 코드를 짜야한다.

-마틴 파울러-

대부분의 프로그래머가 품질에 대해 압박을 받는다지만 일정에 대한 압박만 못하다.

이렇게 일정이 빠듯할 땐 리팩토링 얘길 꺼내지 말고 몰래 실시하자.

-마틴 파울러in 리펙토링 .팀장에게어떻게 말을꺼내나 -

이미지 출처 https://www.slideshare.net/madvirus/mvp-63161829

리펙토링이란 외부적으로 보이는 기능에는 영향을 주지 않으면서 내부 구현을 변경하는 작업을 말한다.

대부분의 소프트웨어가  초기 설계 목적에 맞게 비지니스가 흘러간다면 리펙토링이란 것은 필요없을 것이다.

해당 s/w의 도메인에 대한 이해부족 또는 기획에 다 담지 못한 요구사항이 개발 단계 또는 개발 이후 드러나 설계가 변경되어야 하거나

사업 확장으로  추가되는 기능이 현 설계로는 비효율적이다 판단 될때

소프트웨어는 재설계 되어야 한다.

굳이 이런 거창한 의미가 아니더라도 신입 프로그래머들의 미숙한 추상화와 구글링을 통해 복붙한 소스코드들은 가만히 두면 나중에 타격을 맞기 때문에 사수역할의 선임 프로그래머는 이를 잡아 내어

해당 부분의 리펙토링을 지시 해야 한다는 부분에서도 리펙토링은 당장 내 옆에서도 이루어 질수 있는 작업이고 수시로 꾸준히 이루어 질수 있는 업무다.

객체간 결합도가 높아지면 해당 소프트웨어의 복잡도는 겉잡을 수 없이 증가한다.

결합도가 높은 소스코드 위에서 코딩을 한다면 그 이후 이루어지는 소스코드들은 서로간 긴밀하고 타이트한 관계를 유지 할수 밖에없다.

창업 초기 기획이 이루어 지지 않은 상태에서 개발을 시작했고

기획과 개발이 동시에 진행되면서 개발 경험 부족이라는 문제와 함께 기획 부족이라는 문제를 같이 겪으면서 아주 죽을 맛이 였다.

어차피 만들어놔도 다시 바뀔껀데 라는 생각은 사람을 의욕 저하상태로 빠트리기 충분했고  

정말  소스코드는 꼴도 보기 싫을 만큼 더러웠다.

STS 를 열어 보는 것이 두려웠고 뭐하나 기능수정해달라는 것도 인상을 쓰면서 "이걸 어찌 해야 하나"라는 생각에 한숨부터 쉬면서 소스코드를 만졌다.

결론은 

지금 당장에 잘 짜여진 소스코드가 아니라면 그 이후 계속되는 코딩 작업은 소프트웨어 자산에 제 3금융권 어깨 형님들의  기술 부채를 계속 끌어다 쓰는 것과 같다.

지금 당장 자금이 충분해서 안정되듯이  프로그램은 잘 돌아 가지만 부채가 쌓여서 이자가 겉잡을 수 없이 늘어났을 때 

버그라는 어깨형님들이 당신에게 들이닥쳐 당신의 휴식시간을 집어던지고 깨부시면서

윽박 지를 것이다.

" 돈을 빌렸으면 갚아야지!!"

프로그래머에게 품질에 대한 일정은 주어지지 않는다.

그러나 품질에 대한 책임은 프로그래머에게 있다.

버그가 생겼을때 그 것을 잡아야 되는 당사자는 경영진이 아니다.  

경영진에게  지금 잘돌아가는 소프트웨어에서 

1천라인 짜리 1개 클래스는 객체지향적이지 않으니 

고쳐야 한다고 이해시키는 것은 불가능하다.

이해시키기 위해서 당신은 객체지향이 아닌 prinf("Hello C World\n"); 부터 경영진에게 가르쳐야 할 것이다. 

그냥 마틴 파울러의 조언처럼 몰래 실시하고 품질에 대한 시간을 스케줄에 당연히 포함되도록 일정을 계산해야 한다.

프로그램을 작성할 때 습관적으로 유닛테스트 코드를 작성하는 사람과 그렇지 않은 사람 사이엔 그 자체로 이미 프로그래머로서 가능함기 어려울 만큼 깊은 수준차가 존재하는 것이다.

 -임백준(BaekJoon online 운영자)-

유닛 테스트는 정말 중요하다.  군대에서 토비 스프링을 통해 스프링을 처음으로 접했고

이일민 개발자님의 책을 읽으면서 유닛테스트의 목적을 배우고

테스트 코드는 단순히 잘 돌아가나? 를 보기위한 대충작성하는 것이 아니라는 것을 배웠다.

단위테스트를 하는 이유는 개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빨리 확인받기 위해서다.

이때 확인의 대상과 조건이 간단하고 명확할수록 좋다.

-토비 스프링 vol1-

 창업당시 서비스 오픈을 최대한 빠르게 해야 했다.

최소한의 창업 준비 또는 진행 성과가 좋아야 학교에서 청년 창업을 위해 지원하는 투자금을 타낼수 있었기 때문이다.

클라우드서버 구입과 관리 서버내 리눅스로 환경구성하는 것 대한 문제도 전부 나의 업무였다.

AWS를 쓰려다가 클라우드서버 사용경험이 전무했기때문에

"그래도 한국 업체이면 전화문의로 한국말로 도움을 받을수 있지 않겠느냐 "라는 의견들이 나와서 KT UCloud  를 이용하기로 했었다. 

(지금생각하면 후회한다. 상업화되지 않은 테스트 단계에서 AWS 프리티어로도 충분했는데 큰돈은 아니지만 쌩돈을 썼다.)

처음 하는 일은 늘 그렇듯 힘들었다.

(내가 최고권한서버관리자인데 왜 permission deined 냐

권한좀 주세요 ㅠㅠ 리눅스님 ..

-09월21일 카톡 일기-)

 그러나 어플서버 개발또한 병행 되어야 했고

서버쪽은 개발이 가능한 사람은 나뿐이였기 때문에 많이 지쳐갔다.

그렇기에 나는 매우 합리적인? 결정을 내렸다.

유닛테스트코드를 생략했다. 그때 당시  CRUD 관련 유닛테스트 코드들은 잘 작성 되있었고. Service 계층을 짜는 단계라서

"db에서 잘받아 오는데 뭔 문제 있겠어

문제가 있으면  로그 찍어서 어찌어찌 해결 되겠지"라는 생각을했다

처음에는 문제가 없었다.

그러나 문제는 어플과 연결시킨 한참뒤에 벌어졌다.

입력값이 몇 개가 비었을때, 특수 문자 입력을 막아지 않을것, 과 같이 클라이언트(어플)단의 굉장히 사소한 문제들이 

Service 단에서 예외 처리를 미숙하게 해놓은점 ,선언적 트랜잭션 처리를 생각없이 전부 선언 한것 과 같은 나의 미숙함이 곂치면서 심심하면 어플이 꺼지는 문제가 생겨났다.

문제는 어디서 발생한 에러인지 정확히 몰랐기 때문에 하나의 버그가 발생하면

하나의 기능에 관여하는 클라이언트와 서버 의 모든 클래스를 까봐야 했다.

에러로그로 간단하게 잡히는 문제들도 있었지만

문제는 같은 에러를 잡아 놓고도 다음주가 되면 새로운 에러를 잡기위해 완벽하다 생각했던

소스코드를 다시 검토 해봐야 했다.

기능 추가로 새로운 도메인?이 필요하여 DB에 테이블을 추가하고 그에 필요한  클래스들에는 지금있는 버그들 때문에 바쁘다는 핑계로 테스트코드를 작성하지 않았다.

이런 악순환은 계속되었다.

그때 조금만 더 고생하더라도 테스트 코드를 작성해놨으면 

같은 소스코드를 반복해서검토하고

그때그때 이거 돌아가나? 라는 생각에 main열어서 임시로 돌려보고 다시 지운다던지

하나의 클래스를 테스트하기 위해 어플 부터 서버db 끝까지 전부 한번 돌려봐야만

기능 테스트가 가능한 이런 끔찍한 문제가 안일어 났을까란 생각이 든다.

그때 내가 자주 했던 부끄러운말이 있다

"오늘 서버 테스트 해봐야될거있으니까 다들 모여주세요"

나는 책을 통해 수많은 문제들을 보았고 그 문제들을 해결하는 솔루션을 책을 통해 배웠지만

실제 상황에서 대처하지 못했다.

Junit을 쓸줄알고 mokito를 사용해 더 깔끔한 테스트 코드를 만들어 내는 것과 같은 일들을

아는것과 하는것은 전혀 다른 문제 같다.

개인적인 생각이지만

개발과 설계,관리는 분리되는게 맞는것같다. 두개를 동시에 하기는 힘든 것 같다.

컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다.

좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

-마틴 파울러-

데이터를 뽑고 빼는건(CRUD) 정보처리라는 소프트웨어의 사용목적에 있어서 가장 기본적인 기능이다

하나의 도메인에 대한 CRUD 처리는 너무나 쉽다 구글에 널려있는 jdbc 예제 소스코드를 긁어온다면

Crtl+C,V 3가지 버튼 만으로도 구현 할수 있다.

그러나 10개의 도메인에 대한 CRUD 처리는 좀더 어렵다. 1:N M:N 문제로 여러 테이블들이 서로 얽매여서

비지니스에 핵심적인 도메인이 무엇인지 선택하고 결정하는 것은 향후 개발에 있어서 큰 문제를 일으킬수있다.

예를 들어

우체국에서 사용할 소프트웨어는  '주소' 는 도메인이다.

주소를 통해 물류들을 분류하고 주소를 활용하여 거리를 측정하고 배송비용을 산정한다.

우체국을 위한 소프트웨어를 개발해야한다면 설계자는 주소를 도메인으로 인식하고

주소에 대해 처리될수 있는 여러 비지니스적 문제들을 깊게 파고 들어 설계를 해야 할것이다.

그러나 다른 소프트웨어 에서 '주소'는 회원 정보의 애트리뷰트(속성) 정도만으로도 큰 문제 없이 사용될수있다.

같은 '주소'라는 정보를 처리하는 방식은 그 소프트웨어를 사용하는 클라이언트가 누구냐에 의해

우리(개발자)들은 다르게 인식해야한다.

다시 돌아와 도메인에 대해 얘기 하자면

도메인을 결정하기 위해서는 그 도메인에 대한 이해가 필요하다.

도메인간 연관 관계에 대한 이해 , 그에 맞는 설계 가 진행되지 않는다면 소프트웨어는 개발될수없다.

나는 그점을 간과했다.

경영팀에 해당하는 팀장역활을하는 친구의 말을 너무 쉽게 받아들였다.

"게시판이 필요하고 메시지를 우리 어플 유저끼리 보낼수 있어야해"

"우리 어플에서 만들어진 정보들을 기반으로 pdf파일을 생성하서 메일을 보내줘야해 "

 같은 문장들을 게시판, 메시지, 메일 과 같은 단일 도메인으로 받아들였고

나는 망언을 했다

"그거 쉽겠네 한 3주일이면 될거 같다"

게시물을 등록하는 기능

메시지를 보내는 기능

메일을 보내는 기능

은 너무나 쉽다.

구글링을 하면 발에 치이는 것이 위 기능들에 대해 설명하는 소스코드들이다.

나는 1개의 도메인을 처리하는 소프트웨어를 여러 개 만든다고 생각을 해서

이 기능들을 쉽다고 망언을 뱉었다.

결론을 말하자면 3주만에 끝내겠다던 프로젝트는 5달동안 질질 끌었고(중간고사 기말고사 문제이 껴있긴했지만)

개발이 되는 과정에서 기획은 기능구현이되자마자 변경되는 일도 많았다.

기획이 날아올랐다.

어찌보면 기획은 잘못이 없을수도 있다.

소프트웨어의 끊임 없는 변경은 소프트웨어공학이 해결하고자 했던 오랜 문제 이며

 그 문제를 해결하기 위한 여러 방법론 개발론들이 있다.

나는 단순 기능 구현에만 집중했고 좀더 객체지향적이고 ,추상화를 통해 소프트웨어 결합도를 낮추고자하는

 노력과 실력 그리고 경험이 없었기 때문에 설계가 망가졌다.

나중에는 서버측 하나의 기능테스트를 하려면 개발팀(4명) 전부가 모여야만 가능할만큼 소스코드는 망가져있었다 

(이 부분은 단위테스트의 중요성에서 자세히 다룰것이다.)

 마틴 파울러가 말했다.

컴퓨터가 이해하는 코드는 어느 바보나 다 짤수있다.(돌아가는 코드는 누구나 다 짠다.)

좋은 프로그래머는 사람이 이해할수 있는 코드를 짠다.

나는 바보 였나 보다.

창업을 통해 시작한 프로젝트는 실패했다.

비즈니스적 목적에서나  소프트웨어의 개발 완성 자체에 의의를 둔다면 실패라는 단어가 부적절할수 있지만

나는 개발자로서 이 프로젝트가 실패했다고 결론을 내리고 싶다.

서로가 서툴렀기 때문에

 기획, 개발, 디자인 3요소가 일관성 있는 프로세스에 의해 진행되지 못했다는점

향후 유지보수성이 현저히 떨어질만큼 추상화가 엉망이라는 점

커뮤니케이션이 서툴렀던 점

나의 고집

경영진에게 소프트웨어의 특수성을 이해시키려고했다는 점

설계의 미숙함

실패의 원인 또는 아쉬움을 말하자면 끝이 없다.

그 내용들에 대해 글을 써보고자 한다.

창업 경험 게시글들은 태그 #창업을 전부 걸어놓는다