brunch

You can make anything
by writing

C.S.Lewis

by 김명희 Apr 08. 2021

오늘도 개발자가 안 된다고 말했다

개발자가 바라보는 IT세상

리디북스 메인 신간에 '오들도 개발자가 안 된다고 말했다'라는 제목의 책이 눈에 띈다. 읽어보지도 않았고 책 홍보는 더더욱 아니다. 그저 제목만으로도 현직 개발자를 뜨끔하게 만들어서 관련 주제로 글을 써보려고 한다. 왜 개발자들은 그토록 안된다고만 할까?

1. 시간이 모자라

보통 개발은 다음과 같이 3단계 프로세스로 진행된다.

업무 분석 -> 개발 -> 테스트

이 정도가 개발의 한 사이클이라고 보면 된다. 여기에 테스트 후 수정 개발이 추가될 수도 있다. 비개발자들은 개발 시간만 생각하는데 개발자들은 3단계 프로세스를 염두에 두고 개발 시간을 산정한다. 순수 개발 시간만 생각하고 업무를 요청하면 요청자가 원하는 시간과 개발자가 원하는 시간이 차이가 날 수 있다. 그러면 개발자는 시간이 모자라다고 느끼고 안된다고 하는 것이다.

해결책 : 3단계 프로세스를 염두에 두고 시간 산정을 해서 요청을 하면 좋다.

2. 선 No, 후 Yes

업무 요청 내용이 아리까리한 경우가 있다. 될 것도 같은데 안될 것도 같은 업무. 개발자 머릿속에서 시뮬레이션을 돌려보지만 명확하지 않은 경우다. 막상 될 거 같아서 Yes라고 했다가 실제 개발해보면 안 되는 경우도 많다. 그러니 일단 No라고 하는 거다.

개발자라는 기술자들은 자존심이 세서 앞에선 안된다고 해도 뒤에선 될 수 있는 방법을 찾는다. 그게 정상이다. 기술이 부족해서 구현할 수 없는 건 참을 수 없는 일이다. 내 기술이 부족해서 안 되는 것이라는 말은 할 수 없으니 앞에서는 No라고 하는 것이고.

해결책 : 업무 요청을 할 때 기술적으로 애매해하는 것 같으면 일단 확인해 보고 알려달라고 하자. 개발자에게 시간을 주면 대부분 방법을 찾아와 Yes라고 해 줄 것이다.

3. Big size 업무

요청 내용이 너무 비대할 경우 개발자는 안된다고 한다. 손대야 할 곳이 많거나, 새로운 기술을 도입해야 하거나, 학습을 해서 개발해야 하거나, 기존 소스를 많이 수정해야 한다면 개발자는 업무 범위가 너무 커진다고 생각해서 안된다고 한다.

해결책 : 비개발자가 세부적인 개발 범위까지 알 수는 없다. 대화를 통해 타협점을 찾자.

4. 무조건 No

이런 사람들이 있다. 내 주변에도 있다. 뭔 요청을 하면 무조건 안된다고 한다. 개발자로서 직장인으로서 아주 나쁜 유형이다. 인과 관계를 명확히 해야 하는데 개발하는 사람이 나빠서가 아니라 나쁜 사람이 개발을 하는 것뿐이다. 이런 사람은 개발 말고 다른 일을 해도 나쁜 사람일 확률이 높다.

해결책 : 상급자와 연계해 업무 요청을 하자. 이런 사람은 강제로 시키는 수밖에 없다.

5. Not enough 기술

개발자의 학습 여부와 경험에 따라 기술 능력도 천차만별이다. 또 그만큼 기술이 빠르게 생겨나고 발전하는 업종이기도 하다. 업무 요청을 받았는데 기술이나 경험이 없어서 어떻게 해야 할지 머릿속에 전혀 그려지지 않는 경우가 있다. 그러면 안된다는 말이 나온다. 보통 주니어 개발자에게 자주 보이는 현상이다.

마치 이런 것과 같다. 파스타 요리를 요청했는데 김치찌개라도 끓여본 사람은 어떻게 해야 할지 감이라도 잡는데 요리를 한 번도 안 해본 사람은 갑갑한 거다.

해결책 : 업무 요청을 할 때 개발자의 상급자를 포함해서 요청하자. 담당자가 안된다고 한 일도 상급 개발자가 길을 알려줄 수 있다.

6. 이 산이 아닌가 봐

최초 요청 사항에서 중간에 요건이 바뀌는 경우가 있다. 이럴 경우 나 역시 안된다고 말한다. 업무 분석이 잘못됐거나 클라이언트의 요구 사항이 바뀌었거나 할 수 있다. 인간이 하는 일이니 완벽할 수 없고 바뀌는 일도 있을 수 있다. 그러나 개발자는 중간에 요건이 바뀌면 업무 분석부터 다시 시작해야 한다. 새로 만드는 것보다 중간에 수정하는 게 더 어려울 수도 있다. 바뀐 요건 때문에 처음부터 개발해야 하는 경우도 생긴다. 요건은 바뀌었는데 완료 시간은 똑같다면 개발자는 백 프로 안된다고 말한다.

해결책 : 되도록 요건은 바꾸지 않되 부득이하게 바뀐다면 그만큼의 시간을 더 확보해 주자.

7. 아름다워서 혹은 난해해서

요청 사항에 맞춰 소스 코드에 손을 대야 하는데 소스 코드가 너무 완벽해서 손을 대기 싫거나 코드가 너무 개판이라서 손을 대기 싫거나, 두 가지 케이스의 경우 안된다고 말한다. 보통은 후자의 경우가 대부분이다. 남이 짜 놓은 소스, 남이 짰는데 개판인 소스, 내가 짰는데 개판인 소스, 어쨌건 개판인 소스는 정말 손대기 싫다. 소스를 수정하려면 분석을 먼저 해야 하는데 분석도 어렵고 손대서 제대로 기능하게 만들기도 어렵다. 버그만 더 생길 뿐이다.

해결책 : 그저 간곡히 부탁할 수밖에... 그런 소스 수정하는 개발자도 너무너무 괴롭다.

8. 길들이기

요청자는 개발자에게 일을 시키는 모양새가 된다. 요청자가 갑, 개발자가 을이 되는 모양새인데 개발자가 일을 해줘야 성립이 되니 갑을관계가 다시 역전된다. 개발자 입장에선 해달라는 거 계속해주면 요청사항이 끊이지 않을 테니 적당히 해주고 적당히 안된다고 하고 싶은 거다.

해결책 : 같은 회사 사람들끼리 너무 그러지 맙시다. 서로서로 양보하고 배려하는 마음이 중요.

9. 언어가 달라서

컴퓨터 - 개발자 - 요청자

간략하게 이런 관계가 성립한다. 개발자는 중간에 위치해서 컴퓨터와 요청자를 연결해주는 통역자쯤이라고 볼 수 있다. 그런데 대부분 개발자는 말을 잘 못한다. (내가 잘 못해서 그렇게 느끼는 걸 수도) 왜냐하면 개발자는 인간보다 컴퓨터와 프로그래밍 언어로 대화하는 시간이 훨씬 많기 때문이다. 개발자에게는 입으로 하는 언어보다 프로그래밍으로 하는 언어가 편하고 익숙하다. 그러니 요청자의 요청 내용을 제대로 이해 못해서 안된다고 하는 경우도 있고 에둘러 된다고 말한 건데 요청자가 듣기엔 안된다는 말로 느끼는 경우도 있다.

해결책 : 개발자와는 많은 대화가 필요하고 요청 건에 대해 된다, 안된다를 명확히 확답받아야 한다.

keyword