링크드인 프로필에 한 해 동안 한 일들을 정리해 본다. 이런 저런 일을 많이 했다. 그리고 비워두었던 자기소개 칸에 쓸만한 것들을 생각해 본다. 이상하다. 아무리 생각해도 무엇으로 나를 소개해야 할지 잘 모르겠다. 구직활동을 할 때는 과거의 일들과 지원 회사의 교집합을 찾아서 무엇이든 썼는데, 취직이라는 목적이 없는 지금 나를 표현할 말이 생각나지 않는다.
조용히 지나온 길을 복기해 본다. 난 지금까지 뭘 했나? 나는 어떤 사람인가?
나는 이상하다 싶을 정도로 첫 회사부터 회사를 옮길 때 마다 바닥부터 새로운 것을 만들 기회를 많이 얻었다. 내가 이런 일을 좋아해서 스스로 기회를 쟁취한 것인지, 하늘의 도움이 있었던 것인지는 잘 모르겠다. (아마도 둘 다인 것 같다) 나는 이렇게 바닥부터 새로운 것을 만드는 과정을 소프트웨어가 사람의 생각(또는 A4 용지에 적힌 몇 문장의 말)일 때부터 시작해서 컴퓨터에서 동작하는 소프트웨어가 되고 사용자에게 전달되기 까지의 과정을 겪는다고 표현하는 걸 좋아한다. 나는 아직 사람의 언어로도 표현되지 않은 생각이 소프트웨어가 되고 사용자에게 사용되는 걸 보는 과정을 운 좋게 많이 경험했다. 신입으로 입사한 회사는 테스트 자동화 도구를 만드는 회사였다. 회사에는 초창기부터 10여년간 만들고 고객에게 판매해온 제품이 있었다. 나의 첫 일은 회사 제품을 사용해서 고객을 지원하는 일이었는데 이 일에 실증을 느꼈다. 해가 바뀔 즈음 팀을 옮겨 제품 2.0 버전을 완전히 갈아엎고 3.0 버전을 바닥부터 새롭게 만드는 일에 참여하게 되었다. 10여년간 발전해온 이 코드는 너무 여러 사람을 거치며 간헐적으로 발생하는 오류나 고객의 요구에 유연히 반응하기 어려웠던 것 같다. 그때 여러 타입의 휴대폰과 연결을 구성하고 사용자의 테스트 동작을 자동화하기 위한 API 모듈을 개발했다. 두번째 직장은 무기를 개발하는 방산회사였다. 입사 후 고객이 미사일 시스템의 소프트웨어 업데이트 및 운영을 편리하게 할 수 있는 시스템 개발을 의뢰해 왔다. 한 1년 정도 고객이 종이에 적어준 몇 개의 문장이 소프트웨어가 되는 과정을 즐길 수 있었다. 내 개발자 인생에서 이 시절은 가장 행복했던 기억으로 남아있다. 하루하루 소프트웨어가 완성되어 가는 과정을 느끼며 정말 즐거워 했던 것 같다. 이 소프트웨어를 사용해 눈 내리는 날 군부대를 돌며 시스템 업데이트를 하던 기억이 생생하다. 이후에 나는 미사일 발사 제어 소프트웨어 개발을 맡았는데 이때도 기반 코드 없이 완전히 처음부터 시스템을 만드는 일을 하게 되었다. 여러 시스템들과 연동해야 하는 규모가 큰 소프트웨어를 정말 문서로부터 시작해서 미사일이 하늘로 날아갈 때까지 만들고 테스트해 볼 수 있었는데 이때 소프트웨어가 소프트웨어 답게 되어가는 과정을 제대로 경험한 것 같다. 아마 방산 회사의 엄격한 프로세스를 통과함으로 인해 더욱 그랬을 것 같다. 세 번째 회사는 우주 지상국 스타트업이었다. 입사한 첫 날 책상 위에 아주 두꺼운 제안 요청 문서가 새 컴퓨터와 함께 올려져 있었다. 국가 기관에서 차세대 우주 지상국 시스템을 구축하는 제안서를 작성해 줄 것을 요청하는 문서였는데 몇 달간 그 문서를 단어 하나까지 분석하며 시스템을 이해하고 설계하고 제안서를 썼고 사업을 수주할 수 있었다. 그리고 그 사업 중간에 회사 자체 지상국 서비스 개발에 올인하게 되었는데 회사의 기초가 될 서비스를 새로운 언어(Java)와 새로운 프레임워크(Spring Boot)를 사용해 개발할 수 있었다. 세 번째 회사에서 정말 힘든 시기를 보내긴 했지만 잘 정돈된 웹의 세계에 발을 들여놓았고 내가 기술을 바라보는 시야를 넓힐 수 있었던 것같다. 세 번째 회사와 네 번째 회사의 중간에 잠시의 휴식기에는 Netty와 Spark 오픈소스 프로젝트를 기웃거리다 대용량 파일을 저지연으로 전송해야 하는 이슈에 관심을 가지게 되었다. 그때 포트폴리오를 만들겸 파일 송수신 API 서버를 오픈소스 프로젝트로 시작해 일정궤도에 올려 놓을 수 있었다. 회사가 아닌 스스로 만든 첫 공개 프로젝트였다. 네 번째 회사는 문서 암호화로 업계에서 유명한 회사였다. 거대한 레거시 시스템이 나를 기다리고 있었는데 그 레거시 위에서 고객이 요구하는 기능을 추가하는 일을 해야했다. 나는 그곳에서 3개월의 시간을 다 채우지 못하고 퇴사를 하게 되었는데, 회사의 기술 책임자와의 갈등이 문제였지만 바닥부터 만드는 일이 아니었던 이 회사의 일은 나를 비껴갔다. 그리고 지금의 다섯 번째 회사를 만났다. 이곳은 소프트웨어 팀이 제대로 자리를 잡고 있지 않은 신생 스타트업이었는데, 여기서도 나는 인공 위성 탑재체 소프트웨어를 완전히 밑바닥부터 만드는 일을 했다. 이곳은 제품에 대한 스펙도 제대로 정해져 있지 않았고 그 일부터 차근히 해야했다. 올해 나는 인공위성 탑재체 개발을 마쳤고 우리는 SpaceX에서 2025년 1월 발사를 기다리고 있다. 돌아보면 나는 다른 동료들에 비해 소프트웨어를 바닥부터 시작해서 만드는 일을 많이 경험할 수 있었고, 이 경험이 지금의 나를 만든 것 같다.
앞서 바닥부터 소프트웨어를 만든 경험들을 소개했지만 바닥을 밟기 전에 레거시를 이해해야하는 일 역시 많았다. 어떤 경우에는 시스템의 요구사항이 이전 레거시 코드에 녹아져 있었다. 그래서 레거시 코드를 읽고 이해하는 경험도 많이 할 수 있었다. 당시에는 이런 일들이 무척 괴롭게 느껴졌는데 돌아보면 다소 엉망인 남의 코드(모든 서브 시스템과의 메시지를 처리하는 코드가 하나의 Switch-Case 문에 들어가 10,000라인이 넘는 클래스 같은)를 읽으며 코드가 이런 모습이여서는 절대 안된다는 신념 같은 것을 가지게 된 것 같다. 또한 레거시 코드에서 여러 기술적인 코드를 쏙 빼서 내것으로 만들 수 도 있었는데, 특히 첫 회사에서 제품 3.0 버전을 만들기 전 2.0버전에서 여러가지 윈도우 프로그래밍 기술을 체득할 수 있었고 안정적인 통신 코드들을 선배들의 코드로로부터 배웠고 지금까지도 잘 사용하고 있다. 남의 코드를 읽고 배우는 일은 개발자에게 중요한 것 같다. 남의 코드를 끈질기게 읽는 일은 대학교 학부 시절로 거슬러 올라가는데 그때 오픈소스로 공개된 어셈블러 C 코드를 분석했던 기억이 난다. 그때 코드 하나하나를 프린트해서 서로 연결하며 분석하던 경험이 실무에서 정말 많이 도움이 되었던 것 같다. 그때 왜 그런 일을 했는지 정확히 기억이 나지 않지만 교수님이 코드를 읽어볼 것을 추천했던 것 같다.
언젠가부터 나는 개발 문화를 만드는 일에 관심을 가지기 시작했다. 개발 문화라고 하면 조금 모호한 것 같아, 구체적으로 칭한다면 팀이 함께 잘 개발하는 방법 정도로 설명할 수 있겠다. 예를 들면 git을 사용해서 소스코드를 잘 관리하는 방법, Jira 같은 도구를 사용해 우리의 일들을 식별하고 관리하는 방법, Confluence 같은 것을 사용해 개발 중인 소프트웨어에 대한 우리의 생각(스펙, 설계 등)을 문서로 남기는 방법, 다양한 방법으로 빌드나 배포를 자동화하는 방법 등에 관한 것들이다. 이 일에도 이상스럽게도 내가 가는 팀들은 소프트웨어 개발 문화가 잘 자리잡혀 있지 않았고 회사에 가서 git을 사용하는 것을 뿌리 내리고 이슈 트래킹 도구도 적극 사용하도록 문화를 빌드업 해야하는 일이 많았다.
테스트 자동화 도구를 만드는 첫 회사에서 고객 제품의 테스트 케이스를 액셀 문서로 만드는 일을 가장 먼저 했다. 그때 처음으로 Given / When / Then 같은 테스트 케이스의 기본 구조를 익혔다. 경력이 조금 쌓이고 문서 대신 내가 코드를 마음껏 작성할 수 있을 때 즈음 나는 내가 만든 코드를 테스트하는데 꽤 공을 들였다. 그런 덕분에 시스템 통합을 위해 커밋한 버전으로 테스트를 하면 내가 만든 코드에서 오류가 나는 일은 거의 없었다. 두번째 직장까지는 JUnit 같은 테스트 프레임워크의 도움 없이 디버거나 별도의 테스트 함수를 만들어 내 코드를 테스트 했는데 웹을 접하며 JUnit을 만났다. 내가 그때까지 손수 작성하던 테스트를 위한 인프라 코드들을 죄다 JUnit이 정갈하게 만들어서 제공하고 있었고 나는 테스트 프레임워크의 매력에 푹빠졌던 것 같다. 내가 테스트를 좋아하는 이유를 생각해 보면 테스트는 내 코드가 올바른지 피드백 받는 유일한 수단이기 때문이라고 생각한다. 너무 당연하지만 이 일을 소홀히 하는 사람이 꽤 많다. 그리고 나는 코드 뿐만아니라 제품 자체의 스펙이 올바른지 테스트하고 피드백을 받고 개선하는 일을 좋아한다. 나는 코드를 테스트하는 일을 넘어 우리의 제품이 진짜 고객의 요구를 맞추고 있는지 테스트하는 일 까지 모두 포함해 테스트 업무를 좋아한다. 이런 내용을 담은 내용을 인프콘 2022에서 발표할 수 있었는데 테스트에 대한 나의 애정이 잘 드러나는 것 같다.
나는 언제부터인가 내가 만드는 소프트웨어의 가치에 대해 생각하기 시작했다. 회사 생활을 하다보니 이런 것들을 회사에서 내게 친절히 설명해 주지 않는다는 것을 깨달았다. 그래서 스스로 내가 하는 일의 가치를 정의하기 시작했다. 미사일 발사 제어 시스템을 만들 때에는 내가 대한민국의 방어 체계를 구축해 국가의 안보에 기여한다고 생각했고, 우주 지상국을 만들면서는 우주로부터 오는 가치있는 메시지를 받아주는 시스템을 만든다고 생각했다. 광학 위성을 개발하면서는 지구에서는 볼 수 없는, 우주의 시선으로 사람들이 가치있는 일을 할 수 있도록 돕는다는 미션을 스스로에게 부여했다. 나는 제품이 사용자에게 어떤 가치를 줄 수 있는지 생각한다. 단순히 기술의 집합체로서의 소프트웨어가 아니라 사용자에게 영향을 미치는 제품을 만드는 일을 늘 하고 싶다.
다소 저연차때부터 프로젝트 매니저 역할을 맡았다. 정확히는 두 번째 회사에서 개발자 3~4년차 때부터 프로젝트 PM역할을 맡게 된 것 같다. 처음에는 그냥 책임감 하나로 일을 이끌었는데 내가 매니지먼트 일을 꽤 잘한다고 생각했다. 사람들이 내가 매니징을 할 때 편하다는 얘기를 종종했다. 프로젝트는 대게 큰 불확실성을 안고 진행되는데 나는 이 불확실한 것들을 성실하게 분석해서 확실한 것들로 만드는 일을 잘했다. 이해 관계자들에게 끊임 없이 질문해서 모호한 영역들을 분명하게 하고 문서화해서 사람들과 공유하는 일을 쉬지 않고 했다. 많은 사람들이 그냥 묻어 두어 나중에 폭탄처럼 수면 위로 드러나는 문제 거리를 가능한 프로젝트 초기에 잘 끄집어 내서 해결하는 것이다. 팀원들을 독려해서 함께 일이 되도록 밀고 나가는 능력도 있었다. 우리가 해야하는 일을 식별해서 사람들에게 적절히 할당하고 통합하여 일이 되어 지도록 노력했다. 그러나 매니저로서 늘 좋은 평이 나를 따른 것은 아니다. 난 일 중심적으로 매니지먼트를 해왔는데 어떤 팀에서 사람들과 갈등을 겪으며 사람을 중심에 두는 매니지먼트가 내게 결여되어 있음을 깨닫게 되었다. 이후부터 사람에 대해 조금 더 집중하기 위해 노력하고 있다. 나는 이 매니지먼트 능력을 개발 능력 만큼이나 성장시키기 위해 지금 이 순간도 노력하고 있다.
나를 소개할 만한 것들을 찾기 위해 지난 시간들을 돌아보며 나에 대한 몇 가지 사실을 발견한다.
과거의 나로부터 나는 나를 어떤 유형의 제품과 연결해서 표현할 수 없다. 예를 들면 나는 OO을 만드는 사람입니다, 같은 말로 나를 표현할 수 없다는 뜻이다. 이유는 내가 어떤 한 가지 유형의 제품을 지속적으로 만들어온 것이 아니기 때문이다. 내가 해온 일들을 하나로 이을 수 있는 것은 내가 소프트웨어 엔지니어였다는 것 외에는 없는 것 같다. 소프트웨어 엔지니어로 오랫동안 성장해온 것 자체는 즐겁고 가치있는 일이지만 ‘나는 소프트웨어 엔지니어입니다’라고 나를 소개하기에는 어딘지 모를 아쉬움이 남는다.
어떤 제품과 연결하여 나를 설명할 수 없다는 사실은 질문 한 가지를 내게 던졌다. 나는 어떤 제품을 만들기로 스스로 결정해 본적이 있는가? 많은 직장인들이 그렇지만 나는 회사가 요구하는 것들을 성실히 만들어 왔다. 내가 정말 문제라고 느끼고 해결하고 싶은 열정이 일어나는 일에 뛰어든 경험이 없었다. 무언가 만들고 싶은게 있어서 그걸 만드는 회사를 선택한 적도 없었다. 대신 회사가 정해준 일을 하기 위해 움직여야 했고, 내가 왜 움직여야 하는지 이해하기 위해 일의 가치를 정의하려 몸부림 쳤다. 그러나 많은 경우 스스로 정의한 일의 가치들이 내 마음에 와닿지 못했고 나를 움직이는 열정이 되지 못했다. 그래서 나는 종종 열심히 일했지만 어딘지 모를 허전함을 느끼곤 했던 것 같다. 이런 생각을 하다보니 마흔이 되었는데 아직 내 인생을 시작도 못한 것은 아닌지 생각에 잠기게 된다. 내가 선택한 길로 내가 걸어갈 때 그것이 내가 된다는 생각이 든다.
직장인이라면 누구나 겪는 이 수동성에 대해 생각하다가 조금 예외적인 일들이 내게 있었음을 기억하게 된다. 앞에서 잠시 소개했지만 방산회사에서 미사일 발사 시스템을 관리하는 소프트웨어를 개발할 때였다. 이 일을 할 때 나는 정말 열정적이었고 일의 행복을 느꼈다. 지금 돌아보면 그때 내 마음이 움직였던 것 같다. 분명 내가 선택한 일이 아니었고 회사가 내게 부여해준 일이었는데 그 일은 유독 왜 내 마음을 움직였을까? 이유는 이렇다. 나는 이 프로그램을 개발하기 전에 프로그램이 하는 일을 직접 손으로 해야했다. 새로운 하드웨어 보드가 나오면 일일이 프로그램 파일들을 복사하고 정상 동작하는지 하나하나 확인해야 했다. 그 작업은 무척 귀찮았고 실수가 없도록 신중해야 했으며 내 귀한 시간을 많이 빼았아 갔다. 흔히 막내들이 전담하는 그런 일이었다. 이 일이 얼마나 사람을 성가시게 하는지 뼈져리게 느낀 후에 이 프로그램 개발 프로젝트가 꿈 같이 내게 찾아왔던 거다. 남이 내게 준 일이지만 그 일이 해결하려는 문제를 스스로 뼈져리게 공감했기에 그 일은 내 마음에 와닿았다. 세 번째 회사에서도 비슷한 경험이 있었다. 고객의 우주 지상국 서비스를 설계할 즈음이었다. 지상국이라는 도메인이 어떻게 동작하는지 몰라서 여러 이해관계자들을 인터뷰하면서 화면이 이렇게 동작하는게 맞는지 화면을 PPT로 디자인해서 검토 회의를 연거푸 열었는데 그때 나는 개발자의 행복이라는 것을 다시 한 번 느낄 수 있었다. 예비 사용자들을 만나 현재 시스템은 이래서 불편하고 새로 만들어지는 시스템은 이렇게 되면 좋겠다는 의견을 듣거나, 우리는 그 문제를 이렇게 해결하려 한다는 안을 보여 주며 대화할 때 내 마음이 전심으로 움직였다. 그때 나는 이 일에 얼마나 만족감을 느꼈던지 그런 일을 하는 프로덕트 디자이너로 직군을 전향할 마음까지 먹게 되었고, 몇몇 회사에 프로덕트 디자이너로 지원까지 했으니 그때 내 마음이 어땠는지 짐작할 수 있다. 그 일 역시 내가 하기로 선택한 일이 아니었는데 그 일은 내 마음에 와닿았다. 이번에는 이유가 뭘까? 앞선 사례와는 달리 그때 고통을 겪는 사람들은 내가 아니었다. 대신 진짜 고통을 겪고 진짜 더 나은 시스템을 원하는 다양한 예비 사용자들을 직접 만나 대화를 충분히 나눌 수 있어고 그래서 그들의 문제에 크게 공감할 수 있었던 것 같다. 내가 경험한 이 두 가지 예외적인 사건들로부터 나는 한 가지 사실을 유추할 수 있다. 나는 남이 정해준 문제일지라도 그 문제에 공감한다면 나의 일 마냥 열정적이고 즐겁게 일할 수 있다. 방법은 내가 문제를 겪어서 직접 문제에 대해 이해하거나 아니면 문제를 겪고 있는 사용자들을 가까이 하면서 그들의 이야기를 듣고 그들의 마음을 이해하는 것이다. 남이 선택했을지라도 내가 공감할 수 있으면 그건 내가 될 수 있는 것이다.
최근에 지금 회사의 미션을 이해하기 위해 우리 일의 가치를 정의해 본적이 있다. 우리는 광학 카메라로 지구를 촬영하는 탑재체를 개발하는 회사인데 다음과 같은 미션을 생각해 보았다. 우리는 “지구에서는 볼 수 없는, 우주의 시선으로 사람들이 가치있는 일을 할 수 있도록 돕는다.” 멋진 미션이다. 그런데 마음에 와닿지 않는다. 그냥 우주에서 사진찍는 거잖아. 뭘 하려는건데. 같은 불멘소리가 내 안에서 들려왔다. 글을 쓰기 전에는 내가 왜 그런 생각을 하는지 잘 몰랐는데 이제 알것 같다. 나는 우리가 해결해야 하는 문제에 대해서 충분히 공감하지 못하고 있고 그래서 우리의 일이 마음에 와닿지 않았던 것 같다.
우리는 12월 크리스마스 이후부터 겨울방학에 들어간다. 크리스마스 이브날이었는데 방학 첫 날에 우리를 보고 싶어하는 고객과 미팅이 잡혔다는 소식이 들려왔다. 그들이 우리 회사의 제품에 관심이 있다는 것이다. 그 날 싫을 법도 할 그 미팅이 이상하게 가보고 싶다는 생각이 들었다. 고객이 왜 우리 제품을 필요로 하는지, 무슨 니즈가 있는지 고객을 만나 보고 싶었다. 나의 내면에서 고객을 만나보고 싶은 간절함이 있었던 것 같다. 회사에서 직장인으로 살면서 내가 정말 행복하고 싶다면 나는 고객을 만나는 일에 조금 더 시간을 사용해 보는 것도 좋겠다.
내가 한 일 중에 유일하게 내가 주체적으로 선택하고 시작한 일이 한 가지 있었다. 회사 밖의 일이었는데 세 번째 회사와 네 번째 회사 사이 구직기간에 만든 오픈소스 프로젝트이다. 앞서 잠깐 소개한 것처럼 대용량 파일을 저지연으로 빠르게 전송하기 위한 파일 송수신 API 서버 기능을 제공한다. 만약 이 프로젝트가 잘 되었다면 나는 이 일을 지속할 수 있었을테다. 그리고 나는 파일 송수신 API 서버를 만드는 사람입니다, 같이 나를 소개할 수도 있었을지도 모르겠다. 그러나 이 프로젝트로 나는 성공하지 못했다. 돈을 벌지도 못했고 사람들에게 널리 사용되지도 못했다. 좋아요 17개를 받는 것이 성과라면 성과였다. 이 프로젝트가 제공하는 서비스는 일반적으로 사용되는 파일서버가 제공하는 성능과 유사한 수준의 성능을 보여줬는데 한 마디로 별 특별한게 없다는 거다. 내가 성능 비교를 했던 제품은 마이크로소프트 윈도우즈 운영체제에서 제공하는 FTP 서버였는데 사람들이 같은 성능이라면 내 제품을 쓸 이유가 없는거다. 다만 내 제품은 API를 통해 제어 가능한 편리한 기능을 제공했는데 이런 걸 어디서 필요로하는지 시장을 찾지 못했고 혹 그걸 필요로 하는 이들이 세상 어딘가에 있을지라도 그들과 연결되지도 못했다. 제품 유통의 문제라고 할까? 내가 선택하고 내가 만든 일이 내가 되기 위해서는 독보적인 탁월함을 가지고 사람들의 니즈와 연결되어 살아남을 수 있어야 한다.
과거의 생각들을 종합해 보면 내가 나 다워지기 위해 다음 세 가지가 필요하다고 요약할 수 있겠다. 첫째 나는 내 안에서 일어난 문제를 스스로 해결하기로 선택하고 그 일에 열정을 갖고 임해볼 필요가 있다. 둘째 내가 직접 제품을 만든다면 기존의 것보다 10배는 뛰어난 제품을 만들어야 하고, 그것을 사용자에게 전달하기 위한 유통망까지 기발하게 설계해 내야한다. 셋째 나는 회사 제품의 사용자를 더 가까이 만나 그들의 문제에 공감해야 할 필요가 있다. 요약하면 내가 나 다워지기 위해서는 스스로 공감하는 문제를 뛰어난 방법으로 해결해야 하는 것 같다. 잠시 내 가까이 있어 공감하는 문제들에 대해 생각해 본다.
내 인생에 문제의 순간들을 회상하다 보면 내 직업이 되기도 한 프로그래밍하는 문제가 먼저 떠오른다. 이 문제는 단순한 불편보다는 고통에 가까운 경험을 주기도 했는데, 첫 경험은 대학교 2학년 객체 지향 프로그래밍 수업으로 거슬러 올라간다. 그 수업의 첫 과제로 도서 관리 프로그램 개발이라는 난이도 있는 과제가 나왔는데 내 안에 이 과제를 해낼 능력이 없었다. 나는 머리를 싸매고 고민에 고민을 거듭했지만 결국 과제를 완성할 수 없었다. 그때 프로그래밍이 너무 괴로웠다. 잘하고 싶지만 잘할 수 없는 어떤 성지 같다고 할까. 후에 교수님과의 상담 시간에 나의 고통에 대해 털어놓았는데 교수님께서 무작정 코드를 작성하려 말고 문제를 조금 더 작게 나누어 보라고 조언해 주셨다. 나는 그 이후로 과제를 하나씩 해내기 시작했다. 나를 고통에서 건져준 교수님의 조언은 내가 가고 싶은 지향점이 된다. 프로그래밍이 어렵다는 이 고통스러운 문제는 대학교 첫 과제 때 한 번 마주 하고 끝이 아니었다. 10년 넘도록 개발을 해온 지금까지도 종종 만나고 나는 그때마다 누군가로부터 도움을 받아 고통에서 자유를 얻는다. 내가 받은 것이 많기에 나도 나만의 방법으로 누군가를 이 고통에서 구원해주는 일을 할 수 있다면 좋겠다고 생각한다.
사실 프로그래밍의 고통보다 훨씬 강력하고 컸던 내 인생의 고통은 고등학교까지의 교육을 받던 공부와 관련된 일이다. 나는 대학교에 와서 공부란게 재미있고 내가 왜 공부를 하는지 알게 된 것 같다. 고등학교 시절까지의 공부는 정말 암울했으며 내가 왜 이런 공부들을 하는지 쉽게 이해하지 못했다. 나의 공부의 목적은 그저 2002년 11월 어느 날의 수능시험을 잘보는 것이었는데, 좋은 대학을 가는게 내 12년 공부의 목표였다. 다시 생각해도 암울하기 짝이 없다. 아이를 낳고 기르다 보니 아이들에게 역시 수학 과학 공부를 왜 하는지 모르겠다는 말을 종종 듣는데, 아이들도 나와 크게 다르지 않은 학생 시절을 보낼까 겁이 나기도 한다. 나는 지금까지 어떠한 의미있는 행동도 하지 못했지만 아이들이 왜 수학을 배우고 과학을 배우는지 이해하도록 설명해 주고 싶다는 욕구를 자주 느낀다. 적어도 게임을 좋아하는 아이들에게 너희가 배우는 수학 공식들이 이 게임을 만드는데 사용되며, 너희가 신기해 하는 드론이 하늘에 붕붕 떠있기 위해서 미적분학이 사용된다고 설명해주고 싶다. 한 마디로 공부가 너희와 가까이 실세계에서 사용되고 있으며 너희가 놀라워하는 일들을 이루기 위해서는 공부가 필요하다는 것을 설명해 주고 싶은 거다. 그래서 아이들이 공부의 이유를 알고 조금 더 즐겁게 공부할 수 있다면 좋겠다는 생각을 한다.
이 외에도 만들고 싶은 서비스들도 있었다. 늘 실망스러운 휴게소 음식을 먹으며 휴게소 음식 리뷰 서비스가 있으면 좋겠다고 생각했고, 대학 축제나 주변의 여러 행사의 초대 가수 정보를 모아서 알람해주는 서비스가 있으면 좋겠다고 생각했다. 이런 것들은 사실 지금의 내가 만들 수 있는 여력이 없다고 느낀다. 일단 돈이 되도록 사업화 할 자신도 없고 시간도 없다. 그냥 언젠가 만들 기회가 있을까 하여 적어 둔다.
새로운 것을 만드는데는 많은 시간이 들지만 기존의 것을 개선하는데는 더 적은 시간이 든다. 2022년에 오픈소스 프로젝트로 만들어 두었던 파일 송수신 API 서버의 성능을 높이는 노력은 내가 나 다워지기 위해 해볼 수 있지 않을까? 그리고 이런 서비스를 필요로하는 사람들이 정말 있는지 사람들을 만나보고 그들에게 닿기 위해 조금이나마 노력해 볼 수도 있겠다.
지금까지 내가 나 다워지기 위해 스스로 공감하고 해결하고 싶은 문제들에 대해 생각해 보았다. 하지만 내가 나 다워지기 위한 노력 중 가장 현실적인 것은 다름아닌 현재 회사에 충실하는 것이다. 이곳에서 우리가 해결하는 문제를 이해하고 마음을 다해 일하기 위해 노력하는 것은 매우 실현 가능성이 높다. 고객을 어떻게든 만나고 고객의 소리에 귀를 기울여 보아야 한다.
현실적인 계획과 다소 터무니 없는 계획들이 머리 속에 혼재해있다. 현재로서는 다소 터무니 없는 일들, 곧 내 스스로 어떤 문제를 정의하고 해결해 보는 노력은 생각하면 할 수록 오히려 나를 우울하게 한다. 당장은 내게 돈이 없고 시간도 없기 때문이다. 그런 일을 풀타임으로 당장할 수 있는 여력은 내게 없다. 내 시간을 잘게 쪼개어 언제 내가 나다워지기 위한 일을 할 수 있는지 생각해 보면 평일에는 시간이 거의 없고, 이제 주말이면 나가 놀기 시작한 아이들 덕분에 생긴 토요일 하루 3~4시간이 현실적인 나만의 시간이 되겠다. 과연 일주일에 3~4시간으로 내 생각들을 현실로 바꾸어 낼 수 있을까? 나 스스로 조차 방금 터무니 없는 계획이라 치부해버린 일들을 일주일에 3~4시간씩 마주 해보자. 그리고 가장 현실적이고 단순한 회사의 일에 집중하는 일도 병행하자. 회사에서 매일 나에게 주어지는 일을 성실하고, 정직하게, 그리고 창의적으로 이루어가자. 매일 최선을 다해 최고의 것을 만들자. 고객을 만나 나의 일의 이유를 찾자. 두 가지 일을 병행해야 한다고 생각한다.
아내의 추천으로 김형석 교수님의 ‘100세 철학자의 사랑수업’이라는 책을 펼쳐보게 되었다. 첫 장에서부터 이런 문구가 있다.
나 때문에 행복해지는 사람이 얼마나 있는지가 행복의 기준이 되어야 한다.
-100세 철학자의 사랑수업 중-
마음으로 동의할 수 있는 설득력 있는 문구다. 과거를 돌아보고 미래를 꿈꾸었는데 한 마디로 모든 것을 요약하기에 적절한 문장인 것 같다. 나 때문에 행복해지는 사람이 많아졌으면 좋겠다. 사람들이 나로 인해 행복해 하는 어떤 것들이 곧 나는 누구인지 설명할 것이며 나를 나답게 하는 것들이 되어줄 것이다.
안녕하세요 저는 핀테크회사에 취업한 지 10개월차 되는 풋내기 개발자입니다.
오늘도 여느때와 같이 회사 내 레거시 코드들을 분석하며 '왜 TCP 전문 송수신은 sleep을 걸어서 불편하게 할까' 고민을 하고 서핑을 하다 우연히 주싱님의 블로그에 들르게 되었습니다.
퇴근을 하고 나서도 회사에서 읽었던 회고글이 기억이나 다시 한 번 읽어보게 되었습니다.
참 좋은 글이라고 생각했습니다. 어찌보면 저랑 비슷한 과정을 먼저 겪으신 선배처럼 느껴져서 일 수도 있습니다.
소프트웨어에 애정이 있으신 분인 것 같아, 그리고 삶을 살아가는 모습에 멋짐이 있으신 것 같아 부럽습니다.
그리고 파일 전송 서비스도 깃허브에 들어가 봤습니다. 제가 회사 내에서는 C와 자체 라이브러리를 쓰기 때문에 자세하게 이해하지는 못하였지만, 매력적인 아이템이라고 생각했습니다.
금융권에서 테크핀 회사들(Ex)토스, 카카오뱅크)은 전자문서라 불리는 '전문'을 전송하기 위해 http프로토콜을 많이 사용하지만 이외에 시중은행, 지방은행, 2금융권, 카드사, 보험사, VAN사, PG사 등 다양한 기업들이 기술력 부족으로 인해, 혹은 바꾸기에는 너무 많은 기술부채로 인해 아직까지 TCP/IP를 사용하고 있습니다. 또한 그 전송 과정이 데이터 패킷 유실 위험 때문인지는 모르겠지만 블럭 단위로 쪼개고, 패킷 3~5개 단위로 나눠 보내며 중간중간 1초정도 sleep을 걸고 있습니다. (이로인해 안정성 있는 TCP/IP 송수신 체계를 구축한 것 같지만.. 사이즈가 큰(ex) 1GB)파일의 경우 모니터링을 계속해야 하는게 꽤 불편하게 느껴집니다.)
당근페이에서 http와 tcp/ip의 확장성을 위해 netty를 사용한 기술 블로그 글도 있으니 확인해보는 것도 재밌으실 수 있습니다.
두서 없이 길게 쓰게 되었지만, 이런 도메인에서 이런 문제점이 있다 정도를 말씀드리고 싶었습니다. 좋은 글 써주셔서 감사합니다.