오늘의 생각 - iOS개발자의 커뮤니케이션이란?

오늘은 어제 글을 쓰다가 곁가지로 빠질 뻔 했던 내용인 커뮤니케이션에 대해

간단히 생각을 정리 하려 한다. 언제 내가 이러한 것들을 까먹을지 알 수 없기 때문에..

사실 지식이 아니라 경험이긴 하지만 이때의 생각들을 적어두면

나중에 다시 봤을때 또 다른 영감과 그때는 다르게 생각할 수 있겠다 라는 생각이 들어서..

 

기업들의 채용공고문을 보면 종종 보이는 커뮤니케이션 능력이 좋은 사람.

이러한 조건을 거는 경우가 있다. 이러한 조건은 사실 

수치적으로 표현을 할 수 없는것이기 때문에 지원자가 저 커뮤니케이션 좋아요~

이렇게 주장한다면 사실 그것을 검증할 방법이 명확히 있을까?

있을것 같긴 하다. 그들이 제시하는 커뮤니케이션이란 무엇이고, 그것을 검증할만한

질문들을 마련해 둘 수 는 있겠다. "이런 상황에선 어떻게 할 것인가요 ?" 하는 질문 방법을 통해..

 

다만 내가 겪은 짧은 2년이란 시간동안 내가 경험하고 느낀 커뮤니케이션에 대해 한번 적어보려한다.

서론이 길었는데.. (항상 서론이 주절주절 말이 길어요..)

 

나는 iOS앱 개발자이다. 그렇다 보니 긴밀하게 협업 해야하는 유관부서들이 있는데

우리팀의 경우는 서버팀, 안드로이드팀, 기획팀, 디자인팀은 정말 긴밀하게 협업해야하고,

마케팅, 컨텐츠, 데이터, FE등 과제마다 다른 팀과 협업을 해야하는 경우도 생긴다.

각자 팀이 원하는것이 다르고 상황이 다르다 보니 다른 팀과의 의견을 조율하는것은 필수적인 일이다.

그러한 과정에서 원할이 소통하는것이 커뮤니케이션 능력이라고 생각한다.

 

원활히 소통한다는것은 상대방을 고려해서 친절한 언어로, 쿠션어로,

이해할 수 있는 언어로 이야기 하는것이다. 또 나의 상황을 잘 공유하는것도 커뮤니케이션일 수 있다.

현재 내 상황이 어떠하다 언제까지 무엇을 하겠다 이런식으로 다른 사람들이 예측 가능하게

나의 상황을 알려주는 것도 커뮤니케이션 스킬중 하나일 수 있다. 다만 내가 이야기 하고 싶은건

이것들은 뿐만 아니라 개발자의 커뮤니케이션은 추가적인게 있어야 한다는걸 말하고 싶었다.

 

iOS 개발자의 업무는 iOS앱 기능 개발을 하고 그 기능을 유지보수 하는 일이다.

흔히 사람들은 말한다. "앱 이미 만들어져 있는데 뭘 또 할 게 있어?" 라고

내가 일하면서 느낀것은 고객의 보이스가 끊임 없이 들어온다.

이러한 버그가 있어요, 이게 안되요, 이러한 기능을 추가해주세요 등

고객의 요구 사항에 맞춰서 기능을 개발하고 버그를 고치는게 우리의 업무이다.

또 사업적인 관점에서 이러한 기능을 추가해서 매출을 올려야 한다. 하면

그러한 기능을 개발 해야 하는 것이다. 이러한 상황을 우리는 앱기능개발 및 유지보수라고 칭한다.

또한 시간이 흐를수록 기술이 발전하며 새로운 도구들이나 새로운 아키텍쳐들이 나타난다.

이러한 것들은 기존에 존재했던 어떠한 문제를 해결하기 위해 나타난 것으로 그러한 문제는

우리 팀도 겪고 있었을 문제인 경우가 많다. 이러한 것들을 새로운 도구를 쓰도록, 새로운 아키텍쳐로

리팩토링 다시 만드는 일도 진행한다. 이렇게 하는 일들을 통해 사용자들이 앱을 쾌적하게 사용할 수 있도록

계속 보수하고 고쳐가는 일을 한다. 만약 앱이 버벅이고 갑자기 꺼진다면

사용자들은 떠나갈 것이고 이것은 회사의 매출이 하락하는 결과로 이어질것은 자명하다.

 

이러한 상황에서 우리는 우리 앱의 코드를 지켜야 한다. iOS앱 개발자가 가져야할 마인드라고 해야하나?

가장 기저에 깔려야 하는 태도는 우리 코드는 우리가 지켜야한다 라는 것이다. ㅋㅋ

전쟁도 아니고 같이 잘해보자고 하는 같은 회사 안에서 왜 코드를 지키라는 것일까?..

사실 다른 팀들이 우리의 코드를 직접 수정하거나 망치는 것은 아니다.

정작 우리 코드를 망치는것은 우리다. 이렇게 망쳐진 코드는 기술 부채로 남고

이것은 언젠가 미래의 우리가 그것을 청산해야하는 일이 발생한다. (흔히 레거시라 말하는..)

 

이러한 상황은 보통 커뮤니케이션을 잘 못해서 발생한다고 생각한다.

각각의 팀은 다른팀의 상황을 잘 알지 못한다. 코드 구조는 말할것도 없다.

이러한 상황에서 각각의 팀은 자기의 팀이 원하는 요구사항을 이야기 한다.

흔히 문제가 되는 요구사항의 내용은 "여기선 이렇게 해주고 저기선 이렇게 해주세요"

분기치라는 요구사항이다. 하나 둘 if else 문으로 요구사항을 해결하다보면

발생 가능한 가지수가 늘어나고 여기서도 수정하고 저기서도 수정하고

일을 할때 대상이 되는 코드를 찾아서 꼼꼼하게 수정해야하는.. 결국 우리가 일이 힘들어지게 하는

부채로 남게 되는것이다. 물론 if else 자체가 나쁘다는게 아니라 꼭 필요한 문법이고 분기이지만

경계해야할 것은 어디에만 어떻게 해주세요라는 요구사항이다. 이러한 요구사항은

그 히스토리를 기억을 하고 있어야 하고 그 히스토리를 모르는 사람이 일을 한다면

그 부분은 놓칠 가능성이 생기고 그것이 버그로 이어진다.

 

이러한 상황에서 커뮤니케이션을 통해 더 나은 방법을 찾는 것이다.

그러한 스펙등 분기가 꼭 필요한것인지. 다시 한번 따져보고 대화로 풀어나가면서

우리의 코드를 지켜나가는것이 커뮤니케이션 이라는 생각을 하게 되었다. 

 

한가지 예시를 들어서 우리의 코드를 망치는 요구사항을 이야기 했는데

절대적인건 없다. 다만 일을 하다보면 이거는 아닌것 같은데? 라는 생각이 들때

그 생각을 빠르게 캐치하고 그 원인이 무엇일지 생각한다음 그것의 예상 문제점을 들어

상대방에게 이야기를 해줘야 한다는것이다. 

그게 커뮤니케이션을 잘 하는 사람이 아닐까? 이렇게 생각해보았다.