잡담: 롯데마트 치킨과 네이버

카테고리 없음 2010. 12. 11. 01:32

예전에 티비에서 보니까 보통 식당에서 먹는 5000원 짜리 식사의 원가가 보통 1000원 (+-100원) 정도 된다고 하더라. 만약 이걸 가지고 "1000원 짜리를 5000원에 판다고? 이거 폭리 아냐?" 라고 말하면 골룸

멍청한 티비는 "원가"라고 했지만, 실제로는 "식재료 원가" 이다. 이 식재료 원가는 거의 매출과 비례해서 올라가게 된다. 하지만, 임대료, 인건비, 냉/난방비, 전기료 등은 매출과 큰 상관 없이 고정 비용이 발생하게 된다. 즉, 매출이 적으면 적자, 많을수록 흑자폭은 커지는 구조가 된다. 

보통 1.5만원 전후 하는 치킨의 원가(닭) 가 4000원쯤 된다고 한다. 이걸 롯데마트는 5000원에 판다고 하니까 롯데마트가 도매가를 엄청 낮게 맞추지 않는 이상 닭을 팔아서는 돈이 안된다는걸 알 수 있다. 하지만 이걸 사기 위해서 사람들이 몰려들고 주문해 놓고 기다리는 시간동안 다른 매출을 발생시키기 때문에 롯데마트에게는 남는 장사가 될거라고 예상을 할 수 있다.


네이버의 블로그나 까페를 들어가 보면 광고가 하나도 없다. 벼라별 쓰레기 같은 까페나 블로그가 넘치는 넘치는 서비스를 유지하기 위해서 네이버는 엄청난 돈을 쓰고 있다. 즉, 해당 사업부 자체는 완전 적자 사업부.  그럼에도 불구하고 네이버가 돈을 쓰는 이유는 사람들을 네이버 도메인 안에 가두어 두는 효과 (가두리 정책)이 크기 때문이다.

네이버 까페를 쓰던 블로그를 쓰던 사람들은 그 안에서만 놀게 되고, 네이버는 크롤링 로봇을 돌리지 않고도 그냥 디비에 select 때리는 걸로 양질의 검색 디비를 수집할수 있게 되니 결코 손해보는 사업은 아니게 된다.


한때 뭔가 IT 사업을 해보려는 사람들과 이야기를 해보면 많이 듣게 되는 이야기가 "네이버가 이미 하고 있다" "이거 해서 잘되도 네이버가 비슷한거 만들면 그날로 게임끝"  이었다.

실제로도 네이버가 유사 서비스를 제공하면서 망한 크고 작은 서비스가 한둘이 아니다. (실제로 다음의 까페 서비스도 매우 큰 타격을 입었을 것이라고 개인적으로 추측을 한다. 요즘 잘나가는 까페는 전부 네이버에 있더라...)


롯데마트는 양념 치킨은 안팔고 프라이드만 팔고 있다. 암만 봐도 양념은 진입장벽이 좀 있어 보이는데, 프라이드는 조리하는데 기술적 장벽이 없어 보인다. 그래서 수많은 닭집 사장님들도 스트레스를 받고 있을꺼다. 이거 한 10년쯤 수련해야 맛있는 닭을 튀길수 있다면, 마트 치킨쯤 하면서 비웃을 수 있을텐데, 이쪽은 전혀 모르는 내가 암만 봐도 ... 알바 하루이틀 교육하면 비슷한 맛이 나올듯 하다.


요즘 청년 실업과 맞물려서 청년 창업이 유행인듯 하다. 관련된 글을 보다보면 전부 "아이디어"로 창업을 하려는것 같다. 글쎄... 단순히 아이디어로 창업을 하면 덩치큰 회사에서 달려들 때 버텨낼 수 있을까?




앗싸 글빨.

Posted by 키플러
,

잡담: 블로그 웹 트위터

카테고리 없음 2010. 12. 9. 15:50

현재  웹/블로그/트위터에 간간히 글을 올리고 있는데 그 용도가 조금씩 다르다.

* 웹
웹페이지는 내 마음대로 레이아웃을 꾸밀 수 있다. 특히 내용이 업데이트 되는 컨텐츠를 게시하기에 유용하다. 웹페이지를 통해서 프로그램을 배포하는 개인 개발자를 종종 보았지만, 새 버전이 나올때 마다 새로운 게시물을 올리게 되면 매우 불편하다는것을 깨닫게 된다.

소프트웨어가 아니라 문서를 배포하고 싶다면 위키를 설치해서 사용하는것도 좋다.


* 블로그
어떤 주제를 정하고 약간 긴 글을 올릴때 적당하다. 간혹 잘못된 내용이나 변경된 사항이 있을때 수정을 가하기는 하지만, 대부분 1회성이다. 대중 적어 놓으면 검색엔진을 통해서 사용자들이 원하는 글을 찾아오고는 한다.

* 트위터
그야말로 마이크로 블로그. 그때 그때 이슈에 대해서 뭔가 짧게 글을 남기고 싶을때 적당하다. 검색엔진에서 검색을 해주기는 하지만 검색엔진과 별로 친하지는 않다.


아 또 뻘글..


Posted by 키플러
,

독후감: 정의란 무엇인가.

카테고리 없음 2010. 12. 8. 23:34
간단하게 책 소개를 하자면, 마이클 샌델이라는 교수가 하버드대에서 강의하는 과목의 내용을 책으로 엮은거라고 한다. 아마도 우리로 치면 교양수업쯤 되던가, 아니면 철학과 수업쯤이 되지 않을까 싶다.

처음 책의 소개를 보고 도대체 "정의"라는걸 어떤 식으로 설명을 한다는 거지? 라고 생각을 했었는데, 책의 내용은 우리가 중/고등학교때 도덕시간에 배웠던 내용과 비슷하다고 생각을 한다. 

책의 내용을 평가해서 써볼라고 하니.. 나의 무식이 들어날까봐 그만 두겠다. 초반의 "공리"에 관련된 부분은 참 이해하기 쉬웠다. 어디선가 들어본 "절대 다수의 절대 행복" 이 공리이다.  행복을 수치로 나타낼 수 있다고 가정을 하고, 모든 사람들의 행복을 다 더한값이 최대가 되도록 노력을 하는것이 공리주의가 되는것이다. 

사실 나같이 단순한 공돌이에게는 공리주의는 참 맘에 드는 이론이다. 물론 책에서는 공리주의의 문제점과 다른 이론에 대해서 계속 심도있게 토론을 한다.


어디선가 키배나 논쟁이  붙었을때 이 책을 미리 읽어두었다면 유식한척 하면서 우위를 점하는데 도움을 줄것이다.


ㅇㄱㅈㅂ아앙ㅏㅇㄱㅈㄴㅂㅇ아ㄱㅈㅂㅇㄴㅇㄱㅈㅇㅈ 아 글빨 안서네.

Posted by 키플러
,

잡담: 하위 호완성

카테고리 없음 2010. 12. 1. 14:24

맥OS 구경해 보려고 맥북을 샀었다. 물론 원래 생각했던대로 몇번 테스트해보고 XP 깔아서 잘 쓰고 있다.  

애플과 MS는 둘다 PC용 OS를 만드는 (흔치않은) 기업이다. 그런데 이 두 회사의 OS에는 큰 차이가 하나 있다. 이 글의 주제인 하위 호완성이다.

맥은 OS 버전이 올라가면서 하위 호완성을 보장하지 않는다. 사실 잘 안써봐서 어느정도인지 모르지만, 버전이 0.1 이 올라가면서 하위버전OS 에서 돌던 프로그램이 더이상 안돌아 가는 경우도 있다는 글을 읽은적도 있다. 심지어는 OS 에서 사용하는 CPU 도 바꿔 버리기도 한다.

MS 는 하위호완성을 극도로 중요시 한다. 심지어는 하위 OS 에서 잘 돌던 프로그램의 버그로 인해서 새 OS 에서 잘 안돌게 되니까, OS 에서 해당 프로그램을 인식해서 강제로 버그를 우회(?)해서 돌게 했다는 글도 읽은적이 있다. 

얼마나 하위호완성이 잘되냐면, WINDOWS 1.0 용 프로그램이 아직도 실행이 된다고 한다. (WINDOWS VISTA 에서 XP 용 프로그램이 UAC 정책으로 제대로 실행이 안되는 경우가 많아지자 아예 WINDOWS 7 은 VIRTUAL PC 를 이용해서 프로그램을 실행시킬 수 있게까지 해줬다...)

MS 의 하위 호완성에 대한 집착은 WINDOWS CE 에서도 나타났다. CE 용 프로그램을 만들때 조금만 신경쓰면 소스의 99% 를 WIN32 API 와 호완되도록 프로그램을 짤 수있다. 그래서 나도 일단 윈도우용으로 프로그램을 개발하면서 나중에 CE에서도 돌아갈 수 있도록 포팅하는 식으로 개발을 하고는 했었다.

아이팟 터치에 IOS 4.X 를 깔았다. 원래는 3.X 를 썼는데, 4.X 만 지원하는 앱들이 점점 많아지면서 어쩔 수 없이 4를 깔게 되었다.  만약 PC 용 프로그램을 WINDOWS XP 에서는 안돌아 가고 WINDOWS VISTA/7 만 지원하는 프로그램을 내놓는다면? ... 글쎄 그 프로그램은 시장해서 성공하기 힘들꺼다. 하지만 애플이 만드는 OS 시장에서는 이런게 먹혀들고 있다.



사용자들은 당연히 하위 호완성을 개발사에 요구한다. 몇십만원이나 주고 산 프로그램이 새로 산 PC에 설치할 수 없다면 당연히 신경질이 난다. 하지만 개발사 입장에서는 하위호완성을 유지하는것은 매우 고통스러운 작업이다. QA팀이 테스트해야할 항목은 상수적으로 늘어나게 되고, 개발자도 고통스럽다. WIN32 API 를 보면, 똑같은 기능을 하는 API가 얼마나 많은지 모른다. 전부 하위 호완성을 위해서 API를 정리하지 못했기 때문이다.

하위 호완성을 위해서 남겨둔 레거시 코드는 OS와 프로그램을 무겁게 만든다. 난 처음에 맥OS 와 아이팟을 썼을때 그 속도에 깜짝 놀랬었다. MS 에는 바보만 있고, 애플 프로그래머들이 천재였기 때문일까? 그럴리가 없다. 난 그 원인이 OS 개발 정책의 차이에 있다고 본다.


Posted by 키플러
,

코딩: foldername pathname fullpathname filename

카테고리 없음 2010. 11. 24. 12:11

코딩을 하다보면 파일명이나 폴더명을 파라메터로 주고받는 함수를 만들경우가 많은데, 이때 명칭을 제대로 통일시키지 못해서 곤란한 경우가 많았다. 그래서 한번 정리해 봤다.


* folder 와 directory 용어
도스시절에는 directory 였는데,  윈도우로 넘어오면서 folder 라는 말을 쓰기 시작했고.... 그때부더 혼란이 오기 시작했다.

구글에서도 folder vs directory 로 검색해 보면 외국인들도 두 용어의 사용에 혼란(?)을 겪고 있는듯하다.  일단 나는 글자수가 더 적은(-.-) folder 를 선택하기로 했다.

* path 용어
path 는 파일이나 폴더의 경로명을 뜻한다. 즉

- c:\temp
- c:\temp\test.txt

전자는 폴더의 path, 후자는 파일의 path 이다. 문제는 path 는 절대 경로 뿐만 아니라 상대 경로도 포함한다. 따라서

- ..\..\temp\test.xt

도 path 명이다.



* win32 api 살펴보기

폴더를 파라메터로 받는 api 들은 대부분 pathname 이라고 되어 있고, 파일을 파라메터로 받는 경우는 전체 경로 뿐만 아니라, 상대경로도 가능하기 때문에 그냥 filename 으로 되어 있다.  full path file name 를 처리하는 경우에도 그냥 fileName 을 파라메터로 쓰는경우가 많다.

BOOL RemoveDirectory(
  LPCTSTR lpPathName
); 
BOOL PathIsDirectory(      
    LPCTSTR pszPath
);
BOOL CopyFile(
  LPCTSTR lpExistingFileName, 
  LPCTSTR lpNewFileName, 
  BOOL bFailIfExists 
); 
HANDLE CreateFile(
  LPCTSTR lpFileName, 
  DWORD dwDesiredAccess, 
  DWORD dwShareMode, 
  LPSECURITY_ATTRIBUTES lpSecurityAttributes, 
  DWORD dwCreationDisposition, 
  DWORD dwFlagsAndAttributes, 
  HANDLE hTemplateFile
); 
int _mkdir(
   const char *dirname 
);
FILE *fopen( 
   const char* filename, 
   const char* mode 
);
UINT WINAPI GetSystemDirectory(
  __out         LPTSTR lpBuffer,
  __in          UINT uSize
);
BOOL PathFileExists(      
    LPCTSTR pszPath
);

DWORD WINAPI GetModuleFileName(
  __in          HMODULE hModule,
  __out         LPTSTR lpFilename,
  __in          DWORD nSize
);
...A pointer to a buffer that receives the fully-qualified path of the module. ....

DWORD WINAPI GetFullPathName(
  __in          LPCTSTR lpFileName,
  __in          DWORD nBufferLength,
  __out         LPTSTR lpBuffer,
  __out         LPTSTR* lpFilePart
);


* 내가 만든 규칙
이상을 참고해서 다음은 앞으로 내가 코딩할 때 사용할 규칙이다. win32 api 나 다른 사람의 규칙과는 상관이 없으므로 이 글을 읽는 사람은 별 의미는 부여하지 말고 그냥 참고만 하면 되겠다.

- fileName
파일명을 파라메터로 받을 때 사용한다. 이때 파일명에 경로는 포함되지 않는다.
예: 
test.txt

- folderName
폴더를 파라메터로 받을 때 사용한다. 이때 폴더명에 경로는 포함되지 않는다.
예: 
test\
test

- filePathName
경로를 포함한 파일명을 파라메터로 받을 때 사용한다.
예:
test.txt
c:\test.txt
..\test.txt

- folderPathName
경로를 포함한 폴더명을 파라메터로 받을 때 사용한다.
예:
c:\
c:\temp
..\temp\

- pathName
경로를 포함한 폴더 혹은 파일을 파라메터로 받을 때 사용한다.
예:
c:\temp\
c:\temp\test.txt
..\temp\test.txt

- fullPathFileName
절대경로 파일명을 파라메터로 받는다.
예:
c:\temp\test.txt

- fullPathFolderName
절대경로 폴더명을 파라메터로 받는다.
예:
c:\temp\

- fullPathName
절대 경로 폴더 혹은 파일명을 파라메터로 받는다.
예:
c:\temp\
c:\temp\test.txt




Posted by 키플러
,

티스토리툴바