올해 2월과 3월에 썼던 두 편의 설계 관련 글이 계기가 되어서 개인 브런치에 틈이 날 때마다 생각을 기록하기 시작했습니다. 19편의 기록을 남기면서 설계에 대한 생각을 꾸준히 하는 중에 마침 동료의 모델링 과정을 도우면서 새롭게 느끼는 점을 공유합니다.

비즈니스를 코드로 구현하기 위해 분투하고 있는 다양한 프로그래머의 고민, 문제 해결, 성장 이야기를 들어보고자 합니다. 앞으로 인터뷰나 에세이 등 다양한 형식을 통해 코딩과 비즈니스의 관계를 톺아보려 합니다. 시리즈 세 번째로, 박성철 컬리 풀필먼트&딜리버리 본부장을 만났습니다.

코드는 현실 세계를 반영해야 합니다. 비즈니스의 요구 사항과 사람은 컴퓨터의 작동 방식대로 움직이지 않습니다. 비즈니스를 코드로 구현하기 위해 분투하고 있는 다양한 프로그래머의 고민, 문제 해결, 성장 이야기를 들어보고자 합니다. 앞으로 인터뷰나 에세이 등 다양한 형식을 통해 코딩과 비즈니스의 관계를 톺아보려 합니다. 시리즈 두 번째로, 백명석 케이타운포유(이하 케타포) CTO를 만났습니다.

개발자가 작성하는 자동화된 테스트는 오랫동안 갑론을박이 있던 화제입니다. 그러나 현실적인 타협점을 찾는다면 그 효용성은 분명합니다. 평소에 테스트를 바라보는 몇 가지 관점이 부딪힌다는 생각을 갖고 있었지만 아직 글로 쓴 일은 없었는데, 지난 글 <코드 리뷰에 ‘켄트 벡’의 아이디어 접목하기>와 비슷하게, 켄트 벡(Kent Beck)이 쓴 ‘Abstract vs. Concrete Parameters’란 제목의 글이 고맙게도 또다시 영감을 주어 쓰는 글입니다.

비즈니스를 코드로 구현하기 위해 분투하고 있는 다양한 프로그래머의 고민, 문제 해결, 성장 이야기를 들어보고자 합니다. 시리즈 첫 번째로, 소고기 시장을 코드에 담고 있는 조환 설로인 개발 리드를 만나 인터뷰했습니다. 새로운 도메인에서 문제를 풀어가는 프로그래머들, 성장하고 싶으나 무엇을 더 잘해야 할지 고민이었던 프로그래머들, 비즈니스를 진지하게 고민하는 프로그래머들에게 도움이 되길 바랍니다.

<코드 리뷰가 개발 문화에 미치는 영향>이 발행된 바로 그날, 존경하는 프로그래머인 켄트 벡Kent Beck도 코드 리뷰에 대해 쓴 글 <Thinking About Code Review>을 발행했습니다. 우연이긴 했지만, 마침 코드 리뷰에 대한 글을 막 쓰고 난 참이라 제 글에 다루지 않았던 측면을 살펴 글로 추가하면 좋겠다는 생각이 들었습니다.

요즘 매일 보는 앱 중에 깃허브(github)가 있습니다. 개발에서 손을 뗀 지 벌써 13년이 지났지만, SaaS 기업으로 회사를 키우는 입장에서 코드를 제품(product)을 구성하는 중요한 요소로 보고 있기 때문에 깃허브의 알람을 빠짐 없이 읽습니다. 코드를 중심으로 한 개발자들의 대화를 읽다 보면 코드를 짜지 않더라도 동료들이들이 무슨 생각을 하고, 어떤 논의들이 일의 중심에 놓이는지 큰 노력 없이 알 수 있어 무척 편리합니다. 이 글에서는 조직의 리더 입장에서 바라 본 코드 리뷰에 관한 경험을 토대로, 코드 리뷰가 인간적인 개발 문화를 만드는 데 얼마나 큰 기여를 하는지 말하고자 합니다.

지난 글 <소프트웨어 설계 20년 해보고 깨달은 ‘좋은 설계’의 조건>의 독자 중 한 분이 저에게 기술적인 노하우를 더 공유할 수 있는지 물었습니다. 조금 주저되었습니다. 개발자 입장에서 설계를 다룰 때, 당연히 프로그램을 잘 만드는 것에 집중하기 마련입니다. 이는 당연한 요구입니다. 그러나 ‘모든 상황에서 통하는 기술적인 노하우가 과연 있을까’ 하는 생각을 지울 수 없었습니다. 이러한 가치관을 갖고 있는 제 입장에서 선뜻 자신있게 기술적인 노하우를 꺼내는 일은 어색한 일이 아닐 수 없었습니다. 그래서 스스로에게 질문을 던져 보았습니다. ‘그럼에도 불구하고 하나만 언급해야 한다면 어떤 게 있을까?’라고요.

이 글은 제가 20여년 동안 소프트웨어 설계를 공부하고, 적용해보면서 갖게 된 믿음에 관한 글입니다. 한때 설계에 빠져 공부했고, 잘못된 믿음도 가져봤습니다. 하지만 언어와 실력이 다른 분들과 일하며 설계를 했던 경험을 비롯해 다양한 학습이 저를 설계에 관한 다른 관점으로 이끌었습니다. 이 글을 읽고 최소한 여러분은 설계에 대해 기대하지 말아야 할 것들에 대한 제 견해를 알 수 있을 것입니다. 조금 욕심을 부리자면, 적어도 한 사람 정도는 제 글을 읽고 행동에 변화가 생기는 분이 나타날 수도 있다는 기대를 갖고 글을 씁니다.