✍️ 개발자로 잘 살아가게 만든 나의 사건들

20살, 전공으로 프로그래밍을 처음 접하고 17년이 훌쩍 흘렀습니다. 그 시절부터 쭉 회상하다보면 늘 떠오르는 사건들이 있더라고요. 그리고 이 사건들이 결국, 제가 개발자로 잘 살아가고 싶게 만들었구나 하는 생각도요. 하나. 프로그래밍의 재미를 알게 됨 성적에 맞춰 컴퓨터 공학으로 전공을 택했을 뿐, 대학교 입학 전에는 싸이월드(!)만 열심히 했던 사람이었어요. 학부 1학년 당시, C언어 강의를 수강하며 도저히 검은 바탕에 하얀 글씨로 써내려가는 행위에 흥미를 못느꼈던 저는 부모님께 자퇴 시위까지 했었죠. 그러다 우연한 기회로(= 구구절절한 사연이 있지만 생략) 임베디드SW 연구실의 학부 연구생으로 선배들의 작업을 도왔어요. 도왔다고 표현했지만 사실 선배들의 도움을 받아가며, 내가 코드를 작성한 의도대로 물체(= 하드웨어, 디바이스)가 동작하는 모습을 보며 처음으로 프로그래밍의 재미를 느꼈습니다. '내 코드에 의해 다양하게 동작하는 결과를 확인한 것'이 프로그래밍에 대한 흥미를 끌어낸 첫 사건이었어요. 둘. 문제 정의에 대한 중요성을 깨달음 개발자가 직업이 되고 한동안은 코드에 의한 결과를 보는 것에 빠져있었죠. 요구사항이 명확히 주어지면 코드로 풀어내는 일이요. 그러던 중, 한 회사의 면접을 보았고 면접관은 평소 업계에서 존경하던 분이었어요. 저는 면접 내내 '왜?'에 대한 질문을 계속 받았고, 그 수많은 '왜?'에 단 하나도 제대로 답을 할 수가 없었어요. 그때까지 저는 제가 작성한 코드와 기술에 '왜?' 라는 질문을 던져본 적이 없었거든요. 그저 널리 사용되는 기술을 사용하고, 기능하는 코드를 만들어 내는 것에 머물러있던 거에요. 그리고 비슷한 시기에 업계 선배들과 손코딩 스터디 모임을 하고 있었습니다. 주어진 문제를 읽고 빠르게 코드를 작성해서 결과를 확인하고 싶어했던 저를 선배들은 말렸죠. 코드를 작성하기 전에 주어진 문제를 정확히 읽고 제약사항 등을 확인한 후 정의하는 것 부터 하자고요. 처음에는 답답했던 이 행위가 결국 오답을 줄이고 궁극적으로 빠르게 가는 길이란 것을 알았어요. 이 두 사건은 저에게 '문제를 바라보고 명확히 정의하는 일은 내가 해야하는 일임과 동시에, 적절한 수단을 스스로 선택할 수 있는 시작' 이라는 깨달음을 주었어요. 셋. 목표와 수단을 구분하는 일 우리나라가 아닌 타지에서 빠르게 서비스를 구축해야 하는 일이 있었어요. 그리고 스스로 의사결정을 내려야 하는 일이 굉장히 많은 환경이었고요. 서비스 구축을 위한 처음 6개월 정도는 '우리가 기술적으로 해결할 수 있는 것 / 해결할 수 없는 것 / 해결해야만 하는 것 / 해결하지 않아도 되는 것'을 늘 기준으로 세우며 일했죠. '기술' 자체에 목적을 두지 않고, 서비스가 달성해야 하는 목표를 위해 냉정하게 '기술'에 대한 우선순위를 판단하고 실행하고 성과를 이뤄낸 경험이었습니다. 드디어 '서비스/제품 만드는 일이 즐거운 프로그래머'라는 자체 슬로건에 부합하는 사람이 된 기분이었습니다. 각자의 사건은 다르겠지만, 각 사건에서 얻은 일련의 깨달음은 많은 분들이 비슷하지 않을까 생각해요. 분명 저는 이 사건들로 더 나은 개발자가 되었고요. 앞으로는 또 어떤 사건이 저를 개발자로 계속 살아가게 만들까 궁금합니다. 😅