설계란? I Driven Design with Arrangement

안녕하세요. yeTi입니다.
오늘은 설계에 대한 이야기를 해보려고 합니다.

AI가 구현을 대신하다

설계라는 활동이 무엇인지는 꾸준하게 생각해보는 과정에 있는 것 같습니다.

그런데 요즘 저에게 재밌는 상황이 벌어지고 있다고 느껴집니다. 코딩을 하지만 코딩을 하지 않는 상황에서 설계를 바라보고 있다는 것입니다.

얼마전까지는 DDD, TDD, OOP 같은 개념론을 말하며 어떻게 보다 나은 구현을 해나갈지 생각하고 말을 나누는 상황이었습니다.

하지만 요즘은 Cursor와 ChatGPT를 사용하여 생각을 차리는 시간이 대부분이고 코딩은 간편하게 만들어내고 있습니다. 그 과정에서 그 동안 중요하게 생각하던 구현의 관점은 점점 덜 인식하게 되고 구현된 결과물이 내 의도에 맞는 결과물을 만들어내는지에 관심을 두게 되었습니다.

그로 인해 설계라는 활동이 그 동안 가져왔던 생각들과는 결이 다르게 보이기 시작했습니다.

의도를 드러내다

이러한 맥락에서 최근에 접한 윤지영님의 WHY 는 나라는 존재를 알아차리고 관계속에서 만들어지는 기여를 통해 무한한 시간을 가질 수 있다고 말하는 것에서 영감을 받았습니다.

그로 인해 나라는 존재를 알아차리기 위해 왜 라는 질문을 던지는 시간을 가지고 황갤러리 를 시도하며 내가 좋아하는 것들을 알아간다는 것이 말로써 느껴지는 것과 그림이라는 시각적으로 느껴지는 것이 다르다는 것을 알 수 있는 계기가 되었습니다.

그렇게 저는 얼마 안되는 시간이지만 나라는 사람을 알아가며 나의 의도를 드러내는 연습을 해오고 있었습니다.

그렇게 ChatGPT 와 첫 대화를 시작했습니다.

설계라는 활동이 내가 주도하는 설계가 있고 상대가 주도하는 설계로 나눠볼 수 있을 것 같다는 생각이 들었어

이 말을 시작으로 누가 주도하느냐에 따라 설계라는 활동이 완전하게 달라질 수 있다는 생각이 들었습니다.

여기서 제럴드 와인버그의 대체 뭐가 문제야 를 읽으며 깨달은 문제를 정의할 수 있다는 것이 연결되어 설계라는 것은 문제를 해결하기 위해 구조를 정하고 계획을 만드는 과정이라는 생각이 들었습니다.

그런데 빠져있는 것이 있다는 것을 알아차렸습니다. 어떤 문제를 왜 풀것이고 목표를 언제 얼마큼 왜 달성해야하는지가 빠져있다는 것이 느껴졌습니다.

그렇게 그 동안 저도 개발이라는 활동을 하며 익숙하게 해왔던 행동들이 상대가 주도하는 설계로 느껴졌기 때문입니다.

왜냐하면 그 어디에도 내가 왜 이 문제를 풀고 싶은지 목표를 언제 얼마큼 왜 달성해야하는지가 빠져있었기 때문입니다.

이는 윤지영님의 WHY 에서 말하는 나는 없고 직업만 있을 뿐이었기 때문입니다.

내가 주도하는 설계와 상대가 주도하는 설계

내가 주도하는 설계는 내가 설계의 목표와 의도를 스스로 정의하고, 이를 바탕으로 문제를 구조화하고 해결해나가는 것이라고 생각합니다.

내가 왜 이 문제를 풀고 싶은지, 어떤 가치를 만들고 싶은지에서 출발하여, 내가 문제의 범위를 설정하고 달성 가능한 시점과 방법을 주체적으로 결정하는 것이 내가 주도하는 설계의 특징이라는 생각이 들었습니다.

반면에, 상대가 주도하는 설계는 목표나 의도가 외부(상대나 환경)에서 주어지고, 나는 이를 바탕으로 구체화하거나 실행 방안을 설계하는 것이라고 생각합니다.

이는 외부의 요구나 필요에서 출발하여, 주어진 목표를 달성하기 위해 내가 설계에 참여하되, 외부의 의도를 충실히 반영하는 것이 상대가 주도하는 설계의 특징이라는 생각이 들었습니다.

특히, 문제를 정의하는 관점에서 바라보면 내가 주도하는 설계에서는 내가 관심을 두는 문제를 스스로 정의하며 출발하고 문제의 본질과 가치가 내 안에서 시작되므로 나만의 독창적인 접근법을 가질 수 있습니다.

반면에, 상대가 주도하는 설계에서는 상대가 제시하는 문제나 요구 사항을 받아들이면서 시작하고 문제의 정의가 외부 환경에 의해 설정되며 내가 그것을 맥락에 맞게 해석해야 하기 때문에 상대의 요구와 목적을 충족시키기 위한 실용적이고 구체적인 방향으로 설계하게 되고, 상대의 기대치를 이해하고 그에 부합하도록 최적화된 결과를 내려고 노력하게 되는 것이 상대가 주도하는 설계의 특징이라는 생각이 들었습니다.

이렇게 생각을 풀어가는 과정에서 상대가 주도하는 설계의 관점이 어디서 많이 겪었던 것 같다는 생각이 들었습니다.

문제를 풀어나가는 과정 자체가 나의 표현 방식이 된다

이렇게 문제 정의의 관점에서 시작해서 누가 주도하느냐에 따라 설계라는 활동을 생각하다보니 문제를 풀어나가는 과정 자체가 나의 표현 방식이 된다는 통찰을 느끼게 되었습니다.

글을 쓰고 말을 하고 그림을 그리고 노래를 부르는 것 뿐만 아니라 문제를 정의하고 풀어나가는 과정 조차도 나의 표현 방식이 된다는 것을 알게 된 순간 놀라운 감정에 빠져들었습니다.

그 동안의 여정

그리고 이 표현은 저의 그 동안의 설계적 고민을 가장 응축하여 표현하는 말이라는 생각이 들었습니다.

I Driven Design

그리고 2012년도에 개발자라는 역할로 일을 시작하면서 지속적으로 설계에 대한 의구심을 가지고 고민해왔던 순간들이 생각나기도 했습니다..

• XP, 희한하게 나아지는 방법론
• 좋은 설계하기 (feat. 의사소통)
• 설계의 목적과 검수하는 문화
• 설계를 바라보는 관점 (feat. 소통의 일부)

추상, 소통, 협업은 도구다

그리고 그 동안 고민하던 추상, 소통, 협업은 도구라는 생각이 들었습니다.

도구라는 표현으로 가치가 낮다는 의도는 아닙니다. 제가 드러내고 싶은 뜻은 추상(Abstract)는 문제의 본질을 표현하는 도구이고, 소통(Communication)은 의도를 전달하는 도구이며, 협업(Collaboration)은 의도를 확장하는 도구라는 것입니다.

그리고 이것들이 나의 의도를 드러내고 만들어가는 과정에서 필요한 수단이지 설계 자체를 지칭하는 것은 아니라는 말입니다.

누구의 돈으로 문제를 풀어나가는가

그런데 아이러니하게도 맹점이 하나 있다는 것을 알아차렸습니다.

바로, 누구의 돈으로 문제를 풀어나가는가 하는 것입니다.

내가 내 돈으로 문제를 풀어나가면 내 의도만 반영하며 문제를 풀어나가면 되는데, 현실에서는 다른 사람의 돈으로 다른 사람의 문제를 풀어나가는 일을 하게 됩니다.

그 과정에서 다른 사람이 정의한 문제를 다른 사람이 원하는 방향이 있는데 나의 표현이 우선시되어 내 문제로 치환하여 풀어나간다면 제멋대로 일하는 사람밖에 안된다는 생각이 들었습니다.

실제로 그런 분들이 경영진들과 문제를 원활히 풀지 못하고 독단적인 인식을 받는 경우도 보았기 때문에 유쾌하지 않은 일이 발생할 수 있겠다는 생각이 들었습니다.

테슬라의 개발 문화

어떻게 이 맹점을 보완할 수 있을지 고민해보면서 테슽라의 개발 문화가 본보기가 될 수 있겠다는 생각이 들었습니다.

테슬라는 직원들에게 높은 수준의 자율성을 부여하고, 그들의 창의성을 극대화할 수 있는 환경을 조성한다고 합니다. 직원들이 자신의 의도를 명확히 가지고 문제를 해결할 수 있도록 독려하며, 개인이 자신의 방식으로 문제를 정의하고 접근하도록 하면서, 조직 내에서 창의성을 발휘하게 함 함께 직원들이 자신의 역할을 단순한 수행자가 아닌, 문제 해결의 주체로 인식하도록 하는 것이 테슬라의 개발 문화라고 합니다.

그리고 테슬라는 개인의 창의성을 허용하면서도, 조직의 명확한 목표(예: 지속 가능한 에너지, 전기차 혁신)와 강력하게 정렬된 문화를 유지한다고 합니다. OKR과 비슷한 방식으로, 모든 직원이 조직의 큰 비전에 기여할 수 있도록 유도한다고 합니다.

I Driven Design with Arrangement

테슬라의 조직문화를 알아가면서 아장스망을 통한 정렬과 배치의 재개념화 에서 언급했던 아장스망이 떠올랐습니다.

결국 자신의 의도와 조직의 목표를 정렬하는 것이 맹점을 극복할 수 있는 방법이라는 것이죠.

I Driven Design (본질) 을 통해 개인의 주도성과 창의성을 바탕으로 설계를 시작하는 철학을 가지고 설계자는 자신의 의도와 철학을 중심에 두고 문제를 정의하고 해결 방안을 탐구할 수 있습니다. 이는 개인의 의도가 설계의 출발점이자 고유한 색깔로 반영됩니다.

그리고 Arrangement (조화) 를 통해 개인의 의도를 조직의 목표와 연결하여 균형을 맞추는 과정을 가질 수 있고, 고정된 방식이 아니라, 유연하고 관계적인 배치로 변화하는 환경과 맥락에 적응하여 조직의 요구와 목표를 수동적으로 따르는 대신 개인의 의도와 조화롭게 통합할 수 있겠다는 생각이 들었습니다.

결론

I Driven Design with Arrangement

제가 설계를 바라보는 관점은 위의 인용문으로 표현할 수 있겠다는 생각이 들었습니다.

우리가 풀어갈 문제를 내가 표현할 수 있는 방식으로 정의하고 풀어나가는 것이 중요하고, 그 과정에서 조직이 나아가고자 하는 방향과 일치하여 나의 의도와 조직의 목표가 조화롭게 통합되는 것이 중요하다는 것이 느껴졌습니다.

그 이후 추상화든 소통이든 협업이든 문제를 어떻게 풀어나갈지는 선택의 문제와 효율의 문제라는 생각이 듭니다. 다만, 추상화를 못한다면 개념화의 수준이 약해 문제를 정의하기가 힘들 것이고, 소통이 힘들다면 의도를 전달하기가 힘들 것이고, 협업이 힘들다면 혼자서 문제를 풀어나가게 될 것입니다.

여기서 다양한 이론들과 연결해보겠습니다.

객체 지향이라는 인간의 인식의 틀을 활용해 문제를 정의하기 위해 사고법으로 활용할 수 있고 구현 수준에서 활용할 수 있습니다.

그리고 TDD(Test Driven Development)는 문제를 너무 크게 정의하지 말고 우리가 가장 중요하게 생각하는 작은 문제를 정의하고 풀어나가라고 말하는 것입니다. 그 과정에서 만들어지는 테스트 코드는 이후 변화를 위한 안전지대를 제공할 것이라고 말합니다.

DDD(Domain Driven Design)는 문제를 정의함에 있어 말이 오가는 상황이니 오해가 없도록 말을 정의하라고 말하고 개발자의 사고법과 도메인의 사고법이 다르면 대화도 힘들도 비즈니스 방향성을 맞춰가기도 힘이 드니 문제를 정의하고 풀어가는 과정에서 도메인 지식을 활용하라고 말합니다.

Tidy First 는 동작하는 코드를 만드는 것은 아무도 반대를 하지 않지만 구조를 변경하는 것은 왈가왈부의 문제가 될 수 있기 때문에 티가 나지 않도록 개선해가라고 말합니다. 그리고 어느 날 구조 변경이 필요할 때를 대비해서 주변인들과 관계를 잘 맺어두라고 말합니다.

여기까지가 제가 설계를 바라보는 관점이었습니다.