과거의 기억을 소환하며
선배들 대부분이 퇴사해 버린 팀에 배정된 나에겐, 프로젝트에 투입된 PwC컨설턴트들이 사수나 다름이 없었다. 사실 컨설턴트가 업무를 리딩하면 고객사 직원은 크게 할 일이 없다. 그것도 신입사원급은 그들에게 걸리적거릴 뿐이다. 부서배치 후 3개월을 중구난방으로 일하다가, 컨설턴트가 일하는 방식을 보니, 업무가 정리될 때마다 필요한 산출물이 착착 정리되어 쌓여 갔고, 그 문서를 기반으로 시스템 세팅과 개발이 진행되었다. 문서작업이 시스템 개발로부터 이원화되지 않고, 그때그때 변경사항이 업데이트되어 문서로 기록된 히스토리부터 최근의 설계 내역까지 시스템과 sync가 맞아떨어지는 관리 방식을 처음 보게 되었다. 당시 나는 CO(관리회계) 모듈을 담당하게 되었는데, 재무회계/관리회계 모두 SAP의 온갖 모듈의 데이터가 파이프를 타고 흘러들어오는 '종점'이긴 했지만 회계계정과 회계장부만 들여다보면 되는 재무회계와 달리, 관리회계는 다른 모듈에서 처리한 내부 조직 손익구조과 얽혀 있는 내역까지 다 들여다봐야 했다. 그래서 프로그램 테스트를 하려면 다른 모듈이 데이터를 단계별로 만들어줘야 CO모듈이 설계한 프로그램이 정상적으로 동작하는지 결과를 확인할 수 있었는데, 문제는 다른 모듈도 그들의 우선순위 업무로 바쁜 상태라, 선배들에게 여러 차례 데이터 생성을 부탁을 하는 것이 신입사원으로서 쉽지 않기도 하고, 금방 처리되지도 않는다.
그래서 PwC컨설턴트에게 모든 모듈의 기본 프로그램을 사용해서 데이터를 A부터 Z까지 연결하는 시나리오로 시연 교육을 요청했고, 모든 단계를 캡처 떠가며 기록을 남겨가며 따라 했다.
1. SAP에서 자재 마스터 생성부터 트랜잭션 거래의 한 사이클을 혼자 만들어보기
부서배치 6개월 차에 나는 혼자 자재생성부터 제조 BOM, 생산오더, 생산투입, 완제품 입고, 물류이동, 주문생성, 대금청구의 모든 데이터를 생성할 수 있게 되었다. SAP를 다루는데 제약이 되는 허들이 사라진 게 이때부터였던 것 같다. 뼈대를 볼 수 있게 되니, 뼈대에 붙어 있는 가지와 기능을 이해하는 건 빠르게 확장되었다. 단지 스탠더드 기능을 A부터 Z까지 사용할 수 있다고 SAP가 만만해지는 것은 아니다. 하지만 '혼자' 파고들며 탐색할 수 있는 시야의 반경이 넓어졌기 때문에, 이때부터는 많은 이슈와 비즈니스 케이스를 해결하는데 본인이 어디까지 연결고리를 파고들었는지, 얼마나 많은 시간을 들여 탐색해 보고 가설을 수립하고 테스트해 봤는지에 따라 성장 수준이 달라진다.
2. 프로그램 하나를 온전히 내가 처음부터 끝까지 설계하고, 개발마무리까지 완료하기
처음 프로그램 설계서를 작성했을 때가 기억난다. 다른 회사도 그런지 모르겠지만 회사의 그 누구도 '설계서 작성'에 대한 교육이나 가르침을 주지 않았다. 어느 날 선배가 예산과 실적을 조회하는 프로그램을 설계해 보라며, 설계에 담겨야 할 아우트라인을 설명해 주었다. 자고로 프로그램 설계란, 개발자에게 '이렇게 만들어주세요'라고 알려주는 레시피 같은 것인데 경영학도인 나는, 회사 실무 교육 중 하나인 C#강의를 듣고 과제 결과물을 백지로 냈을 정도로 개발자가 이해할 수 있는 수준의 설계에 대한 이해가 zero에 가까웠다.
회사 공유폴더에 있는 프로그램 설계서도 방식이 천차만별이었다. 어떤 설계서는 말로만 설명이 되어 있거나, 어떤 설계서는 변수명이나 코딩 로직이 일부 작성되어 있었다.
선배의 설명을 듣고 설계서를 작성해 갔다. 내 설계서를 본 선배의 첫마디는 이랬다.
"개발자가 이걸 보고 무슨 말인지 이해가 될 거라고 생각하니? 다시 작성해 와"
무엇이 부족하지를 직접적으로 알려주지 않았다. '넌 이게 이해가 될 거라고 생각하니?'로만 4번 퇴짜를 맞고 5번째 설계서를 가져갔을 때, 개발자에게 전달하라는 ok 사인이 떨어졌다.
모두에게 이런 방식이 통하는 건 아니겠지만, 내 경우엔 조금 돌아가는 이 방식이 의미가 있었다. 설계서를 5번 고치는 동안 '이해할 수 있는 설계서'를 작성하려면 내가 이해해야 하는 프로그램의 동작에 대한 depth가 깊어야 한다는 것을 깨달으며 부족한 부분을 메워나갔다. '스스로' 내 방식의 설계서를 만들어 본 이 경험이 나중에 더 나은 설계서나, 다른 방식의 설계서를 봤을 때 내 것으로 접목시키는 응용력을 발휘할 수 있는 밑바탕이 되어 주었다.
3. 빌런 개발자를 상대할 때 필요한건 납기준수와 완성에 대한 집요함
프로젝트에 투입된 지 몇 개월 후에는 컨설턴트에게 프로젝트 전체 설계 영역 중 작은 영역을 나한테 하나 떼어줘서 해당 프로그램 설계부터 개발테스트까지 오너십을 가지고 작업할 수 있게 해달라고 요청했고, 컨설턴트는 수불집계 이후 단계인 원가차이 계산 영역을 나에게 주었다. 이 때는 내가 몇 번의 월 결산과, 운영 업무로 디버깅을 통해 SAP의 COBOL 코딩 구조를 어느 정도 이해한 상태였기에, 설계서에도 COBOL 코딩을 차용한 방식을 섞어서 작성할 때였다.
그런데, 문제는 개발자였다. 그동안은 사용자 입장의 기능 동작 중심으로 설계서를 작성하면, 개발자들이 그 뒷면에서 동작되는 부분들은 알아서 메워 개발을 해주었었다. 그런데 이 프로젝트에서 일하던 개발자는 설계서에 기록되지 않은 것은 단 1도 개발에 담지 않았다. 즉, 개발할 때 동작의 개연성이라던지, 고민이라는 걸 아예 하지 않는 사람이었다. 그래서 생각 없는 사람에게는 생각 없이 따를 수 있게 설계서를 줘야 했다. 이때 내가 작성한 설계서를 보면 엔지니어가 개발자에게 주는 설계서가 아니라 그냥 COBOL코딩 그 자체나 다름없었다.
게다가 이 사람은 직업의식이 꽝이어서 저녁 6시가 되면 개발 다했다고 실행해 보라며 나한테 넘기면서 퇴근해 버렸는데 내가 프로그램 '실행'버튼을 누르면 바로 덤프오류 화면으로 넘어가버렸다. 다음날 출근해서 오류를 지적하며 프로그램을 고쳐달라고 하면, 어김없이 저녁 6시까지 붙들고 있다가 나에게 개발이 다됐다고 전달하고 퇴근해 버리는데, 실행해 보면 오류였다. 이 일을 반복되자, 프로그램 개발 완료 due date까지 마무리를 하지 못할 것이라는 위기감이 드리워졌다. 어떻게 하면 저 사람을 잡아다가 일을 시켜서 일정 내 마무리를 할 수 있을까 고민하다가, 밤새도록 디버깅으로 내가 찾을 수 있는 오류를 다 잡아내기로 결심했다.
중간중간 오류가 걸리면, 임의로 정상 데이터로 바꿔넣어 오류 단계를 통과하도록 한 뒤에 또 다음 단계의 오류를 잡아내서 다시 정상으로 변형시켜 다름 단계로 넘어가면서 프로그램 전체 로직을 검수했고, 개발자가 수정해야 하는 오류 영역을 다 캡처 뜨고 고쳐야 되는 내용을 기록한 뒤 새벽 4시에 메일을 보냈다.
다음 날, 개발자에게 내가 밤새도록 디버깅을 해서 고쳐야 하는 부분들을 많이 잡아 냈으니 고쳐달라고 했다.
오후 6시 10분 정도가 되었을 때도 개발자가 자리에 앉아 있었다. 화장실을 다녀왔는데, 그 잠깐 사이에 개발자가 퇴근을 하고 자리에 없었다. 당장 개발자에게 전화를 걸었다.
"지금 어디세요?"
"퇴근 중인데요"
"아직 지하철역까지 안 가셨죠? 다시 돌아오세요. 오늘 이거 다 끝내야 해요. 그동안 계속 6시에 다 됐다고 하고 집에 가셨는데 매번 제가 프로그램 실행하자마자 오류 화면이 떠서 일정이 계속 지연되었어요. 제가 개발자님이 알아서 고쳐야 할 오류를 뭣하러 밤새도록 디버깅해서 새벽 4시에 메일을 보냈겠어요? 빨리 사무실로 들어오세요"
난 이때 고작 입사한지 만2년도 안된 직원이었는데, 지금 생각하면 나도 그만큼 절박했던 것이다.
개발자가 한숨을 쉬며 사무실로 되돌아왔다. 나는 아예 개발자 옆에 자리를 잡고 어디까지 수정됐는지 물어보고, 수정된 부분을 바로 디버깅으로 테스트하며 일을 이어갔다. 당연히 밤 10시가 되어도 그 많은 오류들이 금방 수정될 리가 없었다. 개발자가 퇴근하면 안 되냐고 물었다. 개발자와 척을 지면 나에게 불리하기만 했기에, 부서장님을 공공의 적으로 만들었다.
"저도 집에 가고 싶어요. 어제도 새벽 4시에 퇴근했다니까요. 부서장님이 왜 이렇게 일정이 밀렸냐면서 오늘까지 이거 다 고치지 전까지 집에 가지 말래요. 개발자님이 이거 다 수정 안 하시면 저 집에 못 가요. 개발자님도 집에 못 가요"
내가 누군가에게 빌런이 되어본 첫 번째 경험이었다.
4. 스스로 부족한 부분을 파악하고 성장 목표 세우기
이것은 약점과 강점에 대한 이야기가 아니다. 많은 학자와 책들이 강점을 적극 활용하고, 약점을 개선하기 위해 에너지를 너무 많이 들이지 말라고 한다. 그런데 강점/약점은 '재능'에 대한 이야기이며, 업무를 하는 데 있어서는 그 일을 수행하기 위해서는 마땅히 할 줄 알아야 하지만 아직 수준이 부족한 영역들이 존재한다.
신입사원때부터 3년 차가 될 때까지 목표로 한 것은 아래와 같은 것들이다.
- 설계부터 개발까지 프로그램 오너십을 가지고 완결 짓기
- 현업 담당자들의 비즈니스 용어 이해하기: 프로젝트나 프로그램 개발을 위해 현업 미팅에 들어가면, 팀장님과 그들이 빠르게 의사소통을 주고받고, 신입사원인 나는 회의록을 작성한다. 문제는 회의록을 쓰면서도 약어나, 비즈니스 용어들 중 모르는 것이 너무 많다 보니 해석 없어 받아쓰기가 되는 경우들이 있다는 것이다.
그래서 몇 개월 안에 현업 미팅 내용의 80%를 알아듣는 것을 목표로 세웠었다.
- 의사결정 포인트 작성하기: 팀장님을 따라서 미팅을 들어가 들어보면, 팀장님이 주도적으로 현업이 파악하지 못한 부분에 대해 의사결정 포인트들을 짚어서 전달하는 경우들이 자주 있었다. 보통 그룹사의 IT는 철저히 '을'의 입장이지만, 비즈니스 업무의 의사결정 영역에 대해서도 IT가 주도권을 가질 수 있는 부분이 매력적이었다. 내가 참여하는 프로젝트에서 현업이 보지 못한 부분을 먼저 캐치해서 이야기할 수 있는 경험을 가지는 것을 목표로 했다.
- 의사결정 방향 제안하기: 프로젝트에서 의사결정 내역서를 작성하는 경우가 많았는데, 대부분은 비즈니스팀이 결정을 해줘야 하는데, 고려해야 할게 복잡하거나 하면 의사결정을 미루는 경우가 왕왕 발생했다. 문제는 시스템은 정해진 기한 내에 완성이 돼야 했기 때문에 의사결정을 미루면 그 의사결정의 결과를 담아야 하는 시스템 완성도 영향을 받았다. 그래서 어쩔 수 없이 우리 팀은 비즈니스가 파악해서 결정해야 하는 부분들도 의사결정 안을 여러 개 만들어 영향도를 분석하고 정리해서 비즈니스팀에 제공했다. 재밌는 건 우리가 보기에 명백하게 선택되어야 하는 방향은 정해져 있지만, IT팀에서 '이렇게 하세요'라고 하는 것은 비즈니스팀에서 잘 못 받아들이는 경우가 있어, 2~3가지 안을 정리 한 후, 제공한다. 누가 봐도 특정 안건이 옳은 선택인 것처럼 보이지만 들러리들도 같이 가져가는 것이다. 비즈니스 관점에서 의사결정 안을 정리해서 '설득'하고, 기한 내 의사결정을 완수하는 것도 내가 경험하고 싶은 목표 중 하나였다.
이 외에도 여러 가지 목표들이 있었는데, 중요한 것은 '주도적', '능동적'으로 일하는 태도가 성장을 만들어낸다는 것이다. 내가 회사에서 사용하는 시간이 온전히 '회사만을 위한 것', '근무시간은 월급에 대한 대가'이라고 생각하는 사람은 방어적이고, 수동적이고, 선을 긋는 태도로 일을 하게 되는데 본인의 성장에 조금도 도움이 되지 않는다.
이직 후 언젠가 과거 잠깐 사수였던 분과 식사할 기회가 있었는데 이야기 중에 내가 이런 말을 했더랬다.
"제가 그 회사에서 얼마나 고생스럽게 일했는데요. 제가 회사를 위해 그만큼 일했으면, 회사도 저한테 주는 게 있어야죠"
사수는 "인마, 네가 무슨 회사를 위해 그렇게 일했냐? 네가 스스로 만족하지 못해서 그렇게 일한 거잖아. 넌 너를 위해 일한 거야"
그 말을 듣는데 사실 너무 맞는 말이었다. 나는 단 한 번도 '회사를 위해' 일한다고 생각해 본 적 없었다.
내 시간과, 내 손을 거쳐서 만들어지는 결과물들이었고, 내가 80%의 에너지만 썼을 때 어설픈 결과물을 만들어내면 80%나 쓴 그 시간과 에너지가 너무 아까웠다. 그래서 120%를 들여서 제대로 만들었을 때 그 모든 시간과 노력이 멋지게 완결된 모습으로 마무리되었을 때 만족했다. 물론, 기업 내에서 불필요하고 비효율적으로 시간을 들여야 하는 일들이 있긴 하지만, 내 본업에 있어서는 '회사 것'이 아닌 그 경험들이 '내 것으로 내재화되는 과정'이라고 생각하고 일한다면, 좀 더 일이 보람되고 의미 있는 것 같다.