오늘 오전부터 SVN에서 커밋 진행 하면 오류가 나오기 시작 했다. 오류 메세지는 쌩뚱 맞게 ..


Commit failed (datails follow)

 database disk image is malformed 


cleanup 부터 온갖 방법으로 해결을 도모 하였으나, 오류 메세지는 꿈쩍도 하지 않았다.


확인을 해보니 SVN에서 SQLite 를 이용하는데, 이 SQLite 에서 어떤 이유에서인지 table이 깨진 경우 이런 결과가 나온다. SVN에서 서버의 rep-cache.db 파일을 SQLite로 관리를 진행 하고 있으므로, 그 DB 안의 어떤 Table이 오류가 난 것..


해결 방법을 한참을 고민하다가 이렇게 접근을 시작했다.


머너 sqlite3 콘솔을 다운로드 받고 ( http://www.sqlite.org/ ) db 파일을 읽어본다.


커맨드창에서 아래의 명령을 입력 했을때 해당 DB의 무결성 검사를 진행 하게 된다. 만약 여기서 Ok 가 뜨지 않는다면, 해당 DB 파일에 문제가 있는 것이다.


sqlite3  rep-cache.db  "pragma integrity_check"


명령을 진행 하고, 오류가 발견 될 경우 database disk image is malformed  와 같은 오류 메세지가 다시 출력 된다. 그때 조금 저 자세한 정보(?)를 포함하고 오류를 뱉어낸다.


어떤 Table 에서 오류가 발생 했는지 확인 하기 위해서는 sqlite3에서 일일이 테이블을 확인 해봐야 한다. 


SQL로 select * [table] 등으로 진행 해보면 됨. 



해결 방법으로는 여러 방법이 있다. SVN일 경우 제일 빠르고 좋은 해결 방법은 그냥 rep-cache.db 파일을 삭제 하는 것이다. 삭제 하면 SVN이 사용시마다 자동으로 재 생성해서 만든다. 오류가 해결! 최고의 방법이었다 :)



SVN이 아닌 보존 해야 하는 데이터라면, SQLite에서 해당 table을 export 하고 다시 다른 db 파일을 생성해서 import 하는 방법이 있다. 이 경우 테이블 내에 있는 오류난 데이터는 복구 못할 가능성도 있다. 


커맨드 창에서 아래의 방법으로 복구 하면 된다.


sqlite3  [db 파일]


sqlite3> .mode insert

sqlite3> .output [export 후 저장 파일명].sql

sqlite3> .dump


해당 명령으로 [export 후 저장 파일명].sql 파일로 스크립트를 export 하고 이후에 아래 명령을 진행 하면 새 [new db 파일] 이 생성 된다.


sqlite3 [new db 파일]


sqlite3> .read [export 후 저장 파일명].sql


그리고 .exit 명령으로 나와서 해당 db를 이용하면 끝~!




posted by Yuno.org


오늘은 일찍 퇴근해서 집에 오자마자 한 숨 자고 조금 전에 깼습니다. 뉴스를 보다가 스티브 잡스에 대한 기사가 하나 있더군요. 매일 경제에 있던 기사 였는데, 애플의 주가가 40배 넘게 뛰었다는 기사였습니다 그런데, 이 기사에서 눈길이 가는 문장이 하나 있었습니다.
 
듣지도 보지도 못한 혁신적인 제품으로 시장을 선도하기보다는 기존 제품 가운데 대박 가능성이 높은 제품을 찾아내 그 제품을 획기적으로 개선하는 전략을 선택한 것이다.

최근에 새로운 게임에 대한 생각을 한적 있었는데, 제일 많이 들은 이야기 몇가지는 레드오션, 새로운 것.. 이런 것들이었습니다. 저는 개인적으로 게임은 예능으로써의 성격으로 인하여, 선점된 것들이 뺏을 수 없는 시장이라고 보지 않습니다. 오히려 저는 레드 오션과 같은 개척된 시장은 개척 해야 하는 곳 보다 더 장점이 많다고 생각되어 지는데 말이죠.

얼마든지, 내 제품의 경쟁력 강화를 통해서 시장에서의 점유율 확대를 노릴 수 있다고 생각합니다. 세상에서 제일 무서운 시장 진입 방법은 잠식이 아닐까요? 정말, 서서히 서서히 잠식해 나가는것 정말 무섭습니다. 잠식을 통해서 확대한 점유율은 어떤 계기가 생기면 폭발적으로 늘어나기도 합니다. 문제는 어떻게 잠식 하느냐의 문제겠죠.

애플 이야기를 뺄 수가 없군요.

스티브 잡스가 MP3 PLAYER 를 처음 들고 나왔을때 좀 냉소적으로 바라볼 수 밖에 없었습니다. 이미 시장은 한국이나 다른 회사들이 선점하고 있었고, 레드 오션이 아닌가? 하는 이야기가 나오는 상황이었습니다. 그런데, 기존 제품들 처럼 음악 플레이어임에도 기존에는 그냥 지나쳤던 부분들을 개선한 이 아이팟이란 녀석은 정말 서서히 시장을 잠식해나갔습니다. 아이팟이 처음 세상에 나왔을때의 관심과 최근에 아이폰이 나올때의 세상이 보이는 관심의 정도는 엄청난 차이를 변화가 있었습니다. 어쨋든, 개선된 녀석은 천천히 시장을 잠식했고, 클래식 아이팟 3G가 나올때 정도부터 점유율이 크게 늘어나기 시작하더니, 아이팟 미니와 나노를 기점으로 폭발적으로 성장합니다.

아이팟이 뜬 이유. 사실, 간단한 접근이었습니다. 기존의 MP3 PLAYER들이 가지고 있던 불편함을 개선하고, MP3가 가지고 있는 본연의 기능을 충실히 이행하자였습니다. 무슨 뜻이냐구요? 저는 MP3 PLAYER 를 초창기부터 사용을 했는데, 아이팟을 처음 쓰고 제일 놀라웠던 것은 기존의 폴더 접근 방식이 아닌 새로운 방식의 UI 를 사용 한다는 것, 그리고 MP3에 있던 기능이지만 아무도 신경 안쓰던 메타(태그) 기능을 사용한다는 것이었습니다. 아무도 거들떠 보지도 않고 당연히 여기고, 신경 쓰지 않던 것들을 애플에서 적극적으로 개선하고, 이용하면서 원래부터 있던 것임에도 불구하고 획기적이라는 생각이 들었던 겁니다.

MP3P 본연의 기능 보다도 다른 것들에 더 신경을 쓰던 다른 업체들은 결국 선점한 시장도 빼앗기고 맙니다. 음악만 나오면 되지, 용량만 키워주면 되는거지. 이런 기능도 넣어 주지. 이것도, 저것도 넣어 줄께. 이런 생각은 ...결국 부가 기능이라고는 쓰잘데 없던 아이팟에게 몽땅 뺏겨 버리게 되는 결말을 불러오게 됩니다.

온라인 게임... 매달 새로운 온라인 게임이 출시 되는 한국에서는 정말 끊임 없이 나온다는 느낌이 듭니다. 그런데, 아이러니 하게도 매번 새로운 것이라고 나오는데도 불구하고 전에 나온 것과 달라진 것은 없습니다. 변화가 없습니다. 그래픽은 다른데, 케릭터 모양도, 맵의 모양도 다 다른 것 같은데 왜 비슷한 게임 처럼 느껴지는 걸까요?  (그래픽을 이야기 하는게 아닙니다) 게임 그 본질에 대한 완성도는 신경쓰지 않는 것 같습니다.

기존 RPG에서 중요하게 여기던 스토리는 더 이상 중요한게 아닙니다. 화려한 그래픽이 제일 중요하다고 여기는 제작자(기획자가 아닌 제작자입니다)들이 많습니다. 전체적인 즐거움 보다는 순간의 즐거움을 더 중요히 여깁니다. 소위 타격감에 올인 하기도 하고, 게임성을 해치는 편리 기능을 강조 하기도 합니다. 말이 좋아 MMORPG지 R은 시나리오가 약해지면서 사라졌습니다. 자유도라는 명목하에 Role은 알아서 조달이 되어버린거죠. 결국 대부분의 한국형 게임 내에서의 Role 마우스 클릭과 단축키가 되어버리고 말았습니다.

네, 저는 국내 게임 제작 점점 산으로 가고 있다는 생각이 듭니다. 계승-개선을 통한 변화, 발전 보다는 항상 다시 만들다 보니 시행 착오에 의한게 아닌 그냥 비슷한 것들만 나오는 상황에 빠지는 것 같습니다.

게임 회사들이 게임을 제작 할때, 자사가 가지고 있는 실패한 게임, 성공한 게임에 관계 없이 게임성을 비롯한, 사업적 측면, 기술적인 측면 등을 보완해서 새로운 게임을 만든다면 발전을 통한 완성도 있는 게임을 만들 수 있을텐데... 라는 생각이 떠나지 않는 요 몇일입니다.

최근에 크게 성장한 웹 게임 업체인 징가는 조금 더 공격적인 방법을 이용합니다. 소위 Copy and Crush 라는 전략이죠. 될 것 같은 것을 찾아서 비슷하게 만들되 원작 보다 더 잘만드는 겁니다. 원작이 시장 개척이고 뭐고 할 겨를도 없습니다. 통채로 뺏기는 거죠. 물론 개발 기간이 비교적 짧은 웹 게임이기 때문이기는 합니다만... 어쨋든, 벤치 마킹을 통해서 '개선' 하고 그 '개선' 결과를 이용해서 완성도를 높이는 방법.. 나쁘지 않을 것 같다는 생각이 듭니다.

뭐 그렇다고 개선해서 본 게임을 패치 할 수는 없습니다. 개선인데 왜 안되냐구요? 그건 게임이 달라지기 때문입니다. 작은 개선이야 상관 없지만, 대대적인 개선과 보완 작업은 전혀 다른 게임으로 만들어 버리고 말테니까요. 그럴 바에는 개선과 변형을 하고 새로운 내용을 얹어서 라인업을 하나 더 갖추는게 더 좋을 것 같습니다. 물론 어느 정도의 자기 잠식 효과가 있기는 하겠지만, 그로 인한 풀의 증가가 더 클테니까요.

뭐.. 그냥 최근에 든 생각이었습니다. 쓰다보니 벌써 새벽 6시가 넘었군요. 자다 일어난 거지만, 반쯤 감긴 눈과 반 정도는 멈춰버린 머리를 가지고 쓴 넋두리이다 보니 그냥 개선이나 보완, 변경을 이용한 새 게임도 나쁘지 않지 않을까. 정도로 봐주세요 -_-


posted by Yuno.org


예전에 NSIS를 이용 할 경우 대용량 파일을 배포 할때 오류가 나는 문제에 대해서 포스팅을 한 적이 있다. (자세한 내용은 http://www.yuno.org/295 을 참고)

이 때, 해결 했던 방법 중에서 일반적으로 쓰인 방법이 인스톨러와 데이터 파일을 배포해서 2개 이상의 파일을 이용한 배포였다. 그런데, NSIS 자체에서 압축 기능을 지원하고는 있지만, 별도의 압축 파일을 처리 하는 모듈은 없기 때문에 NSIS의 EXCUTE SCRIPT 를 이용해서 COMMAND로 실행 가능한 7Z 압축 바이너리에 압축 풀 파일을 넘겨주어 압축을 푸는 방식을 이용했다.

즉, INSTALL.EXE 와 DATA.7Z 이렇게 2개의 파일을 배포 하지만 INSTALL.EXE 는 설치 능력은 있지만 DATA.7Z 파일의 압축을 풀 능력이 없기 때문에 INSTALL.EXE 자체에 7Z.EXE 를 함께 넣어서 설치 과정중에 7Z.EXE를 별도의 프로세스로 실행해서 DATA.7Z 를 압축 푸는 방식을 이용했다.

하지만, 이 방식이 조금 문제가 있는 것이.. 표준 스트림 버퍼를 이용을 하고는 있지만 7Z.EXE 에서 출력 되는 메세지가 이유를 알 수 없게 버퍼링이 되어서 현재 상태를 바로 보여 줄 수 없다는 문제가 있다. 다시 말하면, 100개의 파일을 압축 푸는데, 어떤 파일을 압축을 풀었다 라고 100번의 메세지가 DETAIL LOG에 나와야 하지만 어떠한 이유에서 이 출력될 LOG가 버퍼링 되어서 뭉쳐서 나오는 문제가 생긴 것이다.

따라서 설치 시간이 오래 걸리는 대용량 설치의 경우 유저들은 이게 설치가 되는건가? 하는 의구심을 품게 된다. 또한 현재 설치가 어느 정도 진행 됐는지 알 수가 없어서 답답함을 가질 수 밖에 없었다.

우리 회사에서도 NSIS를 이용한 배포를 하는데 항상 저 문제가 마음에 걸렸다. 언젠가 시간이 나면 NSIS용 7Z PLUG-IN을 만들어야겠다! 라고 생각하고 있었는데, 최근에 제작 할 시간이 생겨서 작업을 시작하고 보니.. 이런! 이미 나와있다. -_-

Nsis7z plug-in ( 참고 : http://nsis.sourceforge.net/Nsis7z_plug-in ) 을 이용할 경우 NSIS 인스톨러를 이용해서 압축을 풀 수 있게 된다. 대용량 파일을 압축 풀더라도 버퍼링으로 인한 메세지가 밀려서 나오는 문제도 해결 할 수 있을 뿐만 아니라, 현재 설치 상태를 % 로도 표시를 할 수 있다.

사용법도 매우 간단해서, 기존의 처럼 7Z.EXE 를 더 이상 인스톨러에 포함하지 않아도 된다. 플러그인을 다운 받아서 NSIS7Z.DLL 파일은 NSIS의 PLUGIN 폴더에 넣어주면 준비 끝. 그 다음에는 인스톨 스크립트에 몇줄만 추가 하면 완료다.

이 플러그인을 이용 할 경우 2가지 배포 방법을 이용 할 수 있다.

NSIS는 인스톨러 컴파일을 할때 설치 데이터를 인스톨러에 함께 묶는데, 1) 이때 데이터 파일을 함께 묶는 방법, 그리고 2) 데이터 파일을 인스톨러와 별도로 배포 하는 방법으로 나뉘어 진다

1)의 경우는 작은 용량의 배포에 알맞다.
2)의 경우는 대용량 파일을 배포 할때 알맞다. NSIS가 단일 파일을 2GB 이상 지원 하지 않기 때문에 2GB 이상의 데이터를 배포 한다면 별개의 데이터 파일로 배포 하는 것이 좋다.

또한 비스타에서 실행 파일의 용량이 대용량일 경우 실행 시간이 매우 오래 걸리는 문제가 있는데, 이 문제 역시 별도의 데이터 파일을 이용 할 경우 해결 된다.


자, 그러면 플러그인에서 지원하는 명령어들을 확인해 보자. 이 플러그인은 총 3개의 명령어를 지원한다.

Nsis7z::Extract

제일 기본 적인 압축 해제 명령으로 Nsis7z::Extract "ArchiveName.7z" 와 같은 방식으로 사용을 한다. 압축이 풀리는 동안 인스톨러에 표시 되는 프로그레스바는 정상적으로 그 값을 표시 한다.

참고로, 인스톨러의 실행 위치에 함께 있는 파일을 압축 풀기 위해서는
Nsis7z::Extract "$EXEDIR\ArchiveName.7z" 로 경로를 함께 지정해주어야 한다.

경로를 반환하는 상수들에 대해서는 여기를 참고!

Nsis7z::ExtractWithDetails

기본 압축 해제 명령에 % 표시 기능을 추가 한 명령.
Nsis7z::ExtractWithDetails "DATA.7z" "Installing package %s..." 와 같이 2번째 파라미터에 스트링을 넘겨 주면 그에 알맞게 % 표시를 해준다. 위의 명령을 예로 들면 Installing package %s... 을 Installing package 퍼센트% ( 현재 용량 / 전체 용량 ) 으로 표시해준다.

Nsis7z::ExtractWithCallback

마지막으로 ExtractWithCallback의 경우 압축을 다 푼후 지정한 콜백 함수를 호출한다. 콜백을 호출 해줄 뿐 명령 자체는 Extract와 동일하다.

GetFunctionAddress $R9 CallbackFunction  ; CallbackFunction의 호출 주소를 $R9에 저장
Nsis7z::ExtractWithCallback "Data.7z" $R9 ; Data.7z의 압축 해제 후 $R9 주소 함수 호출


위의 3개 함수를 이용하면 각 현재 진행 상태를 안정적으로 표시 할 수 있다. 다만, 이 플러그인의 조금 아쉬운 점은 압축 풀고 있는 파일명을 표시 안해주는 것이다. 하지만, 이 플러그인은 코드가 공개 되어 있으므로 조금만 수정하면 현재 압축 해제 파일명을 DetailPrint 를 이용하여 표시하는 것은 큰 문제가 되지 않을 것이라 생각된다.

posted by Yuno.org
  • Gerbera 2011.02.18 11:32

    NSIS 로 setup 배포할려고하는데 질문있어서 글올립니다.
    현재 배포시키려는 데이터 용량은 10기가 정도인데요
    용량이 크다보니깐 dvd 로 굽는데도 10기가를 나눠서 굽어야하는 문제점이 발생하네요
    분할 압축을 하여 7z 플러그인 명령어는 분할압축데이터에는 먹히질 않는거 같고;
    ExecWait 명령으로 7z 분할 압축 된것을 풀려고 시도를 해봤는데 dvd 로 나누어서 압축 데이터를 넣다보니 압축해제가 되질 않네요
    NSIS로 데이터 10 기가를 dvd 3장으로 나누어서 배포 할 수 있는 방법은 없을까요?

    • Yuno 2011.02.18 12:02

      두가지 방법이 있을것 같습니다.

      처음에는 7z 플러그인 자체를 수정 하는 방법..

      7z 의 플러그인의 코드가 공개 되어 있습니다~ 분할압축데이터에 적용이 가능하도록 플러그인을 수정하는게 제일 깔끔해 보일 것 같습니다.

      두번째는 데이터가 10기가라고는 하지만, 데이터가 실제로는 분할 되어 있다는 가정을 한다면 DVD 여러장에 맞도록 데이터를 분할해서 임의로 압축하고 (파일을 수동으로 나눠서 압축 한다고 생각하시면 될듯)

      NSIS 에서 디스크 1, 2, 3.. 등에 해당하는 스크립트를 따로 제작해서 1번 압축이 끝나면 2번을 넣어 달라는 메세지 형식으로 하는 방법이 있을 것 같습니다.



몇년 전에 읽었던 "조엘 온 소프트웨어"라는 책이 있습니다. 혹시 아직 안보신 개발자 또는 개발자와 함께 일하시는 분들은 한번 읽어 보시기를 추천합니다 ; 이 책의 22장에 보면 " 테스터를 두지 않는 (잘못된) 다섯가지 이유 " 라는 부분이 있습니다. 

다섯가지 이유를 저자는  1)  버그는 프로그래머가 게을러서 생기니까요.  2) 우리 소프트웨어는 웹에 올려놓아서 버그는 금방 고쳐질 수 있으니까요. 3) 고객이 소프트웨어를 테스트해줄 테니까요. 4) 우수한 테스터는 테스터로 일하려고 하지 않거든요. 5) 테스터를 고용할 돈이 없으니까요. 로 들고 있습니다.

이러한 이유를 들어서 테스터를 두지 않는 다면 멍청한 짓이다! 라고 저자는 이야기 하고 있습니다. 저 역시 이 부분을 상당 부분 동감합니다. 제가 지금까지 보고, 겪은 거의 모든 회사는 출시 전날까지 작업을 합니다. 심지어는 패키징 하기 직전까지 코드 작업을 하는 경우가 있습니다. 그나마 그 작업이 버그 수정이라면 다행이지만, 기능 추가와 같은 신규 코드 작업도 있습니다. 그리고는 그냥 업로드 해버립니다. 가끔은 그럴때, 그런데 이거 테스트 없이 그냥 풀어도되나요? 라고 물었을때 거의 모든 사람의 경우 (심지어 나 역시) "테스트 서버(베타 서버)에 올릴 것이니까 괜찮아, 버그 테스트는 유저들이 해줄테고 리포트 들어온거 수정해서 다시 패치 하면 되지" 라는 말을 합니다. (반성중)

바른 자세일까요? 네. 마치 이건 도덕 시험 같습니다. 누구나 저런 자세가 옳다고는 생각하지 않습니다만 "현실"을 생각하면 어쩔 수 없다는 거죠. 네. 저도 현실을 생각해서 저렇게 행동하고 답 했습니다. 그런데, 왜 현실을 고려 할 수 밖에 없는 것일까요? "테스터를 고용할 돈이 없으니까요" 라고 말합니다. 와우! 다섯가지 이유를 하나씩 정말 다 따라갑니다! 

버그가 없이 프로그램을 작성 할 수 있는 프로그래머는 세상에 없습니다. 버그는 프로그래머가 미처 생각하지 못하고 지나친 부분에서 발생합니다. 버그는 프로그램에게는 필연적인 존재입니다. 어떻게 해서든지 출시전에 그 문제점을 찾아서 프로그래머에게 전달을 해야 합니다.

기업에게 있어서 "이미지"라는 것은 매우 중요한 요소입니다. 유저(고객)에게 각인 되는 이미지 중에서 제일 강한 녀석은 바로 첫 인상이죠. 사람과 마찬가지 이지만 말이죠. 어쨋든, 고객이 다운로드 받은 프로그램을 실행 했는데 어처구니 없는 버그가 나온다? ... 그 엄청난 이미지 훼손을 회복하는데 걸리는 시간은 예상을 뛰어 넘습니다. 또한 만약에 그것이 이미 시장에서 어느 정도의 점유율을 차지 하고 있는 제품이 아닌 신규로 릴리즈 된 녀석이라면 시장의 기대 값은 정말 순식간에 0점까지 치닫게 됩니다. 고생은 고생대로 하고, 욕은 욕대로 먹고.. 한 국가에만 릴리즈 되는 것이라면 그나마 이정도 선이지만 해외 파트너사로 릴리즈 했을때는 ... 이거 참 난감해집니다.

이러한 문제는 테스터 조직을 갖추게 된다면 상당 부분 해결이 되지 않을까요?

테스터는 꼭 전문가여야 할 필요는 없습니다. 특정 고객층을 목표로 배포 되는 프로그램이 아닌 대부분의 프로그램은 불특정 다수에게 배포 되어 사용이 되어집니다. 테스터 조직을 전문적으로 관리해줄 관리자와 일반 사용자 처럼 해당 프로그램을 사용해줄 테스터만 있어도 충분한 효과를 낼 수 있습니다! 출시가 잦아서 잦은 테스트가 필요한 제품이 아니라면, QA 조직의 대부분을 임시직 (계약직을 비롯한 파트타임 아르바이트)으로도 충분합니다. 오히려 불특정 다수에게 배포 되는 프로그램은 전문적 지식을 갖추지 않은 일반인 파트타임 아르바이트가 더 효과적일 수도 있습니다. 아니면 해당 소프트웨어를 사용하는 사람들 중에 일부를 파트 타임 아르바이트로 고용해서 테스트를 진행 하게 할 수도 있습니다!

버그가 발견 되면 프로그래머는 슬퍼 할 수 밖에 없습니다. 내 자식 같은 코드에서 버그가 .... 가 아닌 한 밤중에 끌려 나올수도 있기 때문입니다!!! 한 밤중에 긴급 점검을 위해서 택시를 타야 하는 경우, 얼마나 가슴이 아픈지 모릅니다.

테스트 조직에 모든걸 다 해결해 주리라고는 믿지 않습니다. 다만, 테스트 조직의 QA 단계를 지나치면서 고객에게 가는 버그의 수를 줄이고, 버그에서 깍아 먹는 회사 이미지를 보호하고, 한 밤중에 긴급 점검으로 끌려 나오는 빈도 수를 줄이기는 해주리라고는 믿습니다.

아, 그렇다고 프로그래머에게 테스트를 맡기면 안됩니다. 프로그래머는 테스트를 싫어합니다. 또한 테스트를 진행해도 일반 테스터 보다 버그 발견률이 낮을 수도 있습니다. 그것은 아이러니 하게도 프로그래머는 정상적인 방법으로만 사용을 하는 경향이 크기 때문입니다. 하지만, 애시당초 정상적인 프로세스 상에서 버그가 발견 되서 출시 되는 경우는 적습니다. 일반 사용자는 정상적은 방법으로만 사용하지 않습니다. =_= 

아 뭐 ..

그냥 테스트 전문 조직이 있었으면 좋겠다는 푸념이었습니다. 버그 없는 게임을 만들어서 유저에게 욕을 그만 먹었으면 좋겠습니다. ㄷㄷ

이제는 청춘불패나 보러 가야겠습니다. ...;

p.s 테스트 조직에게 출시 거부권이 있다면 더 좋겠지만, 현실적으로는 힘들겠군요. 어떤 회사도 출시를 늦출리는 없을테니 프로그래머를 더 쪼아서 ... ... 저도 프로그래머인지라 차마 더 쪼임 당할 수 있는 발언은 차마 할 수가 없군요 ㅋㅋ

posted by Yuno.org
  • 레이니아 2010.03.20 18:21

    (테스터를 여럿 해본 입장에서) 잘 읽고 갑니다^^
    이상하게 꼭 테스터가 버그보고를 한 이후에 프로그래머분들이 버그재현하실 때에는 꼭 정상작동하곤 해서 마찰이 잦곤 했는데...(...)

    알 수 없는 특정한 조건에서 버그가 튀어나올때 프로그래머분들의 얼굴에 생기는 고뇌는 지금 생각해도 가슴이 아프네요:(

    다시한번 글 잘 읽고 갑니다^^

  • YDK 2010.03.20 21:03

    학교를다니는 학생입니다. 늘 제가 만든코드를 테스트하는과정에서는 버그가 없는데 교수님께 제출하는날부터 거의 매일 버그의 존재를 이메일로 받습니다. 실무에서도 똑같네요, 뼈속깊은곳까지 습관을 들여놔여 겠습니다. 좋은글 잘 보고 갑니다.^^

  • sziim 2010.03.22 13:05

    좋은글 잘 보았습니다.
    작년에 인턴으로 소프트웨어 기업에서 소프트웨어 테스트 엔지니어로 일할 기회가 있었는데
    그곳은 출시 전에 QA승인 없이 출시가 불가능한 프로세스를 갖고 있었습니다.
    그때는 그러한 프로세스... 당연히 학교에서 배우던대로 진행되는구나 싶었는데

    어느덧 학교를 졸업하고 취직을 하니 실제로 저 프로세스를 운용하는 회사는 없는거 같더군요.
    생각해보니 제가 일했던 그 곳도 단기간 수정 불가능한 이슈는 1차 업데이트로 모두 돌려버리고 출시일에 맞춰 출시했지만요 ㅋ



종종 이런 이야기를 듣습니다. "프로그래머는 너무 방어적으로 일을 하는 것 같다." 라는 말이죠.

어떤 의미일까요? 예를 들어서 소프트웨어 개발 회사에서 어떤 프로젝트를 진행을 할때 그 프로젝트의 목표를 구현 하는 일을 소위 기획이라고 합니다. 기획자들은 충분한 시간을 가지고 이 프로젝트의 진행 목적 부터 진행 중간 단계의 표현, 기능 들에 대해서 진지하게 고민합니다. 그렇게 해서 (예제로써) 약 버스를 만들기로 했습니다.

그리고 이것에 대한 내용과 스케쥴을 기획서에 작성을 해서 그 기획서를 들고 프로그래밍 조직으로 찾아가서 이야기 합니다. "이것을 언제까지 만들어주세요." 그러면 프로그래머는 기획서를 쭉 살펴보고 기획서가 너무 부실하다고 생각합니다. 기획서에 써 있는 것들이 어떤 목적으로 구현이 되는 것인지, 그리고 또 어떠한 내용인지 확실히 알 수가 없습니다. (물론 아닌 경우도 있습니다.) 그리고 이것 저것 하나씩 묻기 시작하고, 실제 구현 방법에 대해서 하나씩 생각을 해보기 시작하고 나서 대부분은 이렇게 말합니다. "그때까지는 힘들겠는데요.."  라는 말과 함께 협상을 시작합니다.

그리고 프로그래머는 구현해야 하는 기능 중에서 구현이 애매 모호하거나 시간이 오래 걸릴 것 같은 기능들을 구현이 편한 방향으로 변경을 시도합니다. 때로는 이것은 기획자의 의도와는 좀 다른 방향으로의 결과물을 불러오기는 합니다만 이미 대부분의 상황에서 기획자와 프로그래머는 "협상" 단계에 들어가 있기 때문에 기획자도 그것을 받아 들입니다.
그렇게 해서 최초 목표였던 버스는 승합차가 되어 돌아오게 됩니다. 그리고 그것은 출시 됩니다.

지난 몇년간 게임 회사에서 일 하면서 경험하고, 봐왔던 현상입니다. 기존에 다른 회사에서 일 했던 경험을 바탕으로 한다면 다른 회사 역시 대부분은 저런 흐름을 비일비재하게 겪고 있을 것 같습니다.

프로그래머들은 어째서 저런 방어적 입장을 취하는 것일까요?

공식적인 이유로는 이러한 이유들이 있습니다.

1) 기획자가 정말 무리한 일정을 가지고 온 경우, 2) 일정을 아무리 길게 잡아도 아에 불가능한 것을 요구 하는 경우. (예를 들어 기존에 사용 하고 있던 코볼의 코드를 C#으로 완벽하게 포팅 해주는 프로그램을 만들어 주세요. 와 같은), 3) 나의 일을 줄이기 위해서.  4) 기타.. 어떤 것들이 있을까요?

... 어떤 이유일까요? 사실 이런 이유는 중요한게 아닙니다. 위에서 말한 어떤 이유라고 하더라도 그것은 사실상 개별적 해결이 불가능 하기 때문입니다.

저는.. 이런 일이 발생 하는 이유가 바로 '협상' 단계가 생길 수 밖에 없는 업무 흐름 때문일 거라는 생각이 듭니다. 완전한 갑을 관계에서는 '협상' 따위는 없겠죠. (경우에 따라서는 아주 조금 있을지도 모르지만-_-) 그렇다고 해서 갑을 관계를 형성 하라는 것은 아닙니다. 같은 회사안의 조직이기 때문에 그렇게 해봐야 조직간의 분열을 더 초례 할 뿐입니다.

그렇다면 이렇게 해보는건 어떨까요?

기획자는 처음에 기획을 구상 하는 단계에서 이것의 간단한 '목표' 만을 설정합니다. 그리고 기획 회의를 진행할때 실무자 또는 실무자에게 충분한 영향을 줄 수 있는 사람을 함께 하는 겁니다.

뭐야 이게? 라고 생각하는 분들도 있을 것 같습니다만, 실제 기획을 구체화 시킬때 실제 구현자인 프로그래머가 참석해서 함께 회의를 진행한다면 '협상' 단계 따위는 오지 않습니다. 네, 물론 그 '협상' 단계가 기획 회의에서 이루어지게 됩니다. 하지만, 그 수준이 명확하게 다릅니다. 왜냐하면, 기획 회의에서는 간단한 목표만 정해져 있을뿐, 이것의 정확한 기획 결정이 이루어지기 전이기 때문입니다.

기획 회의에 프로그래머가 참여를 한다면 프로그래머는 그 기획 회의에서 내가 어떻게 방어적 입장을 취할까를 고민하지 않습니다. 말 그대로 기술적인 지식을 바탕으로 그 기획에 함께 참여하게 됩니다. 또한 기획 회의에서는 해당 작업을 해야 하는 목적 등에 대한 고민이 이루어지므로 기획서에서는 그냥 지나치는 (또는 아에 나와 있지 않은) 작업의 목적(사실상 동기)를 프로그래머와 함께 공유 할 수 있게 됩니다. 이것은 프로그래머에게 기존의 방식 보다는 조금 더 주인의식(?)을 부여 할 수 있는 방법이 아닐까 싶습니다. 실제 프로그래머들을 참석 시킬 경우 기획자가 생각하지 못하는 기술적인 지식을 이용한 좋은 방향이나 아이디어가 나오기도 합니다. 손해 볼건 없다는거죠.

또한, 프로그래머가 참여 하므로 애시당초 불가능한 기능에 대해서는 기획 회의에서 충분히 걸러 질 수 있습니다. 그리고 결정 되어지는 것들에 대하여 그 자리에서 프로그래머와 함께 스케쥴 임시 계산이 가능하므로 스케쥴 문제 역시 크게 해결 할 수 있습니다. 어차피 스케쥴 협상을 할 거라면 회의 단계에서 미리 하는데 시간을 아끼는 방법이기도 하죠.

그냥 단지 프로그래머가 기획 회의에 참여 하는 것만으로 기존의 '협상' 단계를 없애거나 최소화가 가능해지지 않을까요?

네.

뭐 그냥 그렇다구요.


posted by Yuno.org
  • 나그네 2010.03.19 16:38

    그래서 외국의 큰 기업들은... 기획자가 디자인을 하고 리드 혹은 그것을 구현할 프로그래머들에게 시간을 정하게 합니다.(꼭 리드만 참여하는게 아닙니다...) 그러니까 기획자가 3개월안에 만든다. 이런게 아니라 원하는게 있으면 그걸 구현할 사람에게 얼마가 걸리는지 물어보고 그것을 따릅니다. 프로그래머가 6개월 걸리면 6개월 기다리던지 아니면 그것을 포기하던지 둘 중에 하나인것이죠. 그리고 3개월이 정해진다고 하여도 개발 중간 중간에 바뀌는것들이 있고 (안바뀌는건 해결 불가능한 문제이죠. 물론 재미없는 게임 만들려면 시간 안에 그대로 만들 수 있습니다. ^^) 당연히 바뀐 만큼 추가 시간을 받던가 아니면 기능을 삭제 합니다.

    한국에서도 일해보고, 외국에서도 일해봤는데... 가장 큰 차이점은...

    '구현할 사람에게 얼마가 걸리는지 물어보고 그것을 따릅니다.' 였습니다.

    수고하세요~

    • Yuno.org 2010.03.20 14:47 신고

      구현할 사람에게 얼마나 걸리는지 물어보고라고 하면 너무 한쪽에 의존하게 됩니다.

      그래서 처음 기획 단계를 제외한 실제 구현 기획 회의 단계부터는 개발자가 함께 참여해서 진행 해야합니다. 스케쥴은 이때 결정이 되는거죠.

  • 피요히코 2010.03.19 18:21

    사실 실제로 프로그램을 구현하는 사람들은 개발자들이니. 실제 소요 시간을 산출할때는 그들의 의견을 따르는게(반영하는게) 옳을것 같습니다.
    뭐 거의 대부분의 경우는 일정이 픽스된 상태에서 기획도 들어가니..(제가 있는곳만 그런가요..) 개발자의 의견은 별로 중요해 보이지 않더라구요. 그러니 끊임없는 야근의 반복되고. 몸과 마음이 지친상태에서 좋은 코드가 나오기도 힘들고. 그러다 보니. 잠재적 오류들이 쌓이고. 오픈 앞두고 철야 반복에. 오픈후에도 하자보수를 해야하고. 하지만 또 다른 프로젝트에 들어가니 일은 더 많아지고. 또 야근에... 이런 반복인거 같네요..
    나그네 님이 말씀하신 것 처럼 실제 구현할 사람에게 의견을 구하고. 그 의견이 받아들여진(반영되어진) 일정대로 일을 한다면. (뭐 중간중간 생기는 변수에 대한것도 반영되는게 베스트겠죠) 개발자들도 더 책임감 있고 편안한 마음으로 일을 할수 있지 않을까 하는 생각이네요. ㅠㅠ

    • Yuno.org 2010.03.20 14:50 신고

      네 맞습니다. 하지만 의견을 구하는 단계가 이미 기획이 완료된 상태에서 한다면 결국 똑같튼 현상이 생깁니다.

      둘다 만족 할 수 있는 방법을 찾는 수 밖에 없죠 ;

      어느 쪽이 반대편을 설득 하는 단계는 준비 완료 된 후가 아닌 준비 단계에서 진행 해야 더 무난 진행이 가능 한 것 같습니다.

  • 쎄미 2010.03.19 19:23

    프로그래머가 같이 붙어서 한다고 그래도, 중간에 대책없이 막히게 되는일도 비일비재하다보니 일정을 좀 넉넉히 잡는게 습관이 되더라구요...

    • Yuno.org 2010.03.20 14:54 신고

      네 맞습니다. 그런데, 이미 프로그래밍팀을 제외한 다른 부분에서는 일정을 결정하고 프로그래밍팀과 이야기 하는게 문제죠.

      그렇게 되면 내부의 상황과는 관계 없이 방어적으로 보일 수 밖에 없습니다. 그렇기 때문에 프로그래밍팀 역시 기본 회의에 전부 참석 해야 하는 이유이기도 합니다.

    • 쎄미 2010.03.20 15:58

      일정을 넉넉하게 잡으려고하면 일을 못하는 사람이나 너무 놀려고하는거 아니냐는 말이 돌아오는게 대부분이죠...

  • ash84 2010.03.19 19:33

    제가 느낄때에는 사실은 프로그램을 개발하는 기간이라는것이 100% 추정 가능한 것이 아니기 때문에 문제입니다. 그리고 본능적으로 프로그래머는 그것을 알고 있지요. 본인 스스로도 이건 3일내에 할수 있습니다. 라고 말하면서도 불안할때가 많습니다. 그런 와중에 프로젝트나 새로운 기획은 기한이 정해진채로 떨어지기 때문에 자동적으로 방어적이 되는것이지요.

    사실 이런 부분을 최소화하려면, 프로그램을 개발하는 일에 대해서 이해할 필요가 있습니다. 그리고 그것들을 고려해서 일정을 짜고 기획자 입장에서는 그런것들을 고려해서 잘(?) 프로그래머를 설득해야 겠지요.

    • Yuno.org 2010.03.20 14:56 신고

      네 맞습니다. 그래서 '기한이 정해진 채'로 떨어지는 것을 막기 위해서라도 기본 회의 단계에서 부터 프로그래머가 참여 해야 하는겁니다.

      이러한 것을 기본 전략 기획 회의(?)에서 이야기 하지 않는다면 어쨋든 그것은 프로그래머 vs 그 외 전부 의 상황이 되어 버리는거죠.

  • Apple-Code 2010.03.19 19:39

    간단합니다. 새로운 것 == 야근

    • Yuno.org 2010.03.20 14:57 신고

      그러게요 -_-

      참고로.. 일반 SI 보다 어지간한 중간 이상의 게임 회사가 더 근무 환경이 더 좋습니다 ㄷㄷㄷㄷㄷㄷ

  • Doonee 2010.03.20 10:46

    제가 생각하는 개발자문화 개선방안은 다음과 같습니다.

    [1] 좀더 적극적이고 적절한 타협을 할줄 아는 개발자의 자세
    - 개발자, 수동적인 것 맞습니다. 왜냐하면 개발자가 능동적이고 적극적이면 스스로 그리고 주변 개발자들 상당히 피곤하게 만듭니다. 일을 스스로 만드는 결과를 초래할 수 있습니다. 그래서 그러한 수동적인 성격들을 옹호하는 건 아니구요, 조금이라도 개선된 개발자문화를 만들려면 위에서 소개해 주신 것처럼 최초회의에 참석하려는 의지를 보여야 하고, 개발자와 개발자외의 사람들에게 적절한 타협을 제시할 줄 아는 적극적인 마인드가 필요한 것 같습니다.

    [2] 능력있는 기획자를 만나는 것
    - 저는 개발 실무경력 10년이 다 되어가고, 여러군데서 여러 기획자들과 일을 해봤지만, 지금까지 사실 능력있다고 생각되는 기획자를 만난적 한번도 없습니다. 제가 경험했던 기획자는 '경영진과 개발자를 연결 해주는 다리역할 하는사람' 혹은 '베타테스터' 정도 였습니다. 베타테스트 끝나도 버그 많습니다. 그렇지만, 버그나오면 기획자 잘못이라고 할까요? 개발자에게 책임을 떠 넘기려는 분들이 많습니다. 그렇지만, 프로젝트가 잘 마무리되면 기획자는 자기가 개발 한 것처럼 보일려고 합니다. 물론 능력있고 자기역할 잘하는 기획자도 있겠지만, 아직은 못 만나봤습니다. 기획자가 다 그렇다는 건 아닙니다. 제가 만났던 사람들에 국한된 경험입니다.

    [3] 경영진의 마인드 개선
    - 가장 중요한건 위의 [1][2]번이 다 되더래도 경영진의 마인드가 개선 안되면 헛탕이죠. 불만 토로하지 말고 시키는대로 하거나 다른 좋은 마인드를 가진 회사를 찾아봐야죠.

    그리고 이건 여담인데요, 적은 급여받고 레벨업 한다치고 야근, 주말근무 자주 하시는 개발자분들... 주변의 다른 개발자들 힘들게 하는거 아시는지 모르겠네요. 경영진 입장에서는 싼값에 일을 많이 하는 직원을 선호합니다. 개발자들이 중시하는 퀄리티 라는건 안중에도 없는 경영진 많습니다. 돌아가기만 하면 개발 끝난 것처럼 생각하는 무식한 경영진 많다는겁니다. 시키는대로 일정만 맞추려고 부실공사로 건물 여러개 만들다보면 현재 직면한 잘못된 개발자문화 문제들이 반복 된다는걸 아셔야 할 겁니다.

    • Yuno.org 2010.03.20 14:59 신고

      네 맞습니다. 제일 힘든것은 [3]이죠. 어지간해서는 스트레스 받을텐데 다행히 저희 회사는 안그렇군요. (자랑)

      좋은 의견 감사드립니다 :)

  • 구차니 2010.03.20 10:47

    예상시간 추정이란게 거의 무의미할 정도로 예측불가능하기 때문이 아닐까 생각이 됩니다.
    처음써보는 혹은 써봤지만 개발에 적용하기에는 몰랐던 부분도 많고
    그로인해 파생되는 문제를 하나둘씩 해결하다 보면 기하급수적으로 시간이 지연되니 말이죠.

    머.. 자조적으로는 "다 내 개발능력이 부족한 탓이야" 라고 하지만..
    가끔 정말 일정이란걸 감안하고 그거에 맞추는걸 보면 신의 능력이 필요하지 않을까 생각이 되더라구요

    • Yuno.org 2010.03.20 15:02 신고

      네 맞습니다. 그렇기 때문에 경력자가 필요한 이유이기도 합니다. 경력자는 지금까지의 경험(소위 노하우)로 인하여 신입 보다 더 높은 적중률을 가지고 있죠.

      어쨋든, 예상이기 때문에 틀릴 수 밖에 없는건 어쩔 수 없습니다. :) 그렇게 배워 나가고 발전하는거죠 뭐 ..;

  • 글쎄요 2010.03.20 14:21

    비유를 하자면 이런거죠.
    당신이 제빵사인데 당신 생각에는 하루에 500개 정도의 빵을 구을수 있다고 생각하고 있습니다.
    그런데 갑자기 빵가게 주인이 1000개를 요구했다고 합시다.
    아니면 케잌은 처음 만들어 보는데 갑자기 케익 500개가 필요하다거나...
    그러면서 그러겠죠 정말 미안하지만 어쩔수 없다고 우리가게가 살려면 어쩔 수 없다고...
    물론 밤을 새서라도 하겠죠 (아님 그만 두던가... 하지만 제빵사라는 자존심이 하게 만들겠죠?)
    한두번이라면 상관없지만 계속 반복되거나 심지어는 이제 그것이 기준이 되어갑니다.
    그럼 당신은 틀림없이 지쳐갑니다.
    그러면서 배우게 되죠.
    내가 구을 수 있는 빵의 최대치를 200개라고 그랬다면 좀 더 여유가 있었을 것이다.
    아니면 새로운 분야는 할 수 없다. 할려면 나한테 공부할 시간을 달라고 그럴껄...
    뭐 이러면서 점점 방어적이 되어가게 된다는 거죠.

    이 시점에서 한번 생각을 해보십시요.
    다 가게가 살기 위해서 하는 일이다 라고 그럽니다만 결국 제빵사의 희생만 요구하는 겁니다.

    우리나라 개발자들의 현실도 이와 다르진 않습니다.
    괜히 3D라고 하지 않습니다. 무조건 일을 던지면 어떻게 해서든 일을 하거나 아니면 비명을 지르거나 일단 일을 던져보자는 심산이죠
    손해 볼꺼 없으니깐... 개발자 경력 약 10년 동안 얻는 결과 입니다.

    영업(기획) - PM - 개발자 : 서로 동등한 관계가 되는게 최선이겠죠
    그리고 자신들은 희생하지 않으면서 개발자의 희생만 요구하는 이런 문화도 개선되어야 합니다.
    개발자에 회의를 가지기 시작하는 일인입니다.

    • Yuno.org 2010.03.20 15:05 신고

      네 맞습니다.

      그렇기 때문에 1000개의 빵을 요구 받는 당황이 되면 안되는겁니다. 1000개의 빵을 더 구워야 한다는 결정이 내려지는 회의에 프로그래머가 있어야 하는겁니다.

      그게 최고 경영진에서 결정 되는 것이라면 프로그래머의 입장을 대변해주는 것은 CTO일 것이고, 일반 회의라면 참여한 프로그래머가 되겠죠.

      초기 결정 단계에서 이것이 녹아 들어가 있지 않는다면 모두의 희생으로 밖에 보이지 않게 되는겁니다.

      그러고 보니, 대부분의 회사가 CFO, CEO는 있지만 CTO는 없군요. 어익후-

  • ㄹㄹㄹ 2010.03.21 07:35

    문제의 본질은 연봉이나 보수죠..
    연봉 최소 5000애 야근수당 및 성과급 옵션까지 때려주면 이 글에서 언급된 내용은 온데간데없이 아주 적극적으로 일할겁니다.

    • Yuno.org 2010.03.21 11:54 신고

      꼭 그렇지는 않습니다. 급여는 절대 '만족'을 가져올 수 없습니다.

      처음 받기 시작 할때와 조금 지난 후의 사람 마음은 절대 같을 수 없거든요 :)

  • 09kim 2010.03.26 11:07

    본질적으로는.. 작업기간에 대한 예측이 어렵기 때문 아닐까요?

    작업 도중 난관에 봉착하게 되기도 하고.. 작업요청 내용이 진화하기도 하니까요.;

    그리고, 개발 공정의 끝부분에 프로그래머가 위치하기 때문에

    '일정 펑크의 원흉'으로 몰리는 경우가 허다하니 이것도 방어적인 태도를 취하는 한 요인이 될 것 같습니다.

    가령 기획서가 늦게 나왔거나, 그래픽 리소스 제작에 문제가 있었더라도

    출시 (혹은 패치) 시기에 작업을 하고 있는 건 대부분 프로그래머 이니까요.

    • Yuno.org 2010.03.26 15:52 신고

      네. 작업 기간의 완벽한 산출은 사실 불가능에 가깝습니다. 그 불가능에 가까운 산출 기간을 최대한 오차를 없애는게 기획 단계에서 개발자 회의 참여의 주 목적이기도 하죠.

      스케쥴을 비롯해서 기획 회의 단계에서 10을 A까지 완성 하기를 결정된 단계에서 프로그래머가 이후에 손을 대서 10과 A가 둘다 변경 되는 것 자체를 보정하기 위한 방법이기도 하구요.


이게 과연 Programming 분류에 들어가야 하나 싶지만. 아무튼.

웹은 그 태생의 한계 때문에 여러 시스템을 구현할때 다양한 편법이 이용되어진다. 처음에는 편법이었지만 시간이 지나갈수록 당연시 되어지고 그 헛점 조차 그 편리함에 덮혀지는 뭐 그런..

방금전에 뉴스 사이트를 보다가 이러한 기사를 보았다.

http://news.naver.com/news/read.php?mode=LSS2D&office_id=032&article_id=0000203799&section_id=102&section_id2=249&menu_id=102

대략 요약하자면 인터넷 쇼핑몰에서 별도의 결제 사이트를 연동하여 결제할때 주고 받는 통신을 위조해서 적은 금액으로 물건을 구매 하는 행위에 대한 이야기다.

이거를 처음 발견했던건 3년쯤 전이었다.

보통 대형 쇼핑몰이 아닌 일반 쇼핑몰들의 결제 시스템은 결제 대행 서비스를 이용한다. 또한 결제 대행 서비스 업체들은 자체 보안 때문에 쇼핑몰 서버에 별도의 모듈을 제공하는게 아닌 본인들이 제공하는 특정 페이지를 연결해서 관련 정보를 받아서 처리하고 해당 결과를 쇼핑몰 호스트로 다시 넘겨주는 작동 방식을 가진다.

이 문제는 결국 쇼핑몰의 결제 시스템은 결제 여부를 대행 업체의 결제 시스템에 의존하게 된다는거다. 두 호스트는 물리적으로 연결 되어 있지만 단일 랜 선이 아닌 인터넷을 넘나드는 공개된 패킷에 의해서 주고 받게 된다.

이는 쇼핑몰 솔루션의 호환성과도 직접적 관계가 있기 때문에 일반적으로 (지금은 어떨지 모르겠지만) GET, POST 와 같은 단순 전송 방식을 사용한다. 차라리 서비스나 데몬이 돌면서 TCP/IP 를 통한 직접 통신이면 나을지도.

아무튼, 그러한 통신은 결국 한번이라도 그러한 시스템을 구축해보거나 시스템 구조를 아는 사람에게는 허약하지 그지없다.

대표적이로 두가지 취약점이 여기서 들어난다.

1. 쇼핑몰에서 대행 업체로 보내는 결제 조건 정보. 즉, 금액과 결제 방식 등의 정보의 공개 문제
2. 대행 업체에서 결제 완료후에 쇼핑몰로 결과를 전송할떄의 문제

이 두가지 문제는 모두 사용자(클라이언트. 여기서는 브라우저)를 거친다는것에 있다.

이중에 제일 쉽게 접근이 가능한 첫번째 문제는 매번 우리가 결제할때 쇼핑몰에서 결제 정보를 브라우져에 특정 URL에 특정 파라미터(위의 결제 정보)를 가지고 열도록 명령하고 그 정보는 사용자 브라우저에 그대로 남은 상태로 해당 페이지로 가게 되는거다.

즉, 해당 페이지를 열때 넘어오는 파라미터를 변경하면 결국 그 파라미터대로 페이지가 열리게되고 이는 위의 기사에서 나온 것 처럼 금액의 변경으로 쉽게 이어진다. 결국 대행 업체의 솔루션은 받은 금액 그대로 (변경 여부는 알 수 없으므로) 결제를 하게 되고 그 결과를 쇼핑 솔루션에 통보 하게 되는거다.

여기서 결국 쇼핑몰 솔루션을 개발한 사람의 완벽성에 영향을 받게 되는데 어지간한 대행 업체는 결과를 보낼때 대략 요청한 결제 번호 (주문 인덱스 넘버와 같은 인덱스 넘버), 금액, 결제 정보 등을 넘겨준다.

결국 이곳에서 결제 번호(인덱스)만으로 결제 여부를 처리 해버리면 백만원짜리를 만원을 결제 했든, 십만원을 결제 했든 해당 주문번호의 결제 여부는 처리가 되어 버리고 완료 처리가 되어 버릴것이다.

이것 저것 크로스 체크를 하는 개발자라면 돌아온 결제 정보의 금액까지 확인 해서 크로스 해야 할 것이고 2번의 문제 역시 막기 위해서 해당 정보를 전송한 호스트의 주소 역시 크로스 체크 해야 한다. 물론 이것도 작정을 하고 스누핑 한다면 대책이 없겠지만 -_-

어쨌든 가급적 결제 시스템과 같은 예민한 시스템은 클라이언트에서는 입력만 받고 모든 전송 및 처리는 호스트에서 처리 하는게 제일 안정적이다.

쩝.

저 기사를 보니까 그때 내가 테스트 했던 10곳의 쇼핑몰중에 저 방법이 통하지 않았던 곳은 단 두곳밖에 없었다는 기억이 다시 새록 떠 오른다.

난 차마 지르지는 못했는데 ...


posted by Yuno.org

게임 케릭터 미리 보기 작업을 하느라 처음으로 ASP.NET C#을 이용해서 그래픽 파일을 브라우저로 전송하는 코드를 작성할 일이 생겼다.

ASP.NET을 처음 만져봐서 각종 정보를 찾아 보니 든든한 클래스가 많이 존재했다. Bitmap, ImageConvert, Color 등..

따라서 게임 그래픽 데이터 파일을 로드하여 Bitmap 에 넣고 각종 변환 작업 (색 변경, 조합, 이미지 머지 등) 수행 후에 BMP로 저장 또는 Response.OutputStream으로 바로 이진 전송을 해도 오류가 나는게 아닌가.

오류도 당황스럽게 GDI+ 일반 오류. (A generic error occurred in GDI+) 가 발생 하는게 아닌가..

뭐가 문제란 말이냐!! GIF나 JPG로는 잘 저장이 되는데! 심지어 파일로도 저장이 잘 되는데 BMP나 PNG, TIFF 등 이미지 손실이 없을 것만 같은 것들은 모조리 저장이 안된다니!?

한참을 고민하다가 해결 방법을 찾았다. 바로 목표 스트림으로 출력하는게 아니고 별도의 메모리 스트림을 거쳐서 찍으니까 모든게 해결. ... 쳇;

뭔가 별도의 포멧으로 저장 할때는 스트림에서 읽었다 썼다를 반복이라도 하는건가!?

------------------------------
  Bitmap Image;

  Image = new Bitmap (320,240);

  Image에 대한 그래픽 처리 blah blah..

  Response.Clear();
  Response.ContentType="image/bmp";
  Image.Save( Response.OutputStream, ImageFormat.Bmp);
  Image.Dispose();

- 출력 오류 GDI+ 일반 오류 발생.

------------------------------

  Bitmap Image;
  MemoryStream memStream = new MemoryStream();

  Image = new Bitmap (320,240);

  Image에 대한 그래픽 처리 blah blah..

  Response.Clear();
  Response.ContentType="image/bmp";
  Image.Save( memStream, ImageFormat.Bmp);
  memStream.WriteTo( Response.OutputStream );
  Image.Dispose();

- 성공


posted by Yuno.org