도아님이 리뷰하신 내용 중에 1) 재압축 파일 제외 2) 분할 압축 3) 압축률과 관련해서는 다음과 같이
개선 중이며, 다음주 중으로 패치 예정입니다.
1) 재압축 파일 제외
: 최근 많은 파일 포맷이 자체적으로 압축된 데이터를 처리하고 있고, 해당 파일을 압축했을
때 얻을 수 있는 압축 효율이 1~2%여서 재압축 파일 제외 기능을 두었습니다. 현재는 도아
님의 리뷰와 같이 확장자 기반으로 하고 있으나 지적하신 바와 같은 문제가 있어 파일헤더
를 분석하는 방식으로 수정하여 내부 테스트 중이며, 다음주 패치에 적용할 예정입니다.
2) 분할 압축
: V3 Zip에서 제공하는 ZIP에 대한 분할 압축은 WinZip에서 생성하는 분할 압축과의 호환을
기준으로 작성되어 있으며, 리뷰에서와 같이 압축 후에 파일을 분할하고 있습니다. 디스
크 사용이나 압축 시간 + 분할 시간으로 인해 비효율적이어서 압축시 분할하여 생성하는
방법을 적용 예정입니다.
3) 대용량 압축 관련 (ZIP64)
: V3 Zip은 대용량 (4GB 이상의 압축) 지원을 위해 ZIP의 확장 형식인 ZIP64를 지원하고 있
으나 미흡한 부분이 있어 리뷰를 진행하는 과정에서와 같이 파일이 일부 누락되는 오류가
있는 것 같습니다. 이 부분에 대해서는 보다 안정성을 확보할 수 있도록 노력하겠습니다.
4) 비정상 압축 파일 생성
: 리뷰에 언급된 압축 완료 메시지가 출력 되었으나 파일이 비정상적인 경우가 있는 부분은
4GB 이상의 대용량 압축 파일로 ZIP64 지원에 있어서의 오류로 판단됩니다. 대용량 압축
과 관련하여 빠른 시간내에 안정화되도록 하곘습니다.
5) 그 외
: 리뷰 글을 읽으면서 저희가 V3 Zip을 개발할 떄 많은 고민을 했던 "미리보기" 기능에 대한
리뷰가 빠져 있는 부분은 좀 아쉬웠습니다. 사진, 그림 등 압축된 상태에서도 내부의 내용
을 쉽게 알아 볼 수 있도록 많은 노력을 들였던 부분이었습니다.^^(사진만이 아니라 JP2K,
PSD 등도 지원합니다~)
좀 더 안정화되고 완벽한 제품을 출시하여야 하나 많은 질책을 받더라도 사용자와의 소통을 통해 안철수
연구소가 만든 제품이 아닌 사용자가 만들어 가는 V3 Zip을 만들려는 마음에 강행(?)되었습니다.
저도 어젠가 내려받자마자 토런트로 받아둔 MS Office 2010의 압축(RAR)을 푸는데 문제가 바로 나타나기에 본격적인 사용을 보류했습니다. 혹시나 토런트로 내려받은 파일이 잘못 된 것인가 싶어 WinRAR로 풀어보니 순식간에 풀리더군요. 글에서 말씀하신 무한루프에 빠지는 것을 경험했습니다.
저 역시 왜 이런 바로 눈에 띄는 버그도 수정하지 않고 출시했는지 의문이 들더군요. 대용량 혹은 다른 압축방식의 파일을 테스트 안해본 것이 아닐텐데 말이죠..
하지만 다음주에 패치도 있다고 하고 꾸준히 유저들과 피드백하여 계속해서 발전하는 모습이 기대되니..ㅋ 안랩을 응원합니다!
7-Zip 애용자였는데...
얼마 전 충격을 먹고 7-Zip을 버리기로 했습니다.
데비안아트에서 90MB 정도로 3중 압축된 아이콘팩을 받았는데...
압축을 다 해제하고 나니 크기가 0인 파일들이 다수 존재하더군요.
분명 오류는 발생하지 않았는데 원래 크기가 0인 파일들을 올렸나? 생각을 했죠.
혹시나 해서 다른 압축프로그램들로 압축을 해제해보니 정상적으로 풀리더군요.
처음 경험한 충격적인 오류네요. ㅠ_ㅠ
위의 파일을 다양한 압축 프로그램으로 해제를 해봤습니다.
국산 : 알집, 빵집, V3Zip
외국산 : WinZip, 7-Zip, PeaZip, WinRAR
놀랍게도 알집과 WinRAR만 정확하게 풀어냈습니다.
알집은 그냥 아무 오류도 뿌리지 않고 제대로 풀어냈고, 윈라의 경우 [심볼릭 링크가 잃어버린 파일을 가리키고 있습니다.] 오류를 뿌려주고 제대로 풀어냈네요.
추측상 심볼릭 링크를 잃어버린 파일을 알집과 WinRAR는 어찌저찌 풀어내나봅니다.(심볼릭 링크가 뭐죠?)
아무튼 알집과 WinRAR를 제외하고는 동일하게 0의 크기를 가진 파일들이 다수 생성됐네요.
윈집은 파일을 다 어디다 버린거니? 5천개나 까먹네요.
PeaZip은 Priority 설정이 가능하여 실시간으로 설정하니 속도가 후덜덜하게 빠릅니다. 조금 더 사용해보고 피집으로 넘어갈 지도 모르겠습니다.
아무튼 귀찮아서 간단하게 압축만 해제해봤으니 관심있으신 분들이 정밀하게 분석해주셨으면 한다는 바램이..^^
이 부분은 프로그램의 잘못이 아닙니다. 심볼릭 링크는 유닉스에서 사용되는 기능이고 윈도에서 이 것을 처리하지 못하는 것은 당연합니다. 더구나 **심볼릭 링크가 잃어버린 링크를 가르키고 있다**면 복구 못해야 정상입니다. 그런데 이 것을 그대로 풀었다면 반대로 알집에 문제가 있는 것입니다. 또 알집의 최대 문제는 풀지도 못하면서 풀었다고 사기 치는 것이므로 오류가 없다고 해서 풀었다고 보기 힘듭니다.
그런데 다른 압축프로그램들에서 크기가 0인 파일들이... 알집과 WinRAR에서는 정상으로 나오고, 아이콘도 정상으로 보이네요.
제 컴에 문제가 있는지...ㅠㅠ
급하게 할 게 있어서 컴을 막 굴렸더니 그런가...
아무튼 포맷하기 전에 댓글 남기고 스르륵 사라집니다.^^
주말 잘 보내세요~
아.... 이글을 지금에서야 발견하다니... - -;
심볼릭 링크는 링크이기때문에 파일이면서도 사이즈가 없는게 맞습니다. 0바이트 파일이 다수 생성되었다는것은 심볼릭 링크를 제대로 인식하고 풀어냈다는 것을 의미합니다.
원래 유닉스에서도 링크대상이 존재하지 않아도 링크 자체는 일부러 만들수도 있고, 이런 경우에 링크 대상이 나중에 나타나도 되도록 되어있습니다.
그러므로 유닉스 쓰시는 분들이라면 이해하시겠지만 "링크대상이 없더라도 심볼릭 링크를 풀어주는것이 옳습니다."
오히려 심볼릭 링크를 하나도 풀지 않았다는것은 심볼릭 링크가 윈도우의 파일시스템에서는 개념 자체가 존재하지 않기 때문에 일부러 풀지 않거나, 심볼릭 링크를 아예 인식하고 있지 않다는 겁니다. 유닉스나 리눅스에서는 이 심볼릭 링크를 풀어주지 않는 것 자체가 심각한 오류인 것입니다.
winrard에서 링크가 끊어졌다는 메시지를 내었다는것은 파일 종류가 윈도우즈에서는 존재할 수 없는 심볼릭 링크이고 윈도우즈 링크로 만들려고 하더라도 대상이 없으니까 경고메시지를 내었다는 것으로 이해할 수 있습니다. 이것은 심볼릭 링크가 뭐고 윈도우즈 사용자에게 어떻게 제공해야 할 것인가를 충분히 이해하고 있다고 보여집니다. 아마도 winrar은 심볼릭 링크가 윈도우의 파일 시스템에서는 존재할 수 없으니, 아예 대상파일을 찾아서 링크 대상과 같은 내용으로 파일을 생성해준 것 같습니다.
마지막으로 아무말 없이 링크 파일이 안풀린다... 이건 유닉스 계열의 파일은 모르는 사람이 짰거나, 어차피 윈도우즈용 프로그램이니까 tar는 별로 쓰이지 않을터이지 적당히... 일 가능성이 있습니다.
윈집에서 파일이 안풀린다는것은, 순수하게 윈도우 파일시스템에 심볼릭 링크 파일을 생성하려다가 윈도우즈에게서 내부 에러 먹고 처리 중단한것으로 보입니다. 요것도 위와 비슷한 이유일 수 있습니다.
해당 압축파일은 지금 보니
심볼릭 링크 5606개
디렉토리 85개
파일 19867개
가 존재합니다.
유닉스 계열에서는 당연히 링크가 끊어진 심볼릭 링크도 생성되어있습니다. → 이게 정상입니다.
안타깝네요... 이걸 좀 빨리 발견했더라면 제대로 된 답을 드릴수 있었는데..
결국 제일 정석으로 곧이 곧대로 풀어낸 것은 7zip이고, 한걸은 더 나아가 유저를 고려해준것은 winrar이라고 할 수 있습니다. 알집에서도 제대로 풀린다고 씌여있는데, winrar과 동일한 파일 개수가 풀려있는지를 확인해봐야 할 것입니다.
winrar은 아마도
"심볼릭링크수 + 파일수 - 끊어진 심볼릭 링크 수 "
만큼의 파일을 생성했을 것입니다.
(윈도우에서는 종류별 파일 개수 세는게 유닉스 계열만큼 편하지가 않아서... -0-; )
리뷰를 통해 주신 의견을 반영하도록 쪼느라 진행에 대한 댓글을 이제서야 답니다.
도아님 리뷰에서 지적해 주신 1) 대용량 압축 지원(ZIP64) 2) 분할 압축 기능 개선
3) 압축률과 관련해서는 다음주 월요일(10/5) 패치 예정입니다. 이외에도 개선에
대해 주신 여러 의견 중에 빠른 개선이 필요한 다음의 내용에 대해 업데이트를 준비
하고 있습니다. 어제도 10G 이상을 다양하게 압축해 보느라 아직 집에를 못갔네요.
1. 대용량 압축 지원 (ZIP64)
. 4GB 이상의 파일의 압축/해제 기능 보완
. ZIP 64 포맷 지원
2. 인코딩 자동화
- 일본어(ShiftJIS), 중국어(간체, 번체)를 자동으로 인식
3. 분할 압축 기능 개선
- 압축 파일 생성 시점에서 분할 크기로 생성하도록 하여 압축 시간 개선
예전에 v3zip 건의사항을 몇몇 채널로 올렸는데 질의에 대한 결과 답변이 없기에 제대로 전달되지 않았는가 하여 다시금 이곳에 올려 봅니다.
업데이트된 버전을 받아서 다시 설치하고 한글 윈도우즈 XP SP3에서 테스트 해 보았습니다.
일단 구버전을 언인스톨하고 재부팅 후, 새로 설치한 프로그램의 버전정보를 보니 1.0.1.0 (247) 이네요.
메일의 첨부파일로 보냈던 테스트셋으로 압축을 해 보니 Unicode BMP(Basic Multilingual Plane)을 벗어나는 코드포인트로 표현된 글자가 이상한 파일명으로 인코딩되어 저장되는 현상이 보입니다.
실제 v3zip으로 BMP밖 영역의 파일명을 압축하고 다시 v3zip으로 열어서 들여다보면 제대로 보입니다. 하지만 winzip최신버전(11.2 이상)이나 info-zip 3.1b등의 BMP밖 코드포인트를 제대로 지원하는 프로그램으로 압축한 결과를 v3zip에서 열어보면 BMP밖 코드포인트가 들어있는 파일만 나타나지 않네요.
이유를 살펴보니 실제 v3zip에서 압축된 zip파일에 BMP를 벗어나는 글자의 경우 local및 central헤더에서 모두 java에서 사용하는 modified UTF-8 로 인코딩된 파일명이 들어 있었습니다.
예를들어 CJK Ideograph Extension B 영역(U+20000 ~ U+2A6DF)에 속한 한자 처음과 끝 2글자(U+20000 U+20001 U+2A6D5 U+2A6D6)를 파일명에 집어넣고 압축하면 표준 UTF-8 인코딩으로는
F0 A0 80 80
F0 A0 80 81
F0 AA 9B 95
F0 AA 9B 96
처럼 4바이트로 한 글자씩 나타나야 합니다.
하지만 v3zip에서는
ED A1 80 ED B0 80
ED A1 80 ED B0 81
ED A1 A9 ED BB 95
ED A1 A9 ED BB 96
처럼 3x2바이트에 한글자씩 언급한대로 Java에서 사용하는 인코딩으로 변경되어 표현되네요.
다행히 압축한 결과가 Winrar나 7zip, Winzip에서 제대로 읽히고 풀리기는 합니다. 하지만 언급한데로 zip파일이 제대로 생성되는 info-zip이나 winzip에서 만들어진 파일을 v3zip에서는 제대로 처리하지 못하네요. BMP를 벗어나는 코드포인트의 경우 가급적 UTF-8 표준을 따라 4바이트로 표현하는게 바람직하지 않을까 생각됩니다.
그리고 왜 이렇게 인코딩을 해서 저장하게 한 것인지 이유가 궁금하네요.
또다른 질문으로서 왜 모든 파일에 일정한 유니코드 인코딩을 지정하지 않고 CP949로 인코딩이 가능한 파일명은 헤더에 CP949를 사용해서 저장하는지요? 혹시 기존 윈도우 사용자의 호환성을 최대한 유지하기 위한 하나의 방편인지요? winzip도 그런 방식으로 압축을 하기에 이런 궁금증이 드네요. PKWARE의 .zip application note에서 그런 언급을 본 적이 없는듯해서 적어 봅니다.
마지막으로 OS X에서 기본으로 제공되는 압축 프로그램으로 압축시 general purpose bit flag 11번째 비트를 local 및 central 헤더에서 1로 세팅하지 않고 OS X의 HFS+에서 강제화하는 Unicode normalization을 사용해 압축파일을 만듭니다. 이렇게 만들어진 압축파일을 윈도우에서 제대로 풀 수 있게 Unicode in NFC로 정규화하는 옵션 및 유니코드 인코딩 지정옵션을 추가해 주셨으면 합니다.
* 약 2만개의 ROM 파일을 포함하고 있는 MAME을 압축하면 Hashed list of file names is invalid - Native error: 00059라는 오류를 내뱉습니다.
* 파일을 분할압축할 때 파일명을 같게 지정하면 파일이름.zip 파일이 사라집니다.
* 미리보기 기능을 켜고 .JPG 파일을 압축해도 미리보기가 표시되지 않습니다. 보기/미리보기 외에 따로 건들여야하는 옵션이 있는 것인지요?
* 1G 이상의 분할 압축을 할 수 없습니다.
처음 두개는 치명적인 버그이며, 나머지 두개는 개선해야 할 부분으로 보입니다. 따로 리뷰를 쓰려고 해도 결국 버그를 지적하는 글이 될 가능성이 많아 지금 고민 중입니다.
삐도리님과 도아님 포스팅 잘 읽었습니다. 삐도리님이 주신 의견은 개발팀에서 현재 검토 중이고 개선 방안을 찾고 있습니다. 포스팅 중엔 UTF-8을 4바이트로 하지 않는 부분과 현재 CP949(현재 OS의 Active Code Page)로 하는 부분은 파일명을 모두 Unicode로 처리시에 기존 국산 압축 프로그램에서 해제를 하지 못하는 부분이 있어서 어쩔 수 없이 선택한 방법입니다. 의견 주신바와 같이 앞이 Unicode와 관련된 부분은 옵션 부분으로 빼서 모든 경우를 커버할 수 있도록 할 예정입니다.
도아님. 1차적으로 개선을 하였지만 아직 여러 버그가 있어서 개발팀을 대표해서 죄송하게 생각합니다. 우선 지적해 주신 부분은 내부 확인을 통해 수정할 예정입니다.
어제 패치된 V3Zip에서는 파일이 많아도 죽는 버그는 없었습니다. 대신 파일이 많으면 파일 목록을 가져오는데 시간이 너무 걸리더군요. 일단 테스트를 조금 더 해본 뒤 다시 리뷰를 올릴 생각입니다. 개인적으로는 기본적인 기능에서만 확실해도 리뷰를 쓰기 훨씬 편할 것 같더군요.
현재 V3zip이나 다른 유니코드 zip 지원 프로그램에서 처리하는 방식이 호환성 유지를 위해서 바람직한거 같습니다. 그렇게 하면 적어도 기존의 압축 프로그램들에서 유니코드로 인코딩된 파일과 디렉토리를 빼고는 보일테니까요. 제가 요청드린 사항은 유니코드 파일명 인코딩을 할 때 BMP를 벗어나는 파일명이 표준 UTF-8 인코딩으로 표기되지 않는것을 표준 인코딩으로 저장되게 해서 다른 유니코드zip을 지원하는 압축 프로그램과 호환을 이루게 해 달라는 것입니다.
그리고 맥 사용자를 배려하기 위한 선택적 추가 사항으로써, 원래 OS X의 잘못인 것이지만 OS X의 기본 압축 프로그램으로 압축을 하게 되면 유니코드를 사용해서 압축을 하지만 general purpose bit flag 11번째 비트를 세팅하거나 Info-ZIP Unicode Path Extra Field를 사용하지 않기 때문에 기존의 압축 프로그램이 제대로 압축을 풀지 못하므로 압축을 제대로 풀어주기 위해서 적어도 인코딩 옵션에 맥에 해당하는 유니코드옵션을 추가해 주셨으면 하는 것입니다. 그리고 OS X의 HFS+ 가 유니코드 코드포인트 중 일부를 풀어쓰기 표현으로 정규화하기에 이를 다시 NFC로 정규화해주는 것도 병행해 주셨으면 합니다. 이런 사항은 예전에 v3zip 공식 홈페이지 건의사항 메일을 통해 Microsoft Internationalized Domain Names (IDN) Mitigation APIs 1.1 에 관련한 API와 애플관련 링크를 알려드린적이 있습니다.
짜장면이 아나리 '자장면'이죠. 그런데 짜장면이라고 많은 사람이 쓰는 이유는 짜장면이 자장면 보다 어감이 좋기 때문입니다. 말이 나오고 맞춤법이 생겼지 맞춤법이 생기고 말이 생기지 않았습니다. 따라서 전 맞춤법에 틀린 것을 알면서 그냥 쓰는 말이 있습니다. 잇점과 짜장면등이죠. 언어는 탄생, 성장, 경쟁, 소멸합니다. 그런데 맞춤법에 말을 맞추면 언어에 이런 생명력을 불어 넣을 수 있다고 생각하는지요? 바다라는 우리 말이 생길 수 있었던 이유는 '바랄'은 맞고 '바다'는 틀리다는 사고가 없었기 때문입니다.
전에 그냥 시험용으로 zip 푸는 프로그램을 만들어 본 적이 있습니다.
[파일당 헤더][파일당 헤더]...[총체적 헤더][파일 요약 헤더][파일 요약 헤더]... 이런 식으로 되어 있더군요.
파일 요약 헤더를 무시하고 파일당 헤더만 이용하면 압축풀 때 더 많은 파일이 풀리는 경우가 있습니다. 그렇다면 파일 요약 헤더를 무시하는 게 좋은 압축 프로그램이라고 할 수 있는 걸까요?
안녕하세요 도아님 처음으로 알게 된 사실이 많네요.
좋은 정보 진심으로 감사드립니다. 일단 질문이 몇 있는데 질문 게시판에 남기려는데. 입력란을 찾지 못 하고 여기에 남기게 되었습니다. 죄송합니다. 지나치셔도 개의치 않겠습니다.
사실 전 알집과 알약을 사용 중이였는데. 이유 즉 아시다시피, 상당히 기능적이기 때문입니다.
부담이 없다고 해야하나. 그냥 가볍게 쓰기 좋은 것 같습니다.
허나, 알집을 쓰면 이상하게 압축파일이 아닌데도 아이콘에 변화가 오고
심지어 윈도우 운영 아이콘 파일에도 변화가 오더라고요. 즉, 마운스 오른 쪽 버튼을 누르고 새폴더
하나 만들려고 했는데 알집 아이콘 그림 새폴더 옆에 그려져 있더라고요. 사실 알집과 새폴더 만들기
전혀 상관없이 없는도 말입니다. 문제가 있긴 정말 있나 싶어서 검색 중에 여기까지 오게 되었습니다. 사실 컴퓨터 구동에 있어 저에게는 그렇게 치명적인 문제는 아니지만 기분이 그냥 좀 찝찝하더라고요. 사족이 길었습니다. 궁금하기도 하고 의견 좀 여쭙고 싶습니다.
1. 알집 대체로 어떤 무료 압축프로그램이 좋을까요 ?
2. 알집 설치하면 레지스트리에도 영향을 주신다고 하였는데 이를 완전히 제거 할 수 있는 방법이 있을지? 알집 설치 이전으로..
3. 알약의 사용은 괜찮은 것입니까? 알집과는 달리 아직까지 그닥 큰 문제나 의문거리를 만들지 않았고 초보인 저로써는 pc 관리이 쉽기에... 2 드라이브를 쓰는 중인데ㅡ 주로 국내 인터넷을 사용하는 드라이브는 v3 , 해외는 알약을 사용 중입니다.
님이 지금 비판하고 비난하고 계신것은 알고있으나
지금 님이 하는 짓이 정당하다고 생각하고있으신가요?
전 이스트빠도아니고 알집에 대해 아는것도 별로없습니다만은
WinRAR이 좋은 이유는 당연히 (돈)을 받으며 일하기 때문인것 같습니다.
솔직히 알집이 돈받고 했다면야 더 발전을 하겠죠
만약 님이 2가지 일을 할수있는데
첫번째일이 로봇을 만들어서 파는거고
두번째일이 로봇을 만들어서 나눠주는것입니다.
도덕적 윤리상은 두번째일이 좋은것 이겠지만
현실적으로 보자면 첫번째일이 겠지요
또 알 FTP도 무료 이므로 그러겠지요
님은 알집을 비난하시기 보다는
그냥 다른 프로그램을 써보면 어떠십니까?
라고 써주시면 감사하겠습니다.
저가 컴퓨터를 처음샀을때 알집을 썻는데
지금과 변화가 거의 없습니다
왜그럴까요?
당연히 발전이 안돼니까 그렇죠
왜 발전이 안됄까요?
자금이 부족해서가 아닐까요?
너무 이스트소프트를 욕하지마시고
한번만 다시 생각해보세요
왜 이스트 소프트의 프로그램들은 모두가 않좋을까?
그래도 이스트소프트 프로그램들에 대해 비난하고싶으시다면
어쩔수없죠
제 의견을 받아달라는게 아니니까요. 이만 글 마칩니다.
이해를 하시고 글을 쓰시기 바랍니다. 저는 애시당초 다른 것을 사용합니다. 그런데 망할 ALZ 형식과 EGG 형식 때문에 다른 것만 쓰고 싶어도 쓸 수 밖에 없습니다. 이런 현실에 대한 이해 없이 이런 글을 쓰면 쓰레기만 하나더 증가합니다. 글을 쓰기 전에 **이해력을 먼저 높이는 것이 순서일 것 같군요**.
또 이 글은 알집에 대한 글이 아니라 V3Zip에대한 글입니다. 봉창을 두드려도 맞는 곳에 가서 두두리시기 바랍니다.
알집은 개인에게만 무료입니다...아니 광고를 보면서 사용하는 애드웨어 입니다. 정말 무료라고 생각하십니까?
그리고 WinRAR은 개인사용자는 무료로 사용이 가능합니다. 쉐어웨어지만, 등록을 권유하는 창만 뜰뿐 계속 사용할 수 있습니다. 도아님의 다른글을 검색해서 읽어보시던지, 인터넷에서 알집 혹은 이스트 소프트 관련 글들을 찾아보십시오. 그럼 왜 비판을 하는지 알게될겁니다.
작년 글에도 글은 계속 올라오는군요. 간만에 kippler님의 압축시대를 구경하다가 V3zip이 생각이 나서 홈페이지 가봤더니 게시판이 없더라구요. 결국 흘러흘러 도아님 블로그로 다시 와버렸습니다. :)
역시나 글 제대로 안 읽고 이상한 소리하시는 분이 계시네요.-지금은 없으려나-
V3zip 홈페이지에는 자세한 설명이 없어서 지금 버전이 어떻게 되는지 어느 점이 개선되었는지가 하나도 없어서 조금 불편하네요. 프로그램 잘 만드는 것도 좋지만, 그런 부분도 신경을 써주면 '아~ 이 개발팀이 이런 점도 신경 써주고 있구나~'하는 걸 소비자들이 알텐데 말이죠.
새판은 1.0에서 완전히 바뀌었더군요. 1.0에서 장점으로 강조한 기능은 다빠지고 기본에 충실한 쪽으로 바뀌었습니다. 제 생각으로는 코드를 아예 다시 작성한 것이 아닌가 싶더군요. 여기에 홈페이지까지 바뀌었기 때문에 이전 홈페이지 정보를 가지고 있는 1.0에서는 최신판을 검사 못하는 듯합니다.