brunch

You can make anything
by writing

C.S.Lewis

by Sweet n Sour Oct 28. 2019

[Sweet]
저 좋은 아이디어가 있는데요 pt. 1

Spec Writing

제목처럼 이번에는 Spec을 적는 법에 대해서 이야기해볼까 한다. 물론 이건 어디서 정해진 책에서 따왔다거나 공부를 했다거나 한 내용이 아니고 내가 지금까지 회사를 다니면서 배운 정보들에 의거한 내용이다. Spec을 쓰는 방법에 대한 자세한 이야기보다는 이번에는 Spec writing에 관련된 나의 회사 경험들에 대해 적고자 한다. Spec writing에 자세한 부분은 part2에서!

Spec이 뭔데?

한국말로 이야기하는 "그사람 스펙이 뭔데"와 비슷한 느낌이라고 할수 있는데 Spec은 Specifications의 줄임말이다. Specification의 사전적 의미는 "열거, 명세서, 내역, 요구조건, 사양"이다. 따라서 우리가 이야기하는 프로젝트의 스펙, 아이디어 스펙, 이라함은 프로젝트나 아이디어에 대한 세부사항을 열거하는 문서 정도로 생각할수 있을것 같다.

나는 지금까지 인턴, 프리랜스, 용병(?) 활동을 제외하면 3개의 회사에 풀타임으로 다녔다. 그 세 회사는 다 문화가 굉장히 틀렸고 모두 그만의 장점이 있었다. 회사 문화가 틀렸기 때문에 당연히 아이디어를 내는 방식에도 차이가 있었다.

삼성 연구실

나의 첫 직장은 미국 실리콘 밸리에 있는 삼성전자 무선사업부 연구실이였다. 연구실의 특성상 이 직장에서 대부분의 시간은 프로토타입을 만들거나 아이디어를 짜는데에 사용되었다. 자세한 프로젝트에 대해서는 나열할수 없지만 처음에는 삼성 핸드폰에 들어가면 좋을것 같다고 생각되는 핸드폰 앱에 대한 연구 및 개발을 했었고 그 이후에는 삼성 기어 vr, 삼성 기어 vr 컨트롤러, IoT (Internet of Things), GVRf (Gear VR Framework) 등에 관련된 일을 했었다. 한국에서 읽는 독자분들이 삼성에 대해 직장으로서 좋은 인식을 가지고 있는지 나쁜 인식을 가지고 있는지는 잘 알지 못하지만 내가 다녀본 결과로는 겉으로 보이는 것보다 훨씬 실리콘밸리에 있는 다른 테크회사들과 동화되는데에 많은 노력이 들어가 있었고 타회사들과 비슷한 문화를 이미 가지고 있었다.

이 당시에 새로운 아이디어가 떠올랐다! 하면 대부분 팀동료나 내 상사, 또는 본사에 대해 잘 알고 계시는 주재원 분들과 이야기를 나누고, 본사에 있는 부서와 연결이 되거나 또는 연구소 내에서 일단 프로토타이핑을 시작하는 경우도 있었다. 아이디어 자체를 서류화하는 작업 (스펙 작성)은 내가 하는 일은 약 5번에 한번 정도 밖에 없었던것 같다. 꼭 내가 개발자라서 라기 보다는 그당시에는 너무 주니어 직급이였기 때문에 그런것도 있는것 같다.

그래서 대부분 화이트보드에서 브레인 스토밍을 하거나 대화를 나누고 난 후에 여러 프로젝트 매니저 분들이나 주재원 분들께서 서류화를 도와주셨던것 같다. 물론 나는 한글로 서류를 작성해본 일이 거의 전무했기 때문에 단어 선정이나 그런 부분에서도 그분들의 도움이 많이 필요했다. 그럼에도 불구하고 보통 내가 내는 아이디어에 대해서는 비지니스 리서치나 마켓 리서치 등등은 나에게 많이 기회를 주셨던것 같다. 그리고 이 아이디어가 더 윗선으로 올라가게 되거나 할때도 항상 나에게 공로가 많이 돌아오는 그런 문화였다.

삼성에서 적었던 스펙 서류들에 대한 기억을 되짚어보면 정보를 압축해서 적는 그런 방식보다는 최대한 많은 정보, 최대한 많은 시장조사, 최대한 많은 경쟁사 조사 등으로 정보가 많을수록 좋은 그런 형식이였던 것 같다.

Snap Inc

브런치는 한국 플랫폼이라서 스냅이라는 회사가 독자분들에게 조금 낯설수도 있을거라고 생각한다. Snap Inc는 스냅챗이라는 어플리케이션을 만든 회사이고, 친구들과 사진을 보내면 몇초후에 그 사진이 사라지고 다시 볼수 없게 되는게 특징이다. (그래서 어플리케이션 로고도 유령 모양이다.) 렌즈 필터들로도 유명한 앱이기도 하다. 내가 스냅에 처음 입사했을때는 개발자는 약 280-300명 정도 되었고 전체 직원은 700명 안팎이였다. 회사 규모가 크지도 않고 스타트업 문화가 컸기 때문에 스냅챗에서의 Spec writing은 3 회사중 가장 즐거웠다. 물론 스펙의 내용에 있어서는 굉장히 엄격 했지만 스펙 안에 웃긴 짤도 넣고 유행어도 사용하면서 즐겁게 스펙을 썼다. 그리고 삼성과 다르게 이곳에서는 내가 내는 아이디어는 내가 스펙까지 다 쓰고 결재까지 받아야 했는데 그 과정이 개발자인 나에게는 굉장히 새로웠고 재밌었다.

내가 가장 스펙을 많이 썼던 때는 Product Experimentation 이라는 팀에 소속되어 있을때였는데, 이 팀은 스냅챗 앱내에서 새로운 기능들이나 바꿀점을 우리가 아이디어를 내서 만들어서 A/B 테스트를 하는 팀이였다. (A/B 테스트는 대조실험인데, 전체 유저층에게 기능을 사용하게 하는것이 아니고 작은 퍼센트의 유저에게만 사용하게 해서 반응과 변화를 측정하는 실험이다) 그런 팀이였기 때문에 스펙을 다들 많이 썼었고 우리 팀 내에서 나는 defense meeting이란 걸 기획해서 했다. 당시 우리팀은 총 6명 이였는데 아이디어가 있으면 그에 대한 스펙을 발표하고 팀내에서 투표를 하고 과반수가 넘으면 더 위로 같이 가서 “우리팀은 동의했다” 라는 서포트를 얻는 뭐 그런 시스템이였다. 그림, 그래프, 짤, 유행어, 등등을 마음대로 사용하면서 스펙을 쓰는 자유로운 분위기의 spec writing 이였다.

아마존 알렉사

현재 나는 아마존에서 알렉사라는 인공지능 플랫폼을 만드는 팀에 있는데 아마존은 Spec writing에 굉장히 정형화 되어있는 형식이 있다. 일단 가장 사용하는 두가지 형식을 소개하려고 한다.

첫번째는 개발자로서 내가 가장 많이 보고 사용하는 스트럭쳐인데, 1-pager, 2-pager, 3-pager, 6-pager 이라고 부른다. 말그대로 한장짜리, 두장짜리, 세장짜리, 여섯장짜리 스펙이다. 보통 새로운 기능을 만들기로 할때 그 기능에 대한 기술적인 디테일이라던지, 유저가 사용할 방식이라던지 등등을 적을때 사용하는 형식이다. 몇장짜리 스펙을 적을지는 보통 기능의 규모에 따라서 정해진다. 이 스펙에 있어 아마존의 특이한 점이 하나 있는데 그건 아마존은 파워포인트를 사용하는걸 크게 선호하지 않는다. 신입 직원 오리엔테이션을 할때도 말해준다 파워포인트를 선호하지 않는다고. 그 이유는 파워포인트를 만들어서 요점만 적어놓고 발표를 하거나 팀원들과 공유를 하게되면 정보의 양도 더 적고, 작성자도 더 많은 생각을 하지 않으면서 만들수 있다는 것인데, 처음에는 별로라고 생각했지만 지금은 말이 된다고 느끼기도 한다.

파워포인트 형식이 아니고 레포트 형식의 스펙이기 때문에 보통 미팅을 시작하면 처음 15분 정도는 스펙을 보내주고 다들 읽는 시간을 가지게 된다. (이 또한 나에게는 신기했던것이 다른 회사에서는 미리 이메일로 보내주고 "미팅 오기전에 읽고 오세요" 했는데 여기서는 미팅이 시작하면 다들 읽기 시작한다..)

두번째 이야기 하고 싶은 스펙은 (나에게는 개인적으로 신기하고 기발했던) PR-FAQ라는 스펙인데, 위에서 언급한 페이저들과 연결되있을수도 있고 아닐수도 있다. 이 형식이 뭐냐 하면 PR-FAQ = Press Release - Frequently Asked Questions (보도 자료 자주 묻는 질문) 이라는 뜻인데, 우리가 이 기능을 세상에 출시를 했을때, 기자분들이 기사를 쓰고 나서 우리에게 물어볼만한 질문과 그 답변 형식으로 스펙을 적는 것이다. 정해진 형식이 있지만 그건 공개할수 없고, 예를 들자면 알렉사에서 날씨를 묻는 기능을 만든다고 치면, "날씨 정보는 어디서 가져오나요?" "날씨 정보는 Accuweather.com에서 가져옵니다." 이런식의 형식으로 서류를 적는 것이다.

보통 이 PR-FAQ가 완성이 되면 다른팀과 협업을 할때도 "우리팀이 이런걸 만들고 있는데, 이게 PRFAQ야 한번 읽어봐" 이런 식으로 PR-FAQ를 공유하게 된다. 그리고 내가 지금까지 본 바로는 윗선에서 새로운 프로젝트를 결재 받을때는 PR-FAQ가 꼭 있어야한다.