코펜하겐고양이

나의 가장 큰 장점이자 단점은 호기심이 많아 다양한 것에 관심이 많고 빨리 배우는 동시에 그만큼 싫증도 쉽게 느낀다는 점이다. 옛말에 재주가 좋으면 먹고살기 힘들다는 말처럼 다재다능해 보이지만, 결국 아무것도 제대로 할 줄 아는 게 없는 저주. 

작년에 서비스기획이라는 실무를 배웠는데(말 그대로 배웠다. 현재 그 일을 하는 것은 아니므로), 그러고 나니 내가 있었으면 좋겠다고 생각했던 앱 서비스를 구체화해보고 싶다는 생각이 들었다. 부지런하다면 벌써 정리가 끝나고도 남을 시간이었지만, 게으르기 그지없는 나는 아무것도 하지 않고 허송세월만 보내고 있었다. 그러다가 이번 달부터 스터디 모임을 알게 되었고, 그 스터디에서 내 아이디어를 구체화해보자는 생각으로 참여하게 되었다.

여러 분야에서 일하는 사람들이 모였고, 개발자, 실무 서비스기획자도 있었다. 스터디를 하면서 우리 회사에는 IT 기획 직군이 없기 때문에 내가 조금만 역량을 키우면 분명 큰 도움이 될 거라는 우물 안의 개구리 수준의 착각이 산산이 부서지고 있다. 주고받는 피드백 중에는 잘 못 알아듣겠는 용어가 30% 정도는 되는 것 같다. 다이내믹 링크, 노출 빈도, 가중치, CPC, CPM... 개념을 아예 못 잡고 있는 것도 있고, 특히 온라인 광고의 세계는 그 자체가 알고리즘으로 무장되어 있어서 단순히 네이버 검색 화면에서 배너나 키워드 광고만 봐서는 그 뒤에서 일어나는 수많은 일들을 이해하는데도 시간이 필요했다. 게다가 하고 싶은 서비스의 비즈니스 모델도 정리가 채 되지 않아서 여간 고민이 되는 것이 아니다. 수익모델을 찾아서 기본 서비스 설계에 녹여놓지 않으면, (지금은 없지만 언젠간 하게 될) 개발자만 고생하고, 외주를 쓴다면 돈을 버리는 일이 될 것이다. 

내가 하겠다고 신청하긴 했지만, 2주가 지난 지금, 너무 괴롭다. 퇴근하고 돌아와서는 쓰러저 자기 바쁘고 솔직히 몸과 마음이 움직여지지 않아 숙제를 미루다가 결국 이렇게 금요일 밤에는 항상 마음이 조급하고 불안해진다.

6월 첫주까지. 끝까지 잘할 수 있을까?

IT팀으로 오면서 좋은 점 하나는 회사 전산 시스템의 논리를 알 수 있는 지도를 갖게 되었다는 점이다. 논리 체계를 대부분 이해할 때까지는 아직 많은 것을 더 들여다보고 공부해야하지만, 논리를 파악하는 방법을 알았다는 것만으로도 내가 해야하는 역할과 그 가능성이 확실해지는 느낌을 받았다. 문제 해결 관점에서 개발자가 아닌 내가 IT부서에서 무슨 역할을 해야하는지 말이다.

어느 중소기업과 마찬가지로 우리회사도 인력관리에 대한 구조적인 문제가 있다.

업무 메뉴얼은 잘 갖춰져 있지 않은 상태에서 5~10년차 정도 되면 많은 사람들이 더 좋은 처우를 받기 위해서 이직을 한다. 특정 시스템을 홀로 담당하던 선임이 그만두면 연차가 어린 사원들은 인수 인계나 업무에 대한 사전 파악을 할 겨를도 없이 맨 땅에 헤딩하듯이 수 많은 문제 상황을 혼자 부딪치고 고군분투하면서 일을 해나가게 되는데, 과거에 하던 일을 누군가에게 안정적으로 넘기고 새로운 업무를 시작한 것도 아니어서 결국 본인 담당인 업무는 늘고 일은 잘 안풀리는 어려움을 겪는 것을 많이 보았다. 어쨌든 고생해서 문제를 안정화시키고 나면 뭔가 보상이라도 받을 수 있으면 좋으련만, 외부의 시선으로 봤을 땐 개선이나 신규 시스템을 도입을 한 것이 아니라 당연히 해야하는 일이 문제가 생기지 않게 한 것 뿐이기 때문에 특별한 보상은 거의 없다. 이렇게 지낸 사람은 결국 몇 년 지나서 5~10년차가 되면 지치고 회사에 대한 믿음을 잃어 회사를 떠나는 악순환이 발생하고 있다.

이러다보니 그룹사 통합의 하나의 전산을 여러 회사가 공통으로 쓰고 있지만, 동일한 업무를 하는데도 각각의 회사가 다른 화면을 보면서 일하는 경우도 많고, 또 어느 회사는 아무 문제 없이 잘 활용하고 있는 기능을 다른 회사는 단지 아무도 설명해주지 않아 몰라서 일명 노가다로 문서작업해가면서 일하는 경우도 있다.

얼마 전에 요청들어온 업무도 같은 상황이었다. 나도 잘 모르는 영역의 데이터 확인에 대한 일이라서 처음에는 어떻게 해야하는지 막막했지만, 시스템 속 정보를 추출하는 쿼리를 확인하고, 해당 테이블의 데이터 목록을 보니, 요청한 데이터가 이미 연결된 테이블에 기록되는 정보였고, 단순히 표시만 해주면 되는 일이었다. 그리고 살펴보다보니, 요청하는 데이터를 더 쉽게 확인할 수 있는 별도의 화면도 시스템에 구현되어 있어서 타 부서는 활용하고 있는 상태였다.

IT부서에서 활용하는 SQL이나 시스템 개발 소스를 보는 방법을 몰랐던 예전이었다면, 수많은 부서의 사람들에게 수소문을 하고, 그러다가 이 사람과 저 사람의 얘기가 달라서 혼란스러워하면서 스트레스 받았을 일을 비교적 쉽게 해답을 얻었다. 그리고 예전의 나처럼 혼선을 겪고 있을 업무 담당자에게 도움을 줄 수 있는 능력을 얻었다.

회사 전체의 시스템을 지구라고 한다면, 나의 수준은 아직 동네 한바퀴 정도이지만 이 것만으로도 소소한 보람을 느낀다. 회사에서 데이터와 관련된 일을 하게 될 것이라고 들었을 때, 내가 궁극적으로 회사에서 어떤 역할을 담당해야 하는 것일까를 고민하다가 '비즈니스의 구석구석에서 만들어지는 각종의 정보들을 필요에 따라 이어줄 수 있는 연결다리가 되어야 하고, 그게 누구나 쉽게 알아볼 수 있는 정보 지도를 만드는 것이 나의 최종 업무목표겠구나'를 생각했었는데, 아주 작은 부분이더라도 그런 일들을 감당하고 있다는 사실이 기쁘다.

IT 부서에서 일을 하기 시작하고 첫 일은 전사 교육을 진행하는 것이었다. 새로운 팀에서 새로운 일에 대한 개념을 잡거나 목표를 그리기도 전에 당장 급하게 처리해야 하는 큰 행사가 눈 앞에 닥쳤기 때문에 마음은 분주했지만, 그래도 크게 부담은 없었다. 내가 직접 가르쳐야 하는 것도 아니었고 강사도 섭외가 되어 있었고, 나는 그저 사람들에게 교육의 취지를 알리고 참석을 독려해서 수강 인원을 파악하고, 인원 규모에 맞게 장소를 정하고 세팅하는 것. 이런 일은 IT와는 무관하게 누구라도 할 수 있는 일이기 때문에 그걸 그냥 하면 됐다. 그렇게 분주하고 정신없이 일곱 차례의 교육을 끝내고 나니 한 달이 지나 있었다. 

그리고 나의 본격적인 IT 업무도 시작되었다.

태블로라는 프로그램을 쓰게 되면서, 우리 팀은 사내에 필요한 데이터를 추출해주는 업무의 주관부서가 되었다. 원래의 우리 팀의 롤은 요청사항을 다시 한번 검토해서 실제 시스템 담당자에게 데이터 추출을 위한 쿼리를 요청하고 그 쿼리를 받아서 데이터를 뽑는 것이었지만, 요청한 사람의 요구사항에 맞게 데이터 추출이 이뤄졌는지를 확인하려면 쿼리 자체를 이해해야만 했기 때문에(뭐 당연한 일이다), 결국 나의 일은 자연스럽게 쿼리를 작성하는 방향으로 바뀌었다. 같은 팀의 동료는 개발자이고 개발 실력이 좋아서 SQL 쿼리를 작성하는 방법이나 오류를 여러가지로 설명해줬고, 나도 스스로 일을 처리할 수 있어야 한다는 생각 하나로 열심히 배웠다. 기본적인 논리가 매우 간단하기도 하고, 온라인에 웬만한 내용은 이미 많은 콘텐츠가 있어서 한 달 정도가 지나고 나니 능숙하게는 아니더라도 원하는 데이터를 뽑을 수 있는 정도는 되었다. 

그런데, 문제는 바로 이 때부터 시작되었다.

데이터 관련된 요구사항을 처리하는 것은 나도 업무를 처리할 수 있지만, 기본적인 서버 관리 영역은 내가 해결하기 힘든 부분이었다. 게다가 서버는 리눅스 환경에 설치되었는데, 회사에 서버만 관리하는 팀은 따로 없을뿐더러 우리 팀의 개발자는 리눅스 서버는 잘 모른다고 했다. (근데 왜 윈도우 서버를 설치하지 않았는지는 아직도 이해되지 않는다. 본인이 관리하지 않아도 될 거라고 생각한 것일까?) 프로그램을 오픈하기는 했지만, SSO 이슈나 서버 업데이트, 유저 데이터 집계 등과 관련해서 서버 관련된 기술지원이 필요한 일이 여전히 많았고 어쩔 수 없이 동료가 혼자 담당해서 처리하긴 했지만, 그 친구도 잘 모르는터라 나에게 가르치지도 못하는 상황이었다. 그렇다고 내가 리눅스 서버를 처음부터 다 배워서 담당하기에는 시간의 여유가 없었다. 그리고 그 와중에 우리 팀은 RPA 개발 프로젝트도 착수해야만 했다. 

RPA 역시 프로젝트 초반에는 업무 내용을 논리적으로 체계화 하는 작업이라 IT 역량이 크게 필요하지 않다. 하지만 개발이 들어가면서부터는 얘기가 달라졌다. 회사의 과욕으로 인해 RPA 시나리오를 2개를 한 번에 작업에 착수했고, 외주 개발자는 1명만 불러들이기로 협의한 상태라 우리 팀의 개발자는 RPA 개발 논리를 배워 같이 개발에 투입되어야 했다. 나도 같이 배웠지만 솔직히 이해하기가 쉽지 않았다. 개념적으로 논리 구조는 이해했는데, 막상 Loop 구문이나 중간에 임시 변수를 설정하는 단계에서는 스크립트를 보고 이해는 하겠어도, 잘못되었을 때 수정할 수 있는 수준으로 이해하지는 못했다. C# 명령어와 정규식 표현을 사용한다고 하는데, 그 용어와 문법의 규칙도 생소했다. 결국 RPA를 개발, 유지보수하는 일도 우리 팀의 개발자가 담당하게 되었다.

당연한 얘기겠지만, IT 부서의 일은 결국 IT 개발(혹은 기술적인 관리)의 단계를 거칠 수 밖에 없다. 그런데 우리 팀에는 팀장님과 개발자는 아닌 나와 개발자 1명이 있다. 프로젝트 시작은 개발자를 포함한 3명이 동시에 여러 개를 벌일 수 있지만, 결국 그 일들은 모두 개발자에게 단계가 넘어가게 된다. 그렇게 우리 팀이(어쩔 수 없이) 벌린 일련의 모든 일들은 현재 우리 팀 개발자에게 모두 기술적으로 의존하고 있다.

임원이 업무를 지시하는 것은 보통 개발 단계의 이슈는 아니라서 스타트는 누구든 쉽게 한다. 그리고 그 임원이 마음이 조급하고 고집이 세다면 그 성화에 못이겨서 프로젝트는 결국 스타트되지만, 마무리는 아무도 책임질 수 없는 상황이 된다. 이런 상황이 일시적인 문제가 아니라 구조적인 이슈라면, 나는 뒤처리는 하지도 못하면서 일만 만드는, IT 부서에는 별로 필요 없는 존재인 게 아닐까 하는 생각이 요즘 부쩍 든다. 내가 아니라 차라리 개발자 한 명이 더 필요한 게 아닐까?

아이디어와 욕심을 스스로 끝까지 감당할 수 없는 상황에서 문제는 항상 동일하게 귀결된다.

결국 개발은 누가하나?