1.
토요일동안 간단한 프로그램을 만들었다. 일종의 일정관리 툴이라고 볼 수 있는데 할 일을 기록하는 게 아니라 한 일을 기록하는 게 특징이다. 서비스에 로그인을 하면 해당 사용자가 하고자 하는 일들이 나온다. 예를 들어 일이란 영어단어 외우기, 운동하기, 청소하기 등이 될 수 있다. 각각의 일은 달력 한 개로 표현되는데 그날 하려고 한 일을 했다면 해당 날짜를 녹색으로 체크할 수 있다.
화면에 나온 달력들을 녹색 체크로 채우는 재미를 느끼게 하는 것이 이 프로그램의 목적이다. 더 정리가 된다면 사용자가 한 십 년치 녹색 체크를 가질 수 있게 유도하는 컨셉을 잡아보고 싶다. 무엇이든 꾸준히 오랜 시간을 한다면 성취할 수 있다는 내 믿음(증거는 없다. ㅎ)을 만든 것이다. 예전에 웹호스팅 받던 개인 서버에서 게시판에 후배 한두 명과 공부한 내용을 기록하던 경험을 살려봤다.
2.
어느정도 기능 구현은 완료됐다. 안정성, 편리성 따지지 않으면 당장엔 너그러운 사용자들과 함께 쓸 수 있는 수준이다. 몇 가지 익힌 것이 있고 더 필요한 것들을 알게됐다. 까먹지 않도록 해당 내용을 정리한다.
PHP 통신
Flash 기술로 서버사이드와 통신을 하는 RPC 라이브러리를 만들어 본 것은 이번이 두 번째다.
한 개는 졸작때 만든 건데 그때는 사용 툴이 Flex가 아니라 Flash였다. 주요 내용은 이렇다.
+ Flash에서 서버와의 통신을 담당하는 객체를 dynamic으로 만든다.
+ PHP 서버에 공개 할 메소드(웹메소드)를 XML로 표현한다.
+ Flash에서 웹메소드 XML을 파싱하여 동적으로 메소드를 삽입한다.
+ Flash에서 직접 구현하지 않은 웹메소드를 사용한다.
+ 자바의 리플랙션을 사용하여 소켓 서버용으로도 똑같이 만든다. (Apache MINA 사용)
위 라이브러리를 사용하여 Flash에서 PHP를 사용한 영단어 퀴즈 프로그램과 자바 소켓 서버를 사용한 멀티유저 블랙잭 게임을 만들었다.
결론적으로 웹(PHP 라이브러리)은 Request가 있으면 Response가 있으니까 라이브러리가 꽤 편리했다. 나는 호출할 수 있는 서버 메소드 목록을 찍어볼 수 있었고 Flash에서 직접 구현하지 않은 메소드 이지만 서버가 넘겨준 스팩대로 호출하면 결과가 나왔다. 그러나 Flash-자바소켓서버 통신에서는 라이브러리의 장점이 나타나질 못했다. 소켓서버는 클라이언트가 뭔가를 요구하지 않아도 서버가 메세지를 보내기도 한다. 물론 이는 소켓 프로그래밍 자체가 가지고 있는 일정 수준의 복잡성 때문이기는 하지만 내 라이브러리가 별로 필요 없어 보이긴 했다.
이번에 새로 짠 Flash-PHP RPC 라이브러리는 개념이 다르다. 졸작때 만든 라이브러리는 서버의 구현 내용을 몰라도 인터페이스가 가능하게 하는 라이브러리였다. WebService처럼 서비스 내용과 프로토콜을 알려주는 라이브러리였다. 제작 목적이 졸작이므로 "서버의 PHP에서 메소드를 만들면 클라이언트의 Flash에서 호출할 수 있습니다." 와 같은 마법같은 문장이 필요하긴 했지만 서버/클라이언트 모두 제작하는 상황에서는 타이핑 몇 줄 줄여주는 것 말고는 쓸데없다. 또 원격 객체를 동적으로 만들면 IDE가 제공하는 자동완성을 쓰지 못한다. 졸작때는 Flash를 사용했기 때문에 자동완성 기능이 약해서 그냥 그냥 넘어갔는데 Flex에서 그러고 싶지는 않았다.
새로만든 라이브러리는 아래와 같은 구조로 작동한다.
+ Request를 처리하는 클래스를 상속받아 새로운 클래스를 만든다.
+ Flex에도 위에서 만든 클래스에 대응하는 클래스를 만든다.
+ 원격 메소드를 호출하면서 class와 method를 post로 넘긴다.
+ php에서 class 이름으로 클래스를 생성하고 method를 실행시킨다.
+ 결과를 XML로 받는다.
대충 앞의 라이브러리와 비슷하지만 서버가 기능 목록을 전송하는 과정이 없고 호출하는 클라이언트도 호출 클래스를 직접 구현해줘야 하는 차이가 있다.
WebORB, BlazeDS 등으로 AMF 쓰는 것을 생각할 수도 있겠지만 남의 것 쓰면 조금 위험할 수 있다는 생각과 실제로 내 웹 호스팅에서는 이 프레임워크들이 잘 작동을 안하기 때문에 또, WebORB는 PHP 버전을 사용해 봤으니 그리 편하다는 생각은 들지 않아서 만들어 봤다.
통신을 하다 생기는 오류는 서로 다른 시스템이기 때문에 문제의 원인을 쉽게 노출시키기 어렵다. Flash가 PHP로부터 xml을 받으려고 했는데 PHP 코드에 에러가 생길 수 있다. Flash에서 xml로 형 변환을 하려다가 PHP 에러 구문이 xml이 아니니까 예외가 뜨게 되는데 이때 심각하게 고쳐야 할 것은 PHP 코드이지 Flash는 아니다(물론 예외 처리가 필요하다). 이때 아무 메세지 없이 Flash 코드를 노려보고 있다면 갑갑해지기 쉽상이다. 이를 수월하게 하기 위한 출력이 필요하다.
UX
DB에 기록하고 결과를 받아서 화면에 표현하기까지 지연이 생긴다. 만약 On/Off 버튼을 구현한다고 하면(GMail의 별표 기능 처럼) 서버 지연 때문에 엇박으로 클릭을 하다가 이제 된건가 하고 가만히 서버의 응답을 기다려야 하는 상황이 생길 수 있다. 이게 생각 이상으로 답답하다. 사용자가 클릭하면 일단은 처리된 것으로 보여주고 서버에서 데이터를 받아서 성공하면 놔두고 실패하면 실패를 알리고 화면을 갱신하는 식으로 처리하는 것이 좋을 것 같다.
당연한 효과들
화면에 보여지는 여러개의 달력 중 변경된 한 개의 달력 내용을 표현하기 위해 전체 달력 레이아웃과 체크 데이터를 새로 갱신할 필요가 없다. RIA의 장점이다. 이게 데이터 전송량에서만 이점이 생긴다고 생각했는데 서버 자원을 절약해 주기도 한다. 물론 AJAX로 할 수도 있겠지만 내 학습상태로는 Flex가 편하다. 물론 이러한 프로그램이면 Flex로 만드는 것 보다 AJAX로 만드는 게 더 좋을 것 같다는 생각이 있다.
더 필요한 것
+ 세션처리 - 세션을 담당하는 게 Flash를 담고있는 브라우저인지, Flash가 서버와 통신하는 객체인지 아직 파악을 못했다.
+ DB 생성 스크립트 - 지금이야 상관 없는데 배포가 되고나서 DB가 바뀌면 골치 아프다. DB도 버전에 따라 자동으로 스키마를 변경 해주는 유틸리티가 필요하다. 이미 있거나 만들기 어렵다는 결론이라도 어디 있을 것 같긴 한데...
+ 서버 자동 배포 - 배치파일과 FTP를 사용하여 업로드를 하던 코드는 만들었었는데 이러면 릴리즈 과정과 같이 묶이지는 못한다. Ant나 Maven을 쓸 수 있도록 변경한다.
+ 그러므로 유닛 테스팅.
+ Debug mode지원 - 앞에서도 썼지만 개발 중에 생기는 오류를 파악할 수 있는 장치가 절대적으로 필요하다.
+ 다른 사람 화면 볼 수 있게 하기.
+ 한 일 등록 정책.
3.
전반적으로 Flex로 그닥 뛰어난 성능은 아니지만 대중적인 서버와 통신하는 효율 적인 방법에 대해 학습을 했다. 앞으로는 통신부분을 더 집중하는 것이 좋을 것 같다. 아무래도 계속 사용할 수 있는 코드이고 한 번 해결해 놓으면 반복적인 테스트에서 의미없이 소비되는 접근 시간을 줄일 수 있기 때문이다.
댓글 없음:
댓글 쓰기