복잡하면 어렵잖아요? 그래서 생긴 Crown Team Leader 감동욱의 현실적 개발 철학

여러 가지가 있습니다만, 설계 측면에서는 의존성을 최대한 줄이는 방향을 선호합니다. 중요한 데이터에 대한 직접적인 변경이 여러 곳에서 이뤄지는 코드는 지양하고 싶어요.

복잡한 요구사항들을 클린한 솔루션으로 풀어내기 위해선 구조 자체가 단순하게 읽혀야 한다고 생각합니다. 데이터, 클래스, 모듈의 관계 역시 입력과 출력이 명확해야 하고 전체 흐름이 가능한 한 단순하게 유지돼야 해요.

반대로 누가 봐도 여기저기 흩어진 데이터들이 아무 데서나 조작되는 구조라면 기능 코드 자체보다 그 데이터를 누가, 언제, 왜 건드렸는지 파악하는 데 더 많은 시간을 쓰게 되거든요. 그래서 가능하면 순수 함수를 지향하려고 합니다. 이런 얘기들이 사실 제가 새롭게 만든 개념은 아니고, 클린 코드나 여러 좋은 자료들을 보면 다 나와 있는 이야기예요.

그런데도 실제로 실무를 하다보면 이런 기본을 제대로 신경 쓰기가 힘들어지곤 하죠. 그럼에도 복잡도가 높아질수록 처음에 지향했던 간결함을 끝까지 유지하는 게 중요하다고 생각합니다.

또 한 가지, 저는 지금 하는 작업을 왜 하고 있는지 말로 설명할 수 있어야 한다고 생각해요.

결국 저는 누군가가 사용할 무언가를 만드는 일을 하고 있고 그 ‘첫 번째 사용자’는 저와 함께 일하는 동료들이니까요. 이유와 맥락을 설명하다 보면 같은 내용을 여러 번 반복해서 말하게 되는 경우도 생기는데 그럴 바엔 애초에 전체 그림을 공유하는 쪽이 훨씬 낫다고 봅니다. 무언가를 물어볼 때마다 답변해주는 건 결국 양쪽 모두의 시간을 쓰는 일이니까요. 그림을 공유하면 보는 사람의 시간만 쓰면 되잖아요. 전체적으로 봤을 때 그 편이 훨씬 효율적이라고 생각합니다.

게다가 대부분의 경우 사람들이 아주 세세한 내부 구현보다는 ‘어떻게 쓰면 되는지’에 관심을 가지는 경우가 더 많더라고요. (혹은 그냥 “이거 좀 해줘”라든가.)

그래서 저는 최대한 단순하고 명확한 인터페이스를 제공하는 것도 중요하게 봐요. 우리가 복잡한 버튼이 잔뜩 달린 키오스크를 꺼리는 이유랑 비슷하다고 생각합니다.

실제로 Dentbird 개발 과정에서도 이런 생각을 적용한 적이 있어요. 3D Mesh Import 과정에 꽤 신경을 썼던 기억이 납니다. 

AI, CAD, FE 등 각 파트에서 사용하는 Mesh Import 방식이 다 다르고 확장자마다 데이터 포맷이나 사용 방식이 전부 달라서 로직이 굉장히 복잡하게 얽혀 있었어요. 중간중간엔 데이터 업로드 코드도 섞여 있었고요.

또 Graphics 쪽을 조금이라도 경험해보지 않으면 Vertex Color와 Texture의 차이조차 구분하기 어려운 상황이 많은데, 실제로 그걸 얘기하는 구성원들끼리도 용어 사용이 뒤섞이는 경우가 많았습니다. 그런데 가장 중요한 건 Import가 실패하면 이후의 어떤 동작도 불가능해진다는 점이에요. 이건 Cloud에서 로그인 기능이 안 되는 거랑 거의 같은 수준의 치명적인 이슈거든요.

그래서 이 문제에 대해서는 구조를 아예 재정리했어요. importMesh라는 단일 함수로 로직을 모으고, 확장자별 처리를 문서화한 내용을 공유해서 다양한 케이스에 대한 테스트 코드도 작성하고 결과도 당연히 함께 공유했습니다. 그래서 “빠르게 구현해야 한다면 그냥 이 함수만 쓰면 된다”는 기준점을 만들어두었죠.

이런 방식들이 늘 정답이라고는 생각하지 않아요. 다만 복잡한 걸 단순하게 만들고 협업하는 사람들에게 설명 가능한 구조를 유지하려는 태도는 지금까지도, 앞으로도 계속 지켜가고 싶은 원칙입니다.

결국 그게 제가 만드는 결과물에 대한 책임감이자 함께 일하는 사람들에 대한 예의라고 생각합니다.

일단 각자 뭘 중요하게 보는지만 알아도 훨씬 수월해져요. 그래서 되도록이면 말 꺼내기 전에 먼저 물어보는 편이에요. 서로 납득할 수 있는 기준을 찾으려면 그게 제일 빠르더라구요. 

가장 신경 쓰는 부분을 하나 꼽자면 팀 안에서 편하게 말할 수 있는 분위기를 만드는 것입니다.

사소한 이야기조차 꺼내기 힘든 환경에서는 중요하고 무거운 이야기는 절대 나올 수 없다고 생각하거든요. 작은 의견이라도 자연스럽게 나눌 수 있는 환경이 되어야 서로 진짜로 협업할 수 있다고 믿고 있습니다.

정해놓은 룰이 많진 않지만 작업할 때 반복적으로 나오는 기준 같은 건 그때그때 정리해서 간단하게 공유 문서로 만들어두는 편이에요.

예를 들어 특정 구조를 쓸 땐 왜 그렇게 했는지, 예외는 어떤 상황인지 같은 걸 간략하게라도 써두면 나중에 다른 사람이 이어서 작업할 때도 그 흐름을 자연스럽게 이어갈 수 있거든요.

그리고 코드나 설계 이야기를 나누다 보면 결국엔 이해한 상태에서 자기 언어로 설명해보는 게 제일 정확하다고 생각해서 되도록이면 “이게 맞는지 제가 다시 설명해볼게요” 식으로 소통하는 경우가 많아요. 서로가 같은 그림을 그리고 있는지를 확인하는 거죠. 그게 정리된 가이드보다 훨씬 빠르게 합 맞추는 방법일 때가 많더라고요.

제가 이상적인 개발팀의 모습은 각자 뚜렷한 강점을 가지면서도 어느 정도는 서로의 역할을 유연하게 보완해줄 수 있는 팀이라고 생각합니다.

정확히 말하자면 지금은 팀리더로서보다는 개인 개발자로서 생각하는 관점에도 꽤나 가까워요. 저는 다른 사람이 작성한 코드에 빠르게 적응하고 파악하는 걸 제 장점 중 하나로 보고 있고, 새로운 코드나 도메인을 익히면서 개발 영역을 넓혀가는 과정 자체를 즐기는 편입니다.

그래서 팀 안에서도 서로의 전문 분야를 명확히 하되 분야가 적당히 겹치는 지점에서 함께 일하고 배워나가는 구조가 서로의 성장에 훨씬 긍정적인 영향을 준다고 생각해요.

그리고 팀원들이 각자 맡은 복잡한 작업을 단순하고 명료하게 정리해내려면 본인이 만든 걸 다른 시각에서 직접 써보는 과정이 꼭 필요하다고 봅니다. 누군가의 코드를 사용하다 보면 자연스럽게 “이건 좀 이상한데?” 하는 감각이 생기게 마련이고 그런 피드백은 결과물의 완성도를 크게 끌어올릴 수 있어요.

기능을 나눠서 개발하더라도 인터페이스를 사용하는 사람은 일종의 사용자고, 그 반대 입장에선 사용자가 어떤 지점에서 불편을 겪는지를 파악하는 게 중요하죠. 단순하고 명료한 결과물을 만들기 위해선 하향식 접근법이 도움이 될 수 있지만 그게 내부 구현의 맥락이나 제약을 이해하지 못한 상태에서 단순히 지시만 하는 구조로 이어진다면 오히려 문제를 낳을 수도 있어요.

그래서 왜 이렇게 만들었는지를 설명하고 이해하는 과정이 꼭 필요하다고 생각합니다. 

막연히 복잡해 보이는 문제도 그 과정을 통해 의외로 쉽게 풀릴 수도 있으니까요.

“단순하지만 강력한” 솔루션이라는 건 결국 ‘누가 써도 이상 없이 작동하는 구조’라고 생각해요.

딱 필요한 만큼만 노출되고, 사용자는 그냥 써보면 감이 오고, 안에서 무슨 일이 일어나든 신경 쓸 필요 없이 결과는 정확하게 나오는 거죠.

Dentbird 같은 자동 보철 설계 솔루션에서는 특히 복잡한 조건들을 사용자 대신 알아서 판단해주는 게 핵심이라 겉으로는 단순하게 보이더라도 안에서는 꽤 많은 계산과 설계가 동시에 일어나야 돼요.

지금은 그런 솔루션을 만들기 위해 모듈 간 책임을 더 명확히 나누고 엉키지 않게 설계하는 데 집중하고 있어요. 한 군데가 틀어지면 다른 기능까지 영향을 줄 수 있으니까 처음부터 어디까지가 어떤 역할인지 선을 잘 그어두는 게 결국 단순함을 만드는 일이라고 생각하거든요.

앞으로 더 많은 기능이 붙게 되더라도 전체 구조는 무너지지 않게 유지하면서 확장해 나가는 게 지금 가장 중요한 포인트입니다.

결국 가장 오래 지속되는 동기는 스스로 판단해서 움직일 수 있는 환경에서 나온다고 생각합니다.

제가 리더로서 할 수 있는 건 각자가 맡은 기술 분야에 집중할 수 있도록 흐름을 정리해주는 일, 그리고 작업 상황을 티켓이나 문서로 명확하게 공유해서 방해 없이 흐름을 이어갈 수 있도록 만드는 것 정도예요. 그 이후부터는 각자의 방향과 속도를 믿고 맡기는 편입니다.

그리고 구성원 각자가 가진 주체적인 동기를 최대한 지켜주려고 노력해요.

개발은 평생 배워야 하는 일이고, 그 길을 선택한 분들이니까 본인이 잘하는 걸 스스로 밀고 나갈 수 있도록 여지를 두는 게 결국 가장 좋은 동기 부여라고 생각하거든요.

저는 그 흐름이 끊기지 않도록 옆에서 받쳐주는 역할을 하고 있고요. 스스로 방향을 잡고 움직일 수 있을 때 더 깊이 있게 성장한다고 믿습니다!

앞으로도 저는 방향을 강요하기보다는 자율성을 설계해 주는 방식으로 팀원들의 동기부여를 도와주고 싶어요.