25년 상반기 회고: 불안과 고뇌(1)

이전 블로그를 날려버려서, 회고를 어떻게 썼는지 잘 기억이 안 난다.

몇 개는 개인적으로 의미 있는 것들이라 가져와야 할 것 같은데 일단 나중에 해야겠다.

 

정기적으로 쓰는 회고는 주단위 학습 기록, 상/하반기 회고, 연간 회고가 될 것 같다.

외에는 굵직한 이벤트가 끝났을 때 회고를 쓸 것 같다. 프로젝트 회고 같은

 

상반기 회고는, 개인과 회사 업무의 영역으로 나눠보려고 한다.

완전히 구분 지을 수 없지만, 글을 구분하기 위해서 그렇게 쓰려고 한다.

---

회사 업무 회고

현 직장은 꽤나 복잡한 환경에 있다.

우리 법인, 본사 법인, 기간 시스템 개발하는 외주 업체, 본사 생산 외주처, 해외 법인 공장 등등

 

이해관계 고려도 해야하고, 시스템 영향도를 다각도로 고려해야 하는 현 직장이다.

그런 상황에서 경험했던 몇 가지를 기술해보려고 한다.

FE 개발자? 소프트웨어 개발자?

세상에는 정말 많은 개발자가 있다. 당장 웹 개발을 세분화하기만 해도 FE, BE, INFRA, QA, SRE, 보안, DBA 엔지니어 등 다양한 직무의 개발자가 필요하다.

 

결국 내가 회사의 영역에서 마주한. 프로의 영역에서 마주한 개발자는 기존에 내가 정의한 것이 맞았다.

현실의 문제를 컴퓨터 기술로 풀어내려는 니즈가 있을 때, 그것을 기술적으로 어떻게 풀어내는가? 를 구현하는 직군이다.

 

컴퓨터가 보편화된 세상에서는 당연히 수요가 많을 수 있는 직군일 수밖에 없다.

여전히 인기도 많고.

 

지난 상반기동안 든 생각은 나는 커리어의 시작을 FE로 정의했지만

결국에는 어떤 문제든 해결할 수 있는 개발자가 최종 목표가 되어야 한다고 생각한다.

 

물론 이런 사고에는 다양한 원인들이 있었다.

FE 직무로 입사했지만, FE 업무를 하지 않으면서 전체적으로 개발을 위한 기획부터 업무가 주어진 회사의 상황.

개인적으로 나를 도와주시는 재영님, 선우님, 브라이언님, 희찬님이 본인의 영역과 다른 파트에서도 통찰력과 개발 능력을 보여주시며 문제해결을 하시던 모습들.

 

개발자는 여전히 참 재미있고, 나를 설레게 하는 직종이다.

평생 공부 해야하는 직업라고 하지만 21세기에서 살아남으려면 그렇지 않은 직업은 몇 없을 것이다.

 

서두가 길었는데, 결론적으로는 문제 해결력을 갖춘 개발자가 되어야겠다는 생각을 다시 한번 확신할 수 있었던 지난 상반기였다.

나름 회사에서 인정받을 수 있는 문제 해결을 하여 성과로 인정받을 수 있었다. 

 

대표적으로는 제품 라벨에 한글 폰트를 출력해야 하는 업무가 있었다.

사내 및 외주처에서 쓰이는 프린터에서 한글을 출력하려면 폰트를 삽입해줘야 하는데,

기간 시스템 개발 외주업체가 기존에 사용하던 폰트는 출처를 파악하기 어려워 추후에 저작권 이슈가 발생할 수 있었기에 무료 폰트를 찾았다.

 

다만, 무료 폰트를 그대로 넣으려니 구형 프린터의 플래시 메모리는 2MB의 여유 공간이 있어서 6MB 폰트가 안 들어갔고,

그래서 어떻게 폰트를 수정하면 좋을지 고민하고 리서치하다가 산업규격으로 지정된 KS X 1001을 찾아내서 필터링하고, 영문이랑 숫자, 특수문자를 추가했다.

 

거기다 DB에서 라벨에 사용되는 문자열을 SQL문으로 필터링해서, 기입되지 않은 특수문자까지 추가 기입을 해줬다.

6MB 짜리 폰트를 554KB로 줄여서 해결했다.

 

여기서 또 발생한 문제가 프린터를 타사와 공유하는 케이스와 프린터 케이블이 RS232여서 데이터가 불안정하게 들어가지 않는 이슈가 있었다. 이를 해결하기 위해서 usb타입으로 프린터 케이블을 교체하고, 타사와 같이 쓰는 경우에는 RS232의 전송속도를 프린터와 PC 속도를 맞추어 전송하는 방식으로 가이드했다.

 

그래도 안된다고 하는 몇몇 회사들이 있어서, 외주관리팀의 협조를 받아 생산 외주처 현장에 가서 직접 폰트를 설치하고 가이드를 드렸다.

 

이런 사례처럼, 어떻게든 문제를 해결할 수 있는 사람이 되기 위해 노력하고 있다.

자회사 법인이라지만, 우리도 나름 스타트업이기에 조직원이 어떻게든 맡은 일을 마무리 지어야 한다.

그래야 살아남는다.

 

대한민국 회사원 中 1

신입사원으로 회사에 입사해 본 입장에서 현직자들이 봤을 때

신입의 가장 답답한 점은 '회사'가 돌아가는 구조를 모른다는 것이다.

 

당연히 모를 수밖에 없지만

종종 이러한 이유 때문에 경력직을 선호하는 것일 수도...라는 생각이 들곤 했다.

 

기본적인 근태부터 결재, 직급 체계, 업무 프로세스, 협업 프로세스 등등 신입사원이 배워야 할 '회사원으로서의 스킬'이 한 트럭이다.

 

일례로, 도움을 드렸다가 곤란했던 적이 있었다.

 

우리 회사는 전산법인이 별도 자회사로 분리되어 있다. 그리고 본사 쪽 하드웨어 관리 업체가 별도로 있다. 그런 상황에서 본사 직원분이 보기에는 그런 구분 없이 내가 전산팀이니, 내게 PC 수리를 의뢰했고 아무것도 모르는 채로 나는 수리해 드렸다. (윈도우 업데이트를 하면서 그래픽 드라이버가 충돌 나서 DDU로 싹 밀고 클린 재설치해드렸다.)

 

근데, 이거는 업무 프로세스상 내가 하면 안 되는 거였고, 그에 대해서 피드백을 받았다.

 

사실 위 사례처럼 크게 문제 되거나 이슈 될만한 것들은 없다.

약간의 눈치만으로도 어떻게 하면 되겠다는 게 눈에 보일 것이다.

 

생각보다 문서 작업 올리는 것도 어렵지는 않았다.

 

품의서나 결재서를 올릴 때도 간단한 지출결의는 기존 문서를 톺아보고 양식에 맞추어 제출하고

기존 사례가 없는 업무 프로세스(설비 신규 견적 건)는 일단 내 기준으로 필요한 것들을 문서화하고 빠르게 피드백받으면서 업무 프로세스를 만들었다.

 

그리고 그 과정 기록하면서 다음에는 질문을 최소화하도록 했다.

 

기술의 레거시는 문제가 아니다.

현재 내가 담당하고 있는 시스템은 20년 이전 기술이거나 현재 트렌드랑 맞지 않는 기술들로 구성되어있다.

C#, MSSQL, DevExpress, Power builder 등등

 

생각보다 자료 찾는게 어려워서 그렇지, 레거시에 대한 인식이 크게 나쁘지는 않다.

애초에 개발이라는게 언어나 방법이 다를 뿐, 결국 문제 해결을 했다는 것이기에.

 

다만, 레거시를 쓰는 사람들의 태도가 되게 중요한 것 같다.

레거시를 쓰면서도, 이슈의 사이드 이펙트와 타 시스템 영향도를 고려해서 처리한다면 그 시스템은 문제가 없을 것이다.

 

현재 기간 시스템 개발 업체는 그런 부분에서 꽤나 아쉬움이 있다.

문제가 발생할 경우 그것들을 단편적으로 처리하려는 경향이 있어서 시스템이 많이 망가져있다.

 

그리고 여전히, 발생하는 이슈들을 그런 관점에서 처리하고 있다.

여기서 내가 해야하는 건, 프로세스를 올바르게 분석하고 다양한 기간 시스템에 미치는 영향을 분석한 뒤

제대로 된 요구사항을 외주 개발처에 전달해야 한다.

 

어떻게 보면 신입의 입장에서는 매우 어렵하다. 스트레스도 꽤 있다.

그럼에도 직장은 프로의 영역이기에 해야하는 일이라고 생각하고 최선을 다하고 있다.

 

기술의 레거시? 생각보다 문제는 없다. 레거시도 결국 프로그래밍 언어이다.

하지만 레거시를 쓴다는 것이, 마인드도 레거시가 되었다는 의미이지 않을까 싶었던 순간이었다.

 

여전히 내가 잘하는 것, 자신 있는 것

작년 취업때도 그렇고, 사회에 나온 20대부터 내가 밀 수 있었던 잘하는 스킬은 커뮤니케이션이였다.

 

특히나 개발자에게 커뮤니케이션이 중요한 이유는 도메인 지식때문이다.

현업, 관련자들에게 도메인 지식을 전수받아야 개발을 잘 할테니 말이다.

애초에 도메인 지식을 컴퓨터로 옮기는 직종이니.

 

내가 정의하는 커뮤니케이션은 다음과 같다.

두 사람 이상의 관계에서 소통이 일어날 때, 모두가 동일한 맥락을 이해하여 같은 방향을 보는 것.

 

회사에서도 이러한 정의를 지키기 위해서 내가 가진 처세술을 열심히 활용하고 있다.

 

정치라고 해야하나.

조금 밀어 붙여야할때도 있고, 물러서야 할 때도 있고.

알아도 모른척, 몰라도 아는 척 해야할때도 정말 많다.

 

누군가의 도움(레버리지)을 이용해야 할 때도 많다.

업무에 어려움이 있다면 상사나 주변 동료의 도움을 받아 업무를 처리해야한다.

 

사람과의 관계에서 나는 토큰의 개념을 쓰는데, 토큰이란 기브앤테이크이다.

예를 들어, 내가 상대방에게 호의를 베풀었으면, 나도 나중에 상대방에게 호의를 요청할 수 있는 그런 것이다.

단순히 정량적으로 판단할 수 없겠지만, 일단 먼저 호의를 베풀면서 그런 토큰을 얻어가는게 내 커뮤니케이션 방식이다.

 

물론 그 안에서 친절함을 갖춰야한다.

 

그런 평가가 있어서 그런지 입사 6개월만에 한 기간시스템의 담당자가 되었는데.... 힘들다

아래 아쉬운 것에서 기술할 듯.

 

아쉬운 것

솔직히 우리 회사가 처해있는 상황이 정말 쉽지 않다.

시니컬하고 폭언/욕설을 일삼는 외주 개발처(쓸까말까했는데 사실이니까 쓴다). 슈퍼 을이 이런 느낌인가.

 

각 담당자가 모듈별로 담당하는게 아니라 기간 시스템 하나를 통째로 관리해야해서,

그 안에서 존재하는 세부적인 도메인 지식을 파악하는게 쉽지 않다.

 

그걸 제대로 파악하려면 디테일하게 파고들어야 하는데 너무 빠르게 컨텍스트 스위칭이 발생하다보니 하나의 지식을 온전히 흡수하지 못한채 컨텍스트 스위칭이 발생한다.

 

현재 나는 15개 이상의 서로 다른 모듈의 이슈를 동시에 트래킹하고 있다.

 

그리고 나머지는 나쁘지는 않은데, 그냥 사회 초년생으로서 흔한 실수? 작은 후회랄까?

조직원 모두가 다 같은 생각일 것이라는 틀린 생각, 개인적인 얘기는 더 줄일 것 등등

 

이런 아쉬운점들이 있었다.

---

너무 글이 길어져서 글을 나누려고 한다.

2편 개인회고에서 계속