http://moordev.tistory.com/20


우선, 링크의 글에서 저는 갖은 삽질을 통해서 안드로이드 버전을 올릴 수 있었습니다. 그런데 이것이 무엇을 의미하는 것인지 이때까지 저는 알지 못했습니다. 갑작스런 한글패치 및 삽질 하기 전에는...


관심 없으시겠지만 패치 제작 동기를 보고 싶으시다면 클릭


우선 이야기는 쭉 거슬러 올라가서 제가 Long Live The Queen의 한글패치가 개발중이라는 소식을 들으면서 시작됩니다.

http://ghap.tistory.com/entry/LONG-LIVE-THE-QUEEN-%ED%95%9C%EA%B8%80-%ED%8C%A8%EC%B9%98-%ED%8C%8C%EC%9D%BC%EC%9E%85%EB%8B%88%EB%8B%A4

끄암이라는 분께서 팀 왈도와 함께 한글패치를 공개중이라는 소식을 듣고는 적용을 해보았습니다. 그리고 이것을 안드로이드로 포팅하기 위해서 또 다른 삽질을 시작합니다.


Ren'Py의 최신 버전을 다운로드 받고 glpatch.rpy 삭제, steam.rpy 삭제, translation.rpy를 unrpyc한 후 2줄 주석 처리

translation.rpy

screen language_select:
    tag menu
    modal false
    add 'video_prefs_bg'
    vbox:

 →

screen language_select:
    tag menu
    # modal false
    add 'video_prefs_bg'
    vbox:

                 renpy.file(fn).close()
                return fn
            except:
                return s
        
        renpy.display.text.text_tags['tag'] = False
label set_language_failed:
    "An error occurred loading the new language:\n%(last_exception)s"
    return

 →

                 renpy.file(fn).close()
                return fn
            except:
                return s
        
        # renpy.display.text.text_tags['tag'] = False
label set_language_failed:
    "An error occurred loading the new language:\n%(last_exception)s"
    return

 

 

 

그리고 안드로이드에만 해당되는 패치로써

config.searchpath[0] 을 전부 '/sdcard' (따옴표 포함)로 찾아바꾸기 함으로써 한글패치 중 translation 폴더를 sdcard에 넣어서 패치가 인식되도록 고칩니다. 


그 다음 이전과 똑같이 rpatool로 llq.rpa 파일을 풀어버립니다.

그리고, 렌파이 런처에서 안드로이드로 작업하면 모든 것이 끝이 납니다. 정확히는 해당 글의 유튜브 영상을 보시면 안드로이드 포팅이 완료 됩니다. 그냥 유튜브 영상을 따라한 후 위의 작업을 해주시면 모두 완료 됩니다.

 

바로 여기까지가 안드로이드포팅을 위한 삽질이었습니다. 그런데 '/sdcard'로 찾아바꾸기를 하는 것을 제외한 나머지 작업이 또 필요하게 될 줄은 저도 몰랐습니다.

안드로이드 포팅 하면서 한글패치를 하고 한글화가 몇 군데가 덜 되었다는 것을 발견 합니다.

이 부분은 포럼에서도 말이 많은 부분이다. 왜 번역이 안 되는지 이유를 알 수 없다고..

즉, 몇군데가 완벽히 번역이 되지 않았는데, 문제는 번역파일 내에 이 문장들이 들어있었던 겁니다. 즉, 번역파일이 있음에도 문장이 번역이 되지 않는 이상한 현상이 생긴 것입니다.

이를 해결하고자 렌파이 내에 자체 번역기능이 있다는 것을 알게됩니다.

options.rpy에

config.language = "korean"

이 한 줄을 추가하고 렌파이 루트에 environment.txt 파일을 만들고, 그 안에

RENPY_UPDATE_STRINGS=""

이 한 줄을 넣어주면 이후 렌파이런처를 통해 게임을 할 때마다 game/tl/korean/strings.rpy 파일이 생성되면서 번역을 위한 파일이 생성 됨을 알 수 있었습니다. 그리고 여기서 번역을 해서 문장을 처리하니 잘 만 되더군요.(좀 노가다이기는 하지만)


그런데.....


렌파이런처가 아닌 스팀을 통해서 실행을 하면 오류가 나는 것이 문제였습니다. 그것도 tl/korean/strings.rpy 파일이 문제라고 하더군요.

웃긴것은 렌파이 런처를 통해서는 잘만 실행이 되었다는 겁니다.

렌파이 런처를 통해서 실행하면 에러가 없었단 말이다. 대체 뭐가 문제야!

....


결론부터 말하자면 렌파이 런처를 통해서 실행하면 최신버전의 렌파이(즉, 안드로이드 포팅을 위해 다운로드 받은 그 렌파이)를 통해 실행이 되고 스팀으로 실행하면 기존에 제작자가 만들었던 렌파이로 실행이 되는 것이었습니다. 즉, 렌파이 버전이 달라서 생긴 문제입니다.

기존 버전은 6.12.2 이었고, 이번에 제가 다운로드 받은 버전은 6.17.7이었습니다. 이 버전 차이가 약간의 문제를 일으킨 것입니다.


제가 안드로이드 포팅을 위해 이리저리 뜯어고치고 바꾸고 한 것이 사실 제가 다운로드 받은 렌파이엔진에 맞게끔 뜯어고친 것과 같은 것입니다. 그리고 저 game/tl/korean/strings.rpy 파일도 기존 스팀으로 다운로드 받은 렌파이로는 처리가 불가능(translation 관련 스크립트가 전무합니다.)했기에 에러를 뿜은 것입니다.


...그래서 렌파이 런처로 어쨌건 실행은 되긴 되니까 배포판 만들기 기능으로 아에 새로운 배포판을 만들어봤습니다.


내가 만든것도 아니면서 배포판 기능을 사용했다... 뭐 직접 배포할 것도 아닌데 뭘


중간에 options.rpy 파일을 손대는 과정이 있었는데 잠깐 무시하고 배포판으로 만들어진 것을 직접 실행해봤습니다. 그랬더니 Steam문제만 일으키고 마네요?

그래서 options.rpy를 기존것으로 교체후에 Steam에 있던 폴더를 교체해봤습니다.

잘만 번역 되네요. 심지어 스팀도 연동 잘 됩니다.그런데 이것이 의미하는 것이 한 가지 있었습니다...게임엔진이 완전히 교체되었다는 사실입니다. 이제, 렌파이도 버전이 바뀌었고, Python도 Python2.6에서 Python 2.7로 바뀌었습니다. 이것이 어떤 문제를 일으킬지는 알 수 없지만, 최소한 번역 관련해서 문제를 일으킬 것 같지는 않군요.


LongLiveTheQueen/lib/ 폴더트리구조부터 바뀌었다. 이외에도 LongLiveTheQueen/renpy/ 도 당연히 바뀌었다. 엔진 버전 자체가 바뀐 상태로.

그리하여...해당 엔진 버전업 패치를 공개하고자 합니다. 그런데... /game/ 폴더 제외하곤 거의 통짜 교체라 이게 먹힐지 안 먹힐지....


닫기



이미 대부분의 기능이 Ghap님 패치에 이식 되었습니다. 몇몇 추가기능(그래픽 가속 기능, 렌파이 번역엔진, 안드로이드 포팅)등을 이용하실 생각이 있으신 분들만 사용해주시면 됩니다.

단순 게임을 즐기기 위해서라면 Ghap님 패치만으로 충분합니다. (몇몇 문장 번역 안 되는 문제는 Ghap님 께서 alpha버전을 통해서 작업하고 계십니다. 필요한 기능이 alpha버전에 들어가 있거든요.)




이 패치는 우선적으로 http://ghap.tistory.com/entry/LONG-LIVE-THE-QUEEN-%ED%95%9C%EA%B8%80-%ED%8C%A8%EC%B9%98-%ED%8C%8C%EC%9D%BC%EC%9E%85%EB%8B%88%EB%8B%A4

여기에 있는 패치 적용이 전제되어야합니다. 즉, Ghap님의 패치를 먼저 하시라구요...


단!!! 우선 Ghap님 패치중에서 options.rpy는 하지 말아주십시오. 엔진 교체시 스팀 연동불가의 원인이 될 수 있습니다. 우선 options.rpy를 뺴고 제 패치를 설치한 후에 구동해 보십시오. 구동이 잘 된다면 그냥 게임을 해주시면 되고 구동이 안 되시면 그 때 options.rpy를 넣어주셔도 늦지 않습니다.


우선 기존의 C:\Program Files\Steam\steamapps\common\LongLiveTheQueen\renpy폴더를 미리 삭제해 주셔야합니다.

안 그러면 엔진충돌 납니다. 혹시 모르니 미리 백업하시는 것도 필수입니다.

리눅스 사용자라면

~/.steam/steam/SteamApps/common/LongLiveTheQueen/renpy 폴더를 미리 삭제해주시면 됩니다.


이전버전

그리고 


윈도우 사용자용(7z압축)
리눅스,MacOSX사용자용(tar.gz압축 권한 설정이 되어있습니다.)


위의 패치를 다운로드 받으신 다음 그대로 덮어쓰기 해주시면 됩니다. 


리눅스 사용자는 tar.gz 파일을 이용하시면 따로 권한 설정을 하실 필요가 없습니다.

그리고 리눅스 사용자에 한해서 다음 명령어로 실행권한을 주시기 바랍니다.(OSX는 모르겠습니다. 아마도 리눅스 처럼 해줘야 할 것 같습니다.)


chmod +x ~/.steam/steam/SteamApps/common/LongLiveTheQueen/lib/linux-i686/LongLiveTheQueen

chmod +x ~/.steam/steam/SteamApps/common/LongLiveTheQueen/lib/linux-x86_64/LongLiveTheQueen

chmod +x ~/.steam/steam/SteamApps/common/LongLiveTheQueen/LongLiveTheQueen.sh


이 패치로 인해 생기는 문제에 대해서 저는 책임을 지지 않습니다. 패치를 함으로써 생기는 문제는 전적으로 사용자 책임입니다.


번역은 Ghap(ghap.tistory.com)님과 팀 왈도의 결과물입니다. 번역본을 다른 용도로 이용하실 분은 미리 번역자분께 허락 받기 바랍니다.


8월 9일 추가


이 이미지를 moodbg.png라고 /game 넣어주시면 기분 탭의화면이 이것으로 바뀝니다. 영문 폰트를 대충 지운 흔적이 보이지만 게임상에선 아무 지장없습니다.(...)


8월 10일 새벽에 추가


Prettyprint.rpy(숫자관련 스크립트)부분을 대폭 수정하여 영문으로 뜨는 부분을 날려버리고 아라비아숫자로 뜨도록 바꿨습니다.  one two 등으로 뜨는 부분을 1,2 로 싹다 바꿨습니다. 하나 둘 셋으로 바꿔도 되지만 우리나라 말 특성상 한 대대 두 소대 세 중대 등 단위가 바뀌면 또 말이 바뀌어서 그냥 아라비아 숫자로 뜨도록 했습니다. 이렇게 하는 것이 더 보기에 낫고요. 일부 함수가 작동을 하지 않은 것으로 판단되어서 그냥 함수를 덮었습니다. 그랬더니 잘 되네요. 이유야 어찌되었든...


그리고 추가 개선 한글 패치에서 Ghap님의 1.5버전에 맞게 일부 수정했습니다. 어쨌건 이 패치를 하면 한글은 잘 나오는데 다른 언어 사용자들은 지옥을 맛보게 될 겁니다.(설마 이 게임을 영어 공부하는데 쓰지는 않겠지요?)


8월 10일 버전 패치(구글드라이브라 속도가 매우 느립니다. 인내를 갖고 기다리시면 다운로드가 될 것입니다.)


윈도우 사용자용(7z압축)
리눅스,MacOSX사용자용(tar.gz압축 권한 설정이 되어있습니다.)


8월 12일 새벽.

로그 기능에 문제가 생겼던 이유는 파이썬이 기본적으로 아스키 코드를 기반으로 만들어지기 때문에 벌어진 일입니다. 해당 파이썬 스크립트 시작 부분에


sys.setdefaultencoding('utf-8')


요 한줄을 추가 함으로써 해결이 됩니다.

브라우저에서 마구 깨지는 문제는 htmlize_readback_log() 함수 첫줄에

<head><meta http-equiv="Content-Type" content="text/html;charset=UTF-8"></head>

이 <html>와 <body>사이에 태그를 삽입하도록 만들면 됩니다.


html = '<html><head><meta http-equiv="Content-Type" content="text/html;charset=UTF-8"></head><body>'


이런 식으로 말이지요.


아래 13일 버전 패치를 통해서 해결 했습니다.

도로 접기


8월 13일 버전 패치(구글드라이브라 속도가 느립니다. 기다려 주시면 링크가 뜰 것입니다.)

{스팀경로}/LongLiveTheQueen 폴더에 압축을 풀기 전에 LongLiveTheQueen/renpy 폴더를 미리 삭제해 주시기 바랍니다.

Ghap님의 패치와 달리 (스팀경로)/LongLiveTheQueen 폴더에 압축을 풀으셔야 합니다.



윈도우용 (7z압축)

리눅스,OSX용 (tar.gz압축 따로 권한설정 필요없음)


수정사항

1. 로그 관련 오류 수정 - UTF-8인코딩을 기본적으로 쓰도록 함 (기존은 ASCII 인코딩이었음)

2. 저장이나 불러오기 중에 빈 슬롯에 "Empty Slot" 을 "비어있음"이라고 뜨도록 함. 200개 까지는 커버 함

3. 과목을 다 배우거나 한 종류만 50을 배웠을 때 과목 명이 영문으로 뜨므로 임시로 그것을 막기 위해


"당신이 현재 배우는 스킬은 50이 되었습니다. 같은 그룹내의 다른 스킬들이 25 이상이 되기 전엔 해당 스킬을 향상시킬 수 없습니다."

"당신은 이 스킬에 대해 더 배울 것이 없습니다."


이런 식으로 뜨도록 수정. - 한국어를 이용한 꼼수 - strings에 적힌 것과는 별개로 translation.rpy에 하드코딩 했으므로 무조건 이렇게 뜹니다.


4. prettyprint.rpy에 몇몇 함수가 여전히 작동 불능상태이므로 readable_number_small함수를 Override하는 식으로 덮었음. 함수가 작동 안 하는 일은 없을 것입니다.

(주의. Ghap님의 1.6버전의 한글패치 중 /translation/kr/ui/printpretty.rpy 파일이 들어있는 한 해당 스크립트가 우선 오버라이드 됩니다. /translation/kr/ui/printpretty.rpy 및 /translation/kr/ui/printpretty.rpyc 파일의 삭제 부탁드립니다. strings파일도 같이 있는 것으로 봐서 ghap님이 실수 하신 것으로 보입니다.)


5. 세이브파일에는 0주차로 뜨고 게임 내에서는 1주차로 뜨는 것을 수정 하는 패치 제작(제작사와 관계없이 수정 했으므로 무슨 일이 벌어질지 저도 모릅니다. 제작사는 버그가 아니라고 했으므로 안 하셔도 됩니다.)

세이브 주차수 관련 패치


압축을 풀어서 /game 폴더에 넣어주십시오.


6. 제일 중요한 오타 및 실수 수정.

,

Gambas는 토마토소스에 야채를 썪어서 만든 매콤한 요리입니다. 보통 뷔페등지에 가면 볼 수 있는 음식이지요. 그런데, 갑자기 우분투 블로그에서 왜 요리이야기룰 하냐고요? 사실 Gambas는 이 요리만 있는 것이 아닙니다. Gambas는 리눅스 환경에서 Basic언어로 GUI를 만들어낼 수 있는 막강한 툴의 이름이기도 합니다.

 하지만, 제작자도 이것을 알고 있어서 프로그램 아이콘이 새우입니다. 토마토소스에 볶은 새우요리인데, 정작 아이콘은 파란 새우네요. 약간 유머와 위트를 섞은 것 같네요.


즉, 이 요리이야기가 아니라 이미지 출처 -http://www.piospaella.com/food/item/gambas-al-ajillo/


바로 이 개발도구 이야기 입니다.


우선 gambas 이야기 하기 전에 Visual Basic이야기를 해야 할 것 같습니다. Visual Basic은 Basic언어를 사용하는 RAD(생산성 향상 개발도구 정도라고 생각하시면 편합니다.)입니다. 우선 쉽기로 유명한 Basic언어를 쓰면서 GUI도 상당히 자유롭게 만들 수 있어서 VIsual Basic은 초보 개발자들에게 입문용으로 많이 추천되어져 왔습니다. 다만, 6.0까지만 그랬고 이후에 나온 VB.net같은 물건은 Basic을 쓰기는 쓰는데 워낙 기능이 많아서 입문용으로 C보다 별로인 물건으로 굴러떨어지고 말았습니다. 실제로 지금도 Visual Basic은 2005이후 버전을 쓰거나(그나마도 대부분 교육용으로 나온 2005 Express을 씁니다.)아직도 6.0을 쓰고 있습니다. 6.0이 가볍기도 하지만, 그만큼 VB.net에서 이것저것 기능을 추가하다보니 문법이 방대해진 것도 한 몫 했습니다. 



Visual Basic 6의 모습, 개발자 친화적이라는 Microsoft의 역작중 하나이다. 출처- 위키피디아



하지만 그 특유의 생산성은 여전해서 아직도 간단한 시리얼 통신을 기기 제어, GUI를 구현하는데 많이 쓰이고 있고, 지금도 막강한 영향력을 발휘합니다. 그러다보니 리눅스나 BSD진영에서도 이러한 Visual Basic스러운 물건이 만들어 지는데 이게 바로 Gambas입니다. 그러나 Gambas와 Visual Basic은 서로 호환이 전~혀 안됩니다. 실제로 Gambas홈페이지(http://gambas.sourceforge.net/en)에서도 Visual Basic과의 차이를 들어가며 설명중입니다.

아는 선배의 부탁으로 gambas로 만들고 있는 측정 프로그램, 이걸 만드는데 하루도 채 걸리지 않았다.


하지만 Gambas도 결국 Basic언어를 쓴 하나의 도구이기 때문에 코드 호환성이 어느 정도 확보가 됩니다. 마음만 먹으면 Visual Basic에서 동일하게 컨트롤을 배치하고 Name을 똑같이 배정한 다음 코드를 그대로 복사-붙여넣기 하면 60%정도는 돌아갈 것입니다. 고작 60%?라고 생각하실 수 도 있겠지만 이 정도면 선방한 셈입니다. Basic을 쓰더라도 Visual Basic와 QBasic은 죽어도 호환 안 되는 것을 생각하면 이거라도 감지덕지입니다. VB나 Gambas나 생산성을 위한 도구니까, 본격적으로 만드는 프로그램에는 적합하진 않습니다. 본격적으로 만드실려면 C/C++나 Python같은 언어로 개발하시는 것이 나중에 기능 추가등에 편리합니다. (Visual Basic으로 제대로 만들어서 판매하는 사람도 있기는 합니다. 언어에 한계란 것이 없어서...) 애초에 OS호환성을 따질 생각이었으면 VB나 Gambas보다는 Python + QTCreator or Glade(GUI를 위한)을 쓰는 것을 추천드립니다. 이 쪽이 나중에 기능 추가를 한다거나 호환성을 확보할 때에는 이쪽이 훨씬 더 편리합니다.


하지만 나중을 위해서가 아니라, 그냥 지금 당장 프로그램을 만들어야 하는데 시간이 없다면 Gambas를 쓰는 것이 100배 낫습니다. 윈도라면 Visual Basic으로 하시면 되고요. 하지만 Visual Basic은 가격도 가격이고, 최근 버전은 너무 더럽게 구동이 느려서 저는 그냥 리눅스 환경에서 Gambas를 씁니다. 원한다면 라이브 리눅스에 Gambas런타임하고 새로 짠 프로그램 넣고 주면 그만이니까요. 지금 당장 데이터를 뽑아내야 하는데 가장 생산성이 좋은 Labview는 가격이 상당한데다가 전용 하드웨어가 필요하고, Python은 Glade나 QTCreator와 조합해야 하는데 못 할 것은 없는데, Gambas에 비해 만드는 것이 쉽지는 않습니다. JAVA도 나쁘지는 않지만 GUI 만들기가 제가 이야기한 것 들에 비해 생각보다 어렵습니다.(Swing은 XML로 뽑아내는 GUI가 없는 것으로 알고 있습니다. 만약 Glade처럼 XML로 뽑아내주는 도구가 있다면 트랙백이나 댓글 부탁드립니다.)


Gambas를 이번에 쓰면서 느낀 것이지만, Visual스러운 개발 환경을 갖추면서 오픈소스란 점은 정말 매력적입니다. 원한다면 뚝딱뚝딱 만들어낼 수 있는 점도 상당히 마음에 들고, 기존 Visual Basic사용자들도 별 무리없이 넘어 올 수 있습니다.(몇몇 문법차이는 배우면 되니까 크게 문제는 없습니다.)


장점만 크게 이야기 한 것 같은데 단점도 생각보다는 큽니다. 우선 Visual Basic의 단점은 모두 물려받았습니다. 컨트롤 부족=개발단계 급증가를 의미합니다. 아니, 컨트롤을 개발해야 하는 입장이 된다면 그냥 Basic을 버리고 C/C++만으로 넘어가는 것이 훨씬 좋습니다. 처음부터 C/C++로 개발을 하면 중간에 Basic을 끼워넣어서 두번 거치게 하는 것보다 더 쉽게 처리 가능합니다. 물론 나중을 위해서 컨트롤을 미리 개발할 수도 있겠지만, 만약 비공개 프로젝트라던가, 단순 레포트제출용 데이터라던가 하면, 이 과정은 그냥 '삽질'일 뿐입니다. VB.net은 이를 해결 하기 위해서 오만가지 잡다한 것들을 다 넣어놓았는데, 도리어 Basic하지 못해지면서 사람들에게 외면을 받고 말았습니다. 2005 Express부터는 그 기능을 그대로 가져오면서 필요없는 것들을 가리는 등의 Basic한 면을 돌려놓았다고는 하는데 이미 Basic세상은 C#이 점령해가고 있었습니다.(아아...Basic은 이렇게 몰락해 가는가....) Gambas도 마찬가지로 VB.net수준으로 만든다면 사람들에게 외면 받을 것입니다. 그러다보니 컨트롤이 좀 부족하다는 느낌이 들 때가 있습니다. SDL같은 물건도 지원하는 굉장한 능력은 지녔지만, 저는 SDL기능을 쓴 적이 없네요. 아니, 사실 쓸 일이 없었던 것일지도 모르겠습니다.


또 다른 단점으로는 OS호환성 문제가 있습니다. 즉, 호환성이 문제를 일으킨다는 것인데 우선 Gambas는 BSD와 리눅스에서 GUI Basic을 사용하기 위한 것으로 출발 했기 때문에 윈도는 전혀 지원하지 않습니다. 특히 Xorg에 거의 대부분 의존하고 있기에 Xorg를 사용하지 않는 다른 OS는 절대로 지원이 안 된다고 합니다. OSX도 Xorg가 그나마 설치가 되기 때문에 그럭저럭 쓸 수는 있지만, OSX는 Xorg의 구동이 매우매우매우 답답하게 돌아가기 때문에 별로 추천하지 않는 다고 하네요. 윈도는 Cygwin에서 GUI를 제외하고는 구동이 된다고 합니다. 그런데 GUI 안되면 왜 Gambas로 개발하나요? 그냥 Python으로 만들던가 Bash스크립트 만들어내지.... 구글을 통해서 알아보니 다들 그냥 가상화해서 리눅스 올려 쓰라고 하네요.

OS호환성 말고도 버전별 호환성문제도 있습니다. 하지만 이 버전별 호환성 문제는 JAVA나 Python도 겪고 있는 문제이니 Gambas만의 문제라고 볼 수는 없습니다. 게다가 Python 2.7이 Python3.x 보다많이 쓰이면서 구 버전을 기본을 설치하는 등의 일도 일어나지 않고 있습니다. Gambas2.x보다 Gambas3.x가 훨씬 더 많이 쓰이고 훨씬 더 많이 포럼에 글이 올라옵니다. 그냥 기존 Gambas2프로젝트를 Gambas3로 바꾸는 것이 더욱 이득이 되는 상황이라 이것은 그냥 단점을 상쇄하네요.


리눅스와 BSD에서 Visual Basic같은 도구를 찾으신다면 당연히 Gambas를 설치하세요. 만약 Visual Basic을 쓰셨다면 더욱 금상첨화입니다. 어쩌면 이 새우요리가 여러분의 프로젝트를 빠르게 성장 시킬 동력이 될 수도 있으니까요.

,

두 IDE의 차이는 성능상으로 큰 차이가 없고, 인터페이스도 사람들마다 반응이 달라서 완벽하게 비교는 저의 특성 상 어려웠습니다. 따라서 단순히 사용에 따른 문제와 그 부분에 대한 이야기가 주류로 쓰여질 것입니다.


안드로이드 앱을 개발하려고 한다면 분명 예전에는 100이면 100 Eclipse + ADT였습니다. 사실 그것밖에 답이 없기도 했고 Eclipse가 워낙 JAVA개발툴로써 제일 좋은 물건이었기 때문에 대부분 이것을 이용했고, JAVA를 이용하는 안드로이드로써는 Eclipse와의 궁합이 가장 중요했지요.


그런데 구글은 Eclipse가 상당히 마음에 안 들었던 모양입니다. 자체적으로 Android Studio란 물건을 내놓았거든요. 사람들 반응은 상당히 괜찮은 물건이라고 합니다. 제가 써본 결과로는 잘 모르겠네요. 다만, 한 가지 기능이 상당히 마음에 들던데, 그 기능은 바로 SDK버전 별로 APK를 빌드 해 주는 기능이었습니다.


Android Studio의 모습. Eclipse와 다른 것은 대체 무엇일까?


Eclipse 시절에는 한번 SDK 최소 버전을 설정하면 SDK버전을 맞추기가 상당히 어려웠습니다. 특히 프로젝트를 API 15로 시작했다면 나중에 구 버전 안드로이드 호환을 위해서 API10으로 낮춘다는 것은 불가능한 일이었습니다. 반대로 신 버전 안드로이드의 추가된 기능을 쓰기위해서 API버전을 올리는 것도 문제가 많았습니다. 컴파일이 안 된다거나 소스가 꼬인다던가 하는 일이 많았지요. 그런데 Android Studio로 만들면 이와 같은 문제가 한번에 해결되더군요. 빌드 할 때 API버전별로 APK를 뽑아내줍니다. 나중의 업데이트를 위한 방법으로 정말 좋은 기능이지요. 새 안드로이드가 나올 때마다 호환성 문제를 매번 겪는 것을 감안하면 정말 눈물 나게 고마운 기능입니다.


그 외에도 많은 개발자들은 Eclipse를 버리고 Android Studio로 넘어갔다는 후문입니다. 하지만 딱 하나 Android Studio를 쓰지 못하는 사람들이 있습니다. 바로 NDK가 지원이 안 되는 문제가 있습니다. NDK는 빠른 구동을 위해서는 필요한 라이브러리이지만 일반적인 어플에서는 필요없는 물건입니다. 특히 자바만 이용한다면 당연히 쓸모 없습니다. 하지만, 게임이라던가 동영상 재생기(MX플레이어 같은 소프트 디코딩 지원 재생기)라면 NDK는 없어서는 안되는 물건이지요. 이 사람들은 어쩔 수 없이 Eclipse를 써야합니다.


하지만 Eclipse를 NDK를 쓰지 않음에도 사용하는 사람들이 있습니다. 이 사람들의 생각은 바로 이것입니다. "구관이 명관이다." 아무래도 이 생각으로 아직도 Eclipse를 사용하는 것 같습니다. 심지어 구글은 아직도 Eclipse의 ADT를 지원해주고 있습니다. 그도 그럴 것이 Android Studio는 아직도 베타 딱지를 못 떼내었습니다. 각종 버그가 출몰 중이라고 하는군요. 저도 실행 중 튕김 증상을 겪었습니다. 아직 베타이니 그러려니 하지만, 진짜 중요한 개발이라면 별로 추천할 만한 상태는 아닌 듯 합니다. 아무리 좋은 기능이 있어도 안정적이지 못하면 그건 쓸모없는 것이니까요. 그냥 개인 개발자라면 그래도 무리없이 쓸 수 있겠지만 수십 수백의 돈이 오가는 프로젝트라면 불안정한 Android Studio보다 기존에 써왔던 Eclipse가 더 믿음직 할 것입니다.


기존 안드로이드 개발용으로 많이 쓰인 Eclipse의 모습. JAVA, C/C++등의 범용이라 안드로이드만의 특화 기능은 플러그인을 이용해야만 한다.

개발의 편의성은 Android Studio가 훨씬 더 우세합니다만, 익숙함은 Eclipse가 더 우세합니다. 당연한 이야기겠지만, Eclipse가 기존에 사용되어지는 바람에 서점의 대부분 책들은 아직도 Eclipse만을 설명하고 있습니다. Android Studio에 대한 책은 아직도 찾지 못했습니다. 거기에 따른 여파로 Android Studio에 대한 한국어 커뮤니티도 Eclipse에 비하면 작은 편 같습니다. 다들, 넘어가야한다는 것은 알고 있지만(구글이 Android Studio를 만든 이상 결국 이 것이 표준 개발툴이 될 것임은 당연해 보입니다.) 그동안 써온 습관과 익숙함 때문에 벗어나기 힘들다고 하는군요. 무엇보다 새로 배워야 한다는 부담감도 꽤 있는 듯 합니다. 같은 JAVA코드를 이용하지만, 인터페이스 자체가 다르다보니 생기는 문제라고 할 수도 있습니다.


지금으로썬 Eclipse가 편하다면 Eclipse를 써야겠지만, 결국 Android Studio가 자리를 잡게 되면 이것을 쓸 수 밖에 없는 날이 올 것입니다. 아니면 구글이 또 다른 IDE를 내놓을 지도 모르고요. IDE를 사용하는 것은 개발자 마음이지만, 사용자들은 새로운 기능이 나오면 이 기능을 이용하려고 합니다. 앱 개발자도 엄연히 말하자면 장사꾼이니까요. 장사꾼은 소비자가 원하는 것을 충족시켜줘야 물건이 팔립니다. 해당 앱의 미래를 위해서 제 생각에는 Eclipse로 개발된 앱을 Android Studio에서 바로 끌고 올 수 있었으면 좋겠습니다. 그런 방법이 있을 지는 잘 모르겠지만요.


Android Studio가 현재는 불안정한 모습도 보이고 있지만 Eclipse를 대체할 것은 확실해 보입니다. 기존 JAVA IDE가 아닌 안드로이드 전용의 IDE인 것도 한몫하고 있고, 그만의 특수기능도 가지고 있습니다. IDE와 통합된 테스트 환경이라는 것이 정말 편리하고 또 생산성도 월등히 향상시킵니다. 구글이 Android Studio의 안정화가 완료했다는 소식이 들려온다면 저도 지금 하는 프로젝트를 Eclipse에서 Android Studio로 옮길 예정입니다. 





과연 Android Studio는 Eclipse를 확실히 밀어내고 독보적인 IDE가 될 수 있을까요? 아니면 그동안 써온 IDE라는 장점을 안고 Eclipse가 계속 안드로이드 개발도구의 1인자가 될까요? 그것은 시간이 알려줄 것입니다.


2015. 10. 26

이 글이 적은지도 약 1년정도 지났군요.

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20150628150257

현재 Eclipse 기반의 ADT는 지원이 종료됩니다. 그냥 Android Studio를 쓰는 것이 제일 낫습니다. 이제 버그도 많이 없어졌고 상당히 편리해졌습니다. NDK지원도 잘된다고 하니(Windows에서는 간간히 문제가 있다고는 하지만...가상머신이나 멀티부트로 우분투 깔면 해결됩니다.) 이제는 Android Studio를 쓰시면 됩니다.

,