[밋업 후기] 소프트웨어 장인 정신, 우리가 함께 성장하는 방법 - Goorm Commit

JOY·2024년 1월 3일

지금까지 6번의 오프라인 참석을 했을 정도로 구름 커밋을 즐겨 들었지만, 12월 구름 커밋은 내게 유난히 특별했다. 링크드인으로 팔로우하고 있던 류석문님께서 발표자였기 때문이다.

쏘카 CTO 이신 류석문 님께서 링크드인에 자주 글을 올리시는데, 대부분 개발자로서 고민해 보면 좋을 주제들이나 현업에서 겪은 일화들이라 재미있게 읽고 있었던 터였다. 그런데 마침 12월 구름 커밋에서 발표를 하신다고 인터뷰 내용을 공유해 주셔서 덥석 신청했다. ('회사가 망하길 바라는 개발자를 위한 팁' 시리즈도 재미있다 😝 궁금하신 분들을 위한 링크드인)

류석문님께서 발표하신 내용에 내 생각과 이해를 돕는 정보들을 더해 각색하여 정리해 보았다. 시니어의 시선에서 말씀해 주시는 소프트웨어 장인 정신을 가진 좋은 개발자란 무엇인지 궁금한 주니어분들에게 좋은 내용이라고 생각한다. 더욱이 쏘카에 관심이 있는 개발자라면, 쏘카 CTO의 개발 철학을 엿보는 좋은 기회가 될 것이라 생각한다.

01. 소프트웨어 개발

기존 제조업에서 쓰던 방식은 동일한 입력(비슷하게 숙련된 사람 or 같은 리소스)에 대해 동일한 결과가 출력된다.

우리가 흔히 아는 폭포수 모델 역시 논리적으로는 완벽해 보이지만, ‘변동성’ 높은 인간을 고려하지 못한 모델이다. 초기 모습 그대로 계속 유지되어야만 가능한 이론인데, 현실 세계에서는 예상치 못한 변수가 너무 많다.

따라서, 변동성을 고려하여 이를 개선해야 한다. 마치 김치찌개를 끓이듯 해야 한다고 말씀하셨다. 냉장고에 있는 적절한 재료들을 고른 후, 맛을 봐가면서 상황에 따라 적절한 조리를 해야 한다. 때에 따라서는 이전에 실패한 김치찌개를 만들었을 때를 곱씹어 보면서 레시피를 바꿔본다. 그러다 보면 매번 다르지만 더 나은 결과가 만들어진다.

02. 애자일의 정의와 한계

애자일 개발 방법이란 단기간(통상 2주) 주기로 개발하는 방법이다. 도구보다는 개인과의 상호작용을, 문서보다는 작동하는 소프트웨어에 더 가치를 둔다는 점이 인상 깊었다. 이는 애자일 소프트웨어 개발 선언에서 확인할 수 있다.

그렇다면 애자일을 도입하는 것이 무조건 좋은가?

Not bad, but not good

애자일 소프트웨어 개발 방법론 중 하나인 XP에는 3가지 레이어(layer)가 있다.

layer 1 = TDD + 페어 프로그래밍 + 리팩토링 + 간단한 설계
우선, 어느 정도의 코드 커버리지를 갖춰야 하며 리팩토링을 지속적으로 해야 한다는것이 전제로 깔려있다. 즉, 커버리지가 없으면 지속적 리팩토링 또한 어렵고, 결론적으로 애자일이 어려워진다. 또한, 이 단계를 수행하기 위해서는 앞서 말한 것들을 해낼 수 있는 역량을 가진 개발자들이 있어야 가능하다.
layer 2 = 집단 오너십 + 표준 코딩 + CI + 지속 가능한 속도 + 비유를 통한 전달
앞서 말한 유능한 개발자들이 모여서 스탠더드 한 코딩을 해야 한다. 지속적으로 작업물을 통합하고 코드 리뷰를 진행하여, 모두가 모두의 코드를 다 알고 있어 누구든 즉각 대응이 가능해야 한다.
layer 3 = 협동적 조직 + 신속한 플래닝 + 작은 릴리스 + 고객 테스트
각각의 팀이 하나로 뭉쳐서 협동적으로 일해야 한다. 일을 명확하게 추정하는 방안을 마련해야 하고, 작은 단위로 자주 출시한다. 필요에 따라 풀타임으로 질문에 답변할 실제 기능 사용자를 팀에 추가하기도 한다.

레이어 1부터 3까지 차곡차곡 잘 실행해야 하는데, 그러지 못해서 애자일에 실패하는 경우가 많다. 좋은 도구를 쓰는 것과 목적을 달성하는 것은 매우 다른데, 좋은 도구를 잘 사용하는 데에만 집중한다면 주객전도가 될 우려가 있다.

따라서, 더욱 개선이 필요하다

작동하는 소프트웨어보다는 잘 만들어진 소프트웨어,
변화 대응보다는 꾸준히 가치를 더하는 것,
개인과의 상호작용보다는 전문가 커뮤니티

왼쪽 보다 오른쪽에 가치를 두는 방향으로 개선이 필요하다.

03. 소프트웨어 장인 정신

개발자가 전문가인지 묻는다면, 아직은 그런 취급을 받지 못하고 있다. 개발자가 비로소 전문가가 되기 위해서는 '실용주의' 정신이 중요하다.

예를 들어, '개발자 혼자서도 가능한 TDD' vs '팀 전원이 함께해야 하는 ATDD' 중에서 도입을 고민하고 있다고 가정하자. 이때, 무조건 ATDD를 고집하는 것이 아니라, 우리 팀의 역량을 고려해서 필요한 것을 잘 선택해야 한다.

또한 개발자는 코드 품질을 신경 써야 한다. 코드 품질이 낮을수록, 기능당 개발 시간이 길어진다. 따라서 코드를 작성하는 매 순간마다 코드 품질을 신경 써서, 짧은 주기의 개발 시간을 유지하는 것이 중요하다.

정리하면, 실용주의적인 소프트웨어 장인 정신을 갖추기 위해서는 2가지가 중요하다.

적절한 논리력을 갖춰야 한다.
원리 탐색 능력, 제약조건을 고려한 적절한 해법 찾을 수 있어야 하며, 오버 엔지니어링을 지양한다.
깔끔한 코드를 짜야 한다.
가독성 좋은, 변경이 용이하고, 유지 보수 비용이 낮은 코드여야 하며, 시간이 부족한 탓으로 이를 미루면 안된다.

위 2가지 모두 엄청난 훈련이 필요하다.

꾸준한 연습이 필요하다. 매일 자신의 "몸값을 올리는 시간”을 가져보자.
멀리 가고 싶다면 함께 가라. 가치를 공감하는 파트너를 찾아서 함께 연습해라.

좋은 00 개발자

00 자리에 적합한 단어는 무엇일까? AI, 웹과 같은 '개발 분야' 중 하나가 들어가야 한다고 생각했다면, 이는 위험한 생각일 수 있다. 개발 분야는 매우 다양하며 시간 변동성을 가지기 때문에, 특정 분야 또는 기술을 자신의 정체성으로 삼는 것은 위험하다. 좋은 개발자는 시간 변동성과 무관하게 정의될 수 있어야 한다.

그렇다면, '좋은'은 어떤 의미일까? 이는 공유 능력 + 협업 능력 이라고 말할 수 있다.

개발자가 공유 능력을 갖추어야 하는 이유는 크게 2가지이다.

주변이 똑똑해져야 내가 편하다.
계속해서 공유하면서 같이 일하는 팀원들이 똑똑해지도록 만들자. 나만 일잘러이고 나머지 팀원들은 맨날 사고만 치는 호모 심슨이라면? 이직을 결심해야 할지도 모른다.
좋은 평판을 얻을 수 있다.
개발자 이직에는 인맥이 꽤 큰 작용을 한다. 공유하는 습관을 가진 개발자라면 주변에서 좋은 자리가 났을 때 덕을 볼 확률이 올라간다. 이직 시 레퍼런스 체크하는 경우에도 긍정적으로 작용할 수 있다.

그렇다면 개발자가 협업 능력을 갖추어야 하는 이유는 무엇일까?

개발자에게 짧은 주기의 개발이 요구되기 때문이다.

하지만 협업은 어렵다. 고슴도치도 제 새끼는 함함하다는 말이 있듯이, 기획자와 개발자, QA 모두가 각자 자신의 산출물을 가장 소중히 생각하는 경향이 있기 때문이다. 협업 과정에서 각자 자신의 산출물을 중요하게 여기는 경향이 있어도, 좋은 개발자는 이러한 다양한 관점을 존중하고 조화롭게 조율할 수 있는 능력이 필요하다.

결국, 좋은 개발자는 하드 스킬과 소프트 스킬을 겸비해야 한다. 좋은 코드 작성 능력과 적절한 논리력뿐만 아니라, 공유 능력과 협업 능력 등을 함께 갖추는 것이 중요하다.