최근 중소 규모 회사의 쇼핑몰을 구축해주는 회사의 서버 개발 팀장으로 이직한 친구로 부터 다음과 같은 문의를 받았다.

프론트 개발을 위해 채용된 주니어급 두명의 제안으로 React 를 도입했다. 개발 지식이 전무한 대표는 React 를 사용하면 컴포넌트를 재사용할 수 있다는 말에 비슷한 프로젝트와 사이트를 손쉽게 만들수 있을 것으로 기대하고 있었는데.. 현 상황은 비즈니스 로직은 고사하고 UI 재사용도 불가능해서 매번 새로 만들고 있다.
결과적으로 jQuery 기반으로 개발할 때 보다 생산성이 더 떨어졌고, 주니어 두명은 React 개발자가 더 필요하다고 한다. IE 지원 예기만 나오면 짜증을 내는건 덤이다.
원래 React 는 재사용이 불가능한 건가? 아니면 주니어 개발자 두명이 잘 몰라서 그런건가?

팀은 다르지만, 팀장 없이 주니어 두명으로 이루어진 팀이라서 할 수 없이 자신이 일정 및 진척 상황 정도만 관리하게 되었다고 한다
나는 엄청난 페이지뷰를 소화하는 알리바바가 vue.js 로 개발되었고, 수시로 발생하는 고객사의 ui 변경 요구에 빠르게 대응하기 위해선 react 보다는 vue.js 가 조금 더 유리하다. 더불어 UI 재사용을 위해 bootstrap 처럼 공용 스타일링을 만들어가야만 한다. 처음부터 어려우면 잘 만들어진 UI 라이브러리를 기반으로 삼아 시작하는것도 좋다고 답변을 했다.
생각해 보니 내부 사정을 모른채 다분히 개인적인 취향이 섞인 답변인듯 해서 얼마후 전화를 했다.
친구는 프론트 개발을 담당하는 주니어 개발자 두명과 예기를 했고, 그 두명의 답변과 태도 때문에 당황하고 화가 난 상태였다. 아래 내용은 주니어 개발자의 답변을 요약한 것이다..

네카라쿠베에당토 에선 Vue.js 를 사용하지 않습니다. 여기선 모두 React 를 사용하고 있구요, 따라서 React 가 개발 표준 이에요.

친구는 내 답변을 화두로 던지면 수차례 논의를 통해 건설적인 결과가 나오길 기대했었는데, 예상 밖의 심플한 대답이 나와서 처음엔 당황했다고 했다.
네카라쿠베당토 프론트 개발팀 만큼 알리바바 역시 수준이 높을 것이다. 같은 쇼핑몰 사이트이니 vue.js 가 더 유리한 부분이 있지 않느냐는 질문에 주니어 개발자 두명은 답변은 하지 않고 자기들 끼리 쳐다보면서 팀장과 말이 안통한다는듯 난처한 표정과 재스쳐를 취했다고 한다.
친구는 모욕감에 화가 머리 끝까지 났었고, 담배 한대 피면서 화를 삭히는중에 내가 전화를 한 것이였다.
나도 황당하고 화가 났다. 얼굴도 보지 못한 사람 욕하는게 쓸데 없는 일이라 대표에게 말해서 해결하는게 좋다고 권유 했다.

저녁에 친구에게 전화가 왔다. 대표에서 전후 상황을 보고 했지만, 대표는 프론트개발자를 구하기 힘들다. 어린 친구들이니 당신 경력이면 충분히 핸들링 가능하지 않느냐. 그리고 나의 경력에 대해 캐묻더니 혹시 올 수 있는지 설득해 보라 했다고 한다. 물론 정중(?) 하게 거절 했다.

TV 에서 투명 아크릴로 3면이 막힌 강의실에게 mac notebook 한대 펼쳐 놓고 하루종일 네카라쿠베당토 입사를 위한 코딩을 가르치는 학원이 잠깐 나온적이 있다. 코로나19 상황에도 강의실은 빈 자리 하나 없었다. 나로서는 매우 생소한 광경이었다. 모든 프론트개발자들이 네카라쿠베당토 주문에 홀린 듯 했다.. 이런 세태 라면 주니어 개발자 두명 뿐만 아니라 많은 사람들이 같은 대답과 반응을 할 수도 있겠다는 생각이 들었다..
더불어 고객(SDS) 로 부터 필수 인력으로 인정 받으며 그에 상응하는 등급과 급여를 약속 받았음에도 하도급법 뒤에 숨어서 단가 후려치기와 정직원 교체등의 농간을 일삼는 중간 업체(5웨이) 때문에 곤욕을 치루는 내 자신이 한심스러워서... 인생을 잘못 살고 있나 싶어서 쉽사리 잠 못들고 이렇게 글을 쓰게 되었습니다..

이 내용은 개인적인 관점에서 작성된 개발 후기로 만일 비슷한 업무나 관련된 기술이 필요하신 분들을 위해 포스팅 되었습니다. 


약 2개월 전에 블로그를 통해 개발 의뢰를 받았다. !!


올 초에 알바몬에 게시된 구인 공고를 보고 Photoshop 연동하는 프로그램 개발에 지원 했다가 끝이 좋지 않은 적이 있었다. (자세한 내용은 여기 참조) 화가 나기도 하고 다른 분들이 피해 볼까봐 업체와의 진행 과정을 낱낱이 포스팅 했었는데, Phtoshop 연동 개발에 관련된 내용을 보고 의뢰를 하게 된 것이였다.

분노의 타이핑을 할 때 집사람이 뒤에서 쓸데 없는짓 하지 말고 자라고 구박을 했었는데, 지금에 와선 황당하다고 했다. 돈벌어 오니까 대견한듯 ㅋㅋ


의뢰한 곳은 핸드폰 케이스를 인쇄하는 소규모 업체이다. 요구 사항은 주문받은 다양한 종류의 케이스에 각종 도안을 인쇄하는데 필요한 Photoshop 파일을 생성해 달라는 것이였다. 케이스 인쇄용 프린터의 RIP 에서 Photoshop 파일을 바로 읽어 들일수 있고 업체 담당자는 디자이너 였기 때문에 배치된 결과물은 photoshop 으로 나오기를 원했다.

요구 사항을 처리 하기 위해 프로그램은 크게 3 가지로 구성되었다.

  1. 도안이 담긴 Photoshop document 의 각 레이어를 단일 이미지로 변환
  2. 외주 개발사를 통해 기 구축된 있는 웹기반의 주문관리 시스템에서 생성된 엑셀 파일을 기반으로 변환된 도안 파일을 읽어서 알맞게 배치
  3. 부분 재인쇄를 위해 도안이 배치된 photoshop document 에서 선택된 레이어만 재배열

1,2 번은 Desktop Appllication 이고 3번은 Photoshop Script Plug-in 형태로 개발하기로 계획을 세웠다.


예상보다 한번에 사용해야 하는 도안 파일이 많고, 이미지 로딩시 팔레트와 원판의 컬러모드(RGB / CMYK) 검증, 사이즈(DPI) 체크 등등 프로세스가 많을 수 밖에 없었다. 다행히도 업체 담당자(디자이너) 들은 SSD 를 사용중 이었고, Photoshop CC 2014 는 64bit 프로세스로 동작하기 때문에 메모리 걱정없이 한번에 로딩이 가능했다. 할렐루야!!

그렇지만, Adobe 가 제공하는 빈약한 Photoshop SDK 문서와 세계적으로 한정된 개발자 풀(pool) 이 나를 괴롭혔다. (대부분 프로젝트에서 똑같이 반복되는 일 인듯 하다. 간혹 할 수 있다고 나대는(?) 분들을 만날 수 있는데, 이 문서 대충 홅어 보고 디자이너 앞에서 되도 않는 개발관련 지식을 늘어 놓으며 가능하다고 하는 분들이 99% 였다. 제발 뭐라도 좋으니 해 보고 말좀 했으면 한다.)

Phtoshop 관련된 개발은 나름 자신(?) 있다고 생각해서 기능이 100% 확인되지 않은 상황에서 자신감으로 바로 작업 시작했는데, 예상과 달리 애로 사항이 많았다. 개발 문서에 언급되지 않은 각종 예외 사항들 (UI 와 API 가 다르게 동작하거나 예상외의 제약 사항 등등) 에 부딪히면 당연히 구글링을 하지만, 전세계적으로 이런 개발을 하는 사람이 그렇게 많지 않은지 큰 도움이 못되어서 결국 삽질의 삽질이 이어졌다. 몇번이나 중간에 그만 둘까 하다가 그놈의 가오 땜에 못한다는 소리는 못하고.. 아이디어를 짜내서 꾸역꾸역 해 나가다 보니 완료를 하게 되었다. ㅎㅎ

블로그 운영 방침도 그렇고 특정 업체를 위해 개발된 것으므로 소스나 자세한 설명은 이쯤에서 하고 간단한 화면 캡쳐 로 마무리 하겠다.



< 도안(이미지) 배치 >


< 도안 파일(Photoshop) 레이어 추출 >


< 배치 결과 >



이 업체와 일하면서 즐거운 것은 돈 보다도 Photoshop 연동시 불가능 하다고 생각해왔던 것들을 해 낸 성취감과 젊은 업체 담당자들의 마인드 였다. 젋어서 그런지 모르겠지만 개선을 위해 적극적으로 행동하고 기다려 줄 줄 아는 태도와 생각에 많은 자극을 받았고 즐거웠다. (지인들에게 더 늦기 전에 젊은 친구들이 공격적으로 시작하는 스타트업에서 같이 일해 보고 싶다고 예기하곤 하는데, 이 친구들을 통해 약간이나 심적인 준비가 된 듯 하다 ) 


알바 자리를 구하기 위해 매일 아침 저녁 검색을 해왔는데, 생각지도 못한 경로로 재미있는 일이 들어 올 줄은 생각도 못했다. 이를 계기로 Photoshop CC 2014 관련해서 보다 많은 일이 들어오길 바란다.

전문가, 전문가 를 외치면서도, 나도 모르게 이것 저것 찾아보는 일이 잦다.

작정하고 하나만 해야 하는데, 알바를 위해서 Play+ Postgresql + angularJS 그리고 html5 와 SASS/LESS 등의 정보를 골고루 찾아 보고 있으니 말이다.. 하나만 정말 잘 해도 먹고사는데, 이 3가지를 모두 정통하려고 하니 스스로를 옥죄는 일 밖엔 되지 못하는것 같다..


알바 사장에게 휘둘려서 좀더 저렴한 구축 비용을 위해 오픈소스를 검토하고 마스터 하느라고 나 스스로를 풀스택으로 몰아가는 짓은 하지 말아야 겠다. 저렴하게 해 봤자 문제생기면 이를 위한 노력은 모두 잊어버리고 죽일듯이 덤벼드는 영업치 알바 사장의 바닥은 이미 충분히 경험했다.. 차라리 동생과 나중에 같이 뭔가를 준비하거나 TA 일자리를 얻기 위해 준비하는 용도로 서버쪽 프레임웍에 집중해서 봐야 겠다. 


분당에 있는 연세고운치과 에서 다음과 같은 공고을 올렸다. 자세히 읽어 보면 알겠지만, 소스 제공에 이정도 기능과 기존 emr 솔루션과 연동을 기본 30만원으로 하자는 것은 무슨 생각인지 모르겠다.

목표는 병원의 고객정보 정리에 있는데, key lock 은 왜 필요하고 웹하드 공유는 왜 필요할까? 고객정보가 원외로 노출되는 가능성이 있다는 소리인가? 그리고 사용하는 emt 솔루션 분석 이라니 ㅠㅠㅠ

병원의 누구인지는 모르겠지만, 요구사항과 금액이 상식을 벗어난지 모르는 것인지, 아니면 어디서 못되쳐먹은 단가후려치기를 배워서 써먹는건지 잘 모르겠다..

아래는 홈페이지 주소와 블로그 주소이다. 관심있으면 둘러 보시길 바란다.

http://www.misosmile.com/branch/b_bundang/sub01.html

http://blog.naver.com/miso7122875



최근 알바몬에 서울대에서 시스템 간전성관리 및 리스트 연구실에서 다음과 같은 구인 공고를 잊을만 하면 올리고 있다. 필요한 기술중 다른건 새롭지 않은데, WxWidget 을 C++ 로 하기를 원하는 부분이 눈에 띄여서 눈여거 보고 있다. 

속사정은 잘 모르겠지만, 자주 공고를 내는 걸 보아 하니 사람이 안뽑히거나, 들어와서 금방 나가거나 자신들 기준에 맞지 않는다며 내보내는 경우중 하나 일것이라 생각이 든다. 오래전에 금융 시뮬레이션 시스템 개발시 매트랩 소스를 C 로 컨버전하는 작업을 한 적이 있었다. 내가 C++ 실력이 부족한 탓도 있겠지만, 생산성이 낮아서 결국, 고객측이 먼저 나은 방법을 강구해 보자고 제안했고, 결국 JAva 로 변경했었다. 덕택에 시스템 개발은 속도를 낼 수 있었고, Java 기반의 사내 시스템과 연동 역시 매끄럽게 완료 했던 경험이 있다.

왜 이 연구실에서 이것을 고집하는지 잘은 모르겠지만, 보수적인 금융권도 생산성 및 타시스템 통합을 위해 개발 언어를 변경하는 유연함을 보여주고 있는데 학교가 고집이 왜 이렇게 쎈지 답답하다.. 서울대라는 프라이드가 이들의 사고를 경직시키는게 아닐런지도.. 아니면 어딘가 이정도는 발가락으로 해도 금방 할 수 있으니 돈 받기도 창피해서 밥이나 사달라고 하는 서울대 학부생이 짠 하고 나타나길 기다리는 건 아닌지 모르겠다.


+ Recent posts