[회고] 커뮤니케이션, 직설, 유연한 코드

2024년 12월에 현재 회사로 이직을 하고 9개월이 지났다.
1년도 안 된 시간이지만.... 정말 다이나믹했다. 업무도 업무지만 여러 사건들이 일어나면서 정말 많은 일이 있었고 많은 경험을 쌓은 9개월이었다.
한번 반추해 보고자 회고를 적어 본다.
 

커뮤니케이션에 대해서.

현 회사에서 가장 많이 얻고 깨닫고 경험한 게 커뮤니케이션인 것 같다.
지금까지 세 군데의 회사를 다녔지만, 이 회사에서 제일 말을 많이 하고 있다.
이전의 회사들은 각자가 기능별로 업무를 분담한 풀스택 개발 형식이었고 기획자나 디자이너도 따로 없었어서 하나의 기능을 구현할 때 누군가와 소통하고 상의할 필요가 별로 없었다. 팀장님에게 리뷰받을 때 소통하는 정도가 거의 전부였다.
하지만 현재 회사에서는 백엔드/프론트/게임 클라이언트/기획자로 명확하게 분리된 업무영역을 갖고 있어 필연적으로 소통이 많아졌다.
특이한 점은, 대부분의 소통이 구두로 이루어진다. 4명의 소수인원, 한뼘짜리 공유오피스 사무실이라는 협소한 환경이 가질 수 있는 특권이랄까.
구두 소통은 확실히 빠르고 효율적이다. 큰 회사에서는 기록이 안 남는다는 점 때문에 구두 소통을 싫어하는 것 같지만, 우리같은 작은 팀에서는 가장 효율적인 전달방식이라고 생각한다.
 
문제는 내가 말을 잘하는 편이 아니다.
말을 잘하는 사람은 본인의 생각을 적합한 단어로 표현할 줄 안다. 말을 하면서 문장이 꼬이지 않고, 별로 깊이 고민하지 않고서도 적합한 표현을 실시간으로 찾아낸다.
말을 못하는 사람은 머릿속에 있는 걸 풀어내기 어려워한다. 내 생각을 가장 잘 나타내는 단어를 찾는 데 오랜 시간이 걸리고, 문장의 끝맺음도 자연스럽게 나오지가 못한다. 그렇다. 나는 말을 잘 못한다.
글로 쓰는 것은 괜찮다. 글은 실시간성이 없으니까. 단어와 표현을 고를 충분한 시간을 얼마든지 사용할 수 있다. 비문을 적어 놔도 얼마든지 고칠 수 있다.
하지만 말을 하다가 적절한 표현이 생각나지 않아서 5초간 멈추면 아무래도 이상해지고 만다. 이미 뱉은 이상한 문장을 고칠 수도 없고.
 
일상 대화에서는 괜찮은데, 업무를 하면서 내 의견이나 의사결정 과정을 표현하는 순간에서 적절한 단어가 생각나지 않거나 머릿속의 생각을 제대로 정리해서 표현할 말을 못 찾는 순간이 많았다.
꽤 스트레스였고 진짜 진지하게 이거 때문에 웅변학원을 다녀야 되나 고민했었다. 어린 시절에 웅변학원을 안 갔던 게 이 현상의 원인인 걸까?
말을 잘하시는 팀원분께 말 잘하는 법 좀 알려달라고 요청하기도 했다. (팀원분께선 느리게 말해도 되니까 말을 뱉기 전에 머릿속에서 정리를 한번 해보라고 조언해주셨다)
지금은 그냥 머릿속이 엉킨 느낌이 들어도 최대한 머리에 힘주고 표현을 고르는 법을 익히고 있다.
그래도 9개월간 소통을 하고 나니, 예전보단 좀 나아진 것 같다. 이렇게 능력이 쌓이는 거겠지... (제발 그러기를...)
 

직설적인 표현이 필요한 순간

이 회사에서는 많은 사건이 있었다. 팀원들이 (나 포함) 모두 한번씩 꺾이기도 하고, 파도처럼 넘실거리는 감정의 파노라마를 하루 안에 겪기도 했다. 이러다 큰일나는 거 아냐? 하는 순간들도 여럿 있었다.
이런 경험들을 겪으며 알게 된 것. 솔직함은 의외로 돌파구가 된다.
 
인간을 크게 두 종류로 나누자면 직선형 인간과 곡선형 인간일 것 같다. MBTI로 치면 T와 F가 될 수도 있겠는데(조금 다를 수도 있지만), 내 할 말을 우선시하느냐... 상대방의 감정을 우선시하느냐... 의 차이일 것 같다.
나는 명백한 곡선 인간이었고, 회사에서 내 솔직한 생각을 털어놓은 적이 별로 없었던 것 같다. 불만을 말하더라도 티나지 않을 정도로 에둘러 표현했지, 직설적으로 내뱉은 적은 없었다. 사실 대부분 이러지 않을까. 이런 스킬이 사회생활이라는 말로 포장되기도 하고.
그런데 이번 회사에서 직설적인 화법을 가진 분의 솔직한 피드백이 해결되지 않을 것 같은 문제를 파훼하는 경험을 했다.
너무 심각해서 나아질 수가 없다고 생각할 정도의 문제였는데, 나로선 상상하기도 힘든(그리고 일반적인 회사원의 입장에서도 상상하기 힘든) 어지러울 정도의 솔직한 피드백이 그 상황을 타개했다.
 
그것이 긍정적으로 받아졌다는 것이 사실 제일 의외였지만...
아무런 답도 없는 것 같은 순간에는 솔직하게 털어놓는 것이 도움이 될 수 있다는 것을 배웠다.
생각지도 못하게 긍정적으로 받아들여져서 문제가 해결되기도 하고, 설령 잘 받아들여지지 않더라고 일을 마주하는 내 마음은 훨씬 편해질 수 있다.
 
나는 지금까지 갈등을 피하고자(그리고 왠지 하면 안 된다는 사회생활의 압박감 때문에)
할 말을 삼켜오는 유형의 사람이었는데,
너무 독성을 갖지 않는 선에서는 부정적인 피드백도 할 수 있어야 하지 않을까. 하고 느꼈다.
 
그리고 한 팀에는 직선형과 곡선형이 둘 다 갖춰져야 바람직한 팀인 것 같다.
직선 사람들만 모이면 불화가 생기고, 곡선 사람들만 모이면 이런 돌파구를 찾기 어려울 테니까.
다른 맥락의 얘기지만 이번에 FE콘 네트워킹 세션에서 한 리더 분에게서 채용 철학에 대해 들었는데,
본인은 팀원을 비슷한 유형의 사람끼리 모으려고 하지 않고, 현재 팀에 없는 유형의 사람들을 영입하려고 한다고 하셨다.
커뮤니케이션 타입에서도 적용되는 얘기인 것 같다. 직선 사람이 풀 수 있는 문제가 있고, 곡선 사람이 유리한 경우가 있지 않나.
어떤 게 나은가? 는 무의미하다고 생각한다.
 
아무튼 그래서 배운 건... 할 말은 하고 살자.
 

유연한 코드에 대해서.

이 회사에 들어오고 나서 프론트엔드 개발자의 가장 베이직한 업무일 것 같은 '기능구현'을 정말 많이 했다.
첫번째 회사는 백오피스여서 비슷한 UI를 찍어내는 툴을 개발하고 유지보수하는 데 집중했고, 두번째 회사는 마찬가지로 비슷한 레이아웃이 반복되는 ERP 서비스여서 사내 UI 빌더 툴이 있었고 그 툴과 디자인 시스템을 주로 관리했었는데,
이 회사에 와서 ERP 형태를 벗어난 다이나믹한 웹 서비스를 오롯이 나 혼자서 개발해볼 수 있었다.
너무 해보고 싶은 경험이었고 실제로 너무 즐거웠다.
 
특히 처음으로 기획자/디자이너 분과 협업하면서, 소위 '기획/디자인 변경'을 많이 겪을 기회가 있었다.
모달형이었던 수정페이지가 인라인 페이지로 바뀌기도 하고, 개별 필드가 포커스아웃될 때마다 저장되는 플로우에서 저장 버튼을 눌렀을 때 한꺼번에 저장되는 플로우로 바뀌기도 했다.
기획자분은 꽤 죄송해하셨지만, 나는 사실 너무 좋았다.
정말 겪고 싶었던 '기획변경으로 인한 코드 변경' 을 여러번 경험할 수 있었고, 덕분에 어떤 코드가 변경에 유연한 코드인지 직접 밟아보면서(?) 깨달을 수 있었다.
 
이 회사에서 업무를 하며 제일 많이 고민한 것들을 추려보면 아래 두가지인 것 같다.
1. 기획/디자인 변경으로 인한 수정 상황에서 최소한의 변경으로 유연하게 수정할 수 있는 구조 만들기
2. 기능추가로 코드가 불어나는(?) 상황에서 관심사별로 잘 분리해서 보기 쉬운 코드 만들기
 
2는 어떻게 하겠는데, 1이 너무 어렵다.
이전의 나는 꽤 단순한 사고를 갖고 있었고, 굉장히 단순한 행동패턴으로 코드 아키텍처를 구현했다.
(중복 코드가 있다 -> 통으로 묶어서 함수화/컴포넌트 만들기 -> 재사용성 up, 햅삐 햅삐)
그냥 중복이 되면 무조건 묶었던 것 같다.
 
그런데 기획변경이 되고 기능이 불어나다 보니...
처음엔 UI나 로직이 일치해서 중복을 줄이기 위해 묶었던 애들이 점점 다르게 변경되어야 하는 경우가 많아졌다.
A필드와 B필드가 같은 컴포넌트를 쓰고 있었는데 A필드에는 툴팁을 추가해야 하고, B필드에는 추가텍스트를 넣어야 한다든지... A필드와 B필드의 하위 버튼들에 들어가는 이벤트 핸들링 로직이 달라진다든지... 이런 경우가 반복되었다.
하나로 묶어 둔 두 컴포넌트가 자꾸만 달라지는 것을 끊임없는 분기처리로 막으며 난 깨달았다.
통으로 묶는 것은 만능이 아니라는 것을...
 
요즘에는 정말 아토믹한 컴포넌트/로직만 함수화해서 재사용하려고 하고, 그것들을 조합하는 더 큰 단위의 컴포넌트들은 같은 패턴이더라도 다른 성격의 필드/도메인을 나타내고 있으면 그냥 따로 구현하고 있다. (예전엔 일치하면 일단 묶었다.)
그러다 보니 비슷한 구조의 코드가 서로 다른 페이지들에서 반복되기도 하지만... 상관하지 않기로 했다.
해당 컴포넌트들에 동시에 적용되어야 하는 수정사항이 들어올 확률보다, 각 컴포넌트에 서로 다른 수정사항이 들어올 확률이 크다고 보기 때문이다.
 
물론 이게 또 정답이 아닐 수 있고 3개월 뒤의 내가 머리를 싸매며 대체 이걸 왜 다 따로 빼놨을까!!! 하며 절규할 수도 있을 것 같지만...
최근 이런 복잡성을 제어하는 지혜를 얻고자 클린 아키텍처를 읽고 있는데, 16장 독립성 챕터에서 이런 내용이 나온다.

소프트웨어에서 중복은 일반적으로 나쁜 것이다. ... 하지만 중복에도 여러 종류가 있다. 그중 하나는 진짜 중복이다. 이 경우 한 인스턴스가 변경되면, 동일한 변경을 그 인스턴스의 모든 복사본에 반드시 적용해야 한다. 또 다른 중복은 거짓된 또는 우발적인 중복이다. 중복으로 보이는 두 코드 영역이 각자의 경로로 발전한다면, 즉 서로 다른 속도와 다른 이유로 변경된다면 이 두 코드는 진짜 중복이 아니다.
예를 들어 두 유스케이스의 화면 구조가 매우 비슷하다고 가정해 보자. 아키텍트는 이 구조에 사용할 코드를 통합하고 싶은 유혹을 강하게 느낄 것이다. 하지만 정말 그래야 할까? ... 이는 우발적 중복일 가능성이 높다. 시간이 지나면서 두 화면은 서로 다른 방향으로 분기하며, 결국에는 매우 다른 모습을 가질 가능성이 높다. 이러한 이유로, 해당 코드를 통합하지 않도록 유의해야 한다. 그렇지 않으면 나중에 코드를 다시 분리하느라 큰 수고를 감수해야 한다.

읽으면서 약간 소름 돋았다. 너무 내 상황이라서...
이런 책을 통해 습득한 지식이나 경험들을 기반으로 '아 이러면 안 됐구나!!' 를 조금씩 깨닫고 있는 요즘이다.
 
또, 함수를 잘개 쪼개고 추출하는 것이 좋다고 믿는 타입이었는데, 입장이 좀 달라졌다.
클린 코드를 열심히 읽었다 보니, 복잡한 함수를 명확한 이름을 지어서 쪼개는 건 가독성에 좋아! 하고 믿고 있었는데...
팀장님께도 초반에 이러지 말라고 피드백 듣고, 나 스스로도 3개월전의 내 코드를 보며 '이걸 대체 왜 쪼개서 더 읽기 힘들게 만들어놨지?' 하는 상황들을 자주 마주하고, 중복 없는 추출의 위험성에 대한 강의나 글들을 많이 접하면서...
막 빼지 말자... 하고 느끼고 있다.
(하지만 여전히, 너무 복잡한 건 빼는 게 맞는것 같다. 그 기준을 잡기가 너무 어렵다.)
 
현재 회사에서 코드를 수정해가면서 깨달은 사소한 것들을 추후 블로그 글에 남겨볼까 싶기도 하다.