티스토리 뷰

에세이

My December

June 2016. 12. 4. 01:02

사실 11월에는 마음이 조금 불편했었다. 나도 나름대로 하고 싶어도 할 수 없는 것과 하기 싫어도 해야 하는 것들 사이에서 마음고생을 하고는 있었지만, '그 프로젝트'에서 일하고 있는 다른 사람들을 생각하면 그런 불평도 크게 할 수는 없었다. 차라리 어디 멀리서 일하고 있었다면 폭우가 몰아칠 때 할 일 없이 집에서 멍하니 창밖을 바라보고 있을 때처럼 안락함이라도 느꼈을지 모르겠는데, 들려오는 이야기들 하나하나가 너무 경악스러울 정도로 안 좋아서 그러기도 쉽지 않았다. 특히나 마음이 좋지 않았던 것은 내가 할 수 있는 일이 하나도 없었다는 점이었다. 같이 화내주면 다들 마음이 조금 풀렸을까. 술이나 밥을 사주면 상황이 조금 나아질까. '이런 프로젝트가 존재한다는 것을 견디기 어려워서 회사를 그만둡니다.'라고 말하면 - 물론 뒤에 '아 그런데 제가 거기에서 일하는 것은 아니지만' 이라는 말을 붙여야 되겠지만 - 변화가 있었을까.


하지만 12월에는 마음이 조금 덜 불편해졌다. 보통 어렵다거나 안 좋다는 말이 나오는 프로젝트들은 결국 '남은 일의 양은 많고 일을 끝내는 속도는 느리다'라는 말로 일반화할 수 있는데, 남은 일을 줄이는 것은 보통은 없는 선택지니까 일을 처리하는 속도를 높여야 하는데, 일을 처리하는 속도는 일하는 사람의 능력 X 일하는 시간 X 일의 효율성 X 일하는 사람의 숫자로 결정되니, 일하는 사람들의 능력은 이미 최상급이었고, 그 사람들의 개인 시간을 진작에 모조리 강탈해버렸으니 일하는 시간을 더 늘릴 수도 없고, 효율성이 좋은 프로젝트였으면 안 좋은 말이 나왔을 리도 없었으니 효율성을 늘릴 방법도 없으니 결국 일하는 사람의 숫자를 늘리는 선택이 평범한 의사 결정권자들이 할 수 있는 가장 평범한 선택이었고, 당연하지만 일하는 사람의 숫자를 늘리기 위해서는 그 일을 하지 않는 사람이 그 일을 하도록 해야 하니, 그 일을 하고 있지 않던 나는 그 일을 하게 되었고, 그래서 마음이 조금 덜 불편해졌다.


듣는 것과 보는 것이 다르고, 보는 것과 경험하는 것이 다르게 마련이니 말로만 듣던 '그것들'을 실제로 보고 일을 하게 되었을 때는 살짝 기대감이 있었던 것도 사실이었다. '자, 얼마나 엉망인지 한번 보자!' 충분히 최악의 상황을 가정하고 있었기에 간신히 기절하지 않을 수 있었다. '세상에 다들 이런 걸 지금까지 하고 있었단 말이야?' 프로세스는 거진 무너져있었고, 환경은 완전 엉망이었고, 관리는 정말 최악이었다. 프로세스, 환경, 관리가 원래부터 없었던 것인지 있다가 없어진 것인지가 조금 궁금하기는 했었는데, 예정된 종료일이 한 달도 남지 않았기에 누구한테 물어볼 상황도 아니었다. 신입사원 때는 좋은 소프트웨어를 만들기 위해서 해야 할 것과 하지 말아야 할 것을 많이 배웠었는데, 이렇게 하지 말아야 할 것들만 골라서 하게 되는 미래가 있을 줄 알았다면 조금 덜 열심히 배울걸 그랬다는 아쉬움이 가득했다.


누가 나한테 당신은 왜 아직도 프로그래밍을 그만두지 않았나요 라고 물어본다면 중2 때는 세상을 구하기 위해서 그랬다고 대답했을 것이고 대2 때는 File - New를 눌러서 나오는 텅텅 빈 화면을 캔버스 삼아서 새로운 것을 만들어나가는 기분이 너무 좋아서라고 대답했겠지만, 직장인 2년 차 때는 이 직업이 보통 새로운 것을 만들기보다는 과거의 것을 포장하는 일이라는 사실을 알기에 쉽게 대답을 망설였을 것 같았다. 완전히 독창적이고 새로운 시스템을 만드는 것은 위험부담이 큰일이고, 위험부담이 큰일은 보통 잃을 게 없을 때나 할 수 있는 일이니, 잃을게 완전 많은 사람은 독창적이고 새로운 시스템보다는 기존 시스템을 모사하는 일을 더 선호했다. 물론 잘 돌아가는 시스템을 굳이 돈 들여서 새로 만들 이유는 없으니 보통 '기존 것과 본질적으로는 동일하지만 그래도 돈을 들여서 새로운 것을 만들어야 하는 이유'를 여기저기서 몇 가지 가져와서 더 높은 곳에 있는 사람들을 설득시키고는 그 돈으로 일을 한다이때 '기존 것'을 AS-IS 시스템이라고 부르고, '새로운 것'을 TO-BE 시스템이라고 부르는데, 결국 이 모든 재미없는 일들을 한 마디로 표현하자면 'AS-IS를 TO-BE로 컨버전하는 것'이라고 할 수 있다. 이 표현에서 누가, 왜, 어떻게든 보통 제안서에만 존재하고 프로젝트가 시작하면 생략 가능한 것이 되기 때문에 이 문장에서는 생략했다.


제안서에는 이름으로도 숫자로도 존재하지 않던 사람이었던 내가 이 프로젝트에서 일하게 되었으니, 결국 이 프로젝트는 사람의 숫자를 늘리는 평범한 선택으로 돌파구를 마련하고자 했다는 사실은 프로젝트 바깥쪽에 있을 때도 쉽게 추측할 수 있었다. 잘 안 만들어지는 무언가를 빨리 완성하기 위해서 일하는 사람들에게 더 힘들게 일할 것을 강요하고, 일하는 사람들의 숫자를 최대한 늘려나가는 것은 사실 피라미드나 만리장성을 건설할 때도 있었던 일이니까 기본적으로 근본이 없는 선택이라고 보기는 어려웠다. 사실 이미 망했음을 자인하는 것이 오히려 유리한 포지션을 차지하는 한 수가 될 수도 있는 분위기의 조직이라면 사람 더 넣는 거야 너무나 평범한 의사결정이 될 수밖에 없었다. 하지만 그 조직이 '우리가 당신들의 프로세스를 효율적으로 바꿔드리겠습니다.' 혹은 '우리가 만들어드릴 시스템을 쓰면 예전에 10명이 하던 일도 이제 한 명이 할 수 있습니다'라는 말로 프로젝트를 가져오는 조직이라면, 그 스스로의 업무에도 뭔가 기가 막히고 환상적인, 그러니까 사람을 더 넣지 않고도 프로젝트를 완성할 비범한 선택 몇 가지는 더 있어야 하는 것이 당연했다.


프로젝트에 있는 AS-IS 시스템은 Pro*C를 기반으로 만들어진 것이었다. TO-BE 시스템은 이것을 Java와 Spring 기반으로 컨버전 해서 만들어내고자 했고, 이 과정을 최대한 빠르게 하려고 업무적인 내용의 개선, 그러니까 SQL 구문이나 데이터베이스의 스키마, 비즈니스 로직의 구성 등은 최대한 건드리지 않고 기계적으로 바꾸는 것이 프로젝트의 테마이자 이념이었다. 보통 개선이라는 것은 '이걸 왜 이렇게 했을까. 꼭 이렇게 해야만 하는 것일까'에서 시작해서 '이걸 이렇게 바꾸면 더 좋아질 것 같다'를 거치는 것이 기본인데, 이 프로젝트는 빠른 완성을 위해서 '이걸 왜...'에서 생각을 차단해 버리니 사실 이 일은 개선이라는 말이 들어갈 틈이 없었다. 그러니까 소프트웨어 공학적으로 이 프로젝트는 AS-IS를 TO-BE로 변경하는 일이 아니라  As_Is를 asIs로 바꾸는 일이었다. 이건 정말 너무나 기계적인 일이라서 사람이 할 일이 되지 못했다.


그러면 이 일은 기계가 하자. 라는 것이 이 프로젝트의 비범한 선택이었다. 정말 너무나 비범해서 믿을 수가 없었다. 당연히 이론적으로는 가능한 일이었다. 작업 수행의 시작 요청과 결과 응답을 인터페이스, 셸, DB로 제한하여 동작하는 것을 목적으로 작성한 C 프로그램은 완벽히 같은 동작을 하는 Java 프로그램으로 변환할 수 있었고, 이것은 귀류법으로 증명이 가능한 일이었다. 그런데도 C 언어의 모든 문법을 커버하는 것은 여전히 어려운 일이었지만, 일정한 규칙을 가지는 프레임워크 위에서 돌아가는 프로그램 코드들은 대부분 비슷한 문법으로 짜여지기 마련이었고, 깊이 생각하기보다는 비슷한 코드를 복사해서 붙여넣고 조금 수정한 다음에 일단 돌아는 가니까 나중에 조금 더 효율적으로 고치자고 생각하고는 실제로 고치지 않는 개발자들의 습성이 더해져서 대부분의 코드는 기계번역으로도 커버 가능한 범위 내에 있다고 가정하는 것이 무리는 아니었다. 그러니까 기계를 써서 컨버전을 하자는 선택은 잘못된 선택이라고 말할 수는 없었다. 오히려 피라미드 쌓던 시대에서 산업혁명 시대로 단숨에 넘어갔다고 생각할 수도 있었다.


하지만 문제는 바로 그 기계였다. 통상적인 이미지의 기계와 다르게 여기서 말하는 기계는 하드웨어와 소프트웨어를 모두 포괄한 의미로 쓰이는 단어인데, 하드웨어야 컴퓨터를 말하는 것이니까 무한한 신뢰를 보낼 수 있었지만, C를 Java로 변환해주는 소프트웨어는 - MS나 구글이 그런 것을 적극적으로 하지 않았기에 - 불신의 눈으로 볼 수밖에 없었다. 눈치라는 것이 없는 기계의 특성상 그런 불신에는 신경 쓰지 않고 기계는 엄청난 속도로 C 코드를 먹어치웠고, Java 코드를 배달해주었다. 결과론적으로 말하면 엄청난 속도로 잘못 만들어진 코드를 쏟아냈다고 말할 수도 있었을 것이었다. 이를 바로 잡기 위해 사람들이 일하기 시작했다. 하지만 바로잡아야 할 것들과 기계가 하지 못한 것들이 너무 많았고, 사람들은 빠르게 지쳐갔다. 러다이트 운동 비슷한 것이 일어나지 않은 것은 사람들이 착해서가 아니라 그럴 힘도 없어서가 아닐까 싶을 정도로. 이러한 이야기들에 마음이 불편해졌던 것이 나의 11월이었고, 이러한 이야기의 일부가 된 것이 12월이었다.


결과만 중요하게 생각하면 과정이 무시되고, 숫자만 바라보고 있으면 개인의 감정은 고려대상이 되지 않는다. '이미 상황이 이래서 어쩔 수 없다'라는 이유는 힘든 과정과 건조해지는 감정들을 감당하기에는 지나치게 부실해서, 우리는 자주 무너져 내렸다. 그놈의 프로의식이라는 게 도대체 이런 상황에 적용이 가능한 것인지, 왜 힘든 감정을 숨기고 결과를 내기 위해 기계처럼 일하는 것이 최고의 미덕이 되어버린 것인지, 완벽하지 못하면 귀엽기라도 해야 되는데 왜 우리 일에는 둘 다 찾아보기 힘든 것인지, 매우 창조적이지 못한 일을 하고 있어서 그런지 의문들은 끝없이 만들어낼 수 있을 것 같았다.  그러다 결국 나는 왜 존재하는가에 대한 질문으로 다가가게 되면, 나는 투입 인원에 1을 더하고 완료된 일의 개수에 시간당 5를 더하기 위해 존재한다. 라는 결론을 내리고는 깊이 가라앉았다가 이럴 때에도 속도를 줄이지 않는 것이 프로의식인가 라는 의문부터 다시 시작했다.


예정된 종료일이 다가왔지만 일은 끝나지 않았다. 사람들의 마음은 차갑게 가라앉았지만, 프로젝트는 뜨겁게 떠올랐다. 아마도 다음 단계는 추락이겠지만, 그것을 뻔히 알면서도 예정된 추락을 위해 각자의 에너지를 위치 에너지로 변환하는 과정은 효율이 너무 안 나왔다. 힘내자는 말이 그렇게 힘 빠지는 말인 줄은 처음 알았다. 의미 없는 코드, 의미 없는 행동, 의미 없는 생각, 의미 없는 말들이 너무 많아서 세상이 흑백으로 보일 지경이었다. 누가 4월이 가장 잔인하고 겨울은 따뜻했다고 그랬을까. 12월은 따뜻하지도 않고 이렇게나 잔인한데.


아직도 나는 한참 부족하다는 생각이 들었다. 그렇게 되고 싶다고 생각하는 이미지 속의 실력에 한참 미치지 못하는 실력밖에 없다고 생각했다. 좋은 판이 깔려 있어야 뭐라도 하고, 안 좋은 상황들로 판을 깔아주면 여지없이 나약함을 노출하는 것이 부끄러웠다. 잘못된 것들을 바로잡을 용기가 없는 것도 싫었다. 무엇보다도 이런 감정들이 더 잘하고 싶다는 동기를 부여해주는 원동력이 되지도 않고 그저 무기력함을 생성하는 재료가 되는 상황이 제일 나빴다.


12월이 지나고, 다음 달이 되면 상황이 조금 나아질까? 그렇게 생각하기는 어려웠다. 일정이 연기되었다는 공지는 고통받을 날이 더 길어졌다는 말과 동일하니까. 거기에 내가 뭔가 할 수 있는 일은 거의 없었다. 당장은 아니더라도 언젠가는 모든 것이 조금씩 더 나아질 것이라고 기대할 수 있을까? 그것도 잘 모르겠다. 하지만 그렇게 만들기 위해서 내가 할 수 있는 일들이 몇 가지는 있지 않을까 하는 생각을 하니 마음이 조금 편해졌다. 지금이 2011년 12월이니까, 열심히 노력해서 한 5년쯤 지나면 다시는 이런 일이 없도록 무언가 바꿀 수 있지 않을까. 뭐, 그때는 그렇게 생각했었다.

'에세이' 카테고리의 다른 글

안녕하세요. 감사합니다.  (1) 2018.06.15
2002  (0) 2018.05.16
Routine  (1) 2016.08.01
우리에게 좋은 키보드가 필요한 이유  (1) 2016.04.12
프로젝트에서 화합을 추구하면 안 되는 걸까  (1) 2016.01.12
댓글