[월:] 2022 6월

일본 차량 번호판 인식 / 日本車両ナンバープレート認識エンジン

일본 차량 번호판 인식 Engine입니다.

日本車両ナンバープレート認識エンジンです。

테스트를 위해서 진행 함.

テストのために進む。

Street gate camera for License Plate Recognition

– Japan

– Russia

– Philippine

– Indonesia

– Korea

#smartcity #alpr #philippline #japan #korea #indonesia #Korea

개발자를 찾습니다. 그런데…

개발자를 찾는다는 아우성이 우리나라 뿐만 아니라 해외에서도 들린다.

덕분에 작은 비용으로 영위하던 해외 개발 회사들의 운영비용이 지수함수적으로 치솟는다.

최근에 베트남에서 PM급 인력을 찾는다는 구인 공고가 올라왔는데, 확인된 월급이 $6,000~$7,000을 넘어설 지경이 되었다. 베트남 인건비가 싸다는 것도 이제는 예전 이야기가 되었다. 2~3년 DevOps 경험을 가지면 $1500~2000을 넘어선다. 한국 인건비의 40~60%에 도달한 것이다. 언어 문제, 인력 관리 문제, 현지 직원 파견 문제 등등을 고민하면 베트남이 매력적인 연구 인력 충원 국가가 아니게 되었다.

  • 물론 찾는 인력이 Full stack이고, 특이한 케이스이겠지만, 베트남 인력 구인 구직 사이트에 올라온 정보이니 맞을 것이다.

최근에 협력업체의 요청으로 급히 iOS App 개발자를 찾아야 할 일이 생겼다, 그래서 알고 지내던 국내 개발자 2인에게 연락하였다.

국내 개발자의 경우 2주일 개발에 꽤 큰 비용을 요청하였다.

신규 개발이 아니라, 있는 App의 디버깅이니, 디버깅은 신규 개발보다는 하는 일은 적겠지만, 난이도는 더 높으니 이해 할 만하다.

위험을 감수하고 해외 개발을 의뢰할까 하여 해외 전문 개발자에게 연락을 하니 1/30~1/50 의 비용으로 한다고 하였다.

물론 해외 개발은 여러가지 위험이 있으니 몇가지 안전 장치를 해야 하지만, 그래도 신뢰가 가는 해외 개발자에게 외주를하니 1주일만에 결과가 나왔다.

하기사 2주 걸린다고 이야기한 일을 1주일만에 하면, 서로에게 이익이니 열심히 했다.

시차 문제로 밤 12시 혹은 새벽 5시에 대화를 하여야 한다는 것이 함정이지만, 결과만 잘 나온다면이야… 뭐…

궁굼한 것은,

우리나라 개발자들은 이제 기업들과 마찬가지로 개발자들도 세계를 상대로 경쟁해야 한다는 것을 알고 있을까 ?

한국어를 잘 해서,

대화가 쉽게 되어서,

시차가 없어서를

제외한 국내 개발자들의 경쟁력은 무엇일까 ?

케바케이지만,

주말에도 밤에도 일하는 개발자가 세계적으로 많은 세상에서 그런 개발자를 소싱 가능한 세상이 되었는데 국내 S/W 개발자의 경쟁력은 무엇일까 생각 해 본다.

개발의 위험성은 비슷하다고 간주 할 수 있다.

Feat. 안정성을 이야기 할 수 있지만, 이번에 요청한 회사는 외주 준 곳이 야반도주(?) 하여서 사업적으로 어려워져서 요청 해 왔다. 그러므로 국내건 해외건 개발의 위험성은 비슷하다고 간주 할 수 있다.

Feat. 연중 무휴로 iOS/Android App을 계속 개발하고 유지 보수해야 한다면, 내부 Staff을 두는 것이 유리하지만, 필요할 때 개발하여야 한다면 외부 개발자를 활용하는 것이 유리할 수 있다. 하지만 최근에는 적당한 (?) 수준까지는 연중 무휴로 개발한다고 하여도 내부 개발자보다는 기획자와 테스터를 두고, 외주 개발로 하는 경우가 많은 것 같다.

공감하는 능력.. 이 문제가 아니라..

캡처1-4

(이 글은 3년 전에 써 놓고 지금 올립니다.)

최근에 겪은 일

#1 특정 기능을 위한 서버 프로그램의 데모를 진행하였는데, 계속 버그같은 동작이 나와서 문제가 발생하였다.  결국 데모는 거의 실패 수준이었는데 다행히 원청 업체의 이해로 버그 수정을 하는 것을 전제로 프로젝트를 진행할 수 있게 되었다. 나중에 소스 코드를 받아서 분석하니 버그로 발견된 많은 부분이 사용상에서 그렇게 동작 하도록 의도된 코드였다고 확인 되었다.  담당자가 왜 그렇게 동작하도록 되어 있는지를 제대로 설명하거나 공유하지 않았던 것이다.

#2 모 프로젝트의 계약을 위한 설명자료와 내용을 정리해서 타업체에 보내야 하는 상황. 그 프로젝트는 일년 넘게 진행한 프로젝트라 문제점과 진행한 과정을 모두 알고 있었는데 타업체에 보내야하는 설명하는 자료에는 그런 내용이 전혀 없이 간단한 계약서 한장만 보내졌다. 부랴부랴 회수하고 정리를 다시하고 설명하는 자료와 통화를 여러번한 뒤에야 수습되고 진행 될 수 있었다. 담당자에게  왜 그런 문건을 보냈는지 궁굼해서 이야기를 해 보니 이미 (본인이) 다 알고 있어서 굳이 설명할 필요가 없고, 문의오면 대답해 주면 된다는 답변을 들었다.   부실한 설명으로 오해하기 딱 좋은 상황이고 그로 인해서 문의 오기 전에 프로젝트가 쫑 나는 것에 대한 걱정은 아예 없었다.

두건의 내용은 전혀 다른 프로젝트이고 전혀 다른 상황이지만 의외로 문제의 원인은 같다. 그것은 상대방에 대한 공감하는 능력, 문제를 내 관점에서가 아니라 상대방 관점에서 보는 능력이 혹은 관심이 결여되었거나 부족해서 발생하는 문제이다.

상대방에게 내가 아는 것의 결과물을 설명하는 것이 아니라 상대방에게 필요한 과정과 내용을 충분히 설명하여서 그 결과물의 의미를 설명했어야 한다.  프로그래머가  사용자에게 자신의 스타일로 만든 시스템을 강요하는 것은 상대방의 입장에서 결과물을 어떻게 사용해야 한다는 것을 생각해 본적이 없는 것이었다. 그래서 자신이 테스트한 방법 대로만 문제가 없으면 되는 것이라고 생각하고 시스템을 릴리즈 하는 것이다.

문제는 해결 방법이다.

이러한 문제는 항상 발생하는 사람들에게서만 발생되고,  반복된다.

이에 대해서 고민하는 중에 좋은 분에게서 들은 이야기는

“사람을 바꾸려 하지 말고 사람을 바꿔라”

이다.  언뜻 보면 이해하기 어려운 말인데 한편으로는 이해가 되면서 반대로 실행하기 어려운 말이 되었다.


3년이 지나서 글을 다시 읽어 보니 그때와 다른 생각이 드는 것은
문제는 그런 성향의 팀장/담당자임을 알면서도 맡긴 사람이 (내가) 잘못이라는 것이다.

개선이 되겠거니 , 배우겠지 하는 생각으로 진행한 것이 다 문제가 된 부분이었다.

나에게 문제가 있었다는 성인 군자 같은 말이나 결론인 것 같아서 안 올렸었는데 ,

생각해 보면, 좀더 빨리 다른 시스템을 고민했어야 한다는 점이다.

걸려라 무대뽀~~

모 회사를 위한 전략을 짜기 위해서
아는 분과 회의를 하였다

결국 문제는 기술은 있는데, 상대방의 정확한 필요성을 모르는 것이 문제였다.

“일단, 회사소개를 하고 정확하게 니즈를 물어 보지요?”

라고 이야기하니, 단호한 어조로 대답을 하셨다.

“그 (무대뽀) 전략으로 많은 사람들이 사업을 실패하는 것입니다.

그동안 많은 상대와 (미팅을) 해 보았지만, 정확한 니즈는 상대방도 모릅니다. 그러니 물어보고 니즈를 모르거나 없으니 안된다는 결론으로 도달하는 것입니다. 상대방의 사업을 분석하고 니즈를 찾아내어서 그 이유와 수행 했을 때 기대 이익을 설명할 수 있어야 처음 미팅이 의미가 있습니다. 처음 미팅이후에 다음 미팅을 기대하는 것 입니다.

그냥 물어보면 본인도 니즈를 모르는데 무슨 이야기가 진행 되겠습니까 ?

그리고 니즈를 알면 이미 상대방에게는 우리가 아닌 다른 카운터 파트너가 있는 것입니다.

그리고 처음 한두번에 미팅을 가치있게 하지 않으면 세번째는 없습니다.

굳이 만날 이유가 없지요 그래서 사업이 건건히 실패합니다.”

맞는 말씀이다.

다시 한번 무대뽀 정신을 반성했다.