brunch

매거진 카페에서 읽어도 재밌는 IT 지식

라이킷 83 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 고코더 Sep 29. 2023

[08] 화성에서 이민 온 개발자

너무 다른 개발자와 비개발자의 언어

화성에서 온 개발자, 금성에서 온 비개발자

화성에서 온 남자, 금성에서 온 여자

아주 오랜 옛날 하늘에는 용이 불을 뿜고 땅 위에는 공룡이 거대한 발자국을 남기며 사냥하던 그 시절 우주에는 두 개의 밝고 큰 행성이 떠 있었습니다. 하나는 금성 또 다른 하나는 화성이었습니다. 금성에는 비개발자가 살았습니다. 기획자와 디자이너는 매일 아침 브런치를 먹으며 하루를 시작했습니다. 그리고 사용자들은 세상을 바꿀 그런 생각들로 항상 아이디어가 넘쳐났습니다. 화성에는 개발자들이 살았습니다. 이들은 열정적이었습니다. 아침부터 저녁까지 컴퓨터와 끊임없이 대화를 했고, 언제나 바빴습니다. 그래도 행복했습니다. 그러던 어느 날 두 행성의 사람들은 우연히 서로의 존재를 발견합니다. 너무나 다른 매력을 가진 이들은 서로에게 끌렸고 지구라는 행성에 함께 이주하기로 합니다. 그렇게 두 종족의 불가사의한 동거가 시작되었습니다.

너무 다른 두 행성의 말들

다른 언어

'비개발자', '개발자' 두 종족은 서로 다른 행성의 출신이고 서로가 다를 수밖에 없다는 사실을 기억하지 못했습니다. 그래서 그들은 충돌하기 시작했습니다. 특히 이들은 서로의 언어가 너무 달랐습니다. 분명 같은 지구의 말을 구사하지만 그 말 안에 담긴 내용과 뜻이 너무나도 다르다는 것이었습니다. 어느 날 대책을 세웁니다. 개발자와 비개발자가 같은 문장을 어떻게 다르게 이해하는지 개발자의 시선으로 번역집을 만들기로 합니다.

개발자 번역집

개발자 번역사전

1. 가능은 하죠?

비개발자 : "개발자님 가능은 하죠?"

개발자 : "가능은 한데요. 그걸 하려면.."

비개발자 : "네 가능하면요. 그냥 해주세요."

개발자 : "아니 그게 가능하려면 이렇게 저렇게 수정하고 해야 해서 한 달은 걸려요"

비개발자 : "뭐라고요?!"

개발자 : "한 달이라고요!"

해석

코딩은 거의 모든 것을 만들 수 있습니다. 다만 시간이란 소비재가 필요합니다. 시간이란 게 무한대로 있으면 모든 게 가능하겠죠. 하지만 아쉽게도 개발자는 시간은 그리 많지 않습니다. "가능은 하죠?"라는 말에 함부로 대답했다가는 밀린 업무와 새로운 업무가 더 해져 집에 못 가고 회사에서 먹고 자고 해야 하는 불상사가 일어날 수 있기 때문입니다. 그렇기 때문에 개발자는 '가능'이라는 말에 소극적일 수밖에 없습니다. 그럴 경우 이렇게 해보는 건 어떨까요? "혹시 언제까지 가능하실까요?" 먼저 소요되는 시간을 물어보고 그에 맞춰서 일정을 잡아보는 건 어떨까요? 물론 개발자가 꾀병을 부리지 않는다면 말이죠.

2. 간단(쉬운) 한 거죠?

비개발자 : "이거 간단한 거죠?"

개발자 : "아니요.. 이걸 수정하려면 어쩌고 저쩌고"

비개발자 : "그냥 이거 옆으로 옮기면 될 거 같은데요?"

개발자 : "아니요 그걸 옮기려면 어쩌고 저쩌고"

비개발자 : "그러면 옮기면 되겠네요!"

개발자 : "아니 그걸 옮기려면!@#%^&*()*"

(반복 X3)

해석

비개발자와 개발자에 시선에는 큰 온도차가 있습니다. 보기에는 아주 쉬워 보이는 것도 개발자에겐 아주 어려운 문제일 수 있습니다. "간단해 보이니 버튼 옆으로 1cm 옮겨주세요"가 개발자에게는 "이 3층 건물 옆으로 1센티만 옮겨주세요." 같은 요구사항처럼 들릴 때가 있습니다. 코딩은 복잡하니다. 아무리 쉬워 보이는 문제도 로직이 얽히고설키면 그 작은 버튼 옆으로 옮기는 게 큰 문제일 수 있습니다. 그럴 땐 그 이유를 상세히 물어보는 건 어떨까요? 요구사항의 복잡도를 들어보고 판단해도 늦지 않습니다. 물론 개발자의 설명을 이해하려면 어느 정도 IT 지식은 필요하겠네요.

3. 저것처럼 해주세요

비개발자 : "개발자님 이 부분 페이스북에 있는 기능처럼 해주세요."

개발자 : "아니요. 그걸 만들려면 꽤 어려운.."

비개발자 : "그럼 인스타그램에 있는 기능처럼 해주세요"

개발자 : "그것도 매우 어렵고 어떻게 되어 있는지 저도 잘.."

비개발자 : "그럼 아마존에 있는 저 기능도 안 돼요?"

개발자 : "네 그거 굉장히 어려워요"

해석

경쟁력 있는 서비스의 기능들을 벤치마킹하는 건 매우 좋은 아이디어입니다. 하지만 벤치마킹한 기능 안에는 끝을 알 수 없는 깊이가 존재합니다. 구글의 검색 기능 버튼 하나에는 수 백만 대 서버가 연결되어 있는 것처럼 말이죠. 개발자가 가장 무서운 건 메이저 시스템의 기능과 똑같이 만들어 달라는 요청입니다. 개발자가 갖는 부담감은 이렇습니다. "수 백명의 대기업 개발자들이 오랜 기간 만든 서비스를 나 혼자 만들라고?" 이럴 땐 해당 기능에 대해 개발자와 충분히 이야기를 나눠보고 해당 기능을 분석 후에 계단 오르듯 하나씩 하나씩 만들어가 보는 건 어떨까요?

4. 내일까지 개발해 주세요

비개발자 : "개발자님 이거 내일까지 부탁해요!"

개발자 : "내일 이라니요. 시간이 없어요, "

비개발자 : "이거 중요한 거예요. 저희 팀장님께서 내일까지는 꼭 돼야 한다고 하셨어요"

개발자 : “긴급건인 건 아는데 내일까지는 불가해요 3일 정도 소요될 거 같아요"

비개발자 : "아니 내일까지 해야 된다니깐요"

개발자 : "안된다니깐요"

해석

간혹 개발자를 마치 지니의 요술램프처럼 여기는 경우가 있습니다. 말하면 뭐든지 만들어 내는 마법사처럼요. 하지만 그건 착각일 수 있습니다. 개발자도 협업이 필요로 합니다. 일방적으로 요청하고 비는 소원을 모두 모두 들어줄 수 없습니다. 요정 지니가 아니라 사람이기 때문입니다. 그러므로 일정에 대해서는 꼭 협의가 필요로 합니다. 특히 일정에 대한 아무런 협의도 없이 불쑥 요청을 한다면 기존의 일정들 또한 전부 조절해야 하기 때문에 꽤 난감한 상황을 마주할 수 있습니다. 그렇기 때문에 긴급 요청 전 개발팀에게 일정을 묻고 일정에 대한 의견을 좁혀나가야 할 것입니다. 하지만 너무나 중요해서 당장에 서비스에 영향을 끼치는 긴급건일 경우 개발자도 적극 협조해야 할 의무가 있습니다. 개발자가 아니면 그 오류를 해결할 수 없기 때문입니다.