본문 바로가기
루모의 일상사

신입 프로그래머 X개월 째 (작성중)

by xenophilius 2018.06.12

신입 프로그래머 X개월 째

 

2018년 2월 경북대학교를 졸업하고 3월 부터 일을 시작해 벌써 X월이 되었습니다. 그간 학생으로서 프로그래머를 벗어내고 이제 돈을 받고 일을 하는 프로그래머로서 3개월 일해 보면서 그 간의 감상을 적어보려고 합니다. 많은 대학생과 프로그래밍을 공부 하는 사람들에게 도움이 됐으면 좋겠습니다.실제로 글을 써서 포스팅하자 마음먹은건 3개월차 쯤 이었는데 미완성 상태의 글을 미루고 미루다 보니 어느새 X개월이 되었습니다.

일단 소감

원래 소감이라 하면은 가장 마지막에 말해야 하지만 그러면 너무 뻔하고 재미 없으므로 저는 그냥 3개월 동안 회사를 다녀본 소감을 먼저 말 해 보겠습니다. 일단 처음으로 회사에서 느낀점은 “뭐가 이렇게 복잡하냐”였습니다.

 

복잡함

회사에는 제 생각보다 많은 내부용 시스템들이 있었습니다. 평소엔 아무렇지 않게 쓰고 있지만 곰곰히 생각해보면 꼭 필요한 시스템입니다. 예를들면 휴가 관리, 연봉 계약, 회의실 예약 등등... 그 중에서 주차장 신청 시스템을 보고서는 “뭐야? 이런 것도 있어?”라는 생각이 들었습니다. 저는 차를 안 몰아서 크게 공감하진 못했지만 가만 보니 있어야겠다 싶었습니다. 그렇다면 내가 모르는 부분까지 모두 고민 해 보면 얼마나 많은 사내 관리 시스템이 있을까? 아마 아주 많을 겁니다. 

 

이렇게 하는 일과 역할이 사내 업무 지원인 것들도 있지만 개발 업무를 위한 시스템들도 많았습니다. 처음에는 이토록 많은 내부용 시스템들의 이름을 받아들이는 것도 힘들었습니다. 이름들은 그다지 명확하지도 않았습니다. 딱히 시스템의 역할과 관계가 없는데 억지로 의미를 우겨 넣은 것 같았고 변변한 그래픽 로고도 하나 없으니 나중에는 “그게 뭐였더라?” 까먹기 일쑤였습니다. 아무래도 이공계열 사람들이다보니 작명, 디자인 감각은 눈물 없이는 말을 이을 수가 없었습니다. 이름들이 죄다 AB, XI, POP... 이런 식으로 약칭하는 것도 문제였습니다. AB가 어떤 단어의 약어인지 알고 있는 사람도 드물었고 기껏 알아내도 시스템 이해에 별 다른 도움이 되진 않았습니다. 

 

UI 디자인은 더 심각 했습니다. 모두 부트스트랩을 사용해서 안그래도 헷갈리는데 들어가는 시스템 마다 똑같은 UI를 가지고 있으니 차별점이 없어서 더욱 헷갈렸습니다. 너도 나도 부트스트랩을 쓰니까요. 뭔가 믿음이 가지 않는 UI를 가진 이 시스템들의 첫인상은 저에게 매우 좋지 않았습니다.

 

그렇습니다. 비즈니스 로직에 신경 쓰느라 이런 디자인까지 일일이 생각 할 순 없습니다. 그래서 부트스트랩과 같은 라이브러리는 정말 프로그래머들에게 단비 같은 존재입니다. 대신에 사이트들이 독창성과 개성을 잃어버리게 되는 부담을 안아야 합니다. 모든 시스템을 만들 때 마다 UX/UI 디자이너를 데려다 놓을 수도 없는 노릇입니다. 이 부분에 대해서는 다음에 더 글을 써 봐야겠습니다.

 

처음 시스템을 봤을 땐 대략 이런 느낌입니다. A라는 시스템이 있습니다. A라는 시스템을 관리하기 위해서 B라는 시스템이 있습니다. 그런데 B라는 것을 관리하기 위해 또 C라는 시스템이 있고 ABC 모두를 통합 관리하기 위해 X라는 시스템이 있습니다. 여기에 B라는 시스템이 곧 없어 질 것이고 대신 D가 들어오려 하는 중입니다. 지금은 조금 익숙해 졌지만 가끔 모니터링을 하거나 뭔가 알아보고 싶을 때 어디로 접속하면 좋을지 우왕좌왕 할 때가 많았습니다. 아예 이런 시스템들의 이름과 역할을 모두 정리 해 놓은 위키가 있을 정도였습니다. 왜 이렇게 복잡하게 얽히고 설켜서 사람 머리 터지게 해 놨을까 원망스러웠습니다. 

 

 

심리적 측면에서 말하는 유지보수와 개발 업무

서비스중인 시스템이나 소프트웨어를 유지 하는 것은 매우 중요한 일입니다. 하루에 수천만명이 이용하는 서비스이므로 절대 장애가 나서는 안됩니다. 장애가 나면 곧바로 광고에 타격을 입히게 되고 돈으로 따져보면 평생 일해도 못 갚는 액수입니다. 장애를 내 봤지만 딱히 회사가 돈을 요구하지는 않더군요. 그러나 하지 않는게 좋겠습니다. 

 

3개월 전 까지는 실무라고는 하나도 알지 못하는 학생이었습니다. 그래서 처음 회사에 왔을 때는 무슨일을 하게 될까 기대를 가졌습니다. 어떤 일을 하게 되든 지금 이 세상에 ‘XXX’라는 이름으로 사람들에게 서비스를 제공하는 일 중 일부를 하게 될 테니까요. 그러나 막상 회사에 들어와서는 새로운 서비스를 개발하는 일 보다는 ‘일단’ 회사 시스템을 이해하는 것만으로도 벅찼습니다. 그래서 때로는 지금 내가 정말 프로그래밍을 하고 있는 건지 회의감이 들어 일 하기가 싫어 질 때도 있습니다.

 

평소에 프로그래밍이라고 하면 이랬습니다.

 

“어떤 기능을 가지고 어떤 서비스를 할 수 있는 소프트웨어를 만들까?”

 

이렇게 생각 했어야 했다면 회사에서의 ‘프로그래밍’이라는 것은 아래와 가까웠습니다.

 

“돌아가나?”

 

이런식이라면 “아무튼 되게만 하자”라는 사상에 사로잡히기 쉽다는 생각이 들었습니다. 프로그래밍이라기 보다는 인형에 눈알을 붙이고 꿰메는 것과 같은 다소 수동적인 일이었습니다. 돌이켜보면 if와 for와 같은 문법 외에는 달리 사용한 것이 없었습니다. 

 

재미를 붙이려고 멀티 스레드를 활용해서 성능을 개선 시켜 보고자 했습니다만은 서비스 측면에서 무의미한 작업이라는 이야길 듣고 조금 실망하기도 했습니다. 

 

그러나 이런일이 아예 재미도 없고 도움도 되지 않는 것은 아니었습니다. 저는 평소에 프로그래밍을 할 때 저는 꼼꼼하게 데이터를 살펴보거나 인내심이 필요한 일은 대충 대충 넘겨버립니다. 도움말과 설명서를 자세히 읽어 봐야 함에도 불구하고 먼저 방아쇠를 당겨 버리는 성격입니다. 그러나 맡은 일은 조금만 데이터가 달라도 에러가 났기 때문에 열 받지만 두 데이터를 차근히 비교 해 보는 수 밖에 없었습니다. 대단히 귀찮고 지루했지만 가장 정확하면서 빠른 방법이었습니다. 꽤 짜증나는 며칠의 연속을 견뎌냈습니다. 그치만 이 기간은 학생 프로그래머로서 가진 약점을 훈련 할 수 있었던 좋은 기회였습니다.

 

 

서비스 책임감

‘진짜’ 서비스라는 것을 만져보면 어느정도 프로그래밍에 감이 올 것만 같았습니다. 왜냐면 ‘진짜’니까요. 평소에 학생으로서 장난스럽게 만드는 어플리케이션과는 차원이 다른 어마어마한 무언가를 기대했습니다. 정말 차원이 다르게 거대하고 복잡한 시스템을 마주했습니다. 그러나 이번엔 너무 크고 넓어서 뭔가 내가 일조를 한다는 실감이 없더군요. 

 

막상 제가 어떤 서비스의 담당자가 되니까 매 순간이 불안했습니다. 뭔가 코드를 잘못 써놨고 모두가 잠든 새벽에 치명적인 에러를 일으키면 어떡하지? 내가 알지도 못하는 부분에서 쾅! 에러가 나면 어떻게 하지? 온갖 생각이 다 듭니다. 

 
 

서비스 책임감

 

태그

댓글0