구름은 한 달에 한 번 수요일에 기술, 개발, 성장, 조직 문화 등에 관한 이야기를 나누는 COMMIT 세미나를 진행하고 있습니다. COMMIT은 COMMUNICATION과 IT의 합성어로 개발자가 소스 코드를 커밋하듯 IT 업계를 이루는 분들의 역량을 COMMIT 하고 있어요.
2023년 12월 주제는 ‘소프트웨어 장인 정신’입니다. 개발자가 추구해야 할 가치와 태도가 꾸준히 기술을 갈고 닦는 장인과 다르지 않다는 이야기인데요. 소프트웨어 장인 정신은 무엇이고, 왜 필요한 걸까요? 쏘카 CTO 류석문 님을 미리 만나 이야기를 나눠봤습니다.
🎤 류석문 Seokmoon Ryoo
쏘카 CTO
소프트웨어 개발자 류석문입니다. 20년 넘게 개발자로 일하고 있고, 지금은 쏘카 CTO로 개발자가 성장하는 조직을 만들어 가고 있어요. 공유의 가치를 실천하기 위해 《소프트웨어 품질관리》, 《프로그래머로 산다는 것》, 《프로그래머 철학을 만나다》, 《리더의 생각》, 《리더의 세상 읽기》를 집필했습니다.
20년 넘게 개발자로 일하면서 석문 님도 성장의 벽을 느꼈던 때가 있었을 것 같아요. 석문 님은 어떻게 극복하셨나요?
먼저 말씀드리고 싶은 건 저는 소프트웨어 분야 전공자가 아니에요. 대학에서는 물리학을 전공했고, 대학원도 소프트웨어 계열은 아니었습니다. 따로 소프트웨어 교육을 받아본 적이 없다 보니 매 순간이 도전이었어요. 모르는 게 너무 많았고, 늘 한계에 부딪혔습니다.
경력이 1~2년 정도 쌓이면 제법 잘한다고, 다 안다고 착각하기 쉬워요. 저도 그랬습니다. 자만심에 사로잡혔죠.
그 무렵이었습니다. 열심히 하면 금방 좋은 소프트웨어를 만들 수 있다는 생각에 벤처기업으로 이직했죠. 아시다시피 벤처기업은 조직은 작지만, 할 일이 많아 일당백으로 일해야 했습니다. 그때 좀 꽉 막혀 있다고 느꼈어요. 사수가 없으니 물어볼 사람 하나 없었습니다. 그럼에도 기술 조직을 책임지며 구성원을 기술 측면에서도, 협업 측면에서도 성장 시키고 좋은 결과물도 내야 했죠. 어렵고 힘들고 답답했습니다.
소프트웨어 개발은 특정 기술을 평생 써먹는 게 아니다 보니 바뀌는 트렌드도 따라야 하고 그에 따라 푸는 방식도 달라져야 하거든요. 조직 상황도 천차만별이라 조직마다 해야 하는 일도 다르죠. 지금도 이러한 일종의 ‘벽’을 넘기 위해 계속 시도하고 있습니다.
포기하지 않고 끊임없이 시도할 수 있었던 이유는 두 가지입니다. 첫 번째는 제가 모든 걸 다 할 수 없다는 걸 인정했기 때문이에요. 인정한 다음에는 그걸 더 잘할 수 있는 사람을 찾아 그분과 협업하는 방법을 고민하게 됐죠. 혼자서 모든 문제를 해결하는 게 아니라 협업해야 한다는 걸 알게 된 것. 그게 첫 번째 분기점이었습니다.
두 번째는 금방 끝날 일이 아니라는 걸 인지하는 것이었어요. 저도 젊었을 때는 호기롭게 40살 전에 은퇴해 편안하게 살겠다는 목표를 세웠었습니다. 이 목표가 가능하지 않다는 걸 깨닫고 난 뒤에야 조급함을 버릴 수 있었어요. 오늘 노력하면 내일은 조금 더 나아질 거고, 반복하면 나아진다는 믿음이 생겼죠. 문제를 빠르게 해결하는 데 집중하는 것도 좋지만, 느리더라도 방법을 찾아 계속 시도하는 것도 하나의 길이 될 수 있습니다.
석문 님과 일하는 주니어 개발자 중 성장을 고민하는 분도 있을 거예요. 그분들에게는 주로 어떤 이야기를 해주시나요?
실제로 정체된 건지, 아니면 피드백을 제대로 받지 못해 본인의 상태를 모르는 건지를 아는 게 중요해요.
우리는 계단식 성장이라는 표현을 많이 사용하지만, 사람은 계단식으로 성장하지 않습니다. 꾸준히 성장해요. 기울기는 좀 다를 수 있지만요. 우리가 성장을 인지하는 순간이 성장폭이 배수로 증가하는 때인 것뿐이에요. 형광등 1개보다 주위를 밝히려면 2개, 그다음에는 4개를 켜야 하죠. 성장도 비슷합니다. 2배, 4배의 성장을 만들어 내야 성장을 인지할 수 있어요.
2년차까지는 모든 게 새로워 얻는 게 많습니다. 성장이 빠르다고 느끼죠. 어느 정도 성장하고 나면 더 성장하기 위해 배워야 하는 양이 기하급수적으로 늘어납니다. 이때부터는 하는 일이 루틴하게 느껴지고, 나아지는 게 없다고 생각해요. 성장이 멈췄다고 오해하는 거죠.
성장은 대체로 피드백으로 체감하게 됩니다. 누가 살 빠진 것 같다고 이야기하면 살이 빠졌다는 걸 알게 되는 것처럼요. 안타깝지만 조직 내에서 ‘구성원의 성장’에 대해 피드백을 주는 경우는 거의 없습니다. 대부분은 업무가 끝났는지, 안 끝났는지 정도만 이야기하죠. 본인의 성장 정도를 모를 수밖에 없습니다. 개인이 풀 수 있는 문제는 아니에요. 조직 내 시스템으로 풀어야 하죠.
어느 정도 개인의 노력도 필요합니다. 지금 루틴하다고 느끼는 업무도 처음 맡았을 때는 새로 배우는 게 많기 때문에 성장한다고 느꼈을 거예요. 따라서 계속 성장하기 위해서는 루틴한 업무는 효율을 고민하며 일해야 합니다. 예를 들어 배포에 1~2시간이 걸리고 사람이 일일이 각 단계를 확인해야 한다면 자동화 방안을 찾아봐야 해요. 이런 고민을 해야 루틴한 업무에서도 성장할 수 있습니다.
코드를 작성할 때도 단순히 ‘동작하는 코드’를 작성하려 해서는 안 됩니다. 코드가 얼마나 유지보수하기 편한지, 비즈니스 목적뿐 아니라 차후 서비스 확장에 유연하게 대응 가능한지까지 고민하며 코딩해야 성장할 수 있습니다. 고민 없이 주어진 일만 끝내는 식의 태도에서는 성장이 정체될 수밖에 없어요.
지속적으로 성장하는, 소프트웨어 장인이 되기 위해서는 어떻게 해야 할까요?
사실 장인이 하는 일도 루틴합니다. 하지만, 장인은 실력을 극한까지 끌어올리기 위해 엄청난 시간을 투자하죠. 어떤 것도 대충하지 않고요. 소프트웨어 개발도 그냥 동작하게 만드는 게 중요한 게 아닙니다. 어떻게 더 잘 만들 수 있을지 고민하는 게 중요해요. 그게 소프트웨어 장인 정신이고요.
장인이 되려면 어떻게 해야 할까요? 매일 연습하는 방법밖에 없죠. 장인이 되었다고 아무것도 안 해도 되는 게 아니니까요. 언제까지 배우고 포기하는 게 아니라 그 일을 하는 매 순간 최선을 다해야 합니다. ‘노력의 반복’이 핵심이에요.
특정 기술을 적당히 쓸 수 있는 수준으로 배우는 게 아니라 극한까지 노력하며 성장해야 방향을 잃지 않습니다. 노력하지 않으면서 성장이 정체됐다고 생각한다면 마음가짐을 바꿔보세요.
무엇보다 시간이 급하다고 품질을 희생해서는 안 됩니다. 예를 들어 팝콘을 먹고 있는데, 그 위에 바퀴벌레 한 마리가 떨어졌다고 생각해봅시다. 통째로 버려야겠죠? 아무리 좋은 코드를 유지해 왔더라도 한순간, 급해서 이상한 코드를 넣는 순간, 버려야 하는 코드가 됩니다. 바퀴벌레가 득실거리는 곳에 팝콘을 하나 떨어뜨리고, 먹으라고 한다면 먹을 수 있을까요? 아무리 많은 팝콘을 얹어도 못 먹을 거예요. 지저분해진 다음에 뭔가를 하겠다는 생각은 버려야 합니다. 품질은 희생해도 되는 게 아니에요. 소프트웨어 장인 정신이 필요한 이유죠.
소프트웨어 장인 정신과 애자일은 어떤 관계인가요? 왜 소프트웨어 장인 정신에 주목해야 할까요?
애자일 개발 방법론 중 ‘익스트림 프로그래밍(eXtreme Programming, XP)’이 있습니다. 여기에 소프트웨어 장인 정신에 필요한 게 담겨있어요.
익스트림 프로그래밍은 크게 3개 레이어로 나뉘는데요. 가장 중심에 있는 코어 레이어에서는 개발자가 코드를 잘 쓰기 위한 방법을 이야기합니다. 테스트 주도 개발, 페어 프로그래밍, 리팩터링, 코드 리뷰 등이죠. 코어 레이어를 둘러싼 외곽 레이어는 협업에 관한 내용입니다. 코딩 스탠더드를 만들고, 지속적 통합을 하고, 메타포를 만들어 커뮤니케이션 오류를 줄이는 내용이죠. 가장 바깥 레이어는 개발 외적으로 협업해야 하는 비즈니스 담당자와의 협업에 대해 고민합니다. 애자일의 기저에는 소프트웨어 장인 정신이 기본적으로 깔려 있어요.
과거 소프트웨어 개발 자체는 기술을 잘 만드는 데 초점을 둔 게 아니라 기술을 만들기 위한 프로세스에 방점이 찍혀 있어요. 1960년대부터 90년대까지 그랬죠. 그러다 보니 개발을 잘하는 사람을 제대로 키우기보다는 일정을 맞추는 데 집중했습니다. 이에 대한 반성으로 나온 게 애자일이에요. 그런데, 프로젝트 매니저는 애자일이 떠오르니 애자일에 올라타서는 레이어 가장 외곽에 있는 프로세스만 강조하기 시작했습니다. 결국, 애자일 실천에 실패하게 되죠.
프로세스만 강조하다가 실패하고는, 애자일로 넘어와서도 다시 프로세스로만 풀려고 한 거예요. 이러한 문제 의식에서 소프트웨어 개발자들이 좋은 소프트웨어를 만들 수 있도록, 기저에 깔린 소프트웨어 장인 정신에 다시 주목하게 된 겁니다.
소프트웨어 장인 정신과 애자일은 같아요. 전문가들이 모여 효율적으로 협업하면 좋은 소프트웨어를 만들 수 있고 기획자, 비즈니스 담당자와도 생산적인 관계를 맺어야 한다는 건 당연한 이야기잖아요. 코어 레이어가 아니라 프로세스만 강조하는 게 문제인 거죠.
소프트웨어 장인 정신에서 강조하는 마인드 셋을 갖추려면 개인의 노력도 필요하지만, 먼저 조직부터 변화가 필요해 보여요. 조직을 변화시키려면 어떻게 접근해야 하는지 궁금합니다.
가장 좋은 건 탑다운(Top-Down)과 바텀업(Bottom-Up)이 동시에 이루어지는 거죠. 소프트웨어 장인 정신의 필요성을 아는 리더가 좋은 환경을 만들어 주고, 리더를 믿는 구성원이 열심히 실천하는 게 가장 좋습니다.
리더가 소프트웨어 장인 정신을 전혀 실천하지 않는다면 주니어 개발자는 리더를 설득하려 할텐데요. 안 될 확률이 높습니다.
한 가지 말씀드리고 싶은 건 다른 사람은 안 해도 나는 실천할 수 있다는 점이에요. 내 주변 사람들이 모두 글을 엉망으로 써도 나는 제대로 쓰면 되잖아요. 내가 연습하고, 내 실력이 느는 거니 안 할 이유가 전혀 없죠. 대부분 혼자서도 실천할 수 있는 것들이거든요.
협업 레이어는 좀 다릅니다. 이건 어느 정도 본인의 역량과 영향력이 커져야 조직을 바꿀 수 있는 부분이거든요. 어쩔 수 없는 외부 요인이라 여기고 신경 쓰지 마세요. 지금은 본인이 제대로 할 수 있는 것에 에너지와 시간을 쏟으세요. 환경이 녹록지 않으면 본인이 할 수 있는 일에 집중하는 게 언제나 정답입니다. 그렇게 역량이 늘어 주변을 바꿀 수 있으면 좋은 거고, 안 되면 더 나은 조직으로 가면 되니까요.
석문 님의 이야기를 들으니 소프트웨어 장인 정신이 개발자에게만 필요한 건 아닌 것 같아요. 모든 직군에게 필요한 이야기인 것 같습니다. 주니어 개발자는 가장 먼저 어떤 것부터 실천해보면 좋을까요?
가장 중요한 건 본인의 욕망을 이해하는 거예요. 예를 들어 축구 선수가 되고 싶은 사람이 있다고 가정해볼게요. 근데 제가 야구 선수가 되는 방법을 계속 알려주면 그건 잘못된 거잖아요.
본인이 무엇을 하고 싶고, 어떤 방향으로 성장하고 싶은지에 따라 주변에서 줄 수 있는 게 다르거든요. 물론 기본적인 것은 같죠. 축구 선수든 야구 선수든 기초 체력 훈련을 열심히 해야 하잖아요. 그래서 제가 소프트웨어 장인 정신을 이야기할 때도 기초 체력 훈련 같은 항목은 기본적으로 말씀드립니다.
본인이 원하는 걸 이해했다면 그것을 이룰 방법에 대한 피드백을 받는 게 중요해요. 가까이 있는 동료, 선배, 아니면 본인의 직속 리더에게 받을 수 있겠죠. 여기서 중요한 건 피드백을 곧이곧대로 받아들이면 안 된다는 거예요. 피드백은 본인의 가치관에 맞춰 취사선택해야 합니다. 무조건 실천한다고 성공하지 않아요.
12월 COMMIT에서는 어떤 이야기를 들려주실 예정인가요?
많은 분이 ‘좋은 개발자’라는 표현을 쓰죠. 좋은 개발자가 되고 싶다든지, 좋은 개발자를 채용해야 한다는 식으로요. 하지만, 우리 사회가 공통으로 내린 좋은 개발자에 대한 정의는 없습니다. 이번 COMMIT에서는 소프트웨어 장인 정신을 바탕으로 제가 생각하는 좋은 개발자에 대해 소개하려고 해요. 물론 이 또한 정답은 아닙니다. 성장을 고민하는 분들에게 조금이나마 도움이 되었으면 하는 바람이에요.
더 자세한 이야기는 12월 20일 수요일 오후 7시에 열리는 COMMIT에서 들을 수 있습니다.
Edit Sunny Design Lil