IT 제품 개발 프로세스 파악하기 #5 - QA & 배포하기

IT 개발자를 이해하기 위한 모든 개발지식 온라인 강의를 런칭했습니다. 30% 할인 기간이 얼마 안 남았으니 서두르세요!!🔥🔥

IT 제품 개발 프로세스 파악하기 #5 - QA, 배포

지난 뉴스레터까지 해서 개발자가 짠 코드가 원격 저장소에 무사히 합쳐지는 걸 확인할 수 있었습니다. 원격 저장소에 저장된 프로젝트에는 여러 명의 개발자들이 코드를 쌓아 올리고 수정할 수 있도록 Git이 적용되어 있습니다.

🔗IT 제품 개발 프로세스 파악하기 #4 보러 가기

원격 저장소에 있는 코드는 최종적으로 사용자들이 접근하는 컴퓨터에 설치되고 실행돼야 합니다. 프론트엔드 개발자가 개발한 코드는 웹 서버에, 백엔드 개발자가 개발한 코드는 API 서버에서 실행되어야 하겠죠 (실제 사용자가 이용하는 컴퓨터 환경을 운영 환경이라고 합니다)

QA

개발한 제품이 잘 동작하는지 확인하기 위해 최종적으로 서비스가 배포되기 전에 내부에서 직접 확인을 합니다. 이 작업을 QA(Quality Assurance)라고 합니다. 개발자도 확인을 하겠지만 만약 개발자의 컴퓨터가 아닌 다른 컴퓨터에서 오작동이 날 수도 있습니다. 또한 놓친 부분이 있을 수 있구요.

QA를 하면서 기존 디자인에 맞게 잘 만들어졌는지, 버튼이나 API가 잘 동작하는지 등 개발된 제품을 전반적으로 확인합니다. 웹 개발이라면 컴퓨터 환경, 모바일과 데스크탑에서 잘 동작하는지, 앱 개발이라면 여러 기종들에 문제없이 동작하는지 등을 확인합니다.

보통 규모가 있는 IT 기업에서는 QA 엔지니어가 QA를 체계적으로 진행합니다. 반면 규모가 작은 스타트업에서는 제품 개발 팀(개발자, 기획자, 디자이너 등)에서 직접 사용해보며 문제가 없는지 확인합니다.

[참고]
개발자가 짠 코드가 원격 저장소에 저장되어 있다면, 회사 내에 있는 사람들은 코드를 본인들 컴퓨터에 다운받고 빌드 -> 실행할 수 있습니다. 

4. 코드 배포

QA까지 정상적으로 마쳤다면 이제 사용자들이 사용하는 실제 환경에 적용하는 일만 남았습니다!

일반적으로 개발자가 코드를 짜서 프로젝트에 코드를 합치는 작업들은 전부 개발 환경에서 진행됩니다. 즉 개인 컴퓨터를 통해서 프로그램을 실행시키고 코드를 작성하죠. 이 작업은 실제 사용자들에게 영향을 끼치지 않습니다.

개발환경에서 짠 코드들이 실제 사용자들이 사용하는 운영환경으로 업데이트하는 것을 배포한다고 합니다. IT 회사에서는 정책에 맞게 주기적으로 원격 저장소의 코드를 배포합니다.

[예시]

1. 프론트엔드 개발자가 웹을 개발한 후 웹 서버에 배포하는 작업이 필요합니다.

2. 백엔드 개발자가 API 서버를 개발한 후 API 서버에 배포하는 작업이 필요합니다.

3. 모바일 개발자는 모바일 앱을 개발한 후 앱 스토어에 배포(+심사)하는 작업이 필요합니다.

[참고]
배포라는 것은 사실 서버 컴퓨터에 접속해서 개발자가 짠 코드를 다운받고, 그 코드를 빌드해서 실행하는 작업입니다. 그러나 서버 컴퓨터의 개수가 많다면, 일일이 다운받는 작업이 굉장히 고되겠죠? 그래서 천상계에 계시는 개발자들이 이런 배포 작업을 자동화하는 과정을 개발했습니다. 이를 바로 CD(Continuous Deployment)라고 합니다. 
CD 툴을 사용하면  버튼 한 번 누르면 원격 저장소의 코드가 자동으로 대상이 되는 모든 컴퓨터들에 배포가 됩니다.

책 '빌 캠벨, 실리콘밸리의 위대한 코치' - 에릭 슈미트

- IT 기술의 성지 실리콘밸리에는 정말 성공한 기업들(구글, 애플 , 페이스북 등)이 있습니다. 이 기업들의 수장인 CEO들이 모두 한 사람에게 코칭을 받는다고 하면 믿음이 가시나요? 본 책은 실리콘 밸리에서 가장 유명했던 코치, 빌 캠벨의 이야기를 담고 있습니다. 가장 많은 영향을 받았던 구글의 전 대표이사, 에릭 슈미트가 집필했어요.

- 빌 캠벨은 풋볼 팀 코치로 커리어를 시작했습니다. 그리고 풋볼의 세계에서 비즈니스 세계로 발을 담근 건 39세, 광고 대행사로 입사했습니다. 그리고 코닥, 애플을 거치고 인투이트 CEO -> 코치가 되었습니다.  

본 책에서는 팀을 어떻게 해야 잘 이끌 수 있는지에 대해 다룹니다. 제가 인상 깊었던 부분들을 정리해보면 아래와 같습니다. 

1. 의견은 반박의 대상이지만 원칙은 반박의 대상이 아니다. 모든 사람이 이미 수긍했기 때문이다
-> 어려운 의사 결정을 앞둘수록 원칙에 충실하라고 합니다. 뛰어난 기업들은 원칙들을 잘 정리하고 원칙에 기반해서 의사 결정을 한다고 합니다.

2. 소비자들이 겪는 문제가 무엇인지만 말하라. 그리고 소비자들이 어떤 사람인지만 알려줘라. 그리고 어떤 기능을 만들 것인지는 엔지니어들에게 맡기면 된다. 그러면 당신이 그들에게 무엇을 만들라고 알려줄 때보다 더 좋은 결과물을 얻을 것이다
-> 저는 소프트웨어 엔지니어는 문제를 해결하는 사람이라고 생각합니다. 좋은 제품을 만드는 방법은 본인이 문제를 깨닫고 해결하려고 마음을 먹는 거죠 (다른 팀과 협력을 하는 과정도 중요하지만요)

3. 신뢰의 본질은 약한 모습을 보여주어도 안전하다는 것임을 잘 나타낸다. 하지만 빌에게 신뢰라, 여러 의미가 내포되어 있다. 신뢰란 자신이 한 말을 꼭 지키는 것을 의미한다. ...중략... 빌이 하는 말은 언제든지 믿어도 됐다.
-> 뛰어난 리더가 이끄는 팀에서는 본인들의 약점이 드러나는 것을 두려워하지 않는다고 합니다. 즉 신뢰가 있는 팀이죠. 실제로 구글이 높은 성과를 내는 팀을 내부적으로 분석한 결과, 심리적 안정감이 가장 큰 요소라는 것이 밝혀졌다고 해요.

4. 그는 회의에서 사람들이 핸드폰으로 통화하거나 노트북을 사용하는 행동에 매우 실망스러워했다.
-> 회의에 참석하는 모든 이들은 안건에 대해 동기화가 되어 있어야 합니다. 그리고 의사 결정에 영향을 끼치지 않더라도 회의에서 모두가 의견을 내는 과정이 중요하다고 생각해요.

5. 빌은 다쳤거나 아프거나 아니면 어떤 방식으로든 도움이 필요한 친구가 있을 때 일단 모든 것을 내려놓고 달려가야 한다는 것을 몸소 보여줬어요. 그러라고 친구가 있는 거죠. 빌은 그냥 나타났어요. 빌은 항상 그랬죠. 그냥 달려갔어요.
-> 결국 비즈니스도 사람끼리 하는 일인데 별개의 영역으로 뒀던 제 자신을 반성했습니다. 이익에만 초점을 맞추기보단 상대방을 진심으로 생각하는 태도를 개발하도록 노력하려구요.