본문 바로가기

R&D

 (33)
싸이크로스 제 3회 연구발표회 안녕하세요? 싸이크로스입니다 :) / 5월답지 않게 봄비가 유난히 많이 왔던 5월, 5월 금요세미나는 어땠을까요? 이번 세미나에는 어떤 직원이 눈에 들어왔을지? 그 현장 한번 살펴볼게요! / 요즘 떠오르는 업무용 메신저 서비스 ‘슬랙’을 소개한 ‘이준노’ 사원! 국내 직장인 과반수가 업무용 메신저로 카카오톡을 사용하는데 최근 카카오가 업무용 메신저 ‘카카오웍스’를 내놓았죠! 요 두 가지를 비교하면서 슬랙의 장단점을 설명해주었답니다. / 코로나19 확산으로 재택근무와 원격근무를 지향하는 기업이 늘어가면서 기업 간과 구성원 간 언택트 협업을 가능하게 해주는 대안으로 메신저 기반 협업 툴이 대세라고 해요! 아무래도 협업에서 가장 중요한 것은 ‘소통’이니까요. 과연 싸이크로스와 맞는 서비스는 어떤 것일지 고민해..
싸이크로스 제 2회 연구발표회 안녕하세요? 싸이크로스입니다 :) 따뜻한 봄 날씨에 나른할 법한데도 뜨거운 학구열로 불타올랐던 4월 금요세미나가 진행되었는데요. 그 중 가장 돋보였던 직원들 위주로 세미나 현장을 소개해보려고 합니다! / 이번 세미나를 준비한 직원들이 참 많았는데 그 중 가장 독보적인 존재감을 보여주신 ‘이준호’ 부장님! ‘웹 스프링’이란 주제를 들고 오셨는데요, 웹 스프링이란 프로젝트를 개발할 때 필요한 수많은 라이브러리를 집약체 형식으로 전환할 수 있는 기술이랍니다. 요 웹 스프링을 이용해 손쉬운 개발 환경을 만들어서 수 많은 라이브러리를 편리하게 관리할 수 있는데 이번에 개발하는 제품에서 적용하면 한 층 더 편리한 개발 환경이 될 것 같습니다! 이준호 부장님에게 바통터치 받은 ‘윤소연’ 사원! 웹 스프링을 실제로 적..
싸이크로스 제 1회 연구발표회 안녕하세요? 싸이크로스입니다 :) 지난 2월 26일 싸이크로스 연구소에서 IT 트렌드 및 기술 지식에 관해 서로 공유하는 연구 발표회를 가졌습니다. / 나만 알고 있기엔 너무나 아까운 정보와 제품 개발에 도움이 되는 기술 등을 여러 직원들과 함께 나누는 뜻 깊은 시간이었는데요! / 매달 마지막 주 금요일마다 여는 싸이크로스 ‘연구발표회' 지금부터 그 현장을 한번 보실까요? / ‘연구발표회’의 첫 포문을 연 ‘이준노’사원! 이번에 발표한 주제는 ‘모바일 지원을 위한 기술’로 IT 신기술에 대한 트렌드를 소개했답니다! / 최근 모바일 환경이 커짐에 따라 웹(Web)보다는 앱(App)에서 더 많은 시간을 보내는데요. 아무래도 앱이 웹보다는 더 빠르고 편해서 그렇겠죠? 그래서 이를 보완하는 신기술이 생겼는데 그..
SW컨설턴트의 개발이야기, 열여섯번째.SW개발과 빨리빨리 문화의 저주(개발문화 시리즈3) 이번에 다룰 개발문화 이야기는 '빨리빨리 문화'다. 일을 빨리 하자는게 나쁜 건 아니다. 오히려 이런 '빨리빨리 문화' 덕분에 우리나라가 짧은 기간에 성장했을지도 모른다. 더 짧은 시간에 똑 같은 일을 해낼 수 있다는 것은 경쟁력이 있는 것이다. 우리는 그동안 많은 산업분야에서 '빨리빨리 문화'의 혜택을 입었고, 관련 노하우도 많다. 그런데, 이런 '빨리빨리 문화'가 소프트웨어 분야에서는 독이 되는 경우가 많다. 실제로 독이 되는 경우를 많이 보았다. 시제품은 빨리 만드는데 본제품을 완성하는데는 시간이 훨씬 오래 걸리며 품질도 떨어지고 시간이 흐를수록 유지보수가 무척 어려워져서 제품을 포기하는 경우도 흔하다. 상황을 수습하지 못해, 회사의 종말로 이어질 때도 있다. 유독 왜 소프트웨어 분야에서 '빨리빨리..
SW컨설턴트의 개발이야기, 열다섯번째.부실한 공유문화를 지배하는 개발자의 심리 (개발문화 시리즈2) 본격적으로 소프트웨어 개발 문화에 대해서 얘기해보자. 첫번째는 ‘공유의 문화’다. 회사마다 차이는 있지만 소프트웨어 회사에서 부실한 공유 문화는 많은 부작용의 원천이다. 여러 사람과 정보를 공유하는 것에 따른 장점은 여러가지다. 다양한 시각을 가진 이들의 의견이 반영되면서 프로젝트 리스크가 감소되는 건 물론 개발자는 자신이 해왔던 과거업무의 속박에서 벗어날 수 있다. 반대로 공유문화가 부실한 회사는 왜곡된 의사결정으로 프로젝트 리스크가 커지고, 아키텍쳐나 제품은 뒤죽박죽이 되는 경우가 많다. 개발자는 자신이 과거부터 해온 일들에 발목이 잡혀 고참이 되도 유지보수에 바쁘고 신참에게 일 시키기도 어렵다. 본인 스스로 고급개발자로 성장하기 어려운 구조라고 하겠다. 개발자가 수백명, 수천명인 회사나 개발자가 1..
SW컨설턴트의 개발이야기, 열네번째.왜 적은 인원으로 빨리 개발하나…개발문화의 비밀 (개발문화 시리즈 1) 우리나라에서 소프트웨어 개발이 3D 취급을 받는 이유는 여러가지다. 끝을 모를 야근과 낮은 대우 등도 포함되겠지만 좀더 근본적인 이유는 따로 있다. 낮은 생산성 때문이다. 소프트웨어를 개발해서 회사가 돈을 많이 벌고 세계적으로 성공하는 소프트웨어가 많이 나온다면 생산성의 핵심인 개발자에게 당연히 높은 대우를 해주게 마련이다. 하지만 우리나라에서는 크게 성공한 소프트웨어 회사가 많지 않다. 그리고 소프트웨어 회사의 수익률이 별로 높지 않기 때문에 소프트웨어 개발자에게 좋은 대우를 해줄 수 없다. 결국 이런 소프트웨어 개발에 대한 낮은 대우를 극복하기 위해서는 성공하는 소프트웨어, 성공하는 회사가 많이 나와야 한다. 그럼 성공하는 소프트웨어 회사와 그렇지 못한 회사를 가르는 결정적인 차이는 무엇일까? 판단의..
SW컨설턴트의 개발이야기, 열세번째.공짜 점심이 개발자를 행복하게 할까? 최근에 국내 유수의 소프트웨어 회사들의 구조조정 회오리를 보면 착찹한 생각이 든다. 척박한 우리나라 소프트웨어 환경에서 참신한 개발문화를 도입하고 새로운 모습을 보여주려고 했던 회사들이어서 더욱 안타깝다. 필자는 이런 현상의 결과와 겉모습만 말고 다른 시각에서 좀 더 근본적인 원인을 살펴보고자 한다. 3D 취급을 받고 있는 국내 소프트웨어 개발자들은 잘나가는 실리콘밸리의 소프트웨어 회사들과 높은 연봉을 받는 소프트웨어 개발자들이 부럽지 않을 수 없다. 종종 그런 회사들의 끝내주는 개발 환경이 부러움을 사곤 한다. 공짜 점심, 자유 출퇴근 제도, 공짜 커피, 편안한 사무실, 환상적인 휴게실/오락실/수영장, 선택 가능한 재택근무 등이 그것이다. 물론 회사마다 다르기는 하다. 우리도 개발자들에게 이런 공짜 점..
SW컨설턴트의 개발이야기, 열두번째.거의 다 만들었어요. "거의 다 만들어서 2주후에 개발이 끝나요" 이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다. 개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다. 하지만 이런 대화는 여러 오해를 양산한다. 영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다. 그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다. 우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다. "개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 ..
SW컨설턴트의 개발이야기, 열한번째.개발자, 회사의 과거인가 미래인가. 개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다. 첫 번째는 ‘과거의 가치’이고 두 번째는 ‘미래의 가치’이다. 나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다. 내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다. 반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다. 회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치..
SW컨설턴트의 개발이야기, 열번째.1:10:100 rule 소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다. 성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 대부분의 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다. 소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다. 그 1:10:100 rule을 설명한 그래프가 아래에 있다. 요구사항이 스펙을 작성하면서 바뀌면 "1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 "368"배의 비용이 들어간다. 요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 시간이..

티스토리툴바