일이 잘 안될 때는 소통방법을 점검해야 한다
회사나 사람과 일을 하면서 일이 잘 안될때는 소통방법을 점검해야 한다. 소통안되는 사람들은 질문이나 결정을 할때 아무말을 안하고 문제가 생겼을때만 호들갑을 떤다. 연락할것도 버티다 버티다 하면서 상대방이 반응이 없기를 바라고 있다. 특히나 공공기관과 일을 하는경우 서로의 책임소재 공넘기기에 급급해서 폭탄
계속 읽기 →TOPIC
33개의 기록
회사나 사람과 일을 하면서 일이 잘 안될때는 소통방법을 점검해야 한다. 소통안되는 사람들은 질문이나 결정을 할때 아무말을 안하고 문제가 생겼을때만 호들갑을 떤다. 연락할것도 버티다 버티다 하면서 상대방이 반응이 없기를 바라고 있다. 특히나 공공기관과 일을 하는경우 서로의 책임소재 공넘기기에 급급해서 폭탄
계속 읽기 →공짜를 기반으로 돈버는 방법은 없습니다. 오픈소스, 무료 라이브러리, 무료API 등으로 서비스를 개발하면 반드시 망합니다. 돈을 벌만큼 트래픽이나 데이타가 늘어나면 그때부터는 돈을 제대로 지불해야 합니다. 간혹 국가가 제공하는 값싼 사무실, 인큐베이션, 초기무료사업지원등등 우리주변에 공짜처럼 보이는 유혹
계속 읽기 →새로운 플랫폼 개발을 하면서 달력이 필요해서 인공지능에게 도움을 요청하니 fullcalendar, tui.calendar를 추천해 줬다. fullcalendar는 예전부터 사용을 해봐서 tui.calendar를 써볼려고 몇가지 테스트를 하다보니 fullcalendar에 거의 비슷한 화면과 기능으로 구현되
계속 읽기 →스타트업의 CEO가 회사에 짐이 되고 리스크가 되기 시작할때 나타나는 주요한 증상이 CEO발 즉흥적인 신규 사업, 독단적인 사람의 영입, HR프로그램 도입, 관리 프로세스등을 만들기 시작하는 것등이어요. 이제 내가 "뭔가 쫌 아는" 창업자라는 자의식(이라고 말하고 알량한 교만이라고 해석하는)이 생기기 시
계속 읽기 →구글과 애플의 앱스토어,플레이스토어 정책의 변화 앱을 개발하고 스토어에 올리는 과정이 과거에 비해 너무나도 어려워졌다. 개인정보정책의 중요성이 대두되면서 스토어들이 책임을 회피하기 위해서 개발자에게 상당히 많은 요구를 하고 있다는 생각이 든다. 과거에는 앱을 올려달라고 그렇게 사정하던 시절도 있었는데 지
계속 읽기 →참으로 멍청한 네이버 기술지원을 보면서 네이버가 이 글을 읽기를 바란다. 네이버페이로 주문한 결과를 받기위해 수없이 메일보내고 질문해도 그냥 샘플보고 알아서 잘하라는 기계적인 답변뿐이다. 지들이 만들어준 샘플자체가 오류가 나는 상황이고 실행도 안되는데 서버에 라이브러리 잘 깔으라는 말만 반복... 수없이
계속 읽기 →디비 데이터가 변경될때 변경 로그를 요청하는데 문제는 변경의 정의가 어렵다는 점이다. 필드가 변경된것을 일일이 비교하면서 어떻게 변했는가를 로그로 쌓는다는것이 상당히 번거롭기도 하고 수정하는곳마다 모두 로그 코딩을 넣는게 어렵기도 하다. 로그를 보고자 하는 사람이 로그의 데이타를 직접 이해를 못하다 보니
계속 읽기 →프로그램을 만들어 주는 툴로 서비스를 개발할 수 없다. 요즘들어 페북광고에 프로그램 공모전이니 국가지원이니 하면서 창업을 부축이는 광고를 많이 보게된다. 단적으로 이런 툴로 제대로된 서비스를 만드는건 불가능하다. 단지 홈페이지 수준의 내용을 푸시메세지와 결합해서 쇼핑몰 정도 만드는 수준이다. 개발툴이 없
계속 읽기 →Restfull 서비스 개발 대부분의 앱으로 서비스 하는경우나 잘 설계된 웹서비스이 경우 restfull 이 주도적으로 사용된다. 전체 페이지를 하나로 개발하는 것이 아니라 각각의 디자인 영역과 데이타 영역을 나눠서 서버에서 데이타 또는 html 을 받아서 화면을 처리하는 방식을 많이 사용한다. 여기서
계속 읽기 →MongoDB 도입에 실패하지 않으려면 몽고디비의 속도가 빠르다는 이유만으로 도입한뒤 몇일만에 포기하고 기존 디비로 개발하는 경우를 많이 봤다 결론적으로 몽고디비는 빠른 디비라고 말하기 어렵다 검색엔진의 기본인 Binary 검색 방식이 달라지지 않는한 모든 데이타베이스에서 하나의 데이타를 읽어오는데 걸리
계속 읽기 →실력있는 프로그램어가 되고 싶다면 요즘은 많은 학과에서 프로그램을 기본적으로 배우다보니 수 없이 받은 질문이다 성공한 프로그램어가 되는 길이 있을까? 착한사람되기 만큼이나 어려운 과제라고 생각된다. ㅎㅎㅎ 성공의 기준의 주관적이므로 여기서는 실력있는 프로그램어에 대해서만 생각해보자. 실력있는 작가의 기준
계속 읽기 →서비스를 개발하면서 디자인의 중요성은 매우 중요하다. 하지만 기능이나 안정성은 뒤로하고 디자인에만 몰두하는 경우도 많다. 서비스 기획에 경험이 없는 경우는 기능이나 안정성은 보다는 눈에 보이는 화면에 치우쳐서 서비스를 기획하고 프로젝트를 끌고가게 된다. 특히나 회사의 빅마우스가 설쳐되면 답이 안나오는 경
계속 읽기 →SQL vs NoSQL 데이터 베이스는 전통적으로 SQL 기반으로 구축하고 있다 몇년전부터 갑자기 NoSQL 기반의 몽고디비에 대한 관심이 높아지고 있다. SQL 과 NoSQL의 차이는 무었인가 Structured Query Language 란뜻으로 번역하면 구조화된 조회 언어 정도인데 뭐 중요한건 아닌
계속 읽기 →서비스에 필요한 계정은 반드시 회사차원의 관리를 해야 한다. 외주로 개발한 경우 또는 개발자가 있어도 문서정리를 잘 안했을때 난감할 수 있다. 홈페이지가 죽었는데 개발자 연락이 안돼요. 호스팅을 바꾸고 싶은데 소스는 어디에 있나요. 도메인이 만료되었는데 어떻게 연장하나요. 앱스토어에 앱을 올려야 되는데
계속 읽기 →서비스를 개발한다면 백업시스템을 먼저 구축해야 합니다. 100번의 보안보다 1번의 백업이 중요하다고 믿습니다. 보안에는 데이터 누출의 더 큰 부분이 있지만 많은 서비스 업체에서는 백업을 하지 않고 서비스를 하는 경우를 흔히 보게 됩니다. IDC에 서버호스팅을 하면 보통 SDD에 HDD를 2개 달아놓고 H
계속 읽기 →외주개발을 해야 한다면 사업을 하다가 IT 서비스가 필요한 경우 개발팀을 관리할 여력도 안돼 부득이 외주개발을 한다면 아래의 내용을 고려해야 한다. 1. 전문개발사에서 외주개발시 미팅한 사람이 개발하는 경우는 거의 없다. 원맨 프리랜서가 불안해서 전문 외주 개발사에 의뢰하는 경우 대리급(3년차 미만)이
계속 읽기 →외주개발 vs 자체개발 스타트업이나 IT 비관련자가 개발을 시작할때 하는 첫번째 허들 무었이 더 좋다라기 보다는 어떤쪽이 지금 내 상황에 적합한가 생각하기 쉽다 대부분 선택은 외주개발 답정너... 왜 개발을 할까? 좋은 아이디어나 상품을 가지고 더 크고 싶다는 소소한 희망으로 시작 개발은 잘 모르겠고 돈
계속 읽기 →어떤 서비스를 만들어야 성공할까? 이 업계에서 가장 많이 들은 질문이다 개발할 수 있는데 뭘 할지 모르겠다는 개발자와 기획자가 주변에 너무 많다 누군가 나에게 물어본다면 너무 많아서 뭘 먼저 해야 할까라고 고민이라고 답한다 세상에 하나뿐인걸 찾지 말고 그냥 아무거나 잘하면 된다고 조언해준다. 10년이 넘
계속 읽기 →아주 오래전 L*사에서 외주형태의 UI 개발을 한적이 있었다. 엄청난 디자인 퀄리티의 기획서를 보고서 역시 대기업이 일을 잘한다고 생각했다. 얼마지나지 않아 애플 아이팟을 하나 구매하고 뒷목을 잡았다. 모든 디자인이과 UI/UX가 아이팟(아이폰)을 똑같이 배낀거였다. OS가 지원하지 않고 어플에서 모든
계속 읽기 →모바일 하이브리드 앱 개발시 뒤로가기 기능의 해결안 서비스를 개발하면 당연히 브라우져기반과 안드로이드 애플 3가지를 항상 고민하게 된다. 많은 개발사에서 이를 해결하기 위해서 3명의 엔지니어가 필요하다고들 한다. 나 또한 초기에 이 3가지를 어떻게 통합할 수 없을까에 상당한 시간을 들였으나 해결하지 못했
계속 읽기 →S/W 엔지니어가 되고 싶다면 SI를 하지 마세요 SI는 대한민국 s/w개발에서 가장 많은 부분을 차지하고 있다 개인적인 생각이지만 SI에 한번 발을 딛으면 영원히 빠져나오지 못하는 개미지옥이 된다. 많은 SI업체도 있고 수익이 많은 곳도 있지만 몇개 업체를 제외한다면 아마도 수많은 작은 개발사들이 힘들
계속 읽기 →인공지능이 개발을 대체할 날이 멀지 않은거 같습니다. 개발만 30년이 넘게 해왔지만 요즘처럼 빠르게 발전하는 기술에 정말 놀랄떄도 많습니다. 이것저것 새로운 기술과 언어로 바뀌고 있지만 아직까지도 C, C++로 만든 제품을 지금도 서비스에 이용하고 있습니다. 개발언어역시 남들이 말하는 구세대 언어에 충실
계속 읽기 →관리자페이지(CRM)을 개발하면서 담당자들과 얘기하다보면 왜 CRM을 만드는지 모르는 경우가 흔합니다. 개발자들또한 CRM을 왜 만드는지 보다는 뭔가를 만들어야 된다는 강박관념에 사로잡혀 있는거 같습니다. 무엇을 봐야 할까가 아니라 무었을 보여줄까에서 시작하는 문제가 제일 큽니다. CRM에서는 가지고 있
계속 읽기 →일본에서 라인의 경영권을 가져가기 위해서 여러가지 공세를 펼치고 있는거 같다. 일본의 대표 메신저이기도 하지만 한국에서도 업무용메신저로 상당히 높은 이용률을 가지고 있는 메신저이다. 메신저를 일본에 뺏기네 어쩌내 하면서 갑자기 다운로드를 많이하는 모습을 보면서 일본에 대해서는 왜 그리 감정적, 적대적이기
계속 읽기 →발신전용 메일계정을 만들기 서비스를 만들면 여러가지 이유로 발신할 메일 계정이 필요하다. 가입메일 인증메일 발송용 또는 구매확인, 각종 마케팅으로 인한 메일발송등의 메일을 사용한다. 과거에 비해서 메일을 보낼일이 줄어들기는 했지만 서비스 개발시 메일을 빼고 개발하기도 쉽지는 않다. 단순 발송용으로 메일을
계속 읽기 →IOS, Android 앱에 표시되는 숫자(뱃지)의 의미 초기 앱의 뱃지숫자는 해당 앱에 읽지 않은 알림의 숫자를 의미했다. 아이폰과 안드로이드 모두가 앱에서 뱃지 숫자를 표시해주는 방식이였으나 안드로이드는 뱃지의 의미를 8.0부터 변경했다. 안드로이드는 알림메세지에 쌓여있는 숫자가 뱃지의 숫자다. 프로
계속 읽기 →UI/UX jQuery를 잘 사용하는방법 웹개발에서 jQuery는 화면 UI를 만들때 가장 기초적인 javascript라이브러리다. 많은 개발자들은 jQuery의 event방법을 잘 모르고 javascript와 onclick에 연결하는 수준으로 사용하는것을 흔하게 볼수 있다. jQuery의 가장 잘쓰기
계속 읽기 →Linux OS는 뭘 써야 할까? 윈도우처럼 라이센스를 생각하지 않아도 돼다보니 작은 회사들은 호스팅에서 제공하는 기본 리눅스 OS를 설치하고 본인이 쓰고 싶은 패키지 설치하고 사용하는 경우가 많다. 이러다 보니 본인이 어떤 버젼 어떤 장르의 OS를 선정하는 것이 아니라 그냥 사용한다. 크게 본다면 ub
계속 읽기 →Native APP vs WebView APP 서비스를 만든다고 하면 웹사이트가 아닌 앱으로 만드는 시대가 되었다. 웹 도메인이 한동한 투자가지를 논하던 시대에서 도메인이 뭔지도 모르는 세상이 되어간다. 브라우져 북마크하는 세상에서 앱스토어에서 검색해서 앱을 쉽게 설치/삭제 하는 시대로 들어갔다. 서비스
계속 읽기 →MySQL(Maria) vs Mongo 보통은 RDBMS 를 이용하여 테이블간의 관계를 잘 정리해서 개발하는것이 데이타베이스의 기본이다. 테이블에 데이타가 많아질경우 1:n, n:m 형태가 되는데 초기에는 속도가 빠르지만 데이타가 많이 들어갈경우 속도는 매우느려지고 서버의 부하가 급증하는 문제가 생긴다.
계속 읽기 →PHP가 천대받는 한국의 환경 웹개발을 할때 주로 PHP를 이용하고 있지만 국내 개발자들은 Java가 선호도가 더 높다. PHP를 써온지 오래되기도 했지만 굳이 다른 언어로 바꿀 필요를 별로 느끼지 못하고 있다. 리눅스 서버에서 기본으로 제공하는 APM 환경이기도 하고 다른언어는 태생이 웹을 위한 언어가
계속 읽기 →리눅스서버 보안기초 서버보안의 필요성은 말이 필요없는 부분이지만 정작 보안을 어떻게 해야하는지는 잘 모르는 경우가 많다 로그인 비밀번호를 복잡하고 자주 바꾸면 안전한게 아니다 비번 로그인은 해킹에는 취약한 방법이다 비번 로그인을 못하게하고 ssh키를 만들어 키로그인만 허용하도록 만들어야한다 키접속은 작업
계속 읽기 →하고있는 일이 회사업무 효율화에 대한부분이다 보니 오랜동안 고민해왔다. 눈에 보이는 생산라인이나 정형화된 업무의 경우는 결과의 질과 양으로 그 결과를 바로바로 알수 있다. 하지만 사무실 업무는 지금 우리가 잘하고 있는가에 대해서 검증이 쉽지 않다고들 한다. 여러가지 방법이 많을것이고 정확하다고 할 수 없
계속 읽기 →