PM은 개발을 얼마나 알아야 할까?
feat. 비전공자를 위한 이해할 수 있는 IT 지식
[Kevin과의 1:1 멘토링 2번째 과제]
IT 분야에서 일을 하는 PM, 기획자는 한 번쯤 이런 생각을 해볼 것 같다. "데이터를 보려면 Python이나 R을 공부해야 하나?" 혹은 "개발자랑 대화가 어려운데 어떤 언어를 공부해야 하지?" 나 역시도 그랬었고, 그래서 Python으로 하는 데이터 사이언스 수업을 들었었다. (지금도 그렇지만) 한창 미래를 고민했던 시기였고, 업무에 대한 명확한 정의가 없었기 때문에 그랬던 것 같다. 다행히 지금은 무엇을 공부해야 할지는 아는 정도인 것 같다.
이번 과제는 아래 list에 대해 직접 공부를 해서 답변을 다는 것이다. 각 질문에 대해 얼마나 깊게 공부할 것인가는 스스로가 정한다. 이에, 먼저 '얼마나'에 대해 명확하게 해야 할 것 같다.
내가 뷔페를 운영하는 사람이라고 예를 들어보자. 뷔페 안에 음식 카테고리는 한식, 중식, 양식이 있다. 나는 각 카테고리별 음식이 다 완성되어 뷔페를 런칭할 준비를 마쳐야 한다. 잔치국수, 짜장면, 파스타와 같이 명백한 음식은 각 파트의 쉐프에게 요청하면 된다는 것은 알겠다. 문제는 퓨전 음식이다. 김치치즈파스타를 내보내야 하는데 아직 준비가 안됐다. 그럼 한식 쉐프에게 물어봐야 할까? 아님 양식 쉐프에게 물어봐야 할까? 이렇게 헷갈리는 상황을 최소화할 수 있게 관련된 지식을 알고 있어야 한다. 김치 준비는 한식 쉐프, 치즈와 파스타면은 양식 쉐프가 담당한다는 것을 안다면 중간에서 혼란을 겪거나 두 쉐프를 괴롭힐 필요가 없을 것이다.
개발 지식이 많으면 많을수록 좋겠지만, 일단 한 가지를 깊게 알기보단 넓게 아는 게 필요한 것 같다. 가령, 뷔페의 매니저는 잔치국수 소면은 5분, 파스타 링귀니는 8분씩 삶아야 한다는 걸 먼저 공부하기보단, 면은 삶아서 준비를 해야 한다는 걸 아는 거다. 그래야 면 삶는 기계 사거나 다른 준비를 생각할 수 있으니까. 이처럼 PM은 먼저 (웹이든 앱이든) 하나의 서비스가 '기획' - '릴리즈' - '운영' 각 단계에 필요한 개발 지식을 갖는 게 필요하다. 그리고 나면 (=기본적인 소양이 갖춰지면) 자신의 서비스에서 더 심도 있게 알아야 할 내용을 스스로 이해하고 더 공부할 수 있을 것 같다.
아래 질문 리스트는 첫 번째 (기본 소양 갖추기)에 해당하는 질문에 맞는 것 같다. 이에 맞는 정도의 답변을 작성할 것이다.
1. PM이 알아야 할 지식은 ‘프로그래밍 언어'가 아닙니다.
위에 작성한 내용의 연장선이라고 생각한다. 프로그래밍 언어를 안다는 말은 직접 개발을 하겠다는 말이다. 프로그래밍 언어 말고 기능을 추가할 때 Frontend / Backend는 '어떤' 일을 '왜' 하는지, iOS/aOS 개발자는 어떤 차이가 있는지 등을 알아야 한다. 그래야 이슈가 발생했을 때 원인 파악을 함께 할 수 있고, 해결책 또한 함께 생각할 수 있다.
가령, 최근에 릴리즈한 앱에서 발생했던 이슈이다. QA를 마치고 릴리즈를 마친 앱에서 기존 사용자가 로그인되지 않는 버그가 발생했다. aOS는 구글 측 이슈로 릴리즈가 되지 않았고, iOS에서만 릴리즈가 되었다. 처음 2건의 CS가 들어왔을 땐 별 사용자 실수를 생각했지만, 다시 동일한 CS가 들어왔을 땐 문제가 있음을 깨달았다. 내가 사용하는 계정으로는 로그인이 잘 되는 것을 확인했다. 그리고 앱 내 특정 기능을 사용해보고 문제의 원인을 깨달았다. "아 릴리즈 된 앱이 운영 서버가 아니라 테스트 서버를 바라보고 있구나." 그리고 바로 앱 개발자에게 연락을 해서 버그 수정 후 다시 릴리즈를 했다.
위 사례를 보면 난 프런트의 이슈인가, 서버의 이슈인가를 판단했고 그 이슈를 해결할 사람이 누군지 정도만 알았다. 그리고 그 일을 담당하는 사람에게 바로 리포팅을 해서 다른 팀원을 괴롭히지 않았고, 문제 해결을 하는데 불필요한 시간을 소비하지 않았다. 위 사례에서 프로그래밍 언어는 하나도 쓰이지 않았다. 그저 발생한 이슈의 원인과 담당자만 알면 되었다. 이를 위해서는 Product의 개발적 구조와 팀원의 업무 파악과 같은 거시적인 분야의 지식이 필요하다.
2. 프로그래밍 언어 / Operating System
Q. 프로그래밍 언어는 왜 이렇게 많을까? C, JAVA, JS, Python…
목적이 다르기 때문이다. iOS에서는 Swift를, aOS에서는 Java를 이용한다.(java는 서버에서도 사용된다.) Ruby는 웹 개발에 많이 사용된다. 프로그래밍 언어를 검색하면 위키피디아에는 20가지의 언어가 나온다. 각 언어는 그들만의 특장점이 있다. 가장 많이들 얘기하는 C를 보면, C로 짠 코드는 속도가 빠르고 효율적이다. 그래서 생산성보다 속도가 중요한 분야에서 많이 사용된다. 단점은 디버깅이 어렵다는 것이다. 이에 반해 Java는 확장성이 높습니다. 그리고 유지보수가 편하다는 장점이 있다. 단점은 C보다 상대적으로 느리다. 이에 웹사이트나 운영체제 상관없이 실행되는 응용 software나 Android app에 사용이 된다.
결론은 저마다 장/단점이 다르고, 그것들을 보완하기 위해 계속 새로운 언어가 나왔다. 그리고 지금의 개발자들은 용도에 따라 최적의 효율과 성과를 내기 위해 언어를 선택하여 사용한다. 프로그램 개발이라는 목적은 동일하지만, 어떤 프로그램을 만들 것인가? 가 다르기 때문이다. 이 세상 모든 것에 딱 맞아 통용되어 사용되는 것 없죠?
실생활에서 예를 들면, 숟가락과 삽의 목적은 무언가를 떠서 들어 올리는 용도이다. 다만, 무언가를 들어 올린 것인가가 다르다. 티스푼은 찻잎을 떠서 찻잔에 넣을 것이고, 식사용 숟가락은 밥과 국을 그리고 삽은 흙이나 모래등을 떠서 올린다. 기존에 존재했던 것의 새로운 니즈가 추가되고, 거기에 맞게 새로운 숟가락, 삽들이 나온 거죠.
프로그래밍 언어 역시 마찬가지라고 생각한다. 기존에 있던 언어의 단점을 보안하기 위해서 새로운 언어가 나온 것이고, 그 단점은 새로운 요구사항에 의해 나온 것이다. 그리고 지금의 우리들은 각 언어의 용도(장/단점)를 파악하고 우리가 만드려고 하는 것에 가장 잘 맞는 언어를 선택하여 개발을 한다.
Q. 컴퓨터 조립해보셨나요? 컴퓨터는 무엇으로 구성되어 있나요?
컴퓨터를 조립해본 적은 없다. 다만 1학년 때 컴퓨터 구성요소를 교양 시간에 시험을 봤던 기억이 어렴풋이 난다.
컴퓨터는 하드웨어와 소프트웨어로 이루어집니다. 하드웨어는 RAM, CPU와 같은 부품이고 소프트웨어는 그 부품들을 작동시키기 위한 눈에 보에 보이지 않는 요소입니다. 그리고 컴퓨터의 구성 요소는 5가지이다.
- 입력장치
: 키보드, 마우스와 같이 컴퓨터에 무언가를 입력할 수 있는 장치. 이 글 역시 키보드라는 입력장치로 작성이 되고 있고 입력받은 컴퓨터는 이제 데이터 처리하고 결과를 저장하게 된다.
- 출력장치
: 모니터나 스피커같이 사람이 입력한 데이터가 제대로 처리되었는지, 보여주는 장치이다.
- 중앙처리장치 CPU
: 입력받은 데이터를 읽고 처리하는 역할을 한다. 흔히 사람의 뇌와 같은 역할을 한다고 비유한다.
- 주기억장치
: 주기억장치는 입력받은 데이터를 일시적으로 혹은 영구적으로 저장하는 장치이다. 사람으로 예를 들면, 수학 문제를 풀 때 머리와 노트 2가지를 사용할 때, 머리에 속한다. 간단한 암산 결과를 기억하는 거죠.
- 보조기억장치
: 위 예시로 계속하자면, 노트가 여기에 속한다다. 문제 풀이 과정을 기록하게 되죠. 뇌에 비해 많은걸 기록해둘 수 있다. 다만, 나중에 다시 찾아서 꺼내보기가 힘들다. 이를 컴퓨터에서는 접근 시간이 느리다고 얘기한다.
추가로,
위 구성요소 간 데이터가 전달이 되어야 하는데 이 전달 경로를 시스템 버스(System bus)라고 한다.
Q. 왜 프로그래밍 언어는 계속 업데이트될까요?
이 질문은 생각해보지 않았던 내용이라, Quora와 Stackexchange에 등록된 글을 기반으로 이해했다.
프로그래밍 언어가 처음 나왔을 때의 요구사항 와 사용을 하면서 나온 피드백과 요구사항이 다르기 때문인 것 같다. 1990년대 C를 배운 사람은 함수를 호출할 때 매개변수가 맞는지 컴파일러가 확인해주지 않았다고 한다. 그렇기 때문에 개발자가 이를 봐야 했기 때문에 입문 단계의 사용자는 굉장히 힘들어했다고 한다. 이런 예시를 보았을 때, 결국 개발자가 좀 더 편하게 개발을 할 수 있게 프로그래밍 언어 역시 유지 보수된다고 생각한다. 프로그래밍 언어가 다양한 것과 같은 맥락인 것 같다.
3. 네트워크 / 클라이언트, 서버
Q. 웹은 어떻게 이루어져 있고 어떻게 동작할까?
일반 사용자는 Chrome이나 Safari와 같은 Broser 이용하여 접속을 한다. 쉽게 웹에 들어가기 위한 문을 연다고 생각을 하면 된다. 그리고 특정 홈페이지에 접속하기 위해서 우리는 주소를 입력한다. 예) coupang.com 그러면 우리는 해당 홈페이지 화면이 나오고 원하는 정보를 얻는다. 흔히 얘기하는 인터넷을 사용하는 과정이다.
좀 더 자세히 알아보자.
사용자가 접속하기 위해 사용한 컴퓨터는 Client라고 한다. 그리고 이 요청을 Server가 받아서 원하는 것을 제공한다. Client는 무언가를 Requests 요청하고, Server는 Responses 응답해준다. 우리가 새로운 검색어를 치거나, 새로운 컨텐츠를 보기 위해 클릭하는 모든 과정이 server에 Requests를 날린다고 생각하면 된다. 그리고 결과가 보인다는 건 Responses를 받았다고 생각하면 된다.
그러면 요청한 자료를 서버는 어떻게 응답해줄까?
먼저, Web Server가 있다. Web brower에서 온 요청을 받고 응답해주는 역할을 한다. 요청받은 내용을 혼자서 바로 처리하는 게 아니라, 필요한 페이지의 로직이나 Database 연동을 위해 Web application server에 처리를 요청하는 역할이다. Application server는 얘기한 대로 로직이나 Database의 연동을 담당한다. 그리고 필요한 정보(데이터) Database에 저장되어있다. 쉽게 보면 이런 형식이다.
출처 : 한국데이터산업진흥원쉬운 예로 들어보면, 큰 도서관에 갔다고 생각해보자. 가서 우린 사서에게 어떤 책을 요청(Request)한다. 그럼 사서(Web server)는 책 보관소에 있는 직원(Web application server)에게 해당 책을 요청하고, 그 직원은 보관소(Database)에 가서 그 책을 가져와 사서에게 주고 사서는 우리에게 해당 책을 준다.(Response)
그 외,
- 우리가 주소창에 쓰는 주소는 사실 변환된 값이다. google.com 을 치면 구글 메인화면이 나온다. 저 google.com은 domain(domain name)이다. 실제 주소는 216.58.193.78과 같은 형태이다. 이를 IP(internet protocol)라고 부른다.
- 그리고 이 domain과 IP는 DNS(domain name system)에서 매핑한다. 사람이 읽을 수 있는 도메인 이름을 기계가 이해할 수 있게 IP 주소로 변환해준다.
- 네트워크 7 계층 (OSI 7 layer model)은 통신이 일어나는 과정을 단계별로 알 수 있습니다. 또한, 이를 바탕으로 개발이 되어야 서로 알아들을 수 있게 통신이 가능합니다.
- Http 통신은 Hyper Text Transfer Protocol입니다. 말 그대로 Hyper text를 전송하는 규약을 의미합니다. 위에서 얘기한 데이터를 Request&Response을 반복하는데, 이 과정을 어떻게 하는가에 대한 방식이라고 이해하면 된다.
Q. 반응형 코딩? 그게 뭐예요?
반응형으로 코딩한다는 것은 말 그대로.. 사용자 환경에 즉각적으로 반응하면서 최적화된 화면을 보여줄 수 있게 개발하는 것을 의미한다.
왜 이걸 할까요?
여러 가지 디바이스로 사용하기 때문이죠. 그 환경에 맞춰 최적의 화면을 보여주기 위함이다. 이를 대응하기 위해 반응형웹과 모바일웹을 구축하는데 둘은 엄연히 다르다. 모바일웹은 말 그대로 새로운 웹사이트를 구축하는 것을 의미한다. 좀 더 모바일에 최적화된 상태를 제공할 수 있지만 새롭게 만들어야 하기 때문에 시간과 노력이 든다. 이에 반해, 반응형웹은 디바이스에 맞춰 알아서 사이트의 UI가 변경된다. 하지만 기존 웹페이지의 스타일에서는 크게 달라지지 않는다.
디바이스에 맞는 화면을 보여준다는 목적은 동일하다. 어떤 것을 선택할지는 각 서비스의 방식에 따라서 달라진다.
그 외,
- 반응형을 구현할 때는 고정된 값이 아니라, 비율이 적용되는 단위를 사용한다.
- 디바이스에 따른 스타일 조정을 위해서는 CSS media query를 이용한다. 자바스크립트 만으로도 가능하지만 성능 이슈 등의 문제가 있다.
Q. 아니 앱에 있는 이 부분 얘기하는데, 왜 자꾸 웹 개발자한테 가라는 거죠?
위 질문을 봤을 때 어떤 걸 얘기하는 걸까? 생각이 들었다. 앱에서 보이는 컨텐츠가 문제일 수 있고, 서버의 로직에 영향을 받는 앱 내 기능일 수도 있기 때문이다.
가령, Admin page를 이용해서 앱 내 게시판에 글을 올릴 수 있다고 가정하자. 이때, 글의 URL이 깨졌다면? 앱 이슈라면 모든 글에서 관련된 버그가 있을 것이고, Admin page에서 문제가 있다면 작성을 하거나 등록하는 과정에서 버그가 있을 수 있다. 혹은 서버 이슈일 수도 있다.
정리하자면, 눈에 보인다고 해서 모든 게 앱의 문제가 아닐 수 있다. 필요한 데이터를 서버에서 받아오는지 앱이 가지고 있는지 구조를 알아야 한다. (맨 처음에 비유를 들었던 뷔페의 운영자처럼) 그래야 질문이 있을 때 엄한 사람을 괴롭히지 않고 필요한 정보를 얻을 수 있다.
4. API & JSON
Q. POST는 뭐고, GET은 뭐죠?
앞서 얘기한 웹의 구조와 동작 방식 하단에 http 통신 방식을 살짝 알아봤다. 웹상의 client와 server는 request와 response를 주고받는다. 이때 사용되는 것 중 하나가 Get과 Post이다.
Get은 서버로부터 정보를 조회하기 위해 설계된 방식이고, Post는 서버에 입력 데이터를 전송하기 위해 설계된 방식이다. 쉬운 예로 Get은 조회, Post는 수정이라고 표현을 한다. (단순히 빠른 이해를 위한 설명인 것 같다.)
그 외,
- Get을 쓰면 개인정보가 URL에 나와서 보안 이슈가 있을 수 있다. Post는 이 정보를 Body에 가지고 있다. 하지만 둘 다 보안에 취약한 것은 마찬가지다.
- Post를 쉽게 수정이라고 표현했지만, 생성에 맞는 방식(메소드)이다. 수정은 Put 또는 Patch, 삭제는 Delete 등 더 용도에 맞는 방식을 쓰는 게 맞다.
Q. 요청과 응답을 주고받을 때의 형식?
본의 아니게 위에서 살짝 언급이 된 것 같다. Client와 Server는 request와 response를 주고받는다. 이때 이 방식을 HTTP (Hyper Text Transfer Protocol)라고 한다. 방식이라 함은 통신간에 어떤 내용이 어떻게 작성되어야 함을 얘기한다.
Request 형식은 다음 4가지로 나뉜다.
- Request Line : 데이터 처리 방식(Http Method)과 기본 페이지, 프로토콜 버전이 포함된다.
- Request Headers : Host, User-Agent, Accept, Connection, Content-type, Content-Length가 포함된다.
User-Agent, Cookie, Referer, Host 정보가 포함된다.
- Empty line : 요청에 대한 meta 정보가 전송되었음을 알린다.
- Request Message Body : 보통 비어있지만, 특정 데이터를 담아서 서버에 보낼 수 있다.(Method에 따라 다르다.)
Response 형식 역시 Request와 유사하다.
- Status Line : 응답 상태와 응답 상태 설명이 포함된다.
- Response Headers : Request와 동일하다.
- Empty line : Request와 동일하다.
- Response Message Body : 실제 응답하는 데이터를 나타낸다.
바로 위에서 봤던 Get과 Post가 여기서 말하는 Method이다. 즉 형식은 어떤 내용을 어떻게 주고받을지에 대한 약속이라고 생각하면 된다.
Q. API 문서는 왜 있죠?
개발자와 대화를 할 때 진짜 많이 나오는 단어 중 하나가 API이다. 그만큼 많이 쓰인다고 생각하면 된다.
먼저 짧게 API를 알아보자. API( Application Programing Interface)는 어떤 응용프로그램에서 데이터를 주고받기 위한 방법을 얘기한다. 우리가 익숙한 단어 중 하나가 UI, User Interface이다. 여기서도 동일한 Interface가 나온다. 상호작용을 위한 방법을 의미한다. API는 프로그램들이 서로 잘 상호작용을 할 수 있게 도와주는 매개체라고 생각하면 된다.
다만, API는 서버 개발자가 만들어서 Front 단 개발자에게 전달한다. 그리고 API는 한두 개만 있는 것이 아니기 때문에 별도의 관리가 필요하다. 이 때문에 API 문서가 존재한다. 그래야 다른 개발자가 API를 이용하여 Product을 만들 수 있지 않겠는가.
출처 : city7310위 예시 이미지처럼 칼럼을 채워서 다른 개발자가 원하는 것을 편하게 사용할 수 있게 관리를 해줘야 한다. 문서 관리는 굉장히 귀찮을 수 있다. 이에, Gitbook 같은 서비스가 나온 것 같다.
5. 데이터베이스와 이미지 처리
Q. 쇼핑몰을 생각해봅시다. 여기서 데이터는 대체 뭘까요?
질문의 의도가 정확히 무엇인지 모르겠지만, 지금까지의 내용을 생각하며 답변을 적어보았다. 먼저 쿠팡의 메인 페이지에서 무엇이 데이터일까? 일단 눈에 보이는 모든 것이 데이터이다. 상품의 이름, 이미지가 대표적인 예이다. 회원가입/로그인한 회원 정보 역시 데이터이다.
쿠팡그리고, 회원/비회원의 쇼핑몰에서의 행동 역시 데이터이다. 오른쪽에 있는 "찾던 상품이 아니신가요?"는 내가 클릭했던 제품을 다시 보여준다. 이게 가능한 이유는 내가 페이지에서 봤던 것이 데이터로 남아있기 때문이다.
Q. “클라(클라이언트)가 들고 있어요.” “클라에 저장돼요.” 이게 무슨 말?
먼저 클라는 Client를 줄여 말하는 거다. 눈에 보이는 앱과 웹이라고 생각하면 된다. 즉, 어떤 데이터가 서버를 거쳐 Database에 저장되는 것이 아니라 웹브라우저나 앱(스마트폰 기기)에 저장되는 것을 의미한다. 서버와의 통신이 필요 없이 바로 해당 데이터에 접근하여 사용할 수 있다.
Q. “이미지 좀 바꾸려는데, 자꾸 자기한테 말하면 안 된대요.” 이게 무슨 말?
해당 이미지를 클라에서 변경하는 것이 아니라 서버에서 불러오는 상황일 것이다. 클라에서 이미지를 가지고 있으면 편하지만, 그렇게 되면 서비스가 무거워질 수 있다. 이 때문에 Database에 있는 데이터를 받아와서 이미지 등을 보여준다. 이때는 서버 개발자에게 얘기해서 교체하고자 하는 이미지 파일을 주거나 URL을 변경하는 등의 방식을 취해야 한다.
6. 프레임워크와 라이브러리
Q. 코코아요? 그거 먹는 거 아니에요? 그리고 도서관은 왜 갑자기?
이번 질문에서는 3가지를 알아보자. 프레임워크, 라이브러리 그리고 코코아
가장 많이 본 이미지이다.
먼저 쉽게 적어보면 프레임워크는 반조립된 형태의 건축 Kit이라면, 라이브러리는 특정 건축 작업을 위한 (예, 배선작업, 도배 등) Kit라고 생각하면 될 것 같습니다. 둘 다 집을 짓는데 도움이 되는 Tool이지만, 프레임워크는 큰 뼈대가 잡혀있지만 라이브러리는 뼈대는 없이 특화된 작업을 수행하는데 이용이 된다.
하지만, 위 예시는 많은 오해를 불러올 수 있는 것 같다. 두 개념에서 가장 큰 차이는 애플리케이션의 흐름을 누가 가지고 있느냐 인 것 같다. 프레임워크는 이미 흐름이 잡혀있고, 그 안에서 필요한 것은 사용자가 코드를 채워 넣는다. 반면 라이브러리는 사용자가 큰 흐름을 만들고 거기에 필요한 라이브러리를 가져다 쓰는 방식이다. 그렇게 때문에 먼저 만들고자 하는 애플리케이션의 성격을 생각해야 한다. 그리고 사용자는 이에 맞는 프레임워크와 라이브러리를 찾아서 적절하게 사용할 수 있어야 한다.
코코아란?
먼저 코코아는 프레임워크다. iOS를 개발할 때 이 코코아 터치 프레임워크를 이용한다고 한다. 아이폰이나 아이패드, 애플 워치 등에서 실행되는 애플리케이션의 UI를 제공하는 프레임워크이다. apple 앱을 릴리스할 때도 굉장한 엄격한 자신들만의 규칙을 따라줄 것을 요구하던데, 개발할 때 역시 마찬가지인 것 같다.
7. 협업, 소스 관리, 디자인
Q. Commit? Merge? 이게 뭐예요?
Commit과 Merge 개발자가 추가한 기능을 관리할 때 사용되는 용어이다. 이를 얘기하기 전에 형상 관리와 Github에 대해 짧게 알아보자.
형상관리 혹은 소프트웨어 구성 관리 (Software Configuration Management)
소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것을 얘기한다. 애플리케이션의 기능 추가 및 개선, 버그 수정과 같은 변화가 발생하는 시점을 관리하는 것을 의미한다. 단순히 소스코드뿐만 아니라 개발 환경, 빌드 구조 등 전반적인 환경에 대한 내역과 관리 체계를 얘기한다. 버전 관리 시스템은 소스 코드의 변화를 시간에 따라 기록했다가, 나중에 특정 시점의 버전을 다시 꺼내올 수 있다.
이러한 관리를 하는 이유
히스토리 관리와 코드가 뒤섞이는 문제 등을 예방할 수 있다. 가령, 1.1.0 버전에 추가된 기능이 있다고 하자. 당시에는 버그를 발견하지 못했지만, 1.6.0 정도가 되어서 문제를 발견했다. 이때 해당 기능이 추가되었던 시점을 모른다면 정확한 파악이 어려울 것이다. 해당 기능이 추가된 시점으로 돌아가서 디버깅을 하며 원인을 정확하게 파악할 수 있다.
둘째, 개발자가 많을 때 각자의 작성한 코드를 하나로 병합해야 한다. 이때 기존 코드와 충돌이 있을 수 있고, 서로의 코드를 안정하게 병합할 수 있다. (Google sheet나 slide가 나오기 전 과제를 합칠 때면 ppt나 excel에서 누락되거나 중복되는 경우가 있지 않았던가?)
형상관리 툴
나도 사실 관리 툴이 다양한 것은 이번에 정확히 알았다. 대부분 Git을 썼기 때문에 크게 호기심을 갖진 않았었다. 다름과 같은 타입으로 나뉘고, 주로 Git과 SVN을 많이 쓴다고 한다.
- Client/Server 타입 : Subversion(SVN), CVS, Perforce, ClearCase, TFS
- 분산 저장소 타입 : Git, Mercurial, Bitkeeper, SVK, Darcs
- Folder 공유 타입 : RCS, SCCS
Git의 commit과 merge
commit : Git에서 하나의 논리적인 작업 단위를 commit(커밋)이라고 하며, 새로운 기능을 추가로 개발하면. commit을 남기게 된다.
merge : Git의 merge 기능을 이용하면 변경 이전의 소스 코드와 변경된 소스 코드의 병합이 가능하다.
그 외,
자유로운 이동 : Git을 사용하면 특정 commit 으로의 이동이 자유롭다.
이슈 파악 용이 : 운영 중인 애플리케이션에서 이슈가 발생하였을 때, 특정 시점으로 전환하여 이슈의 원인을 파악하는 과정이 수월해진다
충돌 체크 : Git은 코드 병합 시 기존 코드와 충돌 여부를 체크해 주기 때문에, 하나의 기능을 여러 개발자가 개발하는 경우에 안전하게 각자의 결과물을 병합할 수 있습니다.
Fork를 이용한 저장소 복제 : 중앙 원격 저장소(Upstream)를 개발자가 Fork(포크) 하여 개별 저장소로 관리 가능하
Q. 둘이 싸웠나?? 디자이너와 개발자가 부딪히는 이유.
이건 두 사람의 말을 모두 들어봐야 하지 않나.. 생각이 들었다. 나도 마케터로 일을 했을 때 디자이너랑 많이 싸웠던 기억이 난다.
두 사람이 싸운 이유는 서로의 관점이 다르기 때문이다. 디자이너는 사용자를 생각하면서 디자인을 한다. 각 기능과 위치에 따라서 다른 형태의 디자인 (예, 팝업이나 인터렉션)이 나올 수 있다. 개발자는 적은 리소스로 최대한 효율적으로 개발을 하려고 한다. 디자이너의 작업물은 개발자 입장에선 많은 공수를 가져온다고 생각할 수 있다. 이런 경우 디자인 시스템을 이용하면 마찰이 덜 하다고 하는데, 아예 없진 않을 것 같다.
내가 좀 편하자고 서로 다른 의견을 낸다기보단, 각자의 업무에 충실한 사고방식을 가지고 업무를 하기 때문에 마찰이 생기는 것 같다. 이런 마찰은 PM과 다른 팀원 간에도 충분히 생길 수 있다. 그러기 때문에 우리는 why를 얘기하며 서로의 오해를 줄이는 과정을 반복해야 한다.
작성을 하면서 처음에 가졌던 생각에 조금 어긋난 부분도 있는 것 같다. 알고 있던 것을 심화해서 공부했다고 생각하긴 했다. 위 내용을 정리하면서 개발자 친구와 대화를 가졌다. 자기네 회사에도 기획자나 PM인데 위 항목을 모르는 사람이 많다고 했다. (규모가 큰 IT회사임에도 그렇다고 한다.) 그리고, 확실히 PM업무를 할 때 솔직히 디테일한 개발 지식을 쓰진 않지만 많이 알면 알 수록 좋다고 한다. PM은 리더가 아니지만 개발자들은 그 사람의 개발적 지식을 가지고 신뢰감이 생기는 경우가 많다고 얘기해줬다. 모순된 점인걸 알면서도 어쩔 수 없는 것 같다.
지금 부트캠프의 목적은 쿠팡이라는 국내 최대의 E-commerce 서비스이다. 나도 친구가 얘기한 상황에 직면할 수 있으니, 앞으로 관련하여서 필요한 정보를 좀 더 찾아보고 지식을 쌓아가야겠다.
위 글을 정리하면서 참고한 글이 많아서 별도 페이지를 만들어서 정리해두었습니다. 필요하신 분은 참조하시면 됩니다. 참조
