[SI Q&A 세션 ①] ‘네카라쿠배’ 아니어도 개발자로 성장하고 싶어요

[SI Q&A 세션 ①] ‘네카라쿠배’ 아니어도 개발자로 성장하고 싶어요

[SI Q&A 세션 ②] SI 개발자, 어떻게 성장해야 하죠?

지난 2월 말, 위시켓과 요즘IT 김수보, 안영회 작가가 함께 SI 개발자를 대상으로 Q&A세션을 열었습니다. 사전에 질문을 받고, 그 질문에 대해 현장에서 답하는 시간을 가졌습니다. 초보 및 신입 SI 개발자를 대상으로 기획한 행사였는데, 3~4년차 이상 일하신 분들도 참석해 고민을 나눠주셨습니다. 그날 있었던 대화 내용을 각색해 두 편의 글로 전합니다. 

김수보(이하 김): 안녕하세요, 저는 오늘 이 자리를 기획한 김수보입니다. 저는 1997년 모 대기업으로 입사했고요. 28년 동안 IT 분야에서 활동하고 있습니다. SI는 12년 정도 했고, ‘kth’에 입사해 앱 서비스를 개발하기도 했습니다. 벤처한다고 창업했다가 망해보기도 했네요.

이 자리는 정답을 드리는 강연이 아니라, SI 분야의 고민을 나누는 장이라고 생각해주시면 감사하겠습니다. SI는 이런 기회가 거의 없다 보니 하나 있었으면 했거든요. 얼마 전 요즘IT 노희선 리더님과 SI 업계 이야기를 나눴습니다. 제 후배 하나가 SI를 하고 있는데 회사 막내가 42세라더군요. SI에선 신입사원 보기가 너무 힘들다. 신입으로 들어가려는 분들도 SI를 무서워한다. 그리고 많은 회사에 신입사원을 어떻게 교육할지에 대한 노하우가 없다 등등.

사정이 이렇다 보니, 이 업계가 망하겠다 싶더라고요. SI도 국가의 인프라를 떠받치고 있는 중요한 산업인데 말이죠. 그래서 좀 더 많은 사람이 이 산업을 잘 이해할 수 있게 글을 올리게 되었습니다.(김수보 작가의 페이지 | 요즘IT) “SI 개발자가 어디에서 돈을 벌 수 있을까?”, “SI 업체가 정말 나쁜가?” 오늘 저는 이런 이야기를 드릴 수 있습니다. 정답이라기보다 저의 경험이라는 점을 감안해서 들어주시면 감사하겠습니다.

안영회(이하 안): 안녕하세요, 저는 안영회라고 합니다. 99년쯤에 개발을 시작했어요. 주로 기업 프로젝트를 했는데, 개발 기획이 너무 이상하게 오더라고요. 그래서 아예 기획도 같이 해야겠다 생각했죠. 그런데 사업을 기획하던 회사가 개발자를 안 뽑더라고요. 그래서 IT 컨설팅 회사에 들어갔습니다. 제가 개발도 하겠다고 했죠. 개발 계획이 이상하게 오는데, 우리는 개발자가 없으니까 “제가 할게요”, 한 거예요. 그런 일을 16년 하다가, 조금 지쳐서 다른 일을 해보려고 베터코드라는 회사를 만들었습니다. 중국 시장을 공략하다가 코로나 때문에 다시 돌아왔습니다.

김: 이분이 우리나라에서 자바 진영 스프링 도입에 앞장선 분입니다.(안영회 작가 인터뷰 | 요즘IT) 물론 KSUG라는 커뮤니티의 창립멤버들과 같이 한 거지만요. “스프링 미워요” 하신다면, 이 분한테 푸념하세요. (웃음)

안: 제가 스프링을 만든 건 아닙니다.(웃음) 2004년에 엄청난 규모로 진행된 군의 차세대 프로젝트가 있었는데요, 당시 제가 주도해서 스프링을 도입했죠. 그게 잘 되었는데, 그걸 바탕으로 대기업의 프레임워크를 만들 때 스프링을 기반으로 하며 확신이 생겼습니다. 그런 현장 경험을 제가 공동 설립한 KSUG라는 개발자 커뮤니티를 통해 공유한 것이죠.

그런데 제가 2014년 ‘GS홈쇼핑 모바일 개편’이 대기업 SI의 마지막이어서, 김수보님이 이 세션을 함께 하자고 제안하셨을 때 고민이 되었어요. 2000년대 초반에는 대기업 프로젝트들이 정말 엉망이었는데요. 현재는 현장이 많이 바뀌어서 어떤 도움 말씀을 드릴 수 있을지 모르겠다 싶었죠. 하지만, 어쩌면 그때처럼 어떤 표준과 틀을 잡는 경험이 될 수도 있겠다 싶었습니다. 이런 활동이 계속된다면 도움을 드리고 싶다는 마음이 생겨 오게 됐습니다.

※ 사전에 참가 신청자들에게 질문을 받았습니다. 현장에서 그 질문에 대한 배경설명을 추가로 듣고, 편안하게 이야기를 나누는 식으로 세션이 진행됐습니다. 김수보, 안영회 작가가 답변을 하기도 하고, 참가자 중에 관련 경험이 있는 분들이 답을 하기도 했습니다. 사전 질문과 현장에서 추가로 채집한 배경 설명을 버무려 ‘질문’으로 정리하고, 답변은 발화자를 중심으로 정리했습니다. 

Q. 현재 약 1년짜리 SI 프로젝트에서 일하는 중인데, 그다음에는 어느 정도 기간의 프로젝트를 하면 좋을까요? 또 프로젝트에서는 무엇을 배워야 할까요? 

질문자 사연: 저는 원래 개발 직군이 아니었는데, 작년에 직무 전환에 성공했습니다. 현재는 전임자의 갑작스러운 퇴사로 어떤 프로젝트에 바로 투입되었어요. 1년짜리 프로젝트에 투입될지는 몰랐지만, 지금은 이미 들어온 상태라 앞으로 어떻게 해야 할지 고민이 됩니다. 물론 회사 의사에 따라야 하는 건 맞지만, 프로젝트가 여러 개 있어 개인 의견을 통해 조정도 가능하거든요. 현재 담당한 업무가 “데이터 전환 및 표준화”인데, 이 일을 얼마나 하는게 좋을까요? 그리고, 이 프로젝트에서 무엇을 배우면 좋을까요?

안: 어느 정도 기간을 경험하는 것이 효율적인지에 관해 생각해 봅시다. 효율적이라는 표현을 쓰신 걸 보면 ‘자기 계발’을 염두에 두신 것 같아요. 보통 자기 계발 바탕에 놓인 맥락이 있습니다.

일단 편안한 상태에서 시작해요. 그런데 불편한 게 생기죠. 그 불편한 것 중 내 일과 연결된 걸 찾아야 해요. 그리고 불편한 걸 할 만하게 만들면서 계속 앞으로 나가야 하죠. 그러다 보면 언젠가 그 불편했던 게 다시 편안해져요. 그럼 또 매너리즘에 빠지겠죠? 그러면 다시 불편한 걸 찾아서 그걸 편하게 만들고, 그걸 반복하는 거예요.

이건 스스로 디자인해야 하는데, 환경에 맞춰 잘 찾아야 해요. 제가 추천하는 방법은 작은 것부터 시작하는 거예요. 작은 걸 1년 동안 하다 보면 많이 쌓이죠. 켄트 벡이 쓴 책 <익스트림 프로그래밍>에는 ‘베이비 스텝스(baby steps)’라는 개념이 등장해요. ‘아기 발걸음’으로 뭔가를 한다는 의미죠. 제 아이가 15개월일 때 동료들에게 이 책을 읽어 줬었는데, 실제로 아이가 걷는 법을 학습하는 방식을 보니 이 책의 ‘베이비 스텝스’가 오버랩되더군요.

아기 발걸음은 어떤가요? 우리 아기는 15개월일 때 잘 못 걸었어요. 그런데 눈만 뜨면 계속 걸으려고 하는 거예요. 그렇게 걸음을 배우죠. 그런데 우리가 그렇게 뭔가를 학습하는 방법을 아기한테 가르쳐 준 적은 없죠. 아기는 그냥 계속 하고, 그걸 한 몇 주 하다 보니 혼자 잘 걷게 돼요. 이게 학습의 비밀이라고 봐요.

특히 지식노동은 이렇게 학습하는 거라고 봐요. 작은 것부터 반복하다 보면 그걸 잘할 수 있게 되고, 그걸 잘할 수 있게 되면 또 다른 작은 걸 시도해서 또 잘하게 하는 거죠. 그래서 프로젝트에서 배워야 하는 건 이런 과정을 통해서 찾아야 한다고 생각합니다.

김: 예전에 법무부 프로젝트를 한 적이 있어요. 교도소로 출근을 하고, 검찰 담당자들에게서 업무를 배우기도 했죠. 쉽게 접하기 힘든 분야라 재미있었어요. 프로젝트를 하다가 성격이 맞는다면 오래 해도 괜찮다고 봅니다. 참고로 이런 분야는 특수분야라 나이가 들어도 일자리가 있어요.

하지만, 답답한 부분도 있죠. 민감한 데이터가 많다 보니 가짜 데이터만 가지고 프로젝트를 하기도 합니다. ‘장님 코끼리 만지기 식’으로 개발을 해야 하죠. 지인이 비슷한 프로젝트를 한 적이 있답니다. 범죄 데이터를 다루는 거였죠. 보안 등급상 실데이터는 보지 못하고 프로젝트를 했답니다. 물론 상용화 이후 적절한 후속 조치는 했지만요. 아무튼 매우 힘들었다는군요. 그런데 나중에 회사를 매각할 때 이런 경험이 높이 평가되기도 했답니다. 낮게 보았던 경험들이 다른 상황에서 높게 평가된 거죠.

SI 프로젝트, 특히 공공분야라면 답답한 부분이 많은데요. 시작하는 입장에선 어떤 경험이든 일단 해두면 나중에 다 도움이 되는 것 같아요.

Q. 지금까지 SI 회사에서 경력을 쌓아왔지만, 중소기업의 한계인지 사업 자체의 한계인지, 이 회사의 개발자로 계속 있는 게 맞을까 하는 생각이 들었어요. 작은 규모의 SI라 어려운 건지, 큰 회사도 마찬가지인지 궁금합니다. 혹시 SI를 그만두고 서비스 회사에 도전해야 할까요? 

질문자 사연: 처음에 지방에서 공공 유지보수를 한 2년 정도 했어요. 그러다 기회가 돼서 수도권에 올라와 계정 권한 관리라는 도메인으로 자동차 제조사, 디스플레이 제조사 등 대기업 쪽 프로젝트를 했죠. 그러면서 주변에 아는 사람이나 듣는 이야기도 많아지고, 스스로도 일이 잘 맞기도 하고 재미도 있어서 공부도 하다 보니 다른 걸 많이 접하게 됐습니다. 그런데 아는 게 많아질수록 현재 하고 있는 프로젝트가 저를 퇴보시키고 있다는 느낌을 많이 받았어요. 30~40명 정도의 회사인데, 기술도 새롭지 않고 도메인도 오래된 도메인이다 보니 변화도 어렵고요.

게다가 이제 4년 차로 중간 직급인데, 회사에 PM도 없어서, 사내 비슷한 연차의 다른 분이 PM으로 프로젝트를 두 개 진행하셨고, 일정 관리 같은 게 저에게도 조금씩 넘어오더라고요. 그러다 보니 특정 부분에 개발을 주도하는 역할과 동시에 일정과 클라이언트 관리도 해야 하고, 생산성을 높이는 작업의 일환으로 동일한 기간 내 개발 프로젝트를 두 개 수행하겠다는 회사 계획에도 따라야 합니다. 그런데 회사에서는 특정 솔루션에 대한 투자는 없고, 아직도 Java Web Project로 프로젝트를 수행합니다. 회사는 사람을 굴리는 데만 바빠 보여요. 그래서 “내가 여기 있으먼 내 커리어가 괜찮은 건가” 하는 생각이 저절로 들고요, 치열한 경쟁을 뚫고서라도 자체 서비스를 하는 곳으로 옮겨야 하는 게 아닌가 하는 생각이 듭니다.

저는 현 시점에서 PM을 하고 싶은 마음이 전혀 없는데, 기술은 퇴보하는 것 같고 회사 요구는 점점 더 PM쪽으로 향하고, 저는 PM을 하더라도 개발자를 동시에 하고 싶지만 프로젝트를 두 개나 해야 하다 보니 개발은 할 수 없는 거죠. 저는 이런 걸 원했던 게 아닌 것 같아요. 주변에 자체 서비스하는 회사에 계신 분들 이야기나 대기업 SI 분들 이야기를 들어보면 환경이 너무 달라 괴리감이 들었어요. 제 주변 신입 분들도 사실 비슷한 고민을 하시고요. 그만 두고 다른 걸 미리 준비해야 하나, 이직을 해야 하나, 아니면 회사 안에서 뭔가를 더 해야 하나, 그런 여러 가지 생각을 들어서 도움을 받고 싶습니다.

안: 비슷한 고민을 하시는 분들 이야기를 많이 들었어요. 상관없어 보일 수도 있지만, 아래 그림을 하나 보여드리고 싶어요. 예전에 저희 직원분이 이런 고민을 했어요. “고객사와 대화할 때 왜 항상 결과가 안 좋나?” 그때 상황을 제가 그려본 겁니다.

우리가 업무가 서로 다른 사람들과 대화를 할 때는 주제를 좁혀 놓아야 해요. 업무로 만나기 전까지는 다 다르게 살았잖아요. 게다가 잠깐 만난 사이니까, 대화 주제가 여러 방향으로 튈 수 있거든요. 잘 몰라서 서로의 스타일을 간 보기도 하고요.

그래서 대화를 시작하기 전에 “오늘 무슨 이야기를 할 건지” 지겹도록 이야기해야 해요. 그리고 잘 들어야 하고요. 만났을 땐 구체적인 화면이나 이미지 같은 것을 보면서 말하면 좋아요. 가장 중요한 건 컨텍스트를 이해하는 거죠. 그래야 잠깐 다른 곳으로 새더라도 다시 주제로 돌아올 수 있거든요.

왜 이 이야기를 하냐면요, 보통 회사를 다닐 때 회사 사람들과 충분히 대화하지 않아요. 서로 무슨 생각을 하는지 모르면 일이 진행되지 않는데도 말이죠. 몇 년 동안 대기업에서 DT, DX를 같이 해보았는데요. 오너와 전문 경영인, 차부장급의 의사결정권자들의 입장이 달라서 일이 잘 진행되지 않더라고요. 충분히 대화하지 않고 생각도 맥락도 공유가 되지 않는 거죠. 그러면 아무리 노력해도 일이 수포로 돌아가게 되어 있어요. 그래서 이런 문제가 많이 벌어지는 거죠.

특히 지금은 변혁기잖아요. 그래서 더 맥락 공유가 안 돼요. 예를 들어 DB가 통으로 짜여 있어서 구조를 많이 변경해야 하는데, 고객은 클라우드에 올려야 한다고 해요. 이건 오라클을 도입해야 한다는 식의 문제가 아니라, 네트워크가 분산되도록 프로그램을 다시 짜야 되거든요. 그런데 “그냥 해주세요”하고 등을 떠밀죠. 실행해야 하는 사람들은 토론을 통해 절충안이나 개선안을 만들지 못하고, 그냥 할 수밖에 없는 상황이 벌어지는 거죠. 이게 격동기에 벌어지는 사회 현상입니다.

이걸 남 탓하거나, ‘좋다, 싫다’라고 생각하기보다, ‘왜 이렇게 될까?’를 생각해 봐야 해요. ‘저 사람은 이렇게 하는 게 좋은가? 이걸로 돈을 버나? 이렇게 해야 가정이 평온한가?’ 등등을 말이죠.

질문자분 사례를 생각해 보죠. 회사는 그 일을 시켜야 돈을 벌고 월급을 줄 수 있는 거예요. 현재 시장구조가 그런 거죠. 이걸 현재의 시대상으로 이해하고 받아들였다면, 그다음엔 상호 이익의 관점에서 문제를 봐야 해요. 나도 좋고 회사도 좋은 걸 생각한다면 100% 통해요.

하지만, 경험이 부족할 때는 보고 배울 수 있는 좋은 샘플이 필요해요. 사수 같은 사람이 아니어도 괜찮아요. 내가 보고 배울 수 있는 사람이 회사가 아니더라도 어디엔가 있어야 하죠. 우선은 판을 크게 보시고 이익이 되는 방향을 찾아보면 좋을 것 같아요.

김: 저라면 떠났을 것 같아요. 저도 비슷한 이유에서 모 대기업을 나왔거든요. 1997년, 20대 후반 처음 입사를 했는데, 당시 대형 프로젝트들 PM의 나이가 36~38세였어요. 프로젝트를 나갔다 들어오면 PM실이라는 데 계시면서 하루 종일 바둑 두고 담배 피고 하더라고요. 제 미래라고 생각하니 떠나야겠다는 생각이 들더라고요.

그런데 나와서 좋았을까요? 아니요. 고생했어요. SI를 또 했죠. 하지만 후회하지는 않아요. 아직 그 기업에 입사 동기들이 남아 있어요. ‘나도 남아 있어야 했을까?’ 한때는 아쉬워한 적도 있죠. 하지만 저는 다른 선택을 했으니 이 상태에서 또 길을 찾아가야 했죠.

참가자: 저도 이야기를 듣다가 26년 차에 회사를 나온 사람으로서 한 말씀 보태고 싶어요. 안영회 님 말씀대로, 상황을 객관적으로 보면서 ‘이 상황이 불편하다’ 이상을 이해하려고 해야 해요. ‘이 사람들은 도대체 이걸 어떻게 이해하고 있는가?’ 이렇게 말이죠. 이런 일은 꽤 많이 자주 반복됩니다. 그래서 반드시 꼭 생각해 봐야 해요.

그리고 어떤 행동을 취할 때 나의 욕구없이 행동하면 똑같은 결과가 나오는 것 같아요. 저는 26년 동안 ‘호구’ 생활을 했는데(웃음) 왜 그렇게 된 건지 회사를 나와서야 알게 되었어요. 굉장히 후회했죠. 지금과 같은 상황이라면 이직을 적극 추천하지만, 스스로의 동기 없이 나오지는 않았으면 좋겠어요. 어설프더라도 동기가 있어야 해요. 그 답을 찾는 동안은 현재 직장에서 일을 했으면 해요. 나를 이해하는 시간을 갖는 거죠.

김: 맞아요. 어디로 가고 싶은지 결정하고 나오시면 좋겠어요. ‘회사가 싫어’ 라는 이유로 나오면, 다른 회사 면접을 볼 때도 이전 상황과 비슷해집니다. 새로운 회사에 입사해서도 똑같은 일을 할 가능성이 아주 높아요.

질문자: 처음에 이직했을 때, 더 이상 여기서 배울 게 없다 싶고 또 여러 개인적인 이유로 나오게 됐어요. 그런데 정말 다른 걸 하려고 해도, 지금 제 포지션 때문인지는 모르겠지만, 이직을 하고 나서 뭔가 도메인을 맡기보다 ‘펑크’난 데 자꾸 들어가게 되더라고요.

김: 아마 능력이 좋으셔서 그런 것 같아요. 사장은 자기가 풀고 싶은 문제에 그 일을 잘 하는 사람을 넣고 싶어 하거든요. 그 일을 잘 하시니 선택되는 거 같아요. 사장들의 나쁜 습관이긴 하죠.(웃음) 그런데, 그게 너무 답답하다고 생각하면 변화를 선택하는 게 맞다고 봐요. 다만 이직의 방향을 잡고 나오시는 게 좋습니다. 고여 있는 것보다 변화가 생기는 게 인생에 자극은 되죠.

유영모(이하 유): 시간 있으면 좀 더 제가 덧붙여도 될까요? 저는 “요즘IT”에서 “성장”에 관한 글을 쓰고 있고, 스터디를 진행하고 있기도 한데요. 비슷한 고민을 하는 분들이 많습니다. 질문자분도 개인의 성장, 경력 관리에 대한 고민이 깊은 상황인 것 같아요.

저는 “내가 성장해야 조직이 성장할 수 있다”라고 믿어요. 예전에 저희 회사 CTO님이 쓰신 “SI 개발 10년차인데 코드 좀 봐주세요”라는 글이 있어요. 그 글에서 CTO님의 결론은 “떠나라”였죠. 글을 보면 CTO 님이 코드를 봐달라고 한 SI 개발자에게 물어요. “스프링 프레임워크를 사용하고 계신데, 왜 그걸 선택한 건가요?” 그 개발자가 대답하죠. “고객이 선택해서” 또는 “이미 결정돼서 내려온 상황이에요.” SI 프로젝트에선 대부분 이렇게 대답합니다. 그런 환경에서는 “성장”을 이루기 어렵죠.

저는 그런 맥락에서 ‘떠나라’는 답변이 어느 정도 수긍이 가요. 그렇지만 문제 정의를 바꿔야 한다고도 생각해요. SI라는 환경이 문제라고 하면 거기서 더 이상 할 게 없어요. 환경 탓으로 그치면, 아무것도 할 게 없는 거죠.

예를 들어 공공 SI 분야에서 애자일을 하고 싶다 해도, 공공이라는 환경에서는 할 수 없을 거예요. 안 바뀔 거죠. 그런데 그렇다고 해서 애자일을 아예 못 해보는 거냐, 그렇지는 않다고 생각해요. 그러니까 SI라는 환경이 문제가 아니고, SI에서 무슨 일을 하는지 고민해야 한다고 봐요.

중요한 건 내가 성장하기 위해서는 내가 하는 일이 가치가 있어야 해요. 내 일을 좋아하지 않고 가치 없게 느끼고, 주변을 둘러보니 미래로 보이는 선임도 닮고 싶지 않고, 그렇다면 어떻게 해야 할까요? 저는 그렇게 말하시는 분들께 “똑같이 일하면 똑같이 되는 거”라고 말씀드려요.

떠난다고 해서 해결되는 것도 아니에요. 현실적으로 SI 경험만 가진 분들이 서비스 회사로 가기 쉽지 않아요. 면접 볼 때부터 좋지 않게 보거든요. 또 비전공자들이 SI 개발로 많이 넘어오다 보니, 전반적으로 SI 개발자에 관한 선입견과 허들이 생기는 것 같아요.

하나 명심하면 좋을 것 같아요. 지금까지 하던 대로 하지 않으면 된다고 생각해요. 남들이 시키는 대로, 내가 하던 대로 하지 않으면 되는 거예요. 예를 들어, TDD를 하고 싶지만 TDD를 할 수 없는 환경에서 나는 어떻게 하면 좋을까요? 남들이 아무도 하지 않더라도 TDD를 혼자 해보는 거예요. 혼자 개발을 할 수 있잖아요. 그렇게 해서 내가 그 경험을 쌓는 게 중요하죠. TDD할 수 있는 사람이 주변에 아무도 없다면, 그걸 하는 사람을 찾아가서 도움을 받아 가며 하면 돼요. TDD를 해본 경험이 그렇게 생기고, 다음에 이직할 때 큰 경험 자산이 될 수 있어요. SI 프로젝트에서 안 한다고 나도 안 하면 그 다음 성장으로 나아갈 수 없죠.

우리 팀원이, 우리 팀장이 안 한다고 해서 나도 안 하면 변하는 건 없어요. 변화의 시작은 ‘나’여야 하죠. 애자일도 나부터 시작하면 되는 거예요.

만약에 서비스 회사로 갔다고 해봅시다. 그런데 서비스 회사라고 해서 꼭 환경이 좋은 건 아니거든요. 좋은 문화를 가진 회사로 가야 좋은 거죠. 그런데 그건 가보기 전에는 알 수 없어요. 어떤 환경에 처할지 알 수 없으니, 어떤 환경이라도 나 스스로 학습할 수 있어야 한다고 생각해요.

몇 달 전에 <길 위의 대통령>이라는 다큐멘터리를 봤어요. 김대중 대통령 이야기에요. 대통령이 되기까지 실패를 많이 했더라고요. 거기 인상 깊은 말이 있었어요. “무엇이 되고자 하는 게 삶의 목표라면 실패한 인생이겠지만, 어떻게 살고자 하는 게 목표라면 값진 인생이다.” 예를 들어 내가 쿠팡, 아마존, 구글 개발자가 되고자 하는 게 삶의 목표라면 저는 실패한 인생일 수 있어요. 그런데 SI 시장에서 일하고 있더라도 내가 어떻게 살 것인지, 내 시간의 가치를 다르게 바라본다면 인생을 다르게 정의할 수 있죠.

김: 저는 선택의 문제라고 봐요. 가장 좋은 직장, 가장 좋은 환경을 찾아 떠날 수도 있죠. 물론 아닐 수도 있습니다. 각자 상황에 따라 다를 수 있어요.

약 10년 전만 하더라도, 저도 SI 시장과 문화에 대해 아주 비관적이었어요. 제가 고생을 많이 했죠. 심지어 “왜 저 친구는 저렇게 일을 못 할까” 이런 생각까지 했어요.(나쁜 생각) 그래서 후배들에게 “SI 오지 마라, 네카라쿠배 가라.” 이런 말도 했어요.

그런데 10년 전 어느 날 한 분을 만나고 생각이 바뀌었어요. 지방에서 월 50만 원을 못벌던 분이었어요. 유흥업계 종사자분이셨죠. 이렇게 살아서는 안되겠다 싶었는지 자바 스프링 6개월 교육을 받고 난 후 SI 프로젝트로 들어갔어요. 지금 월 200만 원을 받는다고 하더라고요. “공공 SI이지만 너무 행복하다. 예전에 비하면 너무 안정적인 직장이다. 아이한테 분유를 사다 줄 수 있게 되었다.”

제가 비관했던 그 곳이 그 분에게는 너무 고마운 일터였던 거죠. 이후 SI 산업에 대한 고민도 깊어졌습니다. 그냥 좋지 않게만 바라볼 게 아니라, 개선하고 좋게 만들어가야겠다는 생각을 하게 되었죠.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.