맛있는 이력(feat JSON 상하차)

최근 흥미로운 주제로 이야기를 나눴고 거기서 인사이트를 얻어서 글로써 정리해보려고 한다.

이력서 작성시 프로젝트 이력에 대한 주제였다.

이력서를 좋게 쓰고싶지만 내가 했던 프로젝트 경험들은 전부 구현에 치우쳐저 있었다.

개발자에게 프로젝트 구현은 당연한 일이기 때문에 눈의 띄는 이력이 없어서 속상하던 찰나 지인분들께서 좋은 이야기를 많이해주셨다.

JSON 상하차

프로젝트를 진행할 때는 각종 버그와 마주치며 개발을 진행하지만 막상 이력으로 남기려다보니 적기가 애매한 경우가 있다.

보통 이력서에는 문제해결이나 개선사례를 적는데 내가 해결한 문제해결은 적기에는 너무 간단하고

단순히 JSON 상하차를 하는 프로젝트였기 때문에 개선사례를 적기에도 애매했다.

JSON 상하차라는 단어를 들으면 어떤 느낌인지 감이 올텐데 정말 간단한 CRUD 작업만 했다는 뜻이다.

이에 대해 지인들에게 푸념을 늘어놨었다.. 업무 들어오는게 단순 JSON 상하차이고, 뭔가 개선이나 문제해결을 하고싶어도 못한다고..

그나마 찾아서 찾아서 했던 일이 리팩터링, 테스트 코드 작성과 같은 일이었다.

이마저도 어떻게보면 당연히 해야하는업무 중 하나다.

이런 상황인 사람들이 은근히 많을거라 생각한다.

매력이 참 없네....

보통의 이력서는

• 내가 재직했던 회사와 회사에서 맡았던 업무
• 내가 개발했던 프로젝트 상세

위 두개의 파트를 중점으로 작성할 것이다.

두 개의 파트에서의 목표는 다음과 같다고 생각한다.

내가 재직했던 회사와 회사에서 맡았던 업무 

• 목표 회사에서 원하는 이력을 어필한다.
• 어떤 도메인 지식이 있는지를 어필한다.

지원하는 회사에서 원하는 지원자의 도메인 지식이나 경험은 위의 파트에서 어필할 수 있다.

만약 여기서 지원할 회사와 도메인이 맞지 않는다면 

내가 개발했던 프로젝트 상세에서 내가 어떤 경험이 있고, 어떤 능력이 있는지를 어필한다.

여기에서 본인의 강점이 들어나야 승부가 난다고 생각한다.

안타깝게도 둘 다 내세울 이력이 없다는게 속상했다.

프로젝트 괴롭히기

지인 분이 그럴 때 일수록 프로젝트를 많이 괴롭혀봐야한다라고 했는데 여기서 큰 인사이트를 얻은 것 같다.

그동안 백마탄 왕자님처럼 갑자기 대용량 트래픽 혹은 이력서 업데이트하기 좋은 장애나 개선상황을 기다리기만했다.

갑자기 트래픽이 몰려 동시성 이슈가 발생하고 해당 이슈를 멋지게 처리하는 일을 말이다.

그러나 현실은 간단한 로직으로도 충분히 처리가 가능한 트래픽이었고 심지어 해당 프로젝트가 클라이언트의 개인이 사용하는 경우도 있었다.

그러기 때문에 유지보수 업무나 신규 기능 개발시에도 특별한 고려없이, 특별한 이슈없이 마무리되었다.

그래서 마음 속으로 다양한 경험과 성장을 시켜줄 환경을 찾았던 것 같다.

예를들어 엑셀 업로드나 엑셀 다운로드 같은 경우가 있겠다.

엑셀 업로드나 다운로드같은 기능은 성능 개선하기에 안성맞춤이다.

대용량의 엑셀 파일을 가지고 작업을 할 때 어떤식으로 처리를 하고 개선했는지는 이력에 남기기에 좋다.

하지만 어지간한 엑셀 파일의 크기로는 성능 개선할 상황을 만나기가 쉽지 않다.

이때 필요한게 여기서 마무리하느냐 아니면 계속 괴롭혀보느냐이다.

엑셀의 크기를 억지로라도 키워서 서버에 부하를 주고 이러한 상황에서 성능을 개선해보는 것이다.

마치... 방범창 아저씨처럼..

저 영상의 주인공이신 분의 인터뷰를 보면 저 영상이 탄생된 시기는 회사가 잘나가던 시기가 아니라고 한다.

회사가 어려울 때 해당 영상을 찍어서 올리게 되었고 매출이 급증해서 회사가 살아났다고 한다.

결이 다른 얘기일지 모르지만 방범창이 잘 팔려 고객의 피드백과 다양한 불만사항을 통해 개선해서 만들어진 제품이 아니라는 것이다.

마치 현재 개발하는 프로덕트가 대용량 트래픽을 받지 않고, 성능에 민감하지 않는 상황과 같다고 생각했다.

지금은 발생하지 않더라도 어떤 문제점이 있고 어떤 개선점이 있는지 주의깊게 살펴보는 것이 중요하다.

주어진 환경에서 무언가를 해보려고 했는지가 중요한 것 같다.

업무가 우선이다

모든 프로젝트에는 기한이 정해져 있다.

충분히 마무리할 수 있는 프로젝트이지만 억지로 개선점을 찾는다고 업무에 지장이 되어서는 안될 것이다.

이건 온전히 따로 시간을 투자하는 수 밖에 없다.

비슷한 환경을 만들어 이것 저것 테스트해보고 개선점을 얻은뒤 회사 프로젝트에 적용해봐도 좋을 듯하다.

그럼에도...

하지만 이마저도 한계는 있을 것이라 생각한다.

대용량 트래픽이 몰리고 생각지도 못한 다양한 이슈를 경험하고 개선할 수 있는 환경에 비하면 한계가 존재할 수밖에 없다.

그러나 주어진 상황에서 발만 동동 구르고 있는 것보다는 개선점을 찾아보려 고민하고 노력하는 것에는 큰 차이가 있지 않을까 생각해 본다.