2021년 상반기, KT에서 과제를 마치며..

2021년, 지난 2월 중순부터 6월말일까지 KT로 파견 되어 과제를 수행하였다.

정확한 과제내용은 보안관련 서약 내용때문에 기술할수 없고,
Java Springframework로 구성된 WAS서버와 Vue로 구성된 웹페이지를 도맡아 하게 되었다.

처음 개발환경 세팅부터.. 과제 파악하는 과정에서 정말 정신없는 시간을 지냈던 것 같다.
어찌어찌 보면 다 작년에 했던 frontend, backend 작업들인데, 망분리 환경에서 오프라인 개발 및 빌드 환경을 세팅하는데 애를 참 많이 먹었던 것 같다.

몸과 마음은 고생을 많이 했지만, 그만큼 값진 경험들을 가질수 있었다.
이 포스팅에서는 내가 이번 기회에 배웠던 점 몇가지를 정리해보고자 한다.

---

1. 메일(전자매체)의 중요성

메일은 생각보다 훨씬 중요하고 의미있는 매체이다. 단순 내용 전달의 목적에 더해, 기록이 되어 훗날에도 열람이 가능하다는게 가장 큰 이유이고, 비즈니스상에서 소통을 하는데에 있어서 아마 가장 필수요소가 아닐까 싶다.

내가 전달해야할 사항이 있다면 메일을 통해서 전달을 하는게 가장 깔끔하고 정확한 방법인 것 같다.
나중에 다른사람과 소통 과정에서 이야기가 바뀌거나, 금시초문인 것처럼 모르쇠를 방지할 수도 있다.
메일을 발송하게 되면 그 기록은 나에게도, 받은사람들에게도 남아있다. (만일 당시에 메일을 받지 못한 사람이 있더라도, forwarding이라는 강력한 기능을 통해 다른사람에게도 그 내용을 전달할 수 있다.)

만약 내가 전해야 할 중요한 사항이 있다고 가정하였을때, 이를 메일로 보낸것과 안보낸것은 정말 큰 차이이다.
그 메일 하나로 인해 나중에 잘잘못을 따지는 재판의 선상에 서고 서지않고가 결정된다.

 

2. 밀려오는 요구사항들에 대한 대처

두개의 프로젝트를 동시에 도맡아 하게 되었다. 그러다보니 양 측의 요구사항들이 매일매일 쏟아져 나왔다.
처음에는 어벙벙했다. 클라이언트들의 말들이라면 다 들어주어야 한다 생각하고, 모두 수용하였었다..
그러다보니 몸은 하나인데 To Do 리스트들은 줄어들기보다 매일매일 쌓이기에 바빴었고, 회사 상사분께 이 상황을 말씀드리면서 조언을 구했다. 그러자 피드백을 받았는데, 이는 나의 잘못이 크다는걸 알게 되었다.

고객이 요청한다고 모두 받아들여서는 안된다. 이게 합당한 요구사항인지는 우선 판단을 해야하는 것이고, 나는 혼자서 개발을 하는것이 아니다. 엄연한 소속 회사가 있고, 회사가 KT에 제공하는 인력 자원중 한명이다.
터무니없는 요구사항들은 쳐 내어야 하고, 만일 수용한다 하더라도 이에대한 우선순위는 잘 세워야 한다.

이미 할일들이 쌓였고, 거기서 더 요구사항이 들어올 수도 있다. 이는 당연한 것이다. 하지만
"지금 이러이러한 목록들로 요구사항이 있고, 우선순위는 이렇습니다. 근데 지금 요구하시는 내용들은 급하신 내용입니까? 우선순위 몇번째 정도로 해결을 해드리면 될까요?" 와 같이 탄력적인 수용이 필요하다는 것이다.

1번 내용에 이어 소통이 중요한 이유의 한 부분이다. 두가지 프로젝트들의 각각의 클라이언트들은 다르지만, 두 클라이언트들이 자신의 요구사항이 더 급하다고 얘기를 하면 서로간의 협의를 해서 정해달라고 요구할 수 있다.

누구는 일을 던져주기만하고, 누구는 일을 처리하기만 하고 이럴순 없는것이다.
내가 담당하는 업무의 할당 목록은 내가 관리를 하는것이고, 불합리한것은 당당히 요구할 수 있다.

 

3. 일정관리 & 빠르게보단 정확하게

파견온지 얼마 되지 않았을때에는, 매일매일 야근을 당연한듯이 하고 있었다. 고객의 요구사항이 있다면 작고 사소한것이라도 매일매일 반영을 해서 매일 변해가는 소프트웨어를 전달해주고 싶었다. 그러자 회사 상사분께 꾸지람을 들었다.
야근을 하는게 절대 긍정적인 게 아니다. 일도 중요하지만 쉼도 정말 중요하다. 번아웃은 언제 찾아올지 모르는 도둑같은 존재이다.

정말 급하게 급선무로 처리해야하는 일이 아니라면, 언제나 소프트웨어의 완성에 있어서는 그 속도보단 정확도가 높아야 한다. 만약 내가 6시가 퇴근시간이라고 가정하면, 5시까지는 작업한 것들중에 반영이 가능한것들은 서버에 반영을 할 수 있게 준비를 하고, 반영 한후 모니터링 했을때 문제가 없다면 퇴근하면 되는것이고, 문제가 있으면 원복 해놓고 내일 작업하면 되는것이다.

소프트웨어의 완성도 보다는 우선순위를 해결하기에 급급하다면, 이는 절대 좋은 결과물이 나올 수 없고, 자신에게도 부정적으로 작용할수 밖에 없다.

위의 2번내용 항목에 이어, 정말 주어진 일정보다 주어진 업무가 터무니없이 무겁다면, "이 요구사항들은 이 기한 안에 다 할 수 없습니다. 다른 요구사항들을 제외시켜주시거나, 기한을 좀 더 주세요." 라고 당당히 말할 수 있는것이다.
늘 요구사항대로 움직이는 프로그래머라면, 이러한 일정 관리 능력은 정말 개발 외적인 요소중에 꼭 갖춰야 하는 능력중 하나이다.

---

이 이외에도 쓸 내용들이 더 있는데, 내용이 너무 길어질것을 방지하여 여기까지 마무리 하도록 하고,
다음에 추가 포스팅하거나 할 계획이다.