brunch

You can make anything
by writing

C.S.Lewis

by Insuk Kwak Aug 12. 2016

개발자란 무얼 하는 사람들일까 2

신입시절-자신감 상승

3년 차가 지나기 전까지는 개발자가 여자, 남자를 구분할 만큼의 고민할 거리는 거의 없다.

있다고 한다면, 밤을 새우거나 야근이 끝이 없이 이어지는 삶이어서

20대 꽃다운 나이에 화장한 예쁜 얼굴이 아닌 민낯의 동료 얼굴에 익숙해져야 하며

체력이 받쳐줘야 한다.

다행하게도 난 체력 부분은 12년 차인 지금도 문제가 없어, 2일에 한번 잠자던

지독히 힘들었던 프로젝트도 추억으로 남았을 뿐이다.


만약, 9 - 6 시까지 개발을 하고, 7시 이후에는 자기계발과 주말에는 데이트를

할 수 있는 일상적인 삶이 중요한 사람들에게는 it 관련 직업은 맞지 않다.

물론 운이 좋아 그런 직장을 구한다면, 어떤 시련이 와도 잘 견디시길..

대부분의 한국에서의 it인의 삶은 그렇지 않을 테니..


이번 글은 신입시절의 평범하게 힘들고, 사고 쳤던 몇몇 에피소드를 적어볼까 한다.


에피소드는 누구에게나 일어날 법한 신입들의 사고이기 때문에,

나와 같은 일을 되풀이해서 상사의 눈 밖에 나지 않으려면,

손이 빠른 사람들은 백업을 일상화하고, 자기가 하는 일들에 대한 계획을

정확히 상사에게 보고하는 습관을 기르길 바란다.


첫 출근 하던 날의 다짐

 

어떤 일을 하게 될지, 어떤 사람들을 만나게 될지 긴장되던 신입


그 날 아침 출근을 하며 스스로에게 다짐을 했다.


제일 먼저 불(전등)을 켜고 가장 늦게 불을 끄는 사람이 되겠다고...

그만큼 기대도 되었고 두렵기도 했던 첫 출근이었다.


그 후 직장생활을 하다 보니 반영을 하는 날이 종종 있어서

가장 늦게 불을 끄겠다는 목표는 빠른 포기를 했고..

제일 먼저 불을 켜겠다는 다짐은 2년간 지속했던 듯하다.


새로운 일을 시작할 때 자신과의 다짐 한 가지 정도는 가지는 것이,
직장생활에 지쳐 포기하고 싶을 때도 버티게 하는 힘이 된다.


운영 업무


며칠간 간단한 연락을 받고 전달하는 일만 주로 하다 드디어 업무를 할당받았다.

엑셀로 된 문서였는데, 데이터를 수정하는 일이었다.

문서에는 아이디가 있고, 수정을 해야 하는 필드와 값이 있던 문서였고,

운영 리더인 대리님이 그 끝에 쿼리를 샘플로 만들어 주셨다.

그럼 그걸 드래그해서 내리면 자동으로 쿼리가 만들어져,

ctrl C, V 하고 확인을 하는 단순 업무였다.


엑셀의 텍스트 합치기 기능을 이용한 것이었는데, 운영 업무에서는 엑셀을 잘 활용하면

굉장히 편하단 사실이 그 후 다른 운영을 할 때도 알게 되었다.


그때 당시 맞은편에 연구원 분(현재 페북 친구인데 본인인지 아시려나..)이

 하시던 말이 뇌리에 박혔다.

"그냥.. 프로그램을 만들지.."

그래.. 나도 그런 거 만드는 개발자가 되고 싶은데,

상처만 받고 열심히 데이터 보정 작업을 손가락 아프게 했던 기억이 난다.


훗 날, 10분도 안 걸릴 프로그램이었는데, 아직도 그 일이 잊히지 않는 거 보면

어지간히 마음에 박혔나 보다.


Tip. SI와 SM의 차이점

SI : 시일을 맞춰 기능 개발이 관건임.

여러 프로젝트를 통해 개발자의 개발 능력을 상승시킬 수 있다

SM:문제의 해결 능력이 관건임.

문제가 무엇인지 파악하여 재발하지 않는 방법을 찾는 것을 배울 수 있다.


대형사고


주된 업무가 데이터 보정이었기에 SQL 쿼리 날리는 일이 업무의 반,

디플로이 된 시스템 테스트가 업무의 반이던 시절.

그날도 어김없이 DELETE 문을 날리는데 뭔가 서늘한 기운이 들었다.

그러면 확인을 하면 될 것을 자동처럼 먼저 반응한 내 손가락

COMMIT


그러고 나서 DELETE 문을 보니 WHERE 조건이 없네.....

테이블 전체를 삭제해 버린 것이다.

운영 DB 였기 때문에, 사색이 되어 버린 나는 주변 선임 개발자들을 찾기 시작했다.

그리고 운영 PM에게 사정을 말씀드렸는데 별 대수롭지 않은 얼굴로

 "일주일 전 백업본 밖에 없을 텐데.."

친한 몇 개발자 분들이 좀 찾아보시더니

"아, 방법이 있는 것 같아요"

쪼르르 달려간 나는 그분이 하시는 기적 같은 일을 보게 되었으니,

그건 ORACLE 9i 버전의 불완전 복구 기능..

대략 날린 시간과 테이블을 아마 쓰면 복구해주는 기능이 있었는데

새로 만든 시스템이어서 9i 버전(그 당시는 대부분이 8i를 사용하고 있었음)이었다는 기적적인 사실과

아카이브 모드여야만 가능하다는 사실.

이 두 가지가 가능하여서 데이터는 다 살아났고, 그분은 나의 은인이 되었다.


참고하자> 실서버 데이터 작업을 할 땐 반드시 테이블 백업을 하고 작업하거나

복구할 방안을 찾은 후 작업하는 습관을 기르자.



다른 팀원들의 사고 수습


첫 번째, 다른 개발자가 일정을 딜레이 하면서까지도 완성하지 못한 프로젝트에 대타로 투입되다.


3년 차, 잠시도 쉬지 못한 내 일상에 오래간만에 휴가를 받아 가족들과 휴가를 갔다.

그런 내게 당시 팀장님이 "내일 회사로 좀 와줄래?"라는 연락을 받고

서울에 도착하자마자 회사로 갔다.

가볍게 얘기하시는 이야기인즉슨,  

A과장이 일을 제대로 못 끝내서 네가 대신 들어가야 할 것 같다

뭐 어차피 프로젝트야 줄곧 하던 일이고,

성격상 정확한 스케줄과 범위를 파악하는 게 습관이어서,

형식상 물었다.

"개발 완료일이 언제예요?"

돌아온 대답은... 일주일 전............................................


그 길로 난 PM과 노트북 한대만 들고 고객사로 향했다.

문제는 그게 3일간 감금(?)으로 이어질 줄 몰랐다는 것이었다.

화가 난 고객들은 내가 그 회사 직원이란 말로도 나를 보자마자

화를 냈고, 그냥 난 꿋꿋하게 진행상황 파악하고, 고객이 말해줘야 할 건

욕을 먹어도 물어보고, 그 당시 설루션 버그가 있어서 본사에도 요청을 하고

여러 가지 일을 했다.


그 뒤로 그 고객과는 끈끈한(?) 전우애를 가지게 되었고,

나중에 완료 회식 때, 처음 상황에 대한 사과도 받았고,

난 그냥 나의 성취감에 젖어들었을 뿐이다.


그런데 명심해야 할 것이 있다.

회사가 반복해서 문제 되는 상황을 몸 바쳐 해결해줘도

상사들은 모른다.

그냥 나아지면 또 다른 누군가가 했겠지 하는 생각을 한다.

내가 업무상 성과를 냈을 때는 명확하게 평가를 요구할 줄 알아야 한다.


두 번째, 출장 7일 전 신입 개발자가 db를 엎어 버리다.


당시 우리 솔루션은 좀 독특했다.

설루션 자체가 CMS 개발 툴이었고, 나 같은 개발자들이 그 개발 툴을 가지고

개발을 하면 db에 저장되는 구조였다.


자카르타에 솔루션 납품을 위해 3개월 간 혼자서 시스템을 만들어가는

어느 날, 신입 개발자가 첫 프로젝트를 끝나고 복귀하였다.

그러고 나서 잠시 자리를 비우고 내 시스템을 구동하는데,

분명 영어로 나와야 할 시스템이 한글로 쏟아지는 걸 보고,

아.. 뭔가 잘못되었구나 라는 생각을 했다.

아니나 다를까... 그 친구가 내가 쓰던 db에 자기 프로젝트 소스로

덮어버린 거였다.


예전 불완전 복구 경험이 있어, 찾아봤지만..

우리 회사는 아카이브 모드가 아니었고,

자카르타는 우리 회사에 중요한 프로젝트였기 때문에

R&D 부서에서도 이일을 해결할 선임들을 투입해 주었다.


난 애써 평정심을 찾으려 밥을 먹고 왔는데..

팀장님이 하시는 말씀

"깨끗하게 첨으로 세팅해줄까? 저번 프로젝트 버전으로 세팅해줄까?"

방법이 없단다.

하...... 아...


출장 7일 전이였다...

다시 마음을 가다듬고 열심히 빠른 손놀림으로 다시 개발하기 시작하는데,

뒤에서 개발이사님이랑 사장님이 내 뒤에 서셔서 그러셨다.

"개발자가 백업도 안 하고 개발을 해? 경위서 쓸래?"

참 당찼던 나는

"개발 서버나 확보해주시고 그런 말씀 하세요.

안 그래도 심란한데 가주실래요?"

우리 회사 참 좋은 회사였다.. ^^;;;


사실 개발기간이 3개월이긴 했지만,

설계 변경 및 완벽함을 높이기 위해 꼼꼼하게 하는데

시간이 많이 들었었고,

그마저도 한번 했던 소스다 보니

대충 큰 기능들을 7일간 하루에 1,2시간 자가며 복구했다.


그러자 돌아오는 말

"일주일 만에 만들 거 3개월 걸린 거였어?"

하... 장난하시나요...


아무튼 그렇게 난 장기출장 준비도 못하고 옷 대충 싸서

자카르타에 갔고 거기서 포팅 후 추가 개발 후

서비스를 론칭했다.


그 후로도 난 여러 프로젝트 들에 소소한 해결사 역할을 했고,

그럴 수 있었던 건 여자임에도 불구하고,

감정 공감보다는 문제 해결에 관심 있는 성격 탓이었던 것 같다.


우리 엄마가 종종하시는 말씀이.

"넌 왜 들어만 주면 될걸 다 해결해주려 하니..

네가 아들인지 딸인지 모르겠다"

에이~ 내가 해결해 줘서 좋은 것도 많으면서...


개발 7년 차까지 난 일이 힘들다고 울어본 적은 없었다.

억울하다고 울어본 적도 없었다.


그 후 딱 3번 울었는데

8년 차 이 회사로 다시 돌아왔을 때, 더럽고 치사해서 분에 받쳐 1번,

그 이듬해 거지 같은 상황에 혼자서 몸빵 할 때 1번,

감정적으로 갑, 을 회사가 개발자 및 회사 상대로 인격모독할 때

 열 받아서 1번이다.


여자라는 성별이 눈물이 많다는 평가 속에 끼고 싶지 않아

이 악물었고,

편하게 지내지 않으려 더 도전하며 지냈고,

노트북을 들어준대도 거절하고,

정수기 물도 혼자 갈아대며

스스로 여자란 성에 갇혀 살았다.


이젠 누군가 도움의 손길을 내밀면

받아들일 줄도 알고,

굳이 남자, 여자란 성 속에 차별을 두지 않으려 되뇐다.


그래도 여자들이 남자들을 이용해

편하게 지내려는 습성을 드러낼 때를 종종 보았다.

그런 것들이 결국 여자를 고용하기 싫어하는 분위기를

더 조성하게 된다고 생각한다.


여자라고 갇혀 있을 필요도 없지만,

여자라는 걸 이용하지도 말아야

이 땅에서 똑같이 힘들게 일하고 있는 여자들이

욕먹지 않을 길이다.















매거진의 이전글 개발자란 무얼 하는 사람들일까
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari