사용자 도구

사이트 도구


독서:코딩도_하고_사장도_합니다

문서의 이전 판입니다!


코딩도 하고, 사장도 합니다

프로그래머가 어떻게 사업을 할까 해서 보았는데, 구체적으로 실무적인 내용을 기대했으나 에세이 형식이라서 실무적인 부분은 직접 찾아봐야 할 것으로 보인다. 앞 부분은 프로그래머에게 이런 저런 충고 하는 이야기들.

고등학교 국어시간에 중국 당송8대가 중 한 사람인 송나라 문인 구양수의 삼다와 삼상에 대해 배웠다. 삼다는 글 잘 짓는 비결이 다독(학교에서는 이렇게 배웠으나 원문에는 다문(多聞 들을 문) 으로 되어 있다), 다작, 다상량, 즉 많이 읽고, 많이 짓고, 많이 생각하라는 뜻이다. 프로그램을 잘 만드는 비결 또한 이와 같다. p.108
“몰입의 즐거움/미하이 칙센트미하이” 인용
명확한 목표가 주어져 있고 활동의 효과를 곧바로 확인할 수 있으며, 과제의 난이도와 실력이 알맞게 균형을 이루면 정신을 체계적으로 집중하여 몰입 상태에 빠져들 수 있다. 예를 들어 뛰어난 실력을 지닌 피아니스트가 그의 실력에 걸맞은 난이도 높은 곡을 집중하여 연주하면서 무아지경에 이른 상태를 말한다. p.120
윈도우는 “내가 너를 부를게, 너는 내가 부를 때까지 준비하고 기다려” 하고 말한다. DOS에 젖은 프로그래머는 “무슨 소리야, 내가 왜 널기다려. 내가 부르면 네가 와야지” 한다. 사람들은 정들고 아끼며 익숙한 걸 버리기 싫어한다. 그러다가 정든 그것과 함께 사라져간다. p.143
금융감독원 통합연금포털에서 본인이 가입한 모든 연금의 상세 내역과 매달 받을 수 있는 금액을 확인할 수 있다. p.209
기업이 안정되려면 돈이 있어야 한다. 특히 빚이 아닌 순수한 자기 자본이 어느 정도는 있어야 한다. 이는 일반적으로 작원 1인당 자본총계를 보면 알 수 있다. 이 또한 경험으로 보아 1인당 자본총계가 1억 원이면 안정된 회사로 볼 수 있다. p.228
내가 처음 창업하고 1년도 안돼 접으면서 전문가에게 들었던 평가는 '자본주의를 너무 모른다'였다. 그렇다. 자본주의의 원리(시스템)에 대한 이해 없이 창업에 뛰어들지 말라는 얘기였다. 요즘은 이에 대한 좋은 책이 많다. 그중 한권만 꼽으라면 «EBS 다큐프라임-자본주의»(가나출판사, 2013)인데, 경제학 지식이 없는 사람도 비교적 쉽게 이해할 수 있다.
창업하기 전에 알아두어야 할 게 또 있다. 특정 기간의 사업 실적을 나타내는 손익계산서와 특정 시점의 회사 재무 상태를 보여주는 재무상태표(대차대조표) 정도는 볼 줄 알아야 한다. 기본적인 회계와 세금에 관한 상식도 알아두는게 좋다. p.274
바로 창업을 하고 회사를 운영한다는 것은 엄청난 스트레스라는 점이다. 망할 수 있다는 공포와 두려움이 근원적 스트레스고, 가장 큰 건 회사 내 인간관계에서 오는 스트레스다. 회사에서 월글읍 받는 입장에서 겪는 스트레스와 월급을 주는 입장에서겪는 스트레스는 그 강도가 확연히 다르다. 어느 입장에 있는게 행복할지 냉정히 따져볼 일이다. 그게 싫으면 직원 없이 1인 기업가로살아가는 것도 괜찮다. p.278
세 번째가 무자본 창업이다. 남에게 빌리지도 말고 투자받지도 말고 내 돈도 쓰지 않는 방식이다. 돈 없이 어떻게 창업을 하란 말인가? 먼저 벌어서 쓰라는 얘기다. 앞의 두 방식은 돈을 먼저 쓰고 나중에 번다. 돈을 벌려면 먼저 제품을 만들어야 하고, 거기에 인건비도 들고 재료비, 장비비 그리고 기타 경비가 발생하는데 어떻게 먼저 번다는 말인가? 먼저 판매하고 그 돈으로 나중에 생산하라는 얘기다. p.290
가장 참고할 만한 책을 꼽으라면 «해적들의 창업 이야기»(비전코리아, 2006)다. 무자본 창업의 필요성과 방법을 가장 잘 설명하고 있으며, 무엇보다도 여러 실제 사례를 통해 이해하기 쉽다.
예시) 책 쓰기, 강의, 블로그, 창업전 제품 미리 개발/발표. 팔수 있는 완성품을 만들어서 팔아줄 회사를 찾음.
무자본 창업의 핵심은 비용을 들이지 않는 것이다. 이를 가능하게 하는 방법은 몸빵과 절약이다. p.291
사업 아이템을 선정했으면 반드시 거쳐야 할 과정이 바로 법적 검토이다. 우선 사람들의 상식적인 잣대에 비추어 문제가 없는지 함께 의견을 누눠 보는것에서 출발한다. 조금이라도 미심쩍은 점이 있다면 어떤 법적 규제나 제한은 없는지, 특허를침해할 소지는 없는지를 집중 검토해야 한다. p.309
법적인 검토는 꼭 규제나 제한을 피해 가기 위해서뿐 아니라 때로는 이를 이용하기 위해서도 필요하다. 법적으로 반드시 내가 만든 프로그램을 써야만 하는 상황으로 해석되는 조항이 있다면 어떻게 해야 할지는 말 안해도 알 것이다. p.310
정부의 고용관련 지원정책도 알아두면 도움이 된다. 예를 들어 정부에서 급여의 50%를 일정 기간 지원해주는 정책 같은 게 있는데, 필요한 인력과 맞으면 큰 도움이 된다. 이는 매년 수시로 바뀌면서 정책이 생겼다가 없어졌다 하므로 필요할 때 관심을 가지고 검토해야한다. p.325
법과 친해져야 한다.
기업을 운영하는 데 필요한 기초적인 법 내용은 잘 숙지해야 한다. 보통 연말이나 연초에 바뀌는 법 조항이 소개된다. 특히 고용에 관한 법률 조항은 잘 이해하고 지켜야 한다. p.325
여기서 법무사나 세무사에게 맡기면 다 알아서 해주는데 무얼 그리 고민하냐고 생각할 수도 있다. 그런데 법이란 게 수시로 바뀌며, 그 사람이 상대하는 회사가 수십 수백 개인데 꼼꼼하게 일일이 다 알아서 해주기에는 한계가 있다. 그리고큰 틀에서 개념을 알고 맡기는 것과 전혀 모르고 맡기는 것에는 차이가 크다. p.327
벌금, 과태료, 과징금, 연체료 등 부주의나 또는 몰라서 실수하기쉬운 것에 대해 미리 알아보고 목록을 만들어두는게 좋다. 예를 들어, 법인 기업은 대표이사가 이사를 가면 주소 변경에 따른 등기를 변경해야 한다. p.327
세금절감을 위한 관련 법을 알아둔다
중소기업은 세액 감면을 위한 여러 조세특례 관련 법이 있다. 세세한 것까지 알 필요는 없다. .. 필요할 때 찾아보거나 전문가에게 물어보면 된다.
기업 부설 연구소를 설립하면 연구 개발비에 대한 세액 공제가 있다. … 특히 수익이 증가하기 시작하면 필요하다.
벤처기업 인증을 받으면 법인세 등 몇 가지 세금 감면 혜택이 있다. 그런데 그 내용이 자주 바뀐다. 여기서 핵심은 창업하고 나서 정해진 연도 안에 벤처기업 승인을 받아야 실제적인 혜택이 있다는 점이다. 몇 년마다 한 번씩 심사받느라 번거롭고 돈이 든다. 홍보 효과도 있고 한마디로 폼은 좀 난다고 하는데 실익이 없으면 별로 권하고 싶지 않다. p.328
정책자금에 관심을 갖지 않는다.
대출이자가 예금이자보다 싸고 중도상황 수수료도 없는 경우다. 자금을 받아서 은행에 그냥 넣어두면 된다. 그러다가 예금이자가 대출이자보다 떨어지면 갚아버린다… 예기치 밚은 변수가 있을 수 있으니 신중해야 한다. p.329
회계 업무는 직접 한다.
한 달 또는 석 달에 한 번 영수증을 모아서 세무사나 회계사 사무실에 맡겨서 처리하게 된다. 이를 흔히 '기장 대리'라고 한다. .. 그러나 이렇게 기장 대리를 맡기지 말고 회계 업무는 회사에서 직접 하는 게 좋다.
기장 대리의 가장 큰 문제는 재무 상태나 손익을 비롯한 주요 경영 지표를 실시간으로 확인해 볼 수 없다는 점이다.
시중에 나와 있는 매월 저렴하게 얼마씩 내고 쓰는 회계 관리 프로그램을 도입하면 이 모든 게 해결된다. 발생하는 대로 전표를 바로 입력하면 언제든 실시간으로 알고싶은 재무상태나 손익 등 많은 자료를 정확히 확인할 수 있어 좋다.
그렇더라도 세무사 사무실에비용을 어느 정도 지불하고 관계를 맺는 게 좋다. 회사에서 직접 회계 업무를 한다 해도 전문가에게 물어봐야 할 일도 있고 상의해야 될 일도 있기 때문이다. p.329
흔쾌히 을이 되어주는 것은 어렵지 않은데, 요구 조건에 따라 그에 걸맞은 안전 장치로 보증을 걸어야 하는 경우가 있다. 예를 들어 판매 금액의 80%를 갑에게 주는 대신 매월 최소 1천만 원을 받는 조건(판매액의 20%가 1천만 원을 넘으면 ,0%, 1천만 원 미만이면 무조건 1천만 원) 등과 같이 계약하는 게 좋다. p.334
커스터마이징은 용역비에 제품 비용을 포함하여 매출을 올릴수 있기 때문에 가장 좋은 방식으로 볼 수 있다. 하지만 고객이 늘어감에 따라 수많은 맞춤 변형 제품 또한 늘어나서, 제품 관리가 힘들고 투입되는 인력도 증가하여 수익률은 점점 떨어진다. p.335
하지만 내 제품이 있으면 용역을 하더라도 여러모로 유리하다. 우선 해당 분야의 전문성을 인정받을 수 있어 수주에 유리하고, 수익률을 높일 수 있으며, 제품의 직접 또는 위탁 판매에도 효과가 있다. .. 용역 수행으로 쌓은 기술을 모아 내 제품을 만드는 게 좋다. 여기서 제품이란 그대로 팔 수 있는 완제품을 말한다. p.337
정부 과제는 그 자체로 수익을 낸다기 보다는 본래의 목적과 취지에 맞게 기술을 연구하고 이를 이용하여 원하는 제품을 개발할 수 있다면 큰 도움이 된다. p.337
나는 제품(소프트웨어)의 소스코드를 제공하고, 이를 이용하여 외주 개발을 수행하는 업체로부터 5년 정도 기술료를 받기도 했다. p.338
이자 수익은 직접 매출로 발생하는 것은 아니다. 하지만 해가 거듭되고 수익이 쌓여가면 이를 어떻게 활용하느냐에 따라 영업 외 수익이 달라진다. 당연한 얘기지만 높은 수익이 나는 곳에 투자해두어야 한다. 회사 돈을 주식이나 펀드 등으로 굴리는 담당 직원을 둔 회사도 본 적이 있다. … 그저 안전한 은행 중에서 그나마 금리가 높은 곳에 넣어두고 신경 끄는 게 좋다. p.338
발주기관의 우선 순위를 정한다.
소프트웨어 개발을 발주하는 가장 큰 기관은 정부와 공기업 그리고 대기업이다. 정부 기관도 중앙 부처에서 부터 외청 기관, 지방 자치 단체에 이르기까지 그 수가 헤아릴 수 없이 많다. p.340
수주하려는 분야의 완성 제품을 보유하고 있어야 한다. 근사한 제품 이름도 짓고 저작권 등록도 하고 가격도 책정하여 홈페이지에 공개한다. … 보유 기술이나 솔루션은 무얼 말하는지 애매할뿐더러 잠재적 능력에 불과하다. 반면에 제품은 발주업체에게 이미 실현된 능력으로 보인다. p.341
완성된제품이 있다면 이것을 해당 프로젝트의 필요 소프트웨어로 포함시킬 수 있다. 이것은 마치 필요한 하드웨어 장비나 OS, DBMS 처럼 따로 구입해야할 품목으로 가격을 책정할 수 있다는 뜻이다.
만약 완제품 형태가 아닌 반제품 개념의 라이브러리 형태로 가지고 있다면 어떻게 해야 할까? 이때도 무조건 완제품으로 브랜드를 만들고 유저당, 서버당, 프로세서당 얼마라는 가격을 매기고 이와 같은 방식으로 해야 한다. p.342
규모가 큰 SI 프로젝트의 하청을 받아 개발 용역을 수행하는 것은 통제할 수 없는 여러 위험 요소가 있다. 우선 하청의 단계가 많아지면 단가가 떨어지고 수익성이 나쁘다. … 이런 방식의 개발 용역에는 하청을 주는 회사와 위험 요소를 감안하여 확신한 계약을 따로 맺는 게 좋다.
반면에 소프트웨어만 단독으ㄹ 발주하는 프로젝트는 규모가 작기 때문에 발주사로부터 직접 수주할 수 있다. p.343
입찰하는 큰 프로젝트보다는 수의계약하는 작은 프로젝트 여러 개가 수익성 면에서더 나을 수 있다. p.344
프로젝트의 금액 규모가 크면 그만큼 위험 부담도 커진다. 따라서 회사의 재무 상태를 감안하여 일정 금액 이상의 프로젝트에는 참여하지 않는게 안전하다. p.344
다음 프로젝트에서 보상하겠다는 말로 이번에는 싸게 해달라고 하거나, ' 전략적제휴'나 장기적으로 볼 때 'win-win' 이라는 등으로 공짜나 단가를 낮출 것을 제의받을 때가 있다. 나는 이런 요구에 한 번도 응해본 적이 없다. 시야가 좁아서인지 몰라도 소프트웨어 개발 용역 시장에 '다음은 없다'는 생각을 갖고 있다. p.345
보통 1 Man/Month 당 1천 2백만원에 미치지 못하면 참여하지 않았다. p.346
발주받고 싶은 기관의 관련 업무를 미리 파악하고 프로젝트 기획서를 작성하여 담당 부서에 전달할 필요가 있다. … 설령 나중에 이 프로젝트가 공정한 경쟁 입찰에 붙여진다 하더라도 공고 후 10여 일 남짓의 기간에 작성된 제안서가 미리 1년 전부터 준비하고 다듬어진 제안서를 이기기는 힘들다.
특히 1억 원 미만의 수의계약이 가능한 비교적 작은 프로젝트의 기획서를 여러 건 만들어두고, 이것을 그해 9월 정도에 발주기관 담당자의 손에 들어가도록 하는게 중요하다. p.348
프로젝트의 성공은 기술력으로만 이루어지지 않는다. 기술력은 필요조건이고 거기에 발주사 사람들과의 좋은 인간관계라는 충분조건이 더해져야 성공할 수 있다. p.348
인간관계의 첫걸음은 인사성이다. 특히 발주사로 파견 나가는 직원은 어떻게 인사해야 하는지 철저히 교육시켜 보내야 한다. 아는 사람이든 모르는 사람이든 언제 어디서 마주치든 시도 때도 없이 무조건 인사하도록 한다. 모르는 사람에게는 어떻게 인사할 것인가, 아는 사람에게 상황에 맞는 적절한 인사말 멘트는 무엇인가 등의 인사법에 대한 회사의 규정을 만들어놓는 것도 좋다. p.348
(프로젝트 이름에 현업 전문가의 “이름 약자type” 같이 넣어주는 식)으로 참여한 현업 전문가(domain expert)를 대접해 줄 요소를 잘 찾아봐야 한다. 중간 발표나 최종 발표 등의 행사에도 참여한 전문가에게 의향을 물어 한 부분을 직접 설명하도록 하면 좋다.완료보고서, 매뉴얼등에도 이름을 올려준다. p.350
완료 기한을 반드시 지킨다
기한 안에 마치지 못할 것 같으면 반드시 해야할 기능의 우선 순위를 정하고 완료일까지 가능한 부분만 마치고 모두 마친것으로 완료보고서를 쓰고 검수를 통과하는 능력도 필요하다. 사소하게 미진한 것들은 하자보수 기간에도 얼마든지 보충할 수 있다. p.350
독서/코딩도_하고_사장도_합니다.1711037085.txt.gz · 마지막으로 수정됨: 2024/03/22 01:04 저자 kwon37xi