OOJJRS

3월 한 달은 주말마다 팩토리오를 즐겼다면, 4~5월 두 달은 주말마다 아크를 즐기느라 –_- 한동안 격조했었다.

이제 당분간은 할 게임이 없을 것 같아 안도하면서, 작업한 내역을 스샷으로 대체하여 올려본다.

대화 입력창의 컨트롤을 RichTextBox에서 서드파티 TX TextControl 로 교체해 보았다.

사용법도 상식에서 어긋나지 않는데 문서도 잘 마련되어 있어 만족스럽다.

이런 걸 무료로 풀어주다니 제작사에 감사드립니다.

웹 서버가 클라이언트의 요청을 처리할 때 일반적으로 path와 query를 통해 호출되는 메소드를 분류한다면, 웹소켓은 태생부터가 기존 웹 동작 방식과 다르기 때문에 이 api 사용법에 있어서도 차이점이 생기는 것 같다.

connectionless이기 때문에 매 요청 시 api를 변경할 수 있는 일반 웹에 비해 웹소켓은 TCP와 마찬가지로 connection-oriented인 관계로 처음 연결 요청 외에는 웹소켓 자체 인터페이스만 갖고는 api를 변경할 수가 없다. (기존 http 인터페이스를 이용하면 되겠지만 이 경우 연결을 끊었다 붙였다… 웹소켓 왜 씀?)

웹소켓은 마치 TCP처럼 필요한 콜백 핸들러가 OnOpen, OnClose, OnMessage, OnError 네 가지 뿐이기 때문에 api마다 메소드를 붙이는 기존 웹 개발 방식과도 실질적인 코드 차이가 발생한다.

결론은 웹소켓은 query 사용하지 말고 TCP처럼 패킷을 정의하자.

TDD의 가장 큰 약점으로 꼽히는 것은 바로 GUI 레이어에 대한 테스트가 어렵다는 것이다. GUI는 특성상 유저의 상호 작용을 필요로 하므로 일반적인 테스트 프로젝트처럼 싱글 스레드 기반의 구조적인 프로그래밍으로는 무리가 있다. 그래도 출력을 밀어넣기만 한다면 어찌저찌 되겠지만 출력 내용이 올바른지 검사해야 하거나 입력까지 필요로 한다면 테스트 시스템을 구축하는 비용이 훨씬 커져서 테스트 기반만 마련하다가 프로젝트가 끝날 판이다. (사실 어플리케이션 환경에 따라서는 그러고도 출력 내용을 검사할 수 없는 게 태반이다)

때문에 TDD 방법론에서는 대개 GUI 쪽 테스트 시스템 구축을 포기하거나 휴리스틱한(이라고 쓰고 수동이라고 읽는) 방법을 선택하는데 GUI 테스트가 많이 필요한 환경에서는 분명 솔루션의 부재가 아쉽다. (아예 없지는 않지만 사실 있다고 보기도 좀 프로그램에게 미안하다)

누리에서도 채팅 기능은 생각보다 복잡해서, 출력도 여러 가지를 요구하지만 입력 데이터도 다양하고 채팅의 종류도 다양하다. (마스터 채팅, NPC 채팅, 시스템 채팅, 주사위, 이미지 삽입, 링크, …) 채팅 내용 자체의 출력은 RichTextBox 등을 사용하면 그럭저럭 편하게 할 수 있지만 다음 화면과 같이 나오게 하기 위해서는 윈도우 컨트롤 중 가장 복잡한 ListView 컨트롤 + Owner Drawing의 조합이 필요하다.

커뮤니케이션 도구인 아틀라시안의 힙챗 중 일부

안타깝게도 TDD를 통해서는 저 내용이 제대로 출력되는지 확인하기가 요원하다. 아무리 단위 테스트Unit Test를 거치더라도 그것은 아래의 이미지에서 보듯이 반쪽짜리 테스트 밖에 되지 않는다.

단순하게 도식화된 채팅매니저, 테스트 코드, 실제 GUI 폼 간의 관계

사실 여기서 구조가 제대로 정비되려면 추가 정비가 필요한데 그것이 무엇인지 생각해보는 것도 괜찮을 것 같다.

실제 사용할 경우에는 크게 문제되지 않지만 개발 도중에는 상당히 불편하다. 주요 기능을 개발하기 위해 매번 테스트용 이메일과 비밀번호를 입력하고 들어가는 것은 생각보다 생산성을 훨씬 떨어뜨린다. DB 작업으로 테스트 데이터가 초기화된 다음이라면 테스트 계정을 또 만드는 것이 한 보따리 작업일 수도 있다.

우리는 바보가 아니므로 다음과 같이 질문할 수 있다.

주요 기능부터 만들고 마지막에 로그인(계정) 기능을 만들면 되잖아요.

하지만 누리의 주요 기능에는 다수의 사용자가 상호 작용하는 서버 접속, 대화 등의 기능이 포함되어 있으므로 계정 관련 기능이 먼저 필요하다.

그럼 다른 방법이 있다.

자동으로 이메일과 비밀번호를 테스트용 데이터로 입력해 두면 되죠.

나쁘지 않은 방법이다. 특히 여러 명이 필요 없는 대다수의 초기 기능을 만들 때에는 아마도 가장 빠르게 이런 방법을 사용할 것이다. 하지만 둘 이상의 접속자가 필요한 기능을 테스트할 때에는 여전히 한 개를 제외한 나머지 인스턴스들은 죄다 바꿔줘야 하는 점에 변함이 없다.

좀 더 나아가자.

인스턴스 별로 각기 다른 테스트용 이메일을 사용하게 하는 건 그리 어렵지 않아요.

자, 조금 신중해질 시점이 왔다. TDD가 어플리케이션 개발에 대단한 기여를 했지만 그 역시 여러 약점을 갖고 있었는데 그 중 하나가 바로 테스트 데이터의 오류에 대한 검증이다. 이 부분을 건드리는 순간 분화구 뚫는 용암처럼 온갖 이론과 철학들이 분출된다. 우리의 이야기가 TDD는 아니지만 지금 이 문제에 집중한다면, t1@mail ~ t10@mail 을 인스턴스 별로 할당하고 집어넣은 것이 기능 개발에 어떤 부작용을 발생시킬 지 고민하지 않을 수 없다는 것이다. 단위 테스트를 통해 어느 정도 해결 가능한 면이 있지만 저 정도의 기능 개발은 필연적으로 통합 테스트 단계를 요구한다. 이 단계가 누락되면 나도 모르게 기능 개발에 테스트 데이터가 감안된 사양이 나와버리고, 저 단계를 집어넣으면 기능 개발에 상당한 시간이 소요된다.

그렇다면 다른 주요 기능의 개발과 테스트를 위해 편리함을 더하고자 테스트 데이터를 넣어 문제 가능성을 높이는 찝찝함을 다른 방식으로 혹은 더 영리하게 피할 수 있을까?

개발 중에만 계정 정보 없이 임시로 생성된 정보로 바로 실행할 수 있게 하면요?

이후의 진행을 두 가지로 나누어볼 수 있겠다. 접속 버튼을 눌렀을 때 기계적인 데이터 생성을 통해 계정 정보를 임시로 만들어 넘겨주는 것과, 계정 정보가 없을 때에 대한 예외 처리를 일일이 작성하는 것. 전자의 방식은 사실상 바로 직전에 이야기한 테스트 데이터에 대한 문제를 고스란히 갖고 있으므로 그다지 진보하지는 못했다. 무작위로 여러 데이터를 조합해서 계정 정보를 만들면 오히려 의도하지 않았던 데이터가 사용되어 테스트에 노이즈가 발생한다. 후자의 방식은, 얼핏 보면 초보 프로그래머나 저지를 법한 막무가내식 작업으로 보일 지도 모르지만 서버와 클라이언트 모델을 사용하고 해킹의 위협이 항상 존재하는 프로그램에서는 방어적 기법으로 도배되는 경우가 많이 있다. 물론, 진짜 로직적인 이유로 데이터가 깨졌을 때와 우리가 의도적으로 데이터를 주지 않은 경우를 구분할 수 없으므로 이 방식이 올바르다는 말은 아니다.

약간 복잡한 이야기로 전개해보자.

세 번째 방법에 데이터 추상화를 끼얹어서 테스트 데이터와 실제 데이터를 구분하면 되겠네요

데이터의 종류도 하나의 데이터로 볼 수 있다. 이에 초점을 맞추면 ‘테스트’와 ‘실제’ 라는 속성은 데이터를 구분하는 주요한 데이터 중 하나다. 따라서 이를 데이터 내의 속성으로 추가하든 상속 구조를 차용하든 둘을 분리하여 처리하는데 활용할 수 있다. 그러나 이 구조는 생각보다 개발 비용이 크다. 데이터는 데이터일 뿐, (올바르다고 이야기하는 구조에서는) 보통 기능을 포함하지 않기 때문에 바로 위에서 이야기한 예외 처리 비용처럼 모든 기능이 테스트용일 경우와 아닌 경우에 대해 구현되어야 하는 문제가 발생한다. 여기에 계정 정보가 잘못되었을 때의 처리를 더하면 모든 기능이 최소한 세 가지 경우에 대해 구현되어야 하는데 마스터 계정, 손님 계정, 관전자 계정 따위가 더해지면 문어발도 부족할 지경이다. 이를 도식화하면 아래와 같이 간결하게 나오는데,

Method가 옆으로 무한정 늘어나는 모습이 아름답게(=객체지향스럽게) 보일 수도 있지만 이는 개발 비용을 계속 증가시켜서 투입할 수 있을 때에나 가능한 방법이라고 하겠다. 사양 변경에 맞춰 코드 변경이 전체에 걸쳐 발생하므로 QA가 할 일도 줄어들진 않을 것이다.

그렇다면 저 약점을 극복할 수 있는 방법이 있으니 더더더 복잡한 이야기를 해보자.

궁극의 오의 DDD를 끼얹겠습니다. 코드 변경 없이 동작할 수 있게 하면 되는 거죠?

TDD와 마찬가지로 DDD 또한 개발 방법론에 끼친 영향이 (현재진행형으로) 엄청난데 약점도 거대한 편이다. 우리가 최초 이 이야기를 시작한 이유를 다시 상기해보자. 우린 다른 기능의 개발 및 테스트를 효율적으로 진행하기 위해(=테스트 비용을 줄이기 위해) 과정을 간소화하는 방법에 대해 이야기하고 있다. TDD를 도입하거나 DDD를 도입하거나 (또는 DOP를 계획하거나) 하는 등의 일은 프로그램 설계 단계에서 미래를 결정 짓는 정도의 일이다. 애초에 프로그램이 DDD로 진행되고 있다면 생각해볼 법한 방법이나, 혼자서 만들고 있다면 이 정도 규모로 설계한 것을 재고하길 권한다. 그 시간에 하드코딩하는 것이 훨씬 빠르다.

위와 같은 과정은 단순한 기능 개발 하나에서도 뭔가를 해결하기 위해 고민하면 흔하게 접할 수 있는 문제다. 그런데 결국 해결하지 못하고 고민이 계속 된다. 그 이유가 무엇일까?

네가 너무 완벽한 해결책을 요구해서죠.

완벽한 해결책이라는 단어를 좀 더 풀어서 설명하자면 다음과 같은 속성을 지녔다고 생각한다.

• 미래에 다른 작업이 추가/수정/삭제 되더라도 영향을 주거나 받지 않는 (시간 조건)
  • 미래에 추후 작업이 발생하지 않는(=유통기한이 영구적인)
• 부분 해결이 아닌, 모든 상황에 대한 해결이 가능한 (상황 조건)
  • 자동 작업 외 수동 조작이 추가로 필요하지 않는
• 비개발적인 상황 조건을 고려하지 않고 모두 적용할 수 있는 (자원 조건)
  • 1인 개발일 때와, 5인 이하 소규모일 때와, 50인 이상 대규모일 때 모두 사용 가능한
  • 개발 시간이 없을 때나 넉넉할 때나 모두 사용 가능한

자, 이 포스팅의 주제에 대해 이야기할 시간이 왔다. 우리가 비록 개발자지만 이러한 문제 해결에 대해서, 혹은 설계에 대해서는 0과 1의 딱 떨어지는 결과가 아니라 굉장히(굉장히 굉장히) Fuzzy한 선택과 집중을 할 수 있는 자세가 필요하다는 것이다. 그 중 선두주자는 유통기한이다. 재작업을 좋아하는 개발자가 별로 없을 거라고 생각하지만, 중요한 것은 그 재작업의 빈도인 것 같다. 보통 두 번째와 세 번째 이유는 당연히 고려하면서도 자신의 코드가 언제까지 유지되는가에 대한 부분은 최소한 자신이 해당 프로젝트를 마감할 때까지는 변경이 없을 거라고 (또는 변경이 없게 만들 거라고) 생각을 많이 하는 듯 싶다. 그리고 그 부분이 고민을 끝나지 않게 만든다.

하지만 위의 사례에서, 일단 두 번째 방법을 택한 다음 1시간 정도를 투자해서 앞으로 4개월 정도 버틸 수 있다면 채산성이 훌륭하다고 본다. 그렇게 기본 기능을 만들고, 더 복잡한 테스트 데이터를 요구하는 시점에 좀 더 작업해서 또 y개월을 버틸 구조를 넣고 하는 식이다. 처음부터 미래를 예측하여 많은 고민을 하는 것은 그렇게 좋지 않다고 이야기하지만, 바로 그것을 버리지 못하는 경우를 많이 보아와서 마침 간단한(?) 사례가 있기에 정리해 보았다.

뭐랄까, 간만에 개발 일지다운 글이 된 것 같다. (정작 개발은 안 하고?)

서버 작업이 커져서 눈에 보이는 게 없을 뿐 작업을 하고는 있다. ご,.ご

물론 회사 서버 작업이 우선이므로 코드가 역수입되고는 있지만 잠시 정신차려보니 한달 가량 커밋을 방기했더라…는…

이런 프레임워크 마련은 빨리 눈에 보이는 것들 만들어서 활용하는 것에 관심이 많은 나 같은 작업자들에게는 고역의 과정이다.

항상 그렇지만 이얍 툭탁 하면 생각대로 만들어지는 프로그램이 있었으면 좋겠다….

개발 쪽에 올라오는 페이지들이 누리를 개발하면서 마주치는 이슈 중 분명 까먹을 것 같은 내용들을 정리한 것이다.

아니, 사실은 훨씬 많은데 귀찮아서….

서버 작업으로 프로젝트를 재개할 필요가 있어서 요 며칠 좀 매달렸는데, 이제 감을 슬슬 찾았으니 클라이언트 작업을 시작해도 좋을 듯 하다.

그럼 일지 제목도 나오고 하려나….

날짜는 어차피 게시일이 나오니 필요 없고… 제목에 대한 고민이 필요하구나.

작업을 다시 시작해서 일지라도 올려야지 라고 마음 먹은 것이 무색하게도 하필 서버 작업 차례인지라 보여줄 수 있는 것이 없다…!

오늘은 새 계정 생성 기능을 넣었고 아직 본 작업은 시작도 못 한 채 곁가지 작업들을 하고 있다.

윈도우 서버 위에 웹소켓, MSSQL을 이용하고 있다. 웹소켓의 경우는 윈도우즈7 버전까지는 클라이언트 API 들이 지원되지 않아 7월 29일에 윈도우즈10 이 나오길 고대했던 기억이 있다. (윈도우즈8은 건너뛰었으니까…) 날짜까지 기억할 정도로.

웹소켓이나 async 등의 기능을 보고 있자면 요즘 개발은 정말 편해졌구나 하는 생각이 새삼 든다.

-_-

시작한 지 좀 됐지만 바빠서 차일피일 계속 미뤄지는 터라 작업일지라도 남기면서 반성을 좀 해야하지 않을까 싶다.

말 나온 김에 확인해보니 7월 10일에 시작했는데 9월 말까지 작업하다가 2개월 동안 손도 못 댔다….

누리는 ORPG(Online TRPG) 전용 프로그램이며 주변 몇몇만 알고 있지만 누리1이 2003년도에 나왔다는…!

(요즘엔 빌드도 안 될 것 같다)

기본적으로 누리3의 기능을 대부분 계승하고 있으며 누리1 시절부터 추구해왔던 실시간 지도 기능과 주사위 파워 기능을 이번에도 이어가고자 한다.

그에 더해 누리4에서 핵심적으로 기획 중인 기능은 다음과 같다. (누리4에서 추가되는 기능은 굵은 글씨!)

1. 실시간 지도 작성 / 공유 / 전송 기능
1. GM 및 유저별 전용 레이어 제공
2. 미리 작성한 지도 저장 / 전송 기능
3. 외부 텍스처 및 이미지 활용 기능
4. GM이 조작할 수 있는 지도 안개 기능
2. 대화 및 주사위 기능
1. 다양한 글자 속성 설정 기능 (글꼴, 색상, 모양, 효과, …)
2. 대화 종류 지정 기능 (잡담, 캐릭터 대화, GM의 말, NPC 대사, …)
3. 리플레이 저장, 자동 저장 및 복구 등
4. 대화 활동 그래프 (분석용)
5. 주사위 단축키 / 매크로 설정 기능 강화
3. 네트워크 기능
1. 로비
2. 플레이 방 개설 기능
3. 관전
4. 모바일 연동 기능

위의 기능이 전부가 아니라 “이 정도면 확 좋아졌네” 싶은 것들만 일부 정리해서 나열해두었다.

문제는 언제 완성될라나.