저는 개발자가 아닙니다
소프트웨어 프로그래머는 인공지능으로 대체될 확률이 매우 높은 직업이다. 하지만 소프트웨어 스펙을 작성하는 분석 아키텍트는 인공지능으로 대체될 확률이 매우 낮은 직업 중 하나다. 아무리 인공지능이 발전해도 스펙을 대신 작성해주는 세상이 올 가능성은 매우 희박하다. 그래서 스펙을 작성하는 일은 어렵지만 가치가 더욱 빛난다.
- 머리말 中
저는 데이터분석가입니다.
데이터분석가가 원본데이터(raw data)를 가지고 직접 대시보드를 만들기도 하지만, 요즘은 구글애널리틱스(GA)나 앰플리튜드(Amplitude) 등 자동으로 만들어주는 툴들이 많아지고 있습니다. 그야말로 인공지능으로 대체될 수 있는 기술인 것이죠.
하지만 아무리 인공지능이 발전해도 결국 최초로 지표를 '설계'하기 위해서는 데이터분석가가 필요합니다. 데이터분석가라면 공감하시겠지만, 그 하나의 지표를 발굴하는 것이 정말 어려운 일이면서 그만큼 가치가 빛나는 일입니다.
자, 이렇게 생각하면 운영이나 마케팅 분야에서도 떠오르시는 것들이 있으리라 생각 됩니다. 인공지능이 대체 할 수 없는 일, 그중에서도 <설계>와 관련된 일은 어느 직군이든 하기 마련입니다. 만약 그런 일을 안하고 계신다면, 그런 분들에게도 왜 <설계>가 중요한지 이 책을 통해 알게 되실 겁니다.
Tip. 결국 <설계>를 한다는 관점에서 일맥상통하는 부분이 있습니다. 저는 분석을 위한 설계를 한다고 가정하고, 저에게 익숙한 용어를 대입해가며 읽었습니다. 공감하고 끄덕끄덕 하는 포인트가 굉장히 많습니다.
개발자와 협업을 더 잘 하고 싶다면
위 말을 듣고 나면 '그럴 거면 데이터분석가 혹은 각 직군을 위한 책을 읽으면 되는 거 아니냐'는 생각이 들 수 있습니다.
그럼에도 이 책을 여전히 권하는 이유는, 현업에서 <개발팀과 협업을 위한 설계>를 비일비재하게 하기 때문입니다. 다른 직군과 협업을 하면서 그런 경험을 해보셨을 겁니다. 아주 간단한 일인데 엄청 미안해 하면서 부탁한다거나, 반대로 신경 쓸 일이 많은 복잡한 일인데 사소한 부탁처럼 요청한다거나. 직군마다 전문성이 다르기 때문에 일어나는 현상이죠.
사실 그런 상황에서 적절한 조율을 하기 위해 PM과 같은 매니저가 있습니다. 네, 그래서 이 책의 강력한 추천 대상에도 PM이 있고요. 하지만 매니저가 아니더라도 개발자와 직접 소통해본 경험이 있다면? 그런 분들께도 이 책을 추천합니다.
이 책을 읽고 나서 앞으로 개발팀에 요구사항 혹은 기획서를 전달할 때 무엇을 얼마나 어떻게 전달하면 좋을지 조금 더 윤곽을 잡을 수 있습니다. 그렇게 되면 강약조절을 통해서 불필요한 커뮤니케이션을 줄이고, 상상하던 결과물에 좀 더 빠르고 정확하게 도달할 수 있겠죠.
Tip.
정독을 하지 않아도 됩니다. '소프트웨어 스펙'을 직접 작성할 아키텍트나 개발자가 아니라면요. 용어 하나하나에 집착하면 읽다가 지칩니다. '한 번도 들어본 적 없는 말' 보다 '어디서 들어본 말'의 차이가 아주 큰 만큼 모르는 개발용어는 들어본 정도로 만족합니다.
요지는 "아, 우리 개발팀은 내가 쓴 요구사항 중에서 이걸 열심히 보겠구나" 입니다. 내가 중요하게 생각하는 것과 다른 직군이 중요하게 생각하는 것이 다르다는 것을 깨우치는 것만으로 일단 큰 수확 입니다.
