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

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

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

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

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

Q. 그냥 막연하게 사용했다면, DDD, 클린 코드 등의 개발 방법론을 프로젝트에 적용해 본 경험을 이력서에 적지 않는 게 더 좋을까요?

안영회(이하 안): “DDD, 클린코드 등, 이런 걸로 내 경력을 빛내야지” 이런 마인드를 가진 사람들을 주니어 프로그래머라고 불러요.(웃음) 시니어는 그냥 나이를 먹은 사람이 아니라, 문제를 제대로 정의할 수 있고 그걸 코드로 표현할 수 있는 사람이죠. 연차랑은 직접적인 관계가 없어요.

그래서 이런 질문은 사실 큰 의미가 없어요. 이력서를 평가할 때 DDD를 했는지, 클린코드를 했는지 이런 걸 중요하게 평가하지 않거든요. 특히 큰 회사라면, 받은 이력서가 수백 장일 텐데 그런 요소가 특별히 눈에 띄지 않아요. 그래서 읽히지 않는 이력서도 많아요. 이력서를 쓰실 때 많은 사람들이 그런 걸 고민하시지만, 사실 이력서를 검토하는 사람들은 별로 고민하지 않아요.

“기술 자체에 대해 생각하고 고민하는 것” 그건 개발을 익힐 때 필요한 거예요. 도구죠. “나는 재밌어서 그걸 해요.” 그런데 재밌다고 돈을 주는 건 아니잖아요. 필요한 걸 만들고 필요한 문제를 해결하라고 돈을 주는 거죠.

회사에서 필요로 하는 건 문제 정의와 문제 풀이입니다. 고객의 문제를 알고, 그걸 프로그램으로 변환하는 대가로 월급을 받아요. 그게 핵심이에요. 그걸 익혀야 해요. “개발”이란 정의를 그렇게 바꾸는 게 중요해요.

그런데 20년 차인데도 비슷한 고민을 하는 분이 많이 계시더라고요. 그런 건 좀 안타까웠죠.

최근에 ‘켄트 백’의 책을 하나 번역했어요. 개발을 두 가지로 나누어 보더군요. 영감을 받아 그린 그림이에요.

코드 정리(Tyding)와 동작 변경(behavior change)으로 나누어 보는데, 저는 ‘동작’은 외부의 평가와 관련이 있고, ‘설계’는 일종의 R&D 활동이자 미래 가치를 만드는 부분이라고 봤어요.

원래 개발 프로젝트에서는 ‘내가 원하는 시간 안에 뭔가를 달성할 수 있냐?’ 이게 중요해요. 원하는 시간 안에 그 기능이 나올 수 있어야 하죠.

하지만 ‘설계’는 여러 요소들을 유기체처럼 구성하는 일이에요. 개발자 입장에서는 R&D인 거죠. 그런 능력을 계속 키우면 기술이 바뀌어도 써먹을 수 있어요. 자바든 Go든 사실 프로그래밍 언어를 배우는 건 크게 어렵지 않아요. 설계가 어려운 거죠. 설계를 할 수 있으면 기술 환경 변화에 좀더 빨리 적응할 수 있어요. 그쪽의 쓰임새가 더 큰 거죠. 그러니 어떤 기술 하나에 집중하기보다 이걸 어떻게 해볼까 고민해보고, 그 경험을 쌓을 수 있는 프로젝트나 회사를 찾아보세요. 혹은 그런 훈련을 스스로 해보면 더 좋은 환경으로 가기에 유리해집니다.

내 감정이나 인터넷에 있는 검증되지 않은 정보를 바탕으로, 문제를 정의하지 말아야 해요. 그런 것만 보면 “SI 안 좋대”라고 단순히 말하게 되죠. “왜 이렇게 돼 있지?” 라고 질문하고 바라볼 수 있어야, 노력 대비 효과를 크게 얻는 행동 변화를 만들 수 있어요.

이직을 하거나 하지 않거나 크게 관계 없어요. 내가 이 문제를 어떻게 정의하느냐가 중요하죠.

김수보(이하 김): 제가 아는 한 분 이야기를 해드릴게요. 대구에서 대학교를 나왔고 개발자가 아니었어요. 구미에서 SI를 하다가 회사가 망한 뒤에 서울로 올라와 계속 SI를 했어요. 당시는 40대 초반이었습니다.

그런데 신기술을 하고 싶었어요. SI 프로젝트에서는 하기 어려웠죠. 그런 프로젝트가 없었으니까요. 그래서 그 분은 위시켓에서 적당한 프로젝트를 찾았어요. 단가가 낮고 한 달 안에 끝낼 수 있는 수준으로 말이죠. 1000만원 짜리가 아니라 200만원 짜리를 고른 거죠. 또 시간을 통제할 수 있는 것만 골랐어요. 그런 프로젝트를 하면서 신기술을 공부했죠. 다른 프로젝트를 할 때 그 경험을 넣었고요.

그렇게 신기술도 공부하면서 돈도 꽤 벌었어요. 작은 프로젝트로 신기술을 쌓고, 그 경험으로 큰 프로젝트를 하죠. 그리고 그렇게 인연이 맺어진 고객은 또 일을 줍니다. 매번 협상 티켓을 가지고 있는 셈이죠. 스스로 성장을 위해 많이 노력하고 계신 거고요. 정말 반성을 많이 했습니다. 저도 그분을 보고 닮고 싶다는 욕심이 생겼죠.

어디 회사에 들어가실 생각은 없으시대요. 계속 SI 개발로 먹고 살겠다는 생각을 하더라고요. SI 분야에도 그렇게 자기 생각을 명확히 하고 사는 분이 계십니다. 반면에 “단순히 CRUD만 하면 고급 단가를 받을 수 있어. 먹고 사는 데 지장 없는데 뭘 더 해야 하냐?!”고 외치는 분도 계시더라고요.

참가자: 제 친한 친구 중에도 SI에서 성장한 케이스가 있어요. 저랑 연차가 비슷한 안드로이드 개발자인데요. 친구가 다닌 곳을 보니 SI라고 다 나쁜 회사가 아니더라고요. 좋은 기술을 쓰는 좋은 프로젝트도 있어요. 그런 곳에서 뭔가 하나라도 건질 수 있으면 그 다음엔 더 좋은 환경으로 나아갈 수 있는 것 같아요. SI 프로젝트도 1~2년 동안 기술적으로 커리어 관점에서 원하는 걸 얻을 수 있다면 과감히 해보는 것도 좋은 것 같아요.

Q.공공 SI에 애자일 방법이 적용될 수 있을까요? 

질문자 사연: 주로 아카이브 사업을 하고 있고, 박물관, 도서관, 기록관 등의 프로젝트를 진행하는 회사에서 5년 정도 근무하고 있는데, 회사에서 SI 사업에 애자일 방법, 특히 스크럼 방식을 도입해 추진해 왔어요. 거의 다 실패했는데, 그렇다고 애자일을 포기하지는 않은 상태입니다. 애자일을 어느 정도 저희 환경에 맞게 소화해 적용하고 싶은데, 항상 실패하는 게 답답해서 광범위한 질문을 던졌어요.

안: 제가 최근에는 공공 SI를 해본 적은 없어요. 그럼에도 도움이 될 만한 이야기를 제 경험에서 꺼내볼게요. 저는 이걸 “고객 요구를 어떻게 현명하게 협상할 수 있을까?” 라는 관점에서 이야기하려고 해요.

2008년에 H그룹에서 프레임워크를 만드는 일을 1년 동안 한 적이 있어요. 프로젝트 책임자였죠. 그때 당시 애자일 방식으로 일하고 싶었습니다. 참고로 그 당시는 지금보다 애자일이 더 생소했어요. 그래서 많은 사람들을 설득해야 했죠.

SI 프로젝트에서는 착수금 외에 중간검수를 받고 정산을 합니다. 부조리가 있을까 봐 큰 회사는 독립된 품질팀이 검수를 해요. 심지어 군 사업을 할 때 보니, 감찰 부서에서 하더라고요. 그때 객관성을 보여주기 위해 프로젝트 내용과 관계 없는 객관적인 기준을 내라고 요구해요. “애자일”스러운 것과는 꽤 거리가 있죠. 그런데 이런 부분까지 잘 넘겨야 신뢰가 생겨요. 그래야 협상이든 조정이든 할 수 있고요. 신뢰가 없으면 모든 게 엎어질 수도 있죠.

저는 검수 과정에서 요구하는 객관성, 융통성 없이 “하기로 한 대로 하라”고 한 부분까지 중요하게 생각했고 꽤 성공적으로 대응했죠. 그렇게 인정을 받고는 “애자일”하게 일할 수 있는 부분을 조금 더 넓힐 수 있었어요.

애자일 실패 사례를 수도 없이 들었어요. 실패한 분들과 이야기 나눌 기회가 되면 진지하게 여쭈어보죠. 그러면 매번 드러나는 패턴이 있더라고요.

우선, 애자일에 대한 정의가 불분명해요. 반 이상은 애자일의 핵심보다는 애자일의 어떤 형식들을 이야기해요. “우리는 칸반을 만들어요, 스크럼을 해요” 이런 말씀들이죠. 사실 가장 위험한 게 ‘스크럼’ 입니다. ‘칸반을 어떻게 나눠서 자르고 붙이느냐?’ 이건 그냥 엑셀로 해도 똑같아요. 굳이 전문 도구를 쓸 필요가 없어요. 사실 중요한 건 스크럼이 아니라, 그 내용이에요. 칸반을 만들고 아침에 데일리 미팅을 주기적으로 한다? 그건 사실 그냥 회의랑 똑같죠. 아무리 포장해도 회의거든요? 애자일을 해서 어떤 문제를 해결할 건지, 그 결과를 어떻게 드러낼 건지, 그게 더 중요한데 말이죠. 대부분 그 기준은 갖고 계시지 않더라고요.

프로젝트에 투입되는 사람들은 애자일을 모두 다르게 생각해요. 서로 생각이 같아야 진행이 잘 될 텐데, 애자일 코치가 있는 조직마저도, 코치와 조직원들 생각이 다 달라요. 이러다 보면 더 큰 문제가 생겨요. 고객한테 ‘애자일’ 방식으로 하겠다고 했고, 고객이 수락을 했습니다. 수락을 했다는 건 고객이 우리에게 키를 넘겨줬다는 것이죠. 고객은 우리가 잘하는지, 어떻게 하는지 지켜봅니다. 그런데 우리는 이제 어떻게 잘할 건지에 대해서는 계획이 없죠. 스크럼 같은 형식에 대해 이야기할 수는 있지만, 그걸로 뭘 얻었는지 설명하기가 어렵고, 얻은 게 있더라도 잘 설명하지 못하죠.

“빙산의 환각”이라는 그림을 떠올려보세요. 많은 사람들은 성공한 사람 이야기의 보이는 것만 믿고 높은 기대감을 가지죠. 하지만, 그 성공을 하기 위해서는 말 하기 힘든 창피한 일들도 있고, 어떤 일을 했는지 말하기 힘든 일들도 많죠. 저도 PM 일을 할 때, 직원들이랑 소통이 잘 안 되어서, 5일 내내 1대1로 저녁밥을 먹었어요. 스파게티도 먹고 골뱅이도 먹고 술 한 잔도 하고, 술 못 먹는 애랑은 치킨도 먹고, 같이 앉아서 마음도 풀어주고, 제가 뭘 의도하는지 설명하고 그랬죠. 프로젝트를 성공시키는 데는 그런 안 보이는 일들이 많거든요.

그런데 그 안 보이는 일을 다 ‘애자일’이라는 용어 안에 담기 어렵습니다. 하지만, 애자일에서 가장 중요한 건 ‘칸반’ 같은 형식적인 것들보다 그런 빙산 아래 보이지 않는 부분들이죠.

질문자: 저는 애자일이 어떤 정신 같은 거라고 생각해요. 진짜 문제를 해결하고 싶은 마음에 애자일 정신에 공감하는 거고요. 고객의 니즈를 정확히 파악하고 진짜 고객을 만들고 싶은 것이죠. 애자일도 그러한 목적으로 나왔고요. 고객도 정보 시스템 전문가가 아니다 보니, 요구사항도 많이 바뀌는데요, 그런 걸 조금 더 적극적으로 수용하고 싶은 게 애자일을 하고자 하는 것의 핵심인 것 같아요. 그중에서도 저희가 주로 하는 게 아카이브 사업이다 보니, 그 사업에서 고객이 진정으로 원하는 걸 만들어내면 우리가 서로 윈윈할 수 있지 않을까 싶은 거죠.

실패의 이유로는 1차적으로 공공SI 고객이 문제였고, 두 번째는 내부 팀원도 문제였다고 생각해요. 고객은 폭포수처럼 일을 주고 있었고, 내부에서만 애자일 이야기를 하다 보니 결과적으로는 납기 맞추기에만 매몰됐죠. 고객은 열정이 넘치는데, 팀원들은, 특히 신입 분들은 그런 부분에 부족한 점이 있는 것 같아요. 수동적인 분들이 많고요. 내가 뭘 하면 되는지를 정해주길 바라고, 적극적인 참여를 안 하더라고요.

김: 애자일로 해보겠다고 했을 때 반응해 주는 고객사도 있어요. 왜냐면 운영책임을 안고 있는 고객들이죠. 애자일이 업무에 도움이 된다면, 배우려고 합니다. 그런데 공공은 그렇지 않아요. 때가 되면 순환보직으로 다른 데로 갑니다. 자기가 없어도 이 일이 돌아가야 하니, 새롭게 일을 더하고 싶어하진 않거든요.

공공은 일 문화를 타파하기 힘든 영역이에요. 그래서 크게는 폭포수 개발방법론, 일정 구간만 애자일을 하기도 해요. 고민의 100%는 다 못 풀고 한 30%만 푸는 거죠. 저는 그것만 하더라도 조직에 플러스가 될 수 있다고 생각합니다. 점차 훈련이 되면 회사가 좀 더 가벼워지기는 하더라고요. 하지만, 공공 SI는 규제의 룰로 움직이는 곳이라, 전체를 바꿀 순 없더라고요. 그래서 일부만 잘라서 애자일 하겠다고 제안하는 것도 좋을 것 같아요.

안: 제가 예전에 “SI에 과연 애자일 적용이 가능한가”라는 강연을 한 적이 있어요. 공공은 사실 제가 정확히 모르고, 제가 한 16년 해온 방식을 그대로 적용하기는 어려우실 것 같아요. 저는 프로젝트를 만들 때 개입하니까, “갑”과 교감이 있는 상태거든요. 그 경우는 “애자일”을 도입할 수도 있습니다. 하지만, RFP가 다 나와 있고 개발만 하라는 상황이면, 기본적으로 애자일하기 되게 어려워요.

왜냐면 결국은 사업이잖아요. 시간이 되면 제때 끝나야 하거든요. 그래야 모두가 행복해지죠. 돈이 안 나오면 애자일이고 뭐고 다 필요 없어요. 다 끝이에요. 회사가 부도 날 수도 있잖아요.

컨설팅 회사의 특징은 PM 이 영업할 때부터 개입을 해요. 그래야 플래닝을 하면서 프로젝트를 조율할 수 있거든요. 어느 일은 1~2달 여유를 줘라, 언제까지는 30% 실행하고, 나머지는 이렇게 계획을 세우자, 그다음에 우리가 합의할 수 있게 하자. 이런 이야기들을 다 나눈 다음에 개발을 시작하죠.

그런데 이런 과정 없이 계약을 했다면, 그것 자체가 애자일하기 어려운 환경으로 출발하는 겁니다. 검수, 계약 과정이 개발 전에 끝이 나니, 프로젝트를 쪼개서 애자일하기는 쉽지 않죠.

김: 그렇게 사전 작업 없이 계약한 경우라면 애자일보다는 일단 프로젝트를 잘하는 것에 초점을 맞추면 좋을 것 같아요. 갈등 상황이 적고 팀원들이 진심을 가지고 개발할 수 있는 환경을 만들어주는 게 낫지 않나 싶네요.

안: 이런 맥락에서, 고객 요구를 현명하게 협상할 수 있는 방법이 있다면 어떤 게 있을까요?

켄트 벡은 애자일 선언문의 핵심 멤버인데요. 최근에 <Tidy First?>라는 책도 냈어요. 애자일 선언문에서 ‘Customer collaboration(고객 협력)’과 ‘Contract negotiation(계약 협상)’이라고 표현된 부분이 있어요. 켄트 벡은 이 문제를 푸는 게 자기 사명이고 개발 문화를 전진시키는 길이라고 생각하는데요. 오랫동안 풀리지 않는 문제가 이 두 가지이기도 하죠.

즉, Contract negotiation을 넘어 고객과 “협업”해 보자는 의미입니다. 그런데 Contract negotiation을 극복하려면 협상을 해야 하죠. 프로젝트가 만들어지는 과정에서 어떤 걸 기준으로 돈을 줄지 협상되어 있어야 해요. 그래야 나머지를 탄력적으로 같이 찾아갈 수 있죠.

“부품 조달해”, “검수하고 줄게”, 하는 건 제조업 방식이에요. 소프트웨어를 이 관점으로 보는 분들이 아직 많죠. 그런데 collaboration은 지식노동 방식이에요. 지식 노동은 나 혼자 정해진 방식으로 할 수가 없잖아요.

주니어들이 소극적이라고 하셨잖아요. 그럴 수밖에 없는 게 업무를 잘 모르거든요. 업무를 모른다는 게 일 자체를 모른다는 게 아니라, “업무”에 포함된 정치나 기업문화를 모른다는 거예요. 그런 걸 모르면 주눅이 들고, 회의에도 편하게 참여하지 못 해요. 경험자의 설명이 좋게 들리기는 해도 실제 구현된 모습은 상상할 수 없죠.

그래서 적극적으로 하기가 어려운 거예요. 그런데 협업을 하려면 티키타카를 할 수 있어야 하잖아요. “나 이런 거 하고 싶어”, “나 무슨 뜻인지 알아, 그걸 하려면 이렇게 해야 해.” 라는 아이디어가 계속 오갈 수 있어야 해요. 그런데 그런 대화를 하기 어렵죠. 그런 대화가 곧 collaboration인데 말이죠.

그런데 사실, 공공 영역에서는 Customer collaboration이나 Contract negotiation은 어려운 것 같아요. 하지만 환경 탓만 할 수 없죠. 내 환경에서 내가 원하는 방식으로 원하는 돈을 받고 일할 수 있는 것에 집중해야 할 것 같아요.

현장 질문

※ 세션 후반부에는 사전에 받은 질문에 대한 답변이 끝난 뒤 현장에서 추가로 질문을 받고, 편안하게 이야기를 나누는 식으로 진행됐습니다.

Q. 물경력인 것 같은 4년 차, 어떻게 경력 개발을 해야 할까요? 

질문자1: 4년 차 프론트엔드 개발자예요. 신입 때는 경력을 어떻게든 쌓아야겠다 싶어서 SI든 뭐든 해야겠다 싶어 SI로 시작했어요. 그런데 하다 보니 회사에서 백엔드, 하이브리드도 시키고 해서 프론트엔드로서의 경력이 이상해지는 것 같더라고요. 물경력 같기도 하고요. 그래서 이직 자리를 알아보려 해도, 지원서를 내도 피드백이 잘 안 오더라고요. 그래서 어떻게 경력을 채워야 할지, 중고 신입으로 들어가야 하는 건지 고민이 됩니다.

김: 최근에 들어간 프로젝트가 몇 명짜리 프로젝트였어요?

질문자1: 한 20-30명 정도였어요.

김: 프로젝트를 함께 하는 분들과 친해지는 게 중요해요. 저도 배우고 싶거나 트렌디한 기술이 있으면 그 기술을 하는 SI 프로젝트를 찾아다녔어요. 회사를 옮기기도 하고요. 그런데 그 전에 프로젝트를 함께 뛴 팀원들과 좋은 관계를 이어갔어요. 술을 마셔서 친해지라는 게 아니에요. 실력을 증명해야 하죠. 나중에 ‘같이 일하자’는 제안을 할 수 있도록요.

같이 일하자는 제안을 받는다는 건, 그 일을 맡겼을 때 잘 해낼 수 있다는 믿음이 있으니까 해주는 겁니다. 자기 몫을 다 하고, 동료들에게 그걸 잘 어필하세요. 그러면 그때 함께 일한 동료가 다른 상황에서 함께 일하자는 오퍼를 해요. 그러다 보면 내가 프로젝트를 고를 수 있는 상황이 되죠.

적지 않은 괜찮은 프로젝트들이, SI 프로젝트 소개 플랫폼에 안 나와요. 지인을 통해서 그런 기회를 얻는 경우가 많죠. 프로젝트를 돌아다니다 보면, 정말 실력있는 분들을 만나게 되는데, 그 사람과는 반드시 친해지세요. 프로젝트에 들어가서 조용히 내 일만 하는 건 정말 좋지 않아요. 그건 스스로를 단순 노동자로 만드는 겁니다. 단기 참여라고 하더라도 좋을 관계를 만들어 놓는 게 핵심입니다.

Q. 아직 초보라 업계 돌아가는 방식을 알고 싶어요.

질문자2: 저는 SI 스타트업에서 일하고 있는 디자이너인데, 아직 신입이다 보니 업계가 어떤 방식으로 돌아가는지, 어떤 일을 하는지에 대해서 잘 몰라요. 그런 걸 알고 싶어서 왔어요. 금융 보험 계약 서류를 웹으로 작성하는 제품 관련 일을 하고 있어요.

안: 보험업은 변화가 굉장히 어려운 곳이에요. 보험 상품 자체가 너무 복잡하고 옵션이 많거든요. 설명을 들어도 무슨 소리인지 알 수 없죠. 그걸 간단하게 하려고 ‘다이렉트’란 게 등장했죠. 특히 아이패드, 갤럭시 탭 같은 태블릿PC가 나오면서부터 다이렉트 전환이 일어났어요.

보험회사가 그걸 하는 이유는 간단해요. 계약을 빠르게 진행해야 해서죠. 보험 상품을 그럴듯하게 소개해 고객이 계약을 막 할 것처럼 이야기해 놓고도 계약을 진행하지 않을 수 있잖아요. 그런데 일단 계약을 해두면 위약금을 물게 하거나 수수료 등을 청구할 수 있어서 수익이 엄청나요. 그래서 그 자리에서 바로 계약을 할 수 있는 게 보험사에는 중요하죠.

이런 특수한 분야들은 다 복잡한 사연이 있어서, 그 사연을 이해하고 커리어를 개발해야 해요. 아니면 보편적인 방향으로 잡고 기술을 쌓을 것인지. 그 결심을 하는 게 먼저인 것 같아요.

지인 중에 “보험 보상”쪽 스타트업 하는 분이 있어요. 보상에 필요한 서류를 간편하게 처리할 수 있도록 일을 하고 있죠. 단순한 건 자동 처리하고, 사람이 보고 심사해야 하는 부분은 알려주는 일을 해요. 저와 같은 컨설팅 회사를 다니셨는데, 헤어진 이후에는 다른 테크트리를 탔죠.

저는 혁신, 기술 개발, 데브옵스 쪽으로 관심을 두고 왔고, 그분은 보험이라는 특수한 분야에서 국내 유명 보험사의 전략기획을 맡았어요. 보험 쪽을 정말 잘 알다 보니 이직 제안도 많이 받았지만, 기업문화가 마음에 안 든다고 직접 창업을 하셨더라고요.

커리어도 다 사람이 하는 일이라 계속 천천히 학습해야 돼요. 나한테 맞는지 안 맞는지, 어떻게 바꿔야 하는지를 직접 체험해 봐야 해요. 학습은 체험을 통해 얻을 수 있거든요. 커리어 초반에는 학원 등 수동적인 학습도 하죠. 하지만 초반이 넘어가면 무조건 스스로 해봐야 해요. 나한테 맞나, 계속할 수 있나, 내 퍼포먼스가 어떤가, 이런 질문들이 필요합니다. 계속 해보면서 경험을 쌓아가야 합니다. 그래야 안목이 생기고 다음 선택을 할 수 있어요.

또 내가 하는 일만 생각하기보다 옆 사람은 뭐하나, 어떻게 하면 잘하나, 들여다보고 인맥도 쌓으면서 배워가야 해요. 경력이 20년이 넘어가면, 주변 사람들이 대부분 예전에 함께 일했던 사람들로 남아요. 중요한 일을 하려고 하면, 나도 모르게 ‘이 일 잘할 만한 사람’으로 그 친구가 떠오르죠. 당장 필요한 답이 아닐 수 있지만, 큰 방향은 그렇게 그려보시면 좋을 것 같습니다.

마치며

김: 사실 지금의 SI 시장은 SI라기보다는 ‘IT서비스’ 시장이라고 부르는 게 더 맞아요. 미국 시장에서는 ‘엔터프라이즈 마켓’이라고 부르죠. 저도 SI라는 용어를 쓰지 않으면 좋겠는데, 오늘 이 자리에서는 직관적인 용어를 쓰는 게 좋을 것 같아 SI라고 했어요.

저는 국내 엔터프라이즈 마켓도 신입생들이 건강하게 유입되면 좋겠어요. 그래야 건강한 생태계를 유지할 수 있으니까요.

저는 SI에서 했던 경험들이 좋았어요. 기술을 쫒아서 이직을 하고 프로젝트를 맡았어요. 하루에 한 6억 건 이상 트래픽을 처리해 봤고, TCP/IP 프로토콜 맞추는 것부터 프로세스 설계까지 섬세하게 작업을 했죠. 일반 개발자들이 쉽게 접해보기 힘든 경험들이었고, 저는 그 때 흘린 땀에 대해 자부심이 있어요. 그런 게 SI라서 가능했다고도 생각해요.

은행 전산실에 갔다면, 큰 프로젝트 하나를 끝내놓고 그다음엔 운영 업무를 하다가 은퇴했어야 할 거예요. 물론 회사에 다니는 동안 괜찮은 보수를 받고 재테크를 할 수 있었겠죠. 하지만 저는 제 인생에서 기술을 계속 하고 싶었고 그런 선택을 해왔다고 생각해요.

SI도 그냥 “SI를 한다”’에 그치는 게 아니라, 그 안에서도 내가 원하는 걸 찾고 그걸 위해 나 자신을 자꾸 바꾸어 나가는 게 필요하다고 생각해요.

저는 이런 이야기가 지방 대학에도 꽤 퍼지면 좋겠다는 생각을 했습니다. 이노베이션 아카데미에 근무할 때 경남지역에서 올라온 친구에게 물어본 적이 있어요. “서울에서 공부하니 가장 좋은 게 뭐예요?” 하고요. 그 분은 “대학 다닐 땐 진짜 개발자를 본 적이 한 번도 없어요. 그런데 서울에 오니 많이 만나볼 수 있어 좋아요.” 라고 답했죠.

학생들이 생각보다 현실판단을 잘합니다. 자기가 네카라쿠배에 갈 수 없다는 것도 알고요. 다만 SI 이야기가 너무 나빠서 걱정하더라고요. 그래서 아예 지원할 엄두도 안내더군요. 그래서 정보가 없는 학생들이 굉장히 나쁜 환경에서 IT산업에 진입하는 경우가 많습니다. 이런 자리를 통해서 더 많은 분들께 SI산업 이야기도 전해지면 좋겠다는 생각이 들었습니다. 그래서 오늘 같은 자리를 마련했습니다. 앞으로도 마련해 볼 예정이니 꾸준한 관심을 부탁드립니다.

저는 현재 “한빛앤”이라는 곳에 있고, 사무실이 홍대 쪽에 있어요. 근처 오셔서 연락주시면 점심 사겠습니다.

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