[책 리뷰 / 개발] 오늘도 개발자가 안 된다고 말했다 - 외않됀데?

출처 : Yes24

일전에 동아리 프로젝트를 진행하면서 디자이너님이 질문을 한 적이 있다.

"ㅇㅇ님 API 가 뭔가요??"
사실 이 때 적잖이 당황했다.

API를 어떤식으로 설명해야하지??

내 머릿속에서 API는 호출을 통해 서버에서 데이터를 가져오는 것이였는데, 이걸 개발을 잘 모르는 사람한테 설명하려고 하니 머리가 캄캄해졌다.

이럴 때 치트키, 위키백과를 사용했다.

위키백과 설명도 뭔가 직관적이지 않았다.

 

어떻게 하면 비전공자에게 개발지식을 잘 설명해줄 수 있을까 고민을 했다.

그러던 중 서점에서 재미있는 책을 발견했다.

바로 오늘 리뷰하는 책 "오늘도 개발자가 안 된다고 말했다" 이다.

책 표지의 개발자 표정에 이끌려 책을 열어보았다.

책의 내용을 언뜻 훑어보니, 현업에서 개발자와 협업을 하며 어려움을 겪었던 기획자와 디자이너가 비전공자도 이해하기 쉽게 개발지식을 설명해주는 책이다.

비전공자가 이해하기 일상적인 단어로 쉽게 풀어쓰려고 노력했다.

이 책을 읽고나면 나도 비전공자에게 쉽게 설명해줄 수 있지 않을까 생각했다.

 

 

 

 

 

무조건 Yes만 하는 개발자 VS 무조건 No만 하는 개발자

트와이스 VS 에이핑크 느낌

기획자나 디자이너가 물어보면 무조건 Yes라고 하는 개발자와 무조건 No라고 하는 개발자 둘 중에 어떤 개발자가 좋은 개발자일까??

 

정답은

.

.

.

.

.

둘 다 아니다.

 

우선 무조건 Yes만 하는 개발자의 경우 초보 개발자일 경우가 많다. (뜨끔)

아직 프로젝트의 전체적인 진행 상황을 잘 파악하고 있지 못한 경우가 많아, 요청사항이 현재 하고 있는 일에 어느정도 영향을 끼치는지 모르는 경우가 많다.

또 프로젝트의 전체적인 구조(아키텍쳐) 를 잘 파악하지 못하고 있는 경우가 있어, 요청사항이 프로젝트에 어떤 영향을 끼치는지 모르고 Yes를 한 경우일 수도 있다.

 

이 경우의 Yes는 "최종배포 단계에서의 사용 가능 여부"보다 "기능의 구현 가능 여부"에 대해서만 Yes라고 보는 것이 좋다. 

사실 모든 기능을 구현할 수 있다. 시간만 충분하다면!

아쉽지만 시간이 충분하지 않기때문에 항상 타협을 해야한다.

초보 개발자의 경우 이 부분이 미숙하기 때문에 무조건 Yes라고 할 확률이 높다고 한다.

 

이럴 경우 나중에 기한을 못 맞추는 경우가 발생할 수 있으니 Yes맨이 된다고 좋은 개발자는 아니다.

 

 

다음으로 무조건 No만 하는 개발자이다.

책에도 나오지만 비전공자들은 개발에 대해 잘 모르기 때문에 프로젝트의 구조나 안정성을 고려하지 않고 개발을 요청하는 경우가 있다.

이럴 경우 개발자의 입에서 대부분 No가 나온다.

쌓인 일이 많을 때 개발을 요청할 때도 대부분 No 가 나온다. (이건 모든 일이 마찬가지다)

 

 

그렇다면 프로젝트의 퀄리티와 안정성을 위해 No를 외치는 건데 뭐가 문제가 되는건가??

기획자와 디자이너가 요청을 안하게 된다.

"요청하면 무조건 No 일텐데 굳이 힘들게 요청을 해야돼?" 하는 생각이 들 것이다.

그리고 이것은 은연 중에 팀에 균열을 만들 것이다.

 

기획자, 디자이너, 개발자 하는 일은 다르지만 궁극적으로는 좋은 서비스를 만들기 위해 같이 달려나가는 하나의 팀이다.

이런 팀에서 서로가 눈치를 보고, 하고 싶은 말을 하지 못한다면 좋은 서비스는 나올 수 없을 것이다.

 

 

그렇다면 협업을 잘하는 개발자는 어떤 개발자일까??

대안을 제시하는 개발자이다.

 

"이 기능을 추가하면 안정성에 영향을 줘서 조금 힘들 것 같아요. 대신 이런 비슷한 기능을 사용하면 안정성도 챙기면서 어느정도 만족시킬 수 있을 것 같은데 어떠세요?"

 

"지금 이 디자인으로 수정하려면 기한까지 맞추기 어려울 것 같아요. 대신 중요한 이 부분만 수정하면 어떨까요?"

 

이런 식으로 대안을 제시해주는 누구나 같이 일하고 싶어하는 개발자이다.

그렇기 위해서는 뛰어난 문제해결 능력과, 비즈니를 파악하는 안목, 쉽게 소통하는 기술이 있어야 한다.

즉 개발 실력이 뛰어나고 사회생활을 많이 해본 개발자가 되면 된다.

 

마치 교과서 위주의 공부법 같은 느낌이다.

사실 개발이라는 것을 잘 생각해보면 코딩을 하는 것이지 다른 직업과 엄청 다를 것도 없다.

좋은 개발자는 좋은 사람이 되어야 한다는 것을 다시금 느낀다.

 

 

 

 

 

개발언어 사전

책을 읽고 느낀건 나만의 개발언어 사전이 필요하겠다는 것이였다.

책에서의 API 설명

앞서 API를 어떻게 설명할까 고민했는데 책에서 API에 대한 설명이 나와있었다.

근데 이것도 모듈화같은 단어들이 애매모호한 것 같아서 직관적으로 이해가 되지 않았다. 

구글링과 유튜브를 보면서 내 기준에서 가장 괜찮은 API 설명은 다음과 같다.

 

"한 프로그램에서 다른 프로그램으로 데이터를 주고받기 위한 방법"

 

가장 깔끔하고 이해하기 쉽게 API를 설명하는 것 같다.

 

프레임워크, 라이브러리, API, 프로토콜, HTTP/HTTPS 등 많이 접하고 사용하지만 막상 한 줄로 설명하려면 쉽지 않은 단어들이 많다는 것을 느낀다.

협업이나 면접을 위해서는 이런 개념을 확실히 알고 나만의 것으로 만들 필요를 느낀다.

 

 

 

후기

비개발자를 위한 책이라고는 하지만 책의 내용 절반이 기획자와 디자이너에 대한 일이다.

저자들이 실제 현업에서 일을 하고 있는 기획자와 디자이너다 보니 핵심사항에 대해 간단하고 쉽게 설명해준다.

책의 내용 자체를 가볍게 가져가려는 것이 느껴진다.

전체적인 프로젝트의 진행 흐름과 그 안에서 기획자, 디자이너, 개발자가 어떤 일을 하는지 쉽게 이해할 수 있는 책이다.

😁