brunch

You can make anything
by writing

C.S.Lewis

by Vintage appMaker Nov 15. 2024

개발자 대화의 핵심

생존형 개발자의 생각 #114

1. 개발자는 왜 그럴까?


많은 사람들이 개발자와 대화하기 힘들다고 한다.


여러가지 이유가 있지만 핵심은 “사고방식”의 차이이다. 기획자, 디자이너, PM 모두 업(Job or Role) 가져야 할 “사고방식”의 차이점이 존재한다. 문제는 왠만하면 타직군의 사고방식을 공감하는 것이 어렵지 않은데 유독 개발자만은 “알 수 없는 사고방식”을 가지고 있다. 이유는 “사고방식” 순서가 “귀납적”이기 때문이다 . “우린 이걸 할 수 있어!”라는 긍정의 마인드(요구)로 시작하는 기획자와 달리 데이터 근거로 기획자의 요구(긍정 마인드)가 구현가능한 것인지 방법을 찾는 것이 개발자이다. 대부분 기획자들은 구현 가능성보다 욕망해소를 목표로 기획한다. 반면 개발자는 욕망이 아닌 문제해소의 방법을 찾는다.


그런 점에서 개발자는
(1) “요구사항 논리적 문제점”과 (2) “요구사항을 수행했을 때, 버그 또는 오류”에 집중하게 된다.


전문개발자) 이게 왜 한 번에 되는거야? - 위험한 상황인데?
개발자는 문제를 정의하고 문제를 해소하기 위한 방법을 찾는 사람이다. 모든 방법은 오류가 존재한다.



2. 개발자에게 오류는 과정이자 학습일 뿐


많은 기획자 또는 사업자들이 개발자의 “안되요~” 또는 “문제가 있습니다”에 대해 일을 하지 않으려는 것인가?라는 생각을 한다. 그러나 개발자들은 반대로 “문제점을 제기했음에도 문제를 이해하지 못하는 상황”에 “일을 하겠다는 것이야? 말겠다는 것이야?”라며 불만을 재기한다. 이유는 “문제(또는 오류)는 업무의 과정이고 그것을 극복하는 것이 우리(프로젝트 구성원)의 일”이기 때문이다. 여기서 오류를 극복하고자 노력하는 쪽이 “개발자”에게 집중되면 불쾌하게 되는 것이다.  대부분 “잘못된 요구사항과 판단”에서 비롯되는 경우가 적지 않기 때문이다.


초기 gpt 엔진은 개발자들이 강화학습시켰기에 개발자에 대한 내용은  정확도가 높다.


결론적으로 말해서 개발자가   


안되요

요구사항에 문제있어요


라는 시그널을 보인다면 “문제점을 같이 분석”해야 한다. 그리고 정량적인 TODO 리스트를 산출해야 한다. 여기서 ‘난 모르니 알아서 해줘요”라고 하는 순간. 프로젝트는 위험하게 된다. “알아서, 대충, 멋지게, 빠르게, 확실하게…”등등의 모호한 단어가 난무하는 사람일 수록 개발자들은 그 사람을 “무능”하다고 평가하게 된다.


3. 개발자와 소통이 중요한 이유?


일단  개발자와 대화를 위해서는 "컴퓨팅 사고력에 대한 이해"가 필요하다.


“Maker(생산자)”들은 정량적인 사고로 요구사항을 분석한다. 그러므로 구체화되지 않은 요구사항과 욕망에 대해 꾸준한 질문과 검증을 하게 된다. 결과적으로 기획자 또는 사업자 입장에서 원하는 “생산품”을 얻고 싶다면 정량적인 사고로 “생산물을 만드는 사람”들에 대한 대화법을 터득해야 한다. 정성적인 욕망 또는 ”돈” 또는 “사람에 대한 믿음”만으로 결과물을 얻을 수 없다.


그런 점에서 개발자는 왜 안된다?는 말과 질문이 많은 지 모르겠다라고 고민이 된다면 “컴퓨팅 사고”에 대한 공부를 권한다. 특히 생성 AI 시대에 기획자는 반드시 “컴퓨팅 사고력”이 탑재되어 있어야 한다.


왜냐하면
“개발자와 기획자”의 간극이 사라지고 있다.
수년 전부터 기업에서  
“데이터 기반의 기획자(SQL, Python)”를 요구하고 있다.


이는 “기획자(IT 사업자)가 개발자의 영역”을 어느정도 공유하고 있다는 반증이기도 하다.


4. 정리   


개발자의 “안되요”, “문제있어요”는 일하는 과정이다

개발자는 오류를 염두하고 방법을 찾는다.

오류는 개발자만 해결할 수 없다. 팀 전체(대표포함)가 고민해야 한다.

현업의 변명) 개발자는 개인감정없다.  
일하기 바쁘다. 상대에 대한 관심없다.
코드와 문제에 관심있다.


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari