오징어 게임에서 발견한 SoC

소프트웨어 잘하는 방법, SoC에 대한 이야기

야심 차게 소프트웨어에 대해서 가벼우면서도 진한 이야기를 하나씩 써보려고 했는데, 연초라서 그런지 조직 관리, 목표 관리에 대한 이야기를 연달아 썼버렸다. 그것도 꽤나 묵직하게ㅎ 조금 더 가벼운 마음으로 내가 아는 소프트웨어에 대해서 편하게 이야기해봐야지.

SOC 하면 생각나는 것

SOC 하면 떠오르는 것이 '사회 간접 자본'이라면 정치, 사회에 관심이 많고 공부 잘하신 분일 것 같다. 'System on a Chip'을 떠올렸다면 요즘 핫한 반도체에 관심이 있거나 공학 덕후일 가능성이 높다. 혹시나 '관심사의 분리'를 떠올렸다면, 의심할 여지없는 소프트웨어 개발자일 것이다.

종종 나에게 소프트웨어에서 가장 중요한 것이 무엇이냐고, 좋은 소프트웨어를 위해 가장 중요한 것이 무엇인지 묻는 사람들에게 나는 주저 없이, Separation of Concerns, 즉 관심사의 분리라고 답한다. 관심사의 분리라는 다소 생소한 용어가 무엇이길래 가장 중요하다는 것일까?

소프트웨어가 이렇게 동작해야 한다는 것은 아니다

관심사의 분리를 어떻게 설명하면 좋을까 고민을 시작하자마자 떠오른 짤이다. 관종이 넘쳐나는 세상에서 저마다 자기 이야기를 하고 싶어 하고, 상대방 이야기를 듣기보다는 자기 말만 하는 것이 요즘의 풍경인데 집단적 독백이라고 한다.

집단적 독백은 유아기의 특성으로서 전조작기의 유아에게서 발견되는 특징 중 하나이다. 자아중심성은 유아가 이기적이기 때문에 발생되는 것이 아니라, 전조작기의 유아의 사고는 타인의 입장에서 사고하지 못하기 때문에 발생한다. - 나무위키

조금 억지스러운 면도 있지만, 타인의 입장에서 생각하지 못하는 유아적 독백은 관심사가 분리된 상태를 어느 정도 잘 표현하고 있는 것 같다. 그것이 소프트웨어서 의미하는 바는, 설계된 패키지, 모듈, 클래스 또는 함수가 자기에게 주어진 일, 자기 관심사에 대해서만 충실하게 구현됨을 뜻한다.

"다른 사람 신경 쓰지 말고 네 일이나 잘해!"라는 대사는 영화나 드라마에서 직장 상사나 선생님, 부모님이 사용하기에 너무나 찰진 느낌의 대사인데, 딱 그런 느낌으로 소프트웨어의 컴포넌트를 설계해야 한다는 것이다. 다시 말해, 각각의 소프트웨어 컴포넌트들은 의도치 않게 다른 컴포넌트들에 영향을 받기보다는 주어진 역할에 충실하는 것이 소프트웨어 제품을 개발할 때 가장 중요하다고 할 수 있다.

* 패키지, 모듈, 클래스, 함수와 같은 단위 코드를 임의로 컴포넌트라고 표현했다

그렇다고 해서 모든 컴포넌트가 따로따로 동작한다는 것은 아니다. 각자의 정해진 역할을 충실히 하면서도 정해진 규칙에 따라 협력하면서 동작하는 데, 중요한 것은 정해진 대로만 동작하는 것이다. 예를 들어 축구나 농구 같은 운동에서는 같은 팀의 선수들이 서로의 상황을 잘 인지하고 그에 맞게 적절하게 동작을 변경하지만 소프트웨어 컴포넌트는 그렇게 동작해서는 안된다. 만약 소프트웨어로 비슷하게 운동선수들의 동작을 구현한다면 각 상황에 따른 동작마저도 계산해서, 사전에 정해진 대로 동작해야 한다.

가면을 쓰고 자기 할 일만 하는 오징어게임 병사들

그렇게 생각해 보면 넷플릭스 시리즈 오징어 게임에서 게임을 진행하는 가면 쓴 병사들이 좋은 소프트웨어 컴포넌트의 모습일 수 있다. 각자 분명한 역할이 있고, 다른 병사들에 영향을 주지 않으며, 정해진 대로 협력한다. 가면 쓰고 관심 뚝! 그것이 바로 관심사의 분리, Separation of Concerns인 것이다.

너나 잘하세요가 중요한 이유

컴포넌트 간의 관심사를 분리하는 것이 왜 중요할까? 적당히 섞여있어도 상관없을 것 같은데, 정말 그게 제일 중요하다고? 의문들에 답이 될 수 있는 이야기를 해볼까 한다. 그 이야기는 앞선 글에서 소개한 소프트웨어의 본질과도 깊이 연관되어 있다.

https://brunch.co.kr/@msaltnet/20

다시 오징어 게임을 생각해 보자. 수백 명의 사람들을 통제하면서 오징어 게임을 진행할 수 있는 것은 관심사가 잘 분리되어 있는 병사들이 있기 때문이다. 각자 본인의 역할에 충실하고, 절대적으로 복종한다. 일반적인 경찰이나 군대의 특징이라고 할 수도 있지만, 개인의 생각이 완전히 배제되고, 개인 간의 연결 고리도 철저히 통제된다. 올바른 모습이냐의 가치 판단을 넘어 소프트웨어 컴포넌트들은 그렇게 구성되어야 개발자가 소프트웨어의 동작을 정확하게 통제할 수 있기 때문에 매우 중요하다.

소프트웨어 프로그램, 패키지, 클래스 또는 함수 단위로도 관심사가 분리되어야 한다고 했는데, 그렇다면 얼마나 작은 단위까지 분리돼야 하는 것인지에 대한 고민이 생기는 것이 자연스러운 현상이다. 오징어 게임에서 병사들은 잠을 잘 때도 각자의 방에 들어가서 가면을 벗고 따로 잔다. 군대에서는 소대, 분대 단위로 공동생활을 하는데, 그것조차 제거된 채 미세하게 조정되는 조직인 것이고, 소프트웨어에서는 가능하면 작게 분리 할수록 좋다.

군대에서 조직은 개인간의 상호 보완 효과를 기대한다

얼마나 더 작은 단위로 조직을 구분할 것인지에 따라 장단점이 나눠질 수 있는데, 군대에서 분대나 소대 단위로 함께 생활하는 것은 서로의 생활에 관심을 갖고 도와서 전체 평균 전투 능력을 유지하기 위함이다. 체구가 작은 사람이나 달리기가 조금 느린 사람이 섞여있어도 조직 단위의 활동에서 서로를 단점을 보완해 줄 수 있는 것이다. 하지만 소프트웨어 컴포넌트는 그런 효과를 기대할 필요가 없기에 할 수 있다면 최대한 잘게 나눠서, 관심사를 분리해 놓는 것이 좋다.

물론, 작게 쪼개서 통제하고 관리하는 것에는 추가 비용이 발생할 수 있다. 오징어 게임 병사들처럼 각 방을 만들어줘야 하기 때문이다. 클래스 단위로만 역할 분담을 잘해도 되는데, 함수 단위로까지 정리하려면 더 귀찮고 힘든 일이 될 수 있는 것이다.

작게 분리될 수록 비용이 추가된다

그럼에도 불구하고 관심사를 분리해서 잘 나눠야 하는 것은 세상이 점점 더 복잡해지고 있기 때문이다. 요즘의 소프트웨어 개발은 정말 쉽고 빠르게 간단히 진행되는 것 같지만, 사실 대부분은 이미 만들어진 많은 컴포넌트들로 복잡하지만 탄탄하게 구성해 둔 프레임워크나 라이브러리를 기반으로 동작하기 때문에 가능한 것이다. 게다가 우리가 사용하는 시스템들을 계속 점점 더 복잡하고 거대해지고 있다. 동시에 그 안에서 동작하는 내가 만드는 코드 또한 동료 또는 다른 개발자들의 코드와 함께 동작해야 기능을 제대로 수행할 수 있는 시대가 되었다.

우리가 사용하는 많은 프레임워크와 라이브러리, 앱이 관심사가 잘 분리되어서 만들어지고 활용되고 있는 대표적이 예라고 볼 수 있다. 우리는 서로 관심사를 분리한 채 각자 자신의 일을 잘해야 이 크고 복잡한 시스템이 제대로 동작할 수 있게 되었고, 내가 관리하는 작은 단위 코드들 또한 분리가 잘되어 있어야 동료들과 효율적으로 협업할 수 있기에 모든 컴포넌트는 가능한 관심사가 분리된 상태로 설계되고 구현되어야 한다.

간단한 앱이나 서비스도 그 아래 복잡하고 거대한 시스템을 기반으로 동작한다

내가 신입 사원일 때, 핸드폰의 바이너리가 수십 메가바이트였다. 요즘 최신폰으로 찍은 사진 10장 보다 사이즈가 작았다. 지금은 100배 이상 커졌다. 그때 우리 팀은 40명 남짓되었는데 대부분의 코드를 팀 내에서 작성했다. 지금은 비교할 수 없을 정도로 많은 팀이 협업을 통해서 하나의 제품을 완성한다. 웹 서비스도 비슷하다. 크고 복잡해지는 시스템에서 서비스 단위로 분리된 MSA(Micro Service Architecture) 구조를 사용한다. AI도 비슷하다. A부터 Z까지 모두 직접 만드는 조직은 없다.

이것은 시스템이 커지는 것 외에도 빠르게 변하는 기술 환경과도 밀접하게 관련이 있는데, 작성한 코드를 다시 사용하거나 다른 사람이 사용하기 위해서도 잘 쪼개고, 역할을 잘 정리해서 개발할 필요가 있다. 부드러운 제품이라는 소프트웨어의 본질과 장점이 확실한 효과를 내기 위해서 작은 함수 단위로도 관심사를 잘 분리해서 개발하는 것이 더 중요해진 것이다. 그런 이유로 개발자 평가가 진행될 때, 개발자가 작성한 코드 일부만 보아도 개발자의 능력을 어림잡아 알 수 있다. 마치 첫 소절만 듣고도 합격 버튼을 누르는 것처럼!?

재미있는 것은 프로젝트와 시스템이 커지고 분업이 중요해지지만 그럴수록 관심을 끄고 내가 담당한 역할에만 충실해야 한다는 점이다. 많은 사람들이 분업과 동시에 긴밀한 협업을 통해서 복잡한 시스템을 만들어 가고 있지만, 소프트웨어 자체는 역설적으로 분명히 거리를 두고 맡은 일이나 잘해야 한다는 점이 독특하다. 사람들 간의 조직문화에서는 적당히 서로에게 관심을 갖고 공감하며, 소통을 바탕으로 더 나은 결과물을 만들어 내곤 하는데, 소프트웨어는 정확히 그 반대 방향에서 대문자 T의 모습으로 굳건히 서있는 것이다.

코드 작성할 때는 T, 동료와 협업 할 때는 F

이러한 이유로 소프트웨어 엔지니어는 T와 F를 넘나들수 있어야 한다. 소프트웨어 엔지니어는 관심사를 잘 분리해서 소프트웨어 컴포넌트를 만들 줄도 알아야 하고, 공감을 바탕으로 동료, 유관부서 관계자, 고객과 잘 소통할 수 있는 능력도 갖춰서 그들의 요구사항을 조율하여 코드에 잘 반영될 수 있도록 해야 하기 때문이다. 결국 소프트웨어 개발은 사람의 생각이 코드로 구현되는 과정이기 때문이다.