객체지향프로그래밍

project/presentation/OODP_제안서.pptx에 팀 구성이 명시되어 있다. 이영수(팀장, 디자이너 겸 개발자), 박현규(매니저), 배지운(개발자), 이상헌(디자이너). 커밋 로그와도 일치한다 — 코드 기여자는 두 명뿐이고(MaybeS 90커밋, prevdev 23커밋), imf/network/* 8개 파일은 전부 이영수가 쓴 것이다. 아래 IMF 절의 지적은 imf/network를 제외한 나머지에만 적용했다.

제안서는 "6가지 Stage 게임"을 약속했다. 최종 트리의 맵 데이터는 data/map/stage1.xml과 data/map/new.xml 두 개뿐이다. 6스테이지는 구현되지 않았다.

L4G2EP2/ 아래에 old/, now/, final/ 세 벌이 거의 같은 프로젝트다. 같은 Classroom.java가 1,497줄 / 2,245줄 / 2,225줄로 세 번 존재한다. 브랜치나 태그를 쓰면 될 일을 폴더 복사로 해결했고, 그 결과 저장소의 .java 개수가 세 배로 부풀었다. project/IMF/data/default/default - 복사본.xml도 같은 습관이다.

루프를 돌며 ret[i]를 채운 뒤 ret이 아니라 ary를 반환한다. 호출자는 value가 더해진 배열을 받았다고 믿지만 원본을 받는다. 바로 아래 AddOne(57–63행)은 같은 구조인데 ret을 제대로 반환하므로, 복사-붙여넣기 후 반환문만 고치지 않은 것이다. 다행히 main은 AddOne만 호출해서 증상이 드러나지 않는다 — 즉 이 메서드는 한 번도 실행되지 않았다.

한글 수사 배열 kor은 원소가 11개(인덱스 0–10)인데, first = currentNumber / 10은 세 자리 수에서 10을 넘는다. 100이면 first == 10이라 kor[10]("십")을 두 번 찍어 "십십"이 되고, 110이면 first == 11로 배열 밖을 읽는다. 입력에 상한이 없으므로(GetLastNumber는 사용자 입력을 그대로 받는다) 두 자리 이상을 입력하면 게임이 종료된다.

동일 로직을 Python으로 옮겨 확인했다: Say(99) → "구십구", Say(100) → "십십", Say(110) → IndexError(11).

Assignment1_1.java:13–17의 GetAge()는 호출될 때마다 System.in에 새 Scanner를 열고 닫지 않는다. main에서 세 번 호출되므로 세 개가 열린 채 남는다. 같은 주차의 Assignment1_2.java:17은 in.close()를 호출하므로 몰라서가 아니라 빠뜨린 것이다.

중심은 (canvas_width-10)/2 = 295로 잡아 놓고 반지름은 canvas_height / 2 = 300을 쓴다. 그런데 표본은 Update()에서 rand.nextInt(canvas_width - 10), 즉 [0, 590)에서 뽑는다. 한 변 590인 정사각형 안에 반지름 300짜리 원을 넣으면 원이 사각형 밖으로 삐져나가므로, "원 안" 판정이 과대 계수된다. 반지름을 중심과 맞춘 295로 두어야 내접원이 된다.

동일한 표본 규칙을 Python으로 200만 회 재현해 확인했다: 현재 코드(반지름 300) → 3.2304, 반지름 295 → 3.1393. 2.8% 과대 추정이고, 이는 표본을 늘려도 수렴하지 않는 계통 오차다.

덧붙여 40행 double dist = isDistance(x,y);는 한 번도 읽히지 않고, 바로 다음 줄이 같은 함수를 다시 호출한다. 71행에서는 isIn(nX, nY)가 세 번째로 호출된다(65행에서 이미 in에 담아 두었다).

Update()는 호출될 때마다 Dot을 하나 생성해 layer.children에 넣고, 제거하는 코드는 없다. 그리고 Assignment6.java:17이 settings.gameLoop_interval_ns = 1000, 즉 1마이크로초 주기를 요구한다. 프레임 루프가 실제로 이 속도를 못 내더라도 children은 단조 증가하므로 장시간 실행 시 힙이 고갈되고, layer.Draw(g)가 매 프레임 전체 리스트를 순회하므로 프레임마다 느려진다. 표본 수를 늘릴수록 정확해져야 하는 몬테카를로 과제인데 표본을 늘릴수록 멈춘다.

isStopRequested는 메인 스레드가 Stop()에서 쓰고 워커 스레드가 루프 조건에서 읽는다. pi는 반대 방향이다. 둘 다 volatile도 아니고 동기화 블록도 없다. JIT는 루프 안에서 값이 바뀌지 않는다고 판단해 isStopRequested 읽기를 루프 밖으로 끌어낼 수 있고, 그러면 Stop()을 불러도 워커가 영원히 돈다. Print()가 읽는 pi도 최신 값이라는 보장이 없다. 실습 문서가 "내 주인에 의해 Stop()이 호출되었는지"라고 주석까지 달아 준 변수인데 가시성 문제는 다루지 않았다.

표본 추출 자체는 문제가 없다. 같은 규칙을 재현하면 3.1373이 나와 π에 근접한다 — Window 쪽과 달리 여기서는 중심과 반지름이 맞아 있다.

보고서는 "감염상태에서는 … 만약 해당 위치에 시체가 나타날 확률이 높다면 적은 쪽으로 이동합니다"라고 쓰여 있다. 코드는 그 판단을 하지 않는다.

Infected_Move()는 getDirectionNotExp(expect[CORP], 0, false)를 호출한다. 인자 두 개가 문제다. mapPrefer == false이므로 getNearExpects 256행의 "그 칸 자신의 값" 대입이 건너뛰어져 exp[k]가 0으로 남고, expRev == 0이므로 이어지는 이웃 합산이 전부 × 0이 된다. 결과적으로 유효한 네 방향의 점수가 모두 정확히 0.0이다. getDirection(false, …)은 최솟값을 찾는데, 동점일 때 갱신 조건이 엄격한 <라서 첫 번째 유효 인덱스에서 멈춘다. DirectionCode의 선언 순서가 {Left, Right, Up, Down, Stay}이므로 반환값은 언제나 Left다(왼쪽 벽에 붙어 있을 때만 Right).

즉 감염자 상태의 전체 전략 — 시체 기댓값 맵을 계산하고, 확산시키고, 낮은 쪽을 고르는 — 이 한 개의 리터럴 0 때문에 상수 함수로 무너져 있다. 같은 줄의 조건문도 틀렸다: expect는 [HEIGHT][WIDTH] 배열인데 [nowX][nowY]로 행·열을 뒤집어 읽는다. 맵이 13×13 정사각이라 예외는 나지 않지만 항상 다른 칸의 값을 본다.

같은 메서드 안의 다른 모든 이웃 접근(185행, 260행, 345행)은 isValidPoint로 감싸는데, ForEach_Players 람다 안의 이 한 줄만 검사가 없다. kk == 0일 때 dx[0] == -1이므로 py == 0인 플레이어(맨 윗줄)에 대해 expect[CORP][-1][…]을 쓰려 한다. kk == 2일 때는 dy[2] == -1이라 px == 0인 경우 열 인덱스가 −1이 된다.

조건은 "냉각 시간이 0인 감염자"이고 맵은 13×13에 96명이 들어차 있다. 가장자리 48칸 중 하나에 그런 감염자가 서 있으면 ArrayIndexOutOfBoundsException이 initialize() → 네 개의 오버라이드 전부로 전파된다. 게임 중 거의 확실히 발생하는 조건이다.

Soul_Spawn() 안의 확산 루프에서 행 인덱스 y의 상한이 HEIGHT가 아니라 WIDTH다. 바로 위 411행과 아래 426행은 HEIGHT를 쓰므로 복사-붙여넣기 오류다. 13×13이라 지금은 같은 값이라 드러나지 않지만, Constants.Classroom_Height와 Classroom_Width는 별개의 설정값이고 비정사각 맵에서는 행이 잘리거나 인덱스가 넘친다. 420행의 isValidPoint(y + dy[k], x + dx[k])도 인자 순서가 뒤집혀 있다 — 이 함수의 시그니처는 (Column, Raw)이고, 345행에서는 isValidPoint(x+dx[k], y+dy[k])로 올바르게 호출한다. 같은 파일 안에서 같은 함수를 두 가지 순서로 부른다.

EXPSCORE는 원소 6개짜리 점수 임계값 배열인데 실제로 읽히는 인덱스는 SMAX(0)와 STOT(1)뿐이다. CMAX, CTOT, IMAX, ITOT는 정의만 되고 한 번도 쓰이지 않는다. 게다가 ITOT가 5가 아니라 4라서 IMAX와 같은 칸을 가리킨다 — 쓰였다면 650 대신 25를 읽었을 것이다. 같은 맥락으로 expect는 new double[5]인데 상수 REVS = 5가 있고(배열 첨자로 쓰였다면 예외), 할당된 expect[COST]는 한 번도 쓰이지 않는다.

imf/Window.java의 Update()는 250–277행 전체가 주석이고 본문은 return true; 한 줄이다. Initialize()도 160–242행이 주석이라 processor.install("interaction", …) 이하 다섯 개의 처리기가 하나도 설치되지 않는다. 필드로 선언된 interaction / keyboard / physics / mouse / scene(56–61행)은 전부 null인 채 남고, onReceived()는 본문 전체가 주석인 빈 메서드다. 결과적으로 imf.processor 816줄, imf.object 537줄, 팀원의 imf.network 747줄이 HEAD에서 모두 도달 불가 코드다. 실행하면 default.xml을 파싱해 스프라이트를 뷰포트에 붙이고 그리는 것으로 끝난다 — 입력도, 물리도, 네트워크도 없다.

공정하게 덧붙이면, 학기 제출본은 정상이었다. git show 5d8f226:project/IMF/src/Window.java(2016-06-26, "Update End of Project")에는 inputs.AcceptInputs()와 processor.loop()를 호출하는 391줄짜리 살아 있는 Window가 있다. 깨진 것은 7월 1일 7da901f "new Start"로 시작해 da4cfe1(7월 9일)에서 주석 처리가 확정된 개인 재작성 때문이다. 문제는 그 재작성이 완료되지 않은 채 기본 브랜치에 그대로 남았다는 것이다 — 이 레포를 여는 사람이 보는 것은 제출본이 아니라 이 상태다.

ProcessManager.loop()는 모든 처리기의 매 프레임 호출을 통째로 try로 묶고 빈 catch로 받는다. HashMap.forEach는 예외가 나면 순회를 중단하므로, 어느 한 처리기에서 NullPointerException 하나가 나면 그 뒤 처리기들은 그 프레임에서 조용히 건너뛰어진다. 로그도, 카운터도, 플래그도 없다. 물리가 멈췄는지 입력이 안 먹는지 구분할 방법이 프로세스 안에 존재하지 않는다.

같은 패턴이 Physics.doCollision()(148–150행, catch { return; })과 SpriteObject.invisible()(70–72행)에도 있다. 후자는 trigger_object가 null일 때의 NPE를 삼키려고 존재하는 catch다 — 즉 null 검사를 예외 처리로 대신하고 있다. 저자 코드 전체에서 빈 catch가 9곳, 로그만 찍고 넘기는 catch가 5곳이다.

덧붙여 forEach는 HashMap의 순회 순서를 따르므로 처리기 실행 순서가 명세되지 않는다. 키보드 → 물리 → 상호작용 → 씬 순서가 프레임마다 보장되어야 하는 게임 루프에서 이는 실질적 위험이다. LinkedHashMap 한 글자 차이로 해결되는 문제다.

IProcess 인터페이스가 void finalize()를 선언하고 다섯 개 처리기가 이를 구현한다. 그런데 finalize()는 java.lang.Object의 메서드이고, JVM이 객체를 회수하기 직전에 임의의 시점에 부르는 종료자다. 이름을 이렇게 잡으면 두 가지가 생긴다. (1) 이 클래스들이 전부 finalizable로 등록되어 GC가 별도 큐를 거치게 된다. (2) ProcessManager가 GC 대상이 되면 JVM이 ProcessManager.finalize()를 호출하고, 그 안에서 processors.forEach(… processor.finalize())가 돌아 아직 살아 있을 수 있는 하위 처리기들의 참조를 null로 만든다. 의도한 명시적 정리와 GC의 암묵적 호출이 구분되지 않는다. destroy(), dispose(), shutdown() 중 아무 이름이나 골랐으면 없었을 문제다.

Physics.java:24와 Interaction.java:20이 각각 필드 초기화로 new Timer()를 만든다. java.util.Timer는 기본적으로 비데몬 스레드를 띄우므로, 취소하지 않으면 메인 창을 닫아도 JVM이 살아 있는다. 두 클래스의 finalize()는 참조만 null로 밀 뿐 timer.cancel()을 부르지 않는다. 주석 처리된 Window.Destroy()가 스테이지 전환마다 new ProcessManager를 만들도록 되어 있었으므로, 스테이지를 넘길 때마다 좀비 타이머 스레드가 두 개씩 누적되는 구조였다.

거기에 Physics.java:82는 가시 장애물과 겹쳐 있는 동안 매 프레임 timer.schedule(new DeadTask(), 5000)을 호출한다. 75 fps 설정이므로 가시에 1초 닿아 있으면 사망 콜백이 약 75개 예약된다. 중복 예약을 막는 플래그가 없다.

그리고 그 DeadTask.run()은 Timer 스레드에서 manager.property.setter("dead")를 호출해 게임 상태를 바꾼다. 같은 상태를 게임 루프 스레드가 매 프레임 읽고 AWT가 그린다. 동기화는 없다.

조건식은 왼쪽부터 평가되므로 o가 null이면 target.zPosition(o)나 o.collision에서 이미 NPE가 난다. o == null은 절대 true로 평가되지 않는 죽은 조건이다. 그리고 그 NPE는 위 doCollision의 빈 catch(148행)가 삼킨다 — 방어 코드를 넣었다고 믿게 만드는 코드가 실은 아무것도 막지 않는 구조다.

같은 메서드 위쪽 57–61행에는 public static boolean collision(SpriteObject, SpriteObject) { return true; }가 있다. 이름이 collision인데 인자를 보지 않고 true만 돌려준다. 호출하는 곳은 없다. 140행 boolean exc = false;도 마찬가지로 이후 한 번도 대입되지 않아 153행 if (!exc)가 항상 참이다 — catch에서 exc = true로 표시하려던 흔적만 남고 실제로는 return으로 빠져나간다.

a_y가 0이면 0 / Math.abs(0)은 부동소수점에서 예외가 아니라 NaN이다. v_y = NaN이 되고, 이후 doMove()가 pos_y + v_y를 계산하면 위치도 NaN이 되어 영구히 복구되지 않는다(NaN은 어떤 비교에도 false를 돌려주므로 충돌 보정 분기가 전부 통과된다). PhysicalObject의 a_y 기본값은 0이고(PhysicalObject.java:17), 중력은 Window가 me.a_y = -0.98로 따로 넣어 준다 — 즉 그 대입이 빠진 오브젝트에서 점프하면 즉시 발생한다. 부호를 뽑으려면 Math.signum을 쓰거나 a_y == 0을 먼저 걸러야 한다.

Interaction.setter()의 switch (object.first)는 "hover"/"leave" → "act" → "act_emotion" → "act_emotion_partner" → "dead"/"act_partner"/"act_child"까지 break 없이 흘러내리고, 각 case 안에서 다시 object.first.equals("act") 같은 검사로 실행 여부를 판단한다. 즉 switch가 분기 역할을 하지 않고 진입점 선택 역할만 하며, 실제 분기는 중복된 문자열 비교가 한다. 가운데에 case를 하나 추가하면 위쪽 모든 케이스의 동작이 조용히 바뀐다.

Pair.java:17–19에도 같은 계열의 부주의가 있다: equalsSecond가 compare.second.equals(first)로 두 번째 값을 첫 번째 값과 비교한다. 호출하는 곳이 없어 증상은 없지만, Object.equals(Object)를 오버라이드하지 않고 equals(Pair)로 오버로드했기 때문에 Pair를 HashMap이나 List.contains에 넣으면 동일성 비교로 떨어진다. hashCode()도 없다.

clear()가 queue.clear()를 호출한 다음 줄에서 queue를 생성한다. 그리고 이 clear()는 19–21행의 static 초기화 블록에서 불린다 — 그 시점에 queue는 null이다. 따라서 TimerEvent 클래스가 처음 참조되는 순간 <clinit>에서 NPE가 나고 ExceptionInInitializerError로 번진다. 조건부 버그가 아니라 100% 재현되는 결정적 실패다.

ScriptObject.run() 126행이 event == ALWAYS인 스크립트마다 TimerEvent.put(this)를 부르므로, 명세서가 정의한 always 이벤트는 한 번도 동작한 적이 없다. 이 코드가 단 한 번이라도 실행됐다면 즉시 드러났을 버그라는 점이 중요하다 — nimf 전체가 컴파일만 되고 실행 검증 없이 커밋되었다는 뜻이다.

같은 클래스 32행의 while ((now = queue.peek()).first <= counter)도 큐가 비면 peek()가 null을 돌려주므로 NPE다. 그리고 54행 timer.schedule(task, 1)은 scheduleAtFixedRate가 아니라 1회성 예약이라 이 태스크는 평생 한 번만 실행된다.

rvalue.indexOf("." + 1)에서 "."과 int 1을 +로 묶으면 Java는 문자열 결합을 한다 — 즉 indexOf(".1")이다. 의도는 rvalue.indexOf(".") + 1이었고, 같은 파일 150행은 l.substring(l.indexOf(".")+1)로 올바르게 쓰여 있다. 괄호 하나가 어긋난 결과, 값에 ".1"이라는 부분 문자열이 없으면 indexOf가 -1을 돌려주고 substring(-1)이 StringIndexOutOfBoundsException을 던진다.

119행 가드가 rvalue에 마침표가 있으면 이 분기에 들어가게 되어 있는데, 명세서 78–81행이 예로 든 button.texture="btn_hover.png";의 우변 "btn_hover.png"가 정확히 그 조건이다. 문서가 안내하는 대로 XML을 쓰면 엔진이 죽는다. 설령 예외를 피해도 SpriteManager.get("\"btn_hover")가 null을 돌려줘 NPE가 된다.

명세서 62행은 attribute를 "타겟의 속성 상태를 지정합니다. 비워두면 언제나 참입니다. 예) attribute="visible=true""라고 정의한다. 구현은 이렇다: parse(attribute, attr_name, attr_value)를 호출하고, 그 안에서 파라미터 attr_name과 attr_value에 대입한다. Java는 참조 값을 복사해 넘기므로 이 대입은 지역 변수만 바꾸고 사라진다. 게다가 이 메서드는 static이라 인스턴스 필드 this.attr_name에 쓸 방법 자체가 없다. 즉 ScriptObject.attr_name과 attr_value는 영원히 빈 문자열이고, 스크립트 조건 실행은 구현되지 않은 것과 같다.

이것은 실수가 아니라 언어 모델의 오해다. C에서 char **out을 넘기던 습관이 그대로 옮겨 왔다. 학부 2학년 OOP 과목에서 잡혀야 할 가장 기본적인 개념 중 하나다.

명세서 51–61행은 object@enter/leave/join/interact와 mouse@enter/leave/join/interact를 서로 다른 8개 이벤트로 정의한다. 열거자는 이 8개에 TIMER까지 합쳐 2,3,4,5 네 개의 값만 나눠 쓴다 — TIMER, oENTER, mENTER가 모두 2다. 그리고 103행이 ScriptManager.s_[event.get()]로 그 값을 배열 첨자로 쓴다. 결과적으로 마우스가 객체에 올라간 사건과 캐릭터가 객체에 닿은 사건이 같은 버킷에 들어가 구별되지 않는다. 버킷은 11개 할당되는데 6개만 쓰인다.

같은 파일 21–23행의 public enum Attribute { }는 본문이 비어 있다. 선언만 있고 상수가 하나도 없으며 참조하는 곳도 없다.

리소스 경로가 실제 파일인지 확인하려고 ValidateException을 던지는데, 같은 메서드의 catch가 빈 블록으로 잡고, finally도 비어 있고, 마지막 줄은 조건 없는 return true;다. 존재하지 않는 텍스처 경로도 전부 통과한다. 호출부인 put() 28행의 if(validate(path))는 항상 참이므로 if 자체가 의미가 없다.

이어지는 44–46행 get(name)은 찾지 못하면 null.second로 NPE를 낸다. imf/Window.java:145가 ResourceManager.get("texture").forEach(...)로 무방비 호출하므로, 텍스처가 하나도 없는 맵을 열면 시작하자마자 죽는다.

line.split("=")의 결과에서 s[1]을 검사 없이 읽는다. 빈 줄, 주석 줄, = 없는 줄이 하나라도 있으면 ArrayIndexOutOfBoundsException이 나는데, catch는 FileNotFoundException과 IOException만 잡으므로 이 예외는 밖으로 나가 Window 생성자를 터뜨린다. 39행의 (String)path.get(...)도 참조된 키가 없으면 null 캐스팅 후 replace(…, null)로 NPE다.

그리고 br.close()가 try 블록 안 마지막 줄에 있어서, 위 어느 예외든 발생하면 BufferedReader가 닫히지 않는다. Java 7의 try-with-resources를 쓰면 한 줄로 끝나는 문제고, 이 프로젝트는 이미 람다(Java 8)를 쓰고 있으므로 언어 버전 제약도 아니다.

부수적으로 Window.java:67은 "data/IMF.inf"를 읽는데 실제 파일은 data/imf.inf다. macOS 기본 파일시스템(대소문자 구분 없음)에서는 열리지만 Linux에서는 FileNotFoundException → printStackTrace → 기본 경로만 남은 채 조용히 진행된다.

set("w", "32")는 radius_x = 32로 저장하는데 get("w")는 radius_x * 2 = 64를 돌려준다. 왕복이 항등이 아니다. 이름이 w(width)인 이상 어느 한쪽이 틀렸고, 부모 DrawableObject3D가 반지름 기준인 것을 보면 set이 /2를 빼먹은 쪽이다 — 명세서대로 w="32"라 쓴 스프라이트가 화면에서 64픽셀 폭으로 그려진다. h도 같다.

같은 클래스 51–55행에는 더 근본적인 문제가 있다. Attribute.forEach((s)->set(s, data.get(s)))가 16개 속성을 전부 시도하는데, XML에 없는 속성은 data.get(s)가 null이고 set은 그것을 Integer.valueOf(null)에 넘긴다. 속성 하나만 생략해도 NumberFormatException이다. 명세서 어디에도 16개 전부가 필수라는 말은 없다.