요약
쓸모를 따지지 않고 호기심만으로 코드를 짜는 시간이 개발자의 열정을 지켜 줍니다.
소프트웨어 개발자 크리스토퍼 피리가 자기 사이트에 발표 자료로 올린 글입니다. 일이나 돈, 바깥의 요구가 아니라 즐거움 자체를 위해 하는 프로그래밍을 정의하고, 그 유형과 실천법을 정리했습니다.
왜 중요한가
- 사이드 프로젝트나 면접 준비처럼 결과를 노리는 코딩과 달리, 동기가 안에서 나오는지를 기준으로 삼습니다.
- 쓸모없는 것을 만들어도 된다고 허락해 주어, 생산성 압박 없이 배우는 길을 보여 줍니다.
핵심 내용
- 저자는 재미로 하는 코딩이 번아웃(지쳐서 의욕을 잃는 상태)을 막고 직관과 열정을 길러 준다고 봤습니다.
- 과정을 공개 방송하는 사람, 복잡한 시스템을 장난감 버전으로 다시 만드는 사람 등 다섯 유형을 나눴습니다.
- 계획보다 흥미를 따르고, 지루해지면 관심이 없다는 신호로 받아들이라고 했습니다.
- 배포나 CI/CD(자동 빌드·배포 체계) 걱정이 없는 실험용 공간을 따로 두라고 권했습니다.
- Tsoding, ThePrimeagen, 케이시 무라토리, 벤 이터, 댄 루 등을 본보기로 들고, 재미가 없어지면 멈추라는 규칙만 남겼습니다.
HN 반응
- 여가 코딩이 오히려 사람을 지치게 한다는 경험담이 여럿 나왔고, 회의와 스프린트가 없는 개인 프로젝트는 쉼이 된다는 반론도 있었습니다.
- 한때 채용에서 취미 프로젝트를 높이 쳤다는 지적에는, 이력서를 채우려는 코딩은 이미 재미로 하는 프로그래밍이 아니라는 답이 달렸습니다.
30대 후반이 되어서야 받아들인 냉혹한 현실이 있습니다. 제가 좋아서 하는 일도 여전히 스푼(spoon)을 소모한다는 겁니다. 그러니까 좋아하는 일을 하다가도 번아웃에 빠질 수 있다는 뜻입니다. 프로그래밍도 그런 일 중 하나여서, 여가 시간에 하는 프로그래밍도 보람은 느꼈지만 저를 계속 지치게 했습니다.
더 회복이 되는 방식의 놀이를 찾아 우선순위에 두어야 한다는 걸 깨달은 뒤로 정신 건강이 꽤 좋아졌습니다. 그건 어릴 적부터 품었던 열정이 그저 평범한 직업이 되도록 내버려 둔다는 뜻이기도 했습니다. 하지만 괜찮습니다. 솔직히 더 일찍 그렇게 했으면 좋았겠다 싶습니다. 저를 지금 자리까지 데려온 방식이 앞으로 가고 싶은 곳까지 데려다준다는 보장은 없으니까요.
혹시 여러분은 그렇지 않아서 취미로 하는 프로그래밍이 진짜로 회복이 된다면 잘된 일입니다. 저는 그저 제 경험을 나누고 싶었습니다. IT업계의 헝그리 정신 문화 때문에 이런 조언이 모두에게 맞는 건 아니라는 사실을 깨닫기 어려울 수 있거든요. 특히 감정표현불능증(alexithymia) 기질이 조금이라도 있는 사람들에게는 더 그렇습니다. 직업 프로그래머 사이에는 꽤 흔한 것 같더군요.
저는 아이디어를 그냥 스케치만 해도 비슷한 즐거움을 느낍니다. 때로는 글이나 문서로만, 때로는 연필과 종이로 그립니다. 창작 욕구가 채워지고 나면 그것을 실제로 돌아가게 하려면 대략 어떤 코드를 짜야 할지 머릿속에 그려집니다. 요즘은 보통 여기서 멈춥니다. 만드는 데 드는 노력이 훨씬 크다는 걸[0] 알고, 그게 세상에 존재했을 때의 쓸모는 대개 아주 작거든요. 그래서 아이디어 폴더에 던져 넣고, 계속 머릿속을 떠나지 않는 게 아니라면 다시 들여다보지 않습니다. 그런 경우는 한번 만들어 볼 만하다는 신호일 수 있습니다. 다만 제 프로젝트에는 사업적인 면도 있는 경우가 많아서, 내가 정말 창업자가 되고 싶은지, 개발이 끝난 뒤에도 거기에 시간을 쓰고 싶은지를 더 따져봐야 하는데, 답은 대개 아니오입니다.
[0] 요즘은 AI로 노력이 적게 들 수도 있지만, 저는 그런 도구로 개발하는 데서는 즐거움도 성취감도 느끼지 못합니다
저도 올해 초 40대 중반에 같은 결론에 이르렀습니다. 앞으로 10년쯤 더 일하고 50대 중반에 조기 퇴직해서 전업으로 취미 프로그래밍에 전념할 생각입니다.
저한테도 똑같은 일이 있었습니다. 1년쯤 억지로 취미 프로그래밍을 완전히 끊었고, 지금은 가끔 작은 프로젝트를 하지만 선을 정해 두고 합니다. 요즘은 음악과 독서에 더 집중하고요. 게임 만들기가 제일 덜 부담되는 프로그래밍 프로젝트인 것 같은데, 아트, 디자인, 음악이 섞여 있어서 프로그래밍이 과정의 일부일 뿐이기 때문이라고 생각합니다.
그 정의는 제가 1981년에 컴퓨터를 시작한 방식을 그대로 설명하네요. 라디오쉑(Radio Shack)에서 겨우겨우 돈을 모아 산 4K짜리 8비트 컴퓨터를 집에 가져와 TV에 연결했습니다. 컴퓨터를 만져본 적도 없고 사전 지식도 전혀 없었고, 상자에 든 매뉴얼이 전부였죠(놀랄 만큼 잘 만든 매뉴얼이었습니다). 제 주변에 집에서 컴퓨터를 쓰거나 직장에서 쓰는 사람은 한 명도 없었고, 컴퓨터로 돈을 벌 수 있다는 건 생각조차 못 했습니다. 그냥 게임이 재밌어 보였고, 프로그래밍을 배운다는 발상 자체가 멋있게 느껴졌을 뿐입니다. 흑백으로 인쇄된 취미 잡지에 실린 긴 코드 목록을 직접 쳐 넣고 오타를 찾아내는 건 배우는 방법으로 아주 훌륭했습니다.
어셈블리어를 독학하는 건 더 힘들었습니다. 문서가 없었으니까요. 저는 얼마나 아는 게 없었던지 전화번호부에서 모토로라를 찾아 전화를 걸어 매뉴얼을 어디서 구할 수 있느냐고 물었습니다. 전화를 받은 영업 담당자가 저를 불쌍히 여겼는지 CPU 매뉴얼을 공짜로 우편으로 보내줬습니다. 지금도 그 보라색 레퍼런스 카드를 갖고 있고, 자주 쓰는 오피코드는 외우고 있습니다 ( https://colorcomputerarchive.com/repo/Documents/Datasheets/MC6809-MC6809E%20Reference%20Card%20%28Motorola%29.pdf_ )
처음 돈을 번 건 18개월쯤 뒤, 꽤 쓸 만한 디스크 유틸리티 프로그램을 만들었을 때였습니다. 금요일 밤을 꼬박 새워 완성했죠. 토요일 아침 동네 사용자 모임에서 플로피 디스크에 복사해 5달러에 팔았습니다. 140달러를 벌었고 첫 고객 28명이 생겼습니다. 소프트웨어를 만들어 파는 일에 푹 빠지기에는 충분했습니다. 그 뒤로 약 40년, 스타트업 세 곳, 제품 열두 개 이상, 훌륭한 사람 수백 명의 고용, 고객 수백만 명, PC Magazine 올해의 제품상 두 번을 거쳤고, 저는 후회가 없습니다. 장난삼아 배우고 즐기려고 시작한 일이었습니다. 배운 것도 많았고 즐거움도 컸습니다. 멋진 여정이었고, 적극 추천합니다.
정말 멋진 인생 이야기네요. 저도 호기심 많은 아이로 시작한 건 비슷한데 PC Magazine 올해의 제품상은 못 받았네요! 여기에는 호기심으로 시작했고, 주변에는 관심을 가져주는 친구는커녕 컴퓨터를 본 적 있는 친구조차 없었던 분이 많이 계실 거라 생각합니다.
요즘에도 그런 것에 해당하는 게 있을까요? 멋진 기술이 나오자마자 몇 주 안에 그걸로 뭔가를 파는 스타트업이 생기잖아요. 오늘날 "괴짜" 아이는 뭘 하고 있을까요?
첫 홈런을 치기까지는 안타를 수없이 치고 삼진도 몇 번 당하면서 기술 스타트업을 제대로 하려면 무엇을 알아야 하는지 깨우치는 데 10년쯤 걸렸습니다.
지난 10년 동안 저는 점점 더 많은 시간을 무료 봉사로 들여, 수업이나 예비 창업자 모임에서 이야기하며 '받은 만큼 베푸는' 일을 해 왔습니다. 그래서 그 질문의 여러 변형을 정말 많이 들었습니다. '정답'이 없다는 걸 깨닫는 데만 몇 년이 걸렸어요. 각자에게 맞는 답은 그 사람의 고유한 성격, 기술, 관심사, 처한 환경, 살아온 여정에 따라 다르니까요.
제가 나눌 수 있는 가장 도움이 되는 건 어떤 목표를 겨냥해야 할지에 대한 추측이 아니라 여정에 어떻게 접근할지에 대한 조언입니다. 먼저, 기술 창업가가 되고 싶으시길 바랍니다. 제가 아는 건 그것뿐이거든요. 어떤 기술이 수요가 많아 연봉 높은 안정된 직장을 얻을 수 있는지, 승진은 어떻게 하는지는 전혀 모릅니다. 저는 직원으로서는 형편없어서 어쩔 수 없이 창업가가 됐습니다.
저는 다음에 뭐가 "뜰지" 짐작해서 겨냥한 적이 없고, 그 짐작이 맞을 거라고 보지도 않습니다. 성공한 때는 늘 어떤 고객이 실제로 겪고 있는 진짜 문제에서 출발했습니다. 처음에는 그 고객이 저나 제 친구였지만 그건 상관없습니다. 의욕 있는 고객들이 기존 제품보다 더 나은 해법을 적극적으로 찾을 만큼 심각한 문제이기만 하면 됩니다. 그런 다음 고객이 실제로 돈을 낼 만큼 '더 낫게' 풀 방법을 찾는 겁니다. 모든 면에서 완벽할 필요는 없습니다. 대부분의 면에서 더 낫고, 적어도 한 가지 면에서는 완벽하면 됩니다.
사실 제 최고 히트작 몇 개는 문제의 한 부분을 엄청나게 잘 풀고 그 대가로 다른 영역에서 좀 이상한 단점을 감수하는 영리한 방식으로 성공했습니다. 이 패턴이 통했던 일반적인 예를 들어 보겠습니다. 저와 친구들은 모두 지그재그 위젯(Zig-Zag Widget)을 간절히 원했는데, 좋은 제품은 터무니없이 비쌌고 우리 같은 평범한 사람이 살 수 있는 것들은 지그도 제대로 못 하고 재그도 엉망이었습니다. 그러던 어느 날 밤 피자와 맥주를 앞에 두고 이 한심한 상황에 투덜대다가, 평범한 사람들도 살 수 있는 지그 전용 위젯(Zig-Only Widget)을 만들 수 있을지 머리를 맞대고 구상해 봤습니다. 멍청해 보이는 발상은 재그를 아예 하지 않으면 지그만큼은 최고 제품보다 더 잘할 수도 있다는 것이었습니다. 우리는 지그도 재그도 없는 처지였으니 그 정도 맞교환은 충분히 받아들일 만해 보였죠. 알고 보니 다른 사람들도 그랬습니다. 특히 재그를 안 해서 생기는 최악의 문제를 우회해 주는 '유사 재그' 기능을 몇 가지 넣고 나니 더 그랬고요. 그렇게 해서 세계 최고의 지그(재그는 없음)가 나왔고, 어설픈 지그재그 제품의 4분의 1 가격에 팔았습니다. 사실 새로운 기술은 아니었습니다. 딱 맞는 옛 기술에 새로운 것을 조금 섞고, 영리한 UX 혁신과 멋진 워크플로 연동을 더한 것뿐이었죠. 쾅! 첫 번째 올해의 제품상이었습니다.
수십 가지 다른 버전의 프로토타입을 만들어 문제를 실제로 겪는 살아 있는 고객에게 하나하나 써 보게 하고, 그들의 끝없는 불평과 터무니없는 요구와 가끔 나오는 멋진 제안을 몇 시간이고 공감하며 듣는 일이 재미있게 들린다면, 천직을 찾으셨는지도 모릅니다. 그저 좋은 코드를 쓰고 괜찮은 월급을 받으며 방해받지 않고 싶다면, 친구여, 반대쪽으로 달아나세요. :-) 아이러니한 건 제가 제품을 만들기 시작한 이유가 프로그래밍을 좋아해서였다는 겁니다. 그런데 처음 몇 년이 지나자 코드를 거의 쓰지 않게 됐습니다. 독학으로 하드웨어 밑바닥까지 파고드는 어셈블리어 실시간 그래픽 프로그래머로 시작해서 이 사업을 배운 것은 값진 경험이었습니다. 덕분에 저보다 훨씬 뛰어난 프로그래머들을 알아보고 채용할 수 있었으니까요. 하지만 매출 100만 달러와 직원 20명을 넘긴 뒤로는 코드를 쓰거나 검토하는 시간보다 광고 문구와 법률 계약서를 쓰고 검토하는 시간이 더 많아졌습니다. 그것 또한 값졌습니다. 회사가 커지면서 사업의 곳곳에서 불이 났고, 그때마다 필요하면 마케팅, 영업, PR, 재무, 심지어 법무까지 직접 하다 보니 꽤 잘하게 됐거든요. 그 모든 경험이 매출 1억 달러와 직원 수백 명 규모가 됐을 때 회사를 운영하기 위한 최고의 준비였습니다.
저는 작은 스타트업 위에 늘 떠돌던 존폐의 위협이 정말 싫었습니다. 그러다 어느 날 마침내 깨달았습니다. 끊임없이 닥치는 무서운 새 도전은 제가 계속 성장하고 새로운 기술을 배우도록 떠미는 것이었고, 살아남는 데 그치지 않고 레벨업해서 점점 더 높은 봉우리에 오르는 만족을 느끼게 해 주는 것이었다는 걸요. 여러분도 여정에서 같은 것을 발견하길 바랍니다. 제일 좋은 점은 이제 은퇴한 지금 제가 다시 8비트 어셈블리어와 4K RAM으로 프로그래밍하고 있다는 겁니다. 다만 지금은 아타리, 코모도어, 싱클레어, 암스트라드에서 나온 모든 모델을 갖춘 꽤 방대한 컬렉션이 있다는 게 다르죠. :-)
저도 은퇴했는데, 정반대의 길을 걸은 성공한 직원으로서였어요. :) 좋은 통찰 감사합니다!
들어줄 분이 계신다면 이에 대한 제 생각을 덧붙이고 싶습니다. 핵심은 디자인입니다. "모양과 색깔" 같은 디자인이 아니라 "Notes on the Synthesis of the Artificial"에서 말하는 의미의 디자인입니다.
기술업계 사람들은 기술에 집착합니다. 하지만 실제로 팔리고 사업을 일으키는 것은 훌륭한 디자인입니다. 사용자 경험과 개발자 경험의 균형을 알맞게 잡고, 문제 공간에 대한 어떤 고차원적 정의에 놀랍도록 잘 들어맞는 추상적인 형태를 내놓는 일 말입니다.
중요한 건 한 번도 코드나 도구나 기술이 아니었습니다. 모든 건 사물이 서로 어떻게 맞물리느냐에 달려 있습니다. 인기 게임의 "삶의 질 개선" 모드를 떠올려 보세요. 우리 머리가 다루는 추상적인 시스템이 복잡해질수록 무언가를 디자인할 기회도 늘어납니다. 인간의 인지 공간에는 해결을 기다리는 문제가 정말, 정말 많이 있고, 지금 있는 것보다 더 잘 맞는 추상적인 형태를 어떻게 만들지 누군가 알아차리기만 하면 됩니다.
너무 좋네요! 공유해 주셔서 감사합니다!
저희 엄마와 저도 번갈아 가며 잡지에 실린 코드를 소리 내어 읽어 주고, 다른 한 명이 우리 Commodore 64에 입력하곤 했어요. 엄마는 "난 그냥 게임을 입력하고 하면서 재미있게 놀았는데, thwarted는 진짜로 뭔가를 배우고 있었네" 같은 말을 하시곤 했죠(아뇨, 우리 엄마는 저를 "thwarted"라고 부르지 않으세요).
"Ted"이길 바라요, "Wart"가 아니라.
1979년, 제가 14살일 때 아버지가 TRS-80 Model 1을 집에 가져오셨습니다. 저는 Byte 잡지에 실린 코드 목록을 입력하면서 BASIC을 배우기 시작했습니다. 그러다 제 프로젝트를 직접 구상하기 시작했죠. 너무 좋아서 평생 무슨 일을 하며 살고 싶은지, 어떤 대학 학과에 가고 싶은지 알게 됐습니다.
대학을 졸업한 지 거의 40년이 지났지만 지금도 여가 시간에 코딩과 시스템 설계를 가지고 놉니다. 솔직히 본업보다 이쪽에서 훨씬 더 큰 만족과 행복을 얻습니다.
저는 우울증과 은둔 생활에서 벗어나려고 코딩을 시작했습니다. 형이 게임을 만들고 싶어 했는데 코딩까지 할 여력은 없어서였죠. 그렇게 시작하고 여러 해가 지나서야 제가 프로그래밍에서 즐거움을 느끼는 부분은 몰입 상태(flow)와 배우고 이해하는 것이라는 걸 깨달았습니다.
그래서 "이력서를 위해 오픈소스에 기여해라. GitHub 프로필을 자랑해라"라는 대학의 금과옥조를 실천하기가 정말 어려웠습니다. 열심히 노력해 봤지만 프로젝트를 끝내기가 힘들었어요. 제가 만족할 만큼 이해하고 나면 대개 거기서 멈췄거든요. 그러니까 "좋아, 이제 이해했고, 만약 구현해야 한다면 어떻게 할지 대충 계획도 있어" 하는 단계에서요.
그래서 저에게 잘 맞는 자리는 R&D용 코딩이었습니다. 이해하는 것도 구현하는 것만큼 높게 쳐 주는 경우가 많거든요. 결과적으로 저는 디버깅하고 이해하는 데는 늘 찾는 사람이 되지만, "빨리 구현하는" 사람은 아닐 수도 있습니다.
에이전트 코딩에 대해 복잡한 심정인 것도 같은 이유입니다. 사람은 반복하고 직접 해 보지 않으면 제대로 배우지 못합니다. 남이 낸 문제 해법을 따라가 놓고 이해했다고 스스로를 속이기 쉽죠. 하지만 한편으로 저는 이해도가 높으니 에이전트가 짠 코드를 꼼꼼히 읽어낼 수 있어야 합니다(그래서 다른 사람들이 바이브 코딩한 코드의 PR 리뷰를 맡는 사람이 되는 경우가 많습니다).
취미로 해 온 작은 로봇 프로젝트에서는 균형을 잡기가 힘들었습니다. 주어진 시간이 한정돼 있어서 일을 빨리 끝내는 데는 에이전트 코딩이 훌륭합니다. 하지만 이해도는 타격을 받고, 그 때문에 의욕을 유지하기도 어렵습니다(플로팅 스크립트 같은 건 예외입니다. 더는 매번 matplotlib와 씨름하고 싶지 않거든요).
저와 성향이 똑같으시네요. 저도 연구자, 디버거, 아니면 기술 고고학자가 되면 어떨까 생각해 본 적이 있습니다.
지금은 어떤 일을 하시고, 그 자리는 어떻게 찾으셨나요? 미리 감사드립니다.
지금은 R&D 쪽에서 일하는데, 리서치 엔지니어 같은 역할이에요. 여러 역할을 조금씩 하는데, 어떤 프로젝트에서는 직접 기여하는 사람이고, 다른 프로젝트에서는 이따금 도메인 지식을 보태 주는 "전문가 자원"일 뿐이고, 사업 쪽 사람들이 기술적인 의견이 필요할 때(실사 작업 등)도 전문성 때문에 가끔 불려 가요. 제 첫 대기업 근무에서 맡은 독특한 역할이라 어떻게 찾아야 하는지는 저도 몰라요. 적절한 때에 적절한 자리에서 적절한 배경을 가지고 있었던 덕을 봤어요.
그 전에는 대부분 스타트업(로봇공학 엔지니어링)에 있었는데, 순전히 가면 증후군(과 호기심) 때문에 여가 시간을 대부분 공부(온라인 강의)하고 기술 밋업에 다니는 데 썼어요. 거기서 만난 한 연구자가 주말에 공동 연구 프로젝트를 해 보자고 제안했고, 나중에 한 스타트업에서 (연봉을 꽤 많이 깎고) 연구직을 얻었죠. 그 경험이 제게 가장 큰 도움이 됐다고 생각해요.
재미있긴 하지만, 전문성과 학습은 끝이 없는 과정이라서 지금 있는 곳 같은 데서는 여가 시간 공부만으로 따라가기가 좀 까다로워요. 또 특출난 사람(저는 아니에요)이 아니라면 증명서가 없을 때 다른 사람들에게 내 전문성을 납득시키느라 고생할 것 같아요(저는 박사 학위가 없는데 제 분야에는 박사가 많거든요).
"여러 분야가 섞인 프로젝트의 전문가"라는 점도 도움이 된다고 생각해요. 지난 직장에서는 ML + 신경과학 + 로보틱스였는데, 로보틱스 전문 지식이 있는 사람이 저뿐이라 가치가 있었고 공부할 시간도 많이 쓸 수 있었어요. 뛰어난 로보틱스 전문가들로 가득한 팀이었다면 저한테는 좀 더 어려웠을 거예요
공감합니다. 저도 같은 문제가 있거든요. 그런데 제 경험으로는 "좋아, 이해했어, 이제 흥미 없네" 하는 느낌이 막상 그걸 구현해 보면 사라지는 일이 많습니다. 직접 시험해 보지 않으면 막연한 이해가 옳다고 스스로를 설득하기가 얼마나 쉬운지 실감하게 되니까요.
맞는 말씀이에요! 덧붙이자면, 가치 있는 "경험의 신호" 중 상당수는 실제로 해 보면서 얻은 이해에서 나와요.
기술 면접에서 제가 전문성을 보여주려고 늘 썼던 최고의 이야기는 실제로 해 본 일과 그 실패담이었어요.
짬짬이 하는 프로젝트에서는 그 마지막 한 걸음을 더 내딛기가 정말 어려워요. 산만한 제 머릿속에는 배우고 싶은 게 길게 줄 서 있어서, 지금 하는 프로젝트가 그만큼 진척되기도 전에 다음 것으로 뛰어들어 버리거든요
취미로 하는 프로그래밍은 예전에는 소프트웨어 개발자를 채용할 때 보는 기준 중 하나였습니다. 코딩에 대한 내재적 동기가 있다면 학력이나 경력보다 더 가치 있게 여겨지는 경우도 많았죠. 그래서 주니어 개발자들은 교육과정 밖에서 해 본 이런저런 프로젝트를 이력서처럼 보여주는 사이트를 올려서 경쟁자보다 유리한 고지를 차지하려 했습니다. 일부 회사는 번아웃을 막으려고 근무 시간 중에 사이드 프로젝트를 할 시간을 주기도 했고요.
동시에 업계의 일부 사람들은 뒤처지지 않으려면 여가 시간에도 코딩을 즐겨야 한다는 기대에 불만을 품었습니다. 어떤 사람들은 정말 잘하니까 순수하게 좋아서 했지만, 퇴근 뒤에는 개발자 뇌를 끄고 삶에서 즐기는 다른 일을 하고 싶어 하는 사람들도 있었으니까요.
하지만 코딩용으로 성능이 뛰어난 LLM이 등장하면서, 취미 프로젝트 자체보다 그 프로젝트에 AI를 어떻게 활용하는지를 보여주는 게 더 중요해진 것 같습니다. 주니어 개발자 입장에서는 딜레마입니다.
저는 여전히 취미로 프로그래밍하는 것을 좋아한다면 프로그래밍에 입문하기에 좋은 기준이라고 생각하지만, 이런 점들이 문제가 될 수 있다는 생각을 몇 가지 적어 봤습니다.
취미로 말을 타는 사람들은 자동차가 있다고 해서 신경 쓰지 않아요.
그중 누군가가 해야 한다고 느껴서 하는 거라면 그건 취미 프로그래밍이 아니에요. 이력서 채우기죠.
지표와 목표에 관한 얘기죠. 제가 첫 프로그래밍 일자리를 얻었을 때, 저를 뽑은 이유 중 하나가 집 PC에 어떤 부품을 쓰는지 알고 있었기 때문이라고 하더군요. 그 질문을 미리 공개해서 모두가 공부해 오게 했다면 그 질문을 선별 기준으로 쓰는 건 더는 의미가 없었겠죠. 보상을 기대하지 않고도 어차피 그런 걸 알고 있던 사람을 원하는 거니까요.
그건 취미 프로그래밍의 목적이 아니잖아요. 투자 대비 수익(ROI) 때문에 하는 게 아니에요. ROI가 생길 수는 있겠지만, 저는 그걸 위해서 하는 게 아니라 진짜 호기심 때문에 하거든요.
어릴 때 재미로 하는 프로그래밍은 배우기에 좋은 방법이었지만, 어른이 되면 번아웃이 사람을 잡습니다. 일을 회사에 두고 오지 않으면 금방 엉망이 돼요. 그런데 "취미 프로그래밍"이 번아웃을 막는다고 생각하는 건 대체 무슨 소리인지 모르겠어요. 제 경험으로는 전혀 아니거든요.
사람마다 다른 게 분명해 보입니다.
저한테는 어느 정도 효과가 있는데, "지금 회사에서 내가 뭘 하고 있나", "이 개인 작업이 정말 재미로 하는 건가, 아니면 스스로 강요하고 있나"에 크게 달려 있어요.
간단한 테스트가 하나 있는데(이것도 어디까지나 저한테만 해당하는 거예요), "이걸 남에게 공유할 생각인가, 아니면 오직 나만을 위한 것인가?"입니다.
어떤 의미로든 일이나 압박이 되는 구석이 전혀 없다면, 정말로 탐구하는 즐거움이 있는 일이에요. 그렇다면 그냥 바쁘다는 느낌보다는 오히려 머리를 식히는 효과가 더 클 수도 있고요.
사람마다 분명히 다르겠지만, 제 경험으로는 직장에서 하는 프로그래밍과 퇴근 후 몰래 하는 코딩은 완전히 다른 종류의 일입니다. 개인 프로젝트에는 프로덕트 매니저도, 스프린트도, 회의도, Jira도 없습니다.
본업이 주로 고개 숙이고 코딩만 하는 일이라면 공감이 안 될 수도 있지만, 저는 제가 원하는 걸 제 방식대로 개발하는 것이 회사 환경에서 협업하며 받는 스트레스로부터의 휴식이 됩니다.
인생의 교훈 하나. 좋아하는 일은 직업으로 삼지 마세요. 결국 그 일이 싫어지게 만들 테니까요.
그것도 잘 이해가 안 가요. 저는 제 일과 하는 업무가 좋거든요. 다만 뭐든 너무 많이 할 수는 없죠. 좋아하는 일을 하며 생활비를 벌 수 있지만, 5시가 되면 생각하는 머리를 끄고 다른 걸 하러 가야 해요.
Tsoding [1]을 응원합니다. 제가 가장 좋아하는 취미 프로그래머예요.
[1] - https://www.youtube.com/@TsodingDaily
스폰서를 받으며 (유료로) 성공적인 유튜브 채널을 운영하는 단계가 되면, 그게 아직 취미라고 할 수 있을까요?