불난 프로젝트, 불끄러 가보기

출처 : Pixabay

 

소스 분석

소스를 주욱 흝어본다.

어플리케이션 구조를 역컴파일 해본다.

왜 그 모듈을 그렇게 나누었는지 이해해본다.

 

엇, 저건 뭐지?

저렇게 했을리가 없는데.

 

자세히 들여다 본다.

이해가 안되는 부분이 있다.

소스의 업데이트 날짜를 본다.

 

사람들에게 물어본다.

이 때쯤 무슨 일이 있었냐고?

 

무슨일이 있었단다.

짐작해본다.

아, 그래서 이렇게 처리했구나.

 

무슨일이 없었단다.

일단 마크를 해둔다.

 

그런 게 여러 경우가 보인다.

뭔가 공통점이 있다.

급하게 메꾼 자국들이다.

"이 조직은 마구잡이로 일을 주는구나."

 

그런 게 몇개 안보이고, 공통점 없이 서툴러보이기만 한다.

"그냥 초보자를 데려다 짜게 했구나."

여긴 신입사원들을 돌보지 않는구나.

 

소스를 전혀 고친 흔적이 없다.

"이 조직은 소스까진 관리하지 않는 조직이구나."

"아주 관리가 탄탄하던지, 아주 허술하던지 하겠는데."

 

누군가 열심히 짰다면, 이유가 있는 거다.

아무 것도 없다면, 그 또한 이유가 있는 거다.

 

원인분석

사업담당자와 미팅을 한다.

 

구체적인 이야기를 안하고, 페이스북 이야기만 한다.

"아, IT서비스를 전혀 이해못하는 분이구나."

제작과정에 대한 경험이 없는 분이다.

대화가 되면 좋겠지만, 아니라면 포기해야 한다.

 

4차산업 이야기만 하고, 실천방안은 궁금해하지 않는다.

"아, 체면 과시를 위해 사업하시는 분이구나."

조찬모임 다녀오면 방향이 바뀌어 있을 가능성이 크다.

처음부터 합류할 건지 아닐 건지 고민하는 게 좋다.

 

어떻게 실패했는지 이야기하지 않고, 질문을 계속 회피한다.

'걔가 잘못한 거야.'

'너도 믿지 않아.'

'급해서 널 데려온거야.'

간혹 이렇게 생각하기도 한다.

'너도 쓰고 버릴 거야.'

아주 나쁜 사장이다.

직원 대 사장의 관계로 끝이다.

 

옛날에 있던 어려움을 이야기한다.

무엇을 하고 싶었는데, 어떻게 실패했는지 이야기를 한다.

"아, 비로소 이야기할 상대를 만났구나."

이런 분하고는 이야기가 통한다.

당신의 꿈을 실현시켜드리겠습니다.

 

미래를 이야기해야 설계방향이 생긴다.

그래야 뭘 포기해야 할지 알 수 있다.

이유를 알 수 없으면 포기할 걸 선택하지 못한다.

 

 

해결방안

바보가 아닌 사람이 개발했는데,

문제가 생겼다면 그 사람문제가 아닐 가능성이 크다.

 

조직문제이거나 사업방향의 문제다.

어플리케이션 구조가 사업방향과 상이할 확률 99%다.

시스템 구조, 어플리케이션 구조.

모두 다시 고민해봐야 한다.

 

시스템 구조는 "대량 트래픽"에 초점을 둔다.

어플리케이션 구조는 "기능의 확장성과 변경"에 초점을 둔다.

은행업무라면 짜임새 있께 꽉 차도록 짜겠지만,

SNS서비스라면 느슨하게 짜야 한다.

시장이 반응하지 않으면 고쳐야 하기 때문이다.

 

구조변경까지 할 것인가?

소스변경에만 머물 것인가?

 

구조변경을 하지 않으면, 문제가 30%쯤만 해결된다.

하지만 구조변경은 시간과 노력이 많이 들어간다.

하루 아침에 할 만한 일도 아니다.

잠깐 하고 말것인가,

오래 해야 할것인가.

그런 고민도 된다.

 

 

조치

남이 만든 소스에 손댈 때는 고민이 된다.

어디까지 만질 것인가?

이유를 모르는 코드는 선택이 필요하다.

냅두던지, 덜어내던지.

 

대부분 냅두는 방향으로 선택한다.

이유를 알 수 없으니까.

 

고칠 때는 고민한다.

어디까지 고칠 건지.

 

싹 고치려면 새 공사다.

부분만 고친다면 아무래도 만족스럽지 못하다.

 

이럴 때 있으면 좋은 거.

History Report = Issue Tracker = 업무메일이다.

이유를 알 수 있게 해준다.

 

이거 잘 되어 있는 회사가 드물다.

대게 형식에 맞춰 제목만 써놓고 만다.

난 내용이 알고 싶은데...

 

건강한 개발자는 "주석"을 잘 달아놓는다.

자기가 왜 이렇게 개발했는지 누군가에게 알려준다.

훨씬 의사결정하기 쉽다.

"그래, 이건 고쳐 쓰면 되겠다."

 

 

현실

소스만 고쳐준 적도 있고,

아예 전부다 뜯어고친 적도 있고,

팀을 정리정돈 한 경우도 있다.

 

그런데,

그런데 말이다.

고마워 한 경우를 별루 보지 못했다.

왜일까?

 

이 정도로 망가졌다면

이미 90% 포기하고 있었던 거다.

잘 수습되어도 고맙지 않은 거다.

쪼끔 고마워하긴 한다.

 

10년 쯤 되던 해에 깨달았다.

너무 애쓰지 말자구.

답답한 사람이 있어야 문제푸는 것도 의욕이 난다.

해도 그만 안해도 그만이면

당신만 답답해하지 말자.

 

 

부탁

가장 좋은 건 망가지기 않게 하는 거다.

다 망가져서 손쓸 수 없을 때가 되면,

귀신할애비를 불러도 원상복구하기 힘들다.

 

좋은 사람을 만나야 한다.

좋은 사람 만나고서야 일을 시작하는거다.

아무리 급해도 요리사 없이 식당하면 안된다.

아무리 운때가 좋아도 그냥 흘려보내는거다.

 

대기업이 부러운 건

그런 사람을 돈 많이 주고 사올 수 있다는거다.

소기업이 아쉬운 이유는

그럴 돈이 없다는거다.

회사가 성장할 때까진 인연에 기대는 수 밖에 없다.

 

이런쪽 사업을 하고 싶으면

평소에 좋은 사람을 많이 만나라.

누군가 도와줄 상황이 되면 그 때 해보는거다.

그게 인연이고 사업운이다.

 

제발.

제발.

제발.

 

 

끝.

---

 

※ 생뚱맞은 이야기지만,

소방수가 국가직화 되어야 하는 이유도 같다.

불이 나서 전소상태에 가까워지면 주인은 포기한다.

다 끄고 나도 그냥 망연자실이다.

 

불 끄는데 돈내라고 하면 아연 실색할거다.

어느 순간부터 포기해 버린다.

 

대형 화재는 그 집만의 일이 아니다.

옆집에 옮겨 붙지 못하도록 해야 한다.

역시 옆집 보고 돈내라고 하면 기겁할 수도 있다.

불 끄는 데 와서 돈아끼려고 할 것이다.

아니, 아예 내버려두었다가 원래 화재주인에게

보상금을 청구하는게 이득일 수도 있다.

 

즉, 불 끄는 건 개인이 아니라 공공의 이익에 부합하는 경우가 많다.

사유재산 관점에서 접근하면 에러가 많이 생긴다.

 

하지만, IT 프로젝트는 좀 다르다.

망가진다고 옆집으로 번지지 않는다.

그러니 주인이 아닌 사람이 안달내지 말자.

 

그래서 불끄러 가면 이 질문 하는게 습관이 되었다.

"이 프로젝트 주인이 누굽니까?"

주인이 없으면 선택해야 한다.

포기하던지, 내가 주인을 하던지.

 

주인 없는 프로젝트는 아무도 보상하지 않는다.

그러지 않으면 좋겠는데, 매우 자주 반복된다. 

 

진짜 끝.