One Stable Build

이 스크린샷은 조작된 것이 아니에요. 이거 찍으려고 안 돌아가는 테스트 케이스 다 주석처리 해버린 것도 아니에요. 어디 허드슨이 그렇게 허술한가요. 저기 보면 200개에 가까운 테스트 케이스가 돌아가고 있는게 다 나오잖아요. 어디 허드슨이 운빨로 빌드가 성공하는 툴인가요. 테스트 케이스 하나 얻어 걸려서 성공해본 적이 없네요. 200개에 달하는 테스트 케이스 하나하나를 다 만들거나 고치거나 해서 빌드를 돌리고 끝까지 성공 못하는 테스트 케이스 하나 하나를 다 성공시킨 결과라구요.

9월 8일 서울의 도심에 있는 모 프로젝트 사무실에서 있었던 일이에요. 아침에 출근 하려고 일어났는데 몸이 뭔가 정상이 아닌거 같더라구요. 원래 아침엔 다 그런거 아닌가 싶어서 씻고 출근하려고 하는데, 양치질 하고 있으려니까 속이 갑자기 엄청나게 거북해지는거에요. 어차피 아침밥은 잘 안 먹으니까 그냥 무시하고 출근을 했어요.

출근해서 일을 하려고 하는데, 뭔가 좀 정신이 없었어요. 뭔가 서양의학적으로는 설명 안되고 동양의학적으로 설명해야 될 것 같은 그런 증상이라고 할까요. 몸에 기가 다 빠진 듯한 느낌? 생화학 무기중에는 맞으면 온 몸이 무기력해진다는 그런 무기도 있다고 배웠는데, 그걸 좀 마셔버린거 아닌가 싶은 그런 느낌이요. 후배들이 어디 아픈거 아니냐고 물어봤을 때 아 심각하구나라는 생각이 처음으로 들었어요. 저 원래 아픈거 잘 안 드러내는 스타일이거든요. 친구가 병원에 빨리 가보라고 해서 망설임 없이 병원으로 바로 갔을 정도로 꽤 심했어요. 전 중학교 졸업한 이후로는 안과를 제외하고는 병원에 한 번도 아파서 간 적이 없었거든요. 그 자랑스러운 기록을 깨버릴 정도니까 꽤 심했지요.

병원에 갔다가 큰 소득 없이 돌아왔어요. 스트레스 좀 덜 받고 살면 괜찮아질 거라고 하더라구요. 둥글둥글 미끈미끈한 알약만 몇 개 받아왔네요. 다시 돌아와서 아무 일도 없었다는 듯이 일을 하려고 했는데 뭔가 조금 나아진 것 같지만 여전히 속이 안 좋았어요. 점심 먹을 자신도 없어서 점심도 거르고 오후에 조퇴를 할까 말까 고민하다가 그래도 집에 갈 정도는 아니겠다 싶어서 다시 일을 했어요.

유닛테스트 코드를 만들고 있었어요. 제가 맡은 부분은 대략적으로 200개 정도의 테스트가 이루어졌어요. 하나씩 돌리기에는 엄두가 나지 않아서 CI서버의 도움을 빌리기로 했지요. 그런데 제 컴퓨터에서는 잘 돌아가던 테스트들이 CI서버에 올라가니까 별별 이유로 자기 실패했다고 주장하는거에요. '이거 안되는데?'라고 하면 조건반사적으로 튀어나오는 '제 컴퓨터에서는 잘 되는데요?'가 정말 억울할 정도로 정확하게 재연되는거에요. CI서버에서 자꾸 실패하는 테스트들이 한 20개씩 나와서 하나하나 다 제 컴퓨터에서 돌려봤는데 이건 또 의심할 여지 없이 단박에 성공해버렸거든요. 이미 성공한 테스트를 더 성공하게 할 수도 없고 제가 손 댈 부분이 별로 없었어요.

사실 물론 모든 일에는 이유가 있고, 소프트웨어 개발은 더더욱 그렇죠. 실패한 테스트 케이스들을 눌러보면 다들 하나씩의 이유는 있었어요. 가장 많이 나타난 이유는 역시나 파일 경로의 문제였어요. 간단히는 상대경로가 서버에서는 잘 안 잡히는 문제에서 부터, 심각하게는 리소스 폴더를 제대로 못 가져오는 문제까지 다양했지요. 사실 3년 전에 만들어진 테스트 케이스들은 CI서버에서 돌아갈 것을 전혀 상정하지 않고 만들어져있었고, 심지어 디렉토리 변경이 제대로 되나 테스트하기 위해서 cd c:\windows 를 해보고 되면 성공..이라고 가정했던 테스트 케이스도 있었어요. CI서버가 유닉스 환경이라면 바로 실패할 케이스 였지요. 그런 것들을 하나둘 씩 정리하고 나니 성공률이 조금 올라가기는 했어요. 하지만 쉬운 오류들을 잡고 나니 정말 어려운 애들이 10개 정도 남아버렸지요.

저녁 6시가 되었어요. 퇴근 시간이 되었지요. 문득 원래 오늘은 공연 가려고 오후 반차를 썼던 날이었다는게 기억 났어요. 애초에 못 갈것 같았던 공연이었지만, 몸 상태가 이래서는 일이 없었어도 못 가는 건 마찬가지였다고 생각하니 마음이 좀 편했어요. 제가 공연을 좀 가봐서 아는데, 스탠딩 구역은 어지간한 체력이 없으면 버티기 힘든 곳이거든요. 지금 상태로는 메탈 공연은 커녕 클래식 공연을 보라고 해도 자신이 없었어요. 대신 이 빌드만 빨리 성공 시키고 집에 가서 좀 쉬어야 겠다고 생각했어요.

있는 파일도 없다고 테스트를 실패하고, 고친 부분들이 자꾸 에러를 내서 아무래도 CI서버의 워크스페이스를 한 번 싹 지우고 처음부터 다시 받아서 정리를 해야겠다고 생각했어요. 워크스페이스도 잘 안 지워져서 후배한테 서버에 원격접속해서 좀 억지로 지워달라고 부탁을 했지요. 그리고 다시 빌드를 돌렸어요. 소스코드들을 다시 처음부터 새롭게 받아서 빌드가 돌아가기 시작했지요. 받는 시간이 좀 걸려서 그런지 꽤 오래 걸리더라구요.

그리고 순식간에 10개의 실패가 더 늘어버렸어요. 갑자기 속이 더 아파지는 기분이었어요. 뭐랄까. 반에서 말썽 부리는 애들 그룹때문에 신경이 많이 쓰였는데 느닷없이 얌전하던 애들이 집단으로 사고를 쳤다는 소식을 들은 담임선생님의 기분이랄까요.

사실 원래 착하던 애들은 조금만 타일러도 마음을 잡을 수 있으니까요. 새롭게 무더기로 등장한 실패들도 그리 어렵지 않게 잡을 수 있었어요. 새로 등장한 애들의 로그를 자세히 뒤져보니 제가 미처 생각하지 못했던 부분들이 있었더라구요. 이것들을 고치면서 얻어걸린 애들도 있었어요. 10개 늘었다가 14개가 한 번에 줄어들어서 남은 실패는 겨우 6개. 갑자기 희망이 생겼어요.

그런데 끝까지 남은 실패들은 정말 악성 실패들이었어요. 도대체 어디가 잘못 되었는지 감도 오지 않았어요. 로그를 살펴보니 파일이 없어서 실패했다고 그러는데, 제 컴퓨터에도, 서버에도 파일은 분명히 있었거든요. 혹시 없나 해서 서버 컴퓨터에 직접 가서 직접 찾아봤는데도 있었구요. 3분만에 14개를 줄였는데 30분이 지나도 한 개를 줄이지 못해서 점점 초조해지고 있었어요. 속도 여전히 안 좋았구요.

8시가 넘어가니까 피곤하기도 하고 밥도 못 먹어서 힘이 빠지기도 하고 아픈 건 더 심해지는 것 같고 그래서 거의 그냥 누워있었어요. 한 30분 누워있다가 어렴풋이 일어나서 그냥 빌드를 다시 눌러봤어요. 혹시나 내가 누워있는 동안 뭔가 상황이 갑자기 바뀌어서 성공하지는 않았을까. 하지만 내가 아무것도 하지 않으면 상황은 아무것도 바뀌지 않아요. 2분 남짓한 빌드시간동안 속으로 계속 안될꺼야..라고 중얼거리다가 정말 안된 결과가 나오고 나니까 그냥 다시 엎드려 버렸어요. 의사가 스트레스 좀 덜 받으라고 했는데 그러려면 직업을 바꿔야 될 것 같다는 생각을 했어요.

9시가 넘어가서 부스스 일어나고 나니까 그냥 퇴근하고 내일 할까..라는 마음이 강해지기 시작했어요. 집에 가서 한 10시부터 내일 아침까지 자버리면 뭔가 상황이 다 나아지지 않을까 라는 생각이 들기 시작했어요. 그런데 정말 조금 남았는데 남겨두고 집에 가는 것도 기분이 좋지는 않을 것 같아서 조금만 기운내서 더 해볼까 마음먹었어요. 매일같이 막차시간까지 남아있던 적도 있었는데 아직 겨우 9시 인걸요.

원인은 대충 알고 있었어요. 개발DB에 접속이 잘 안되서 발생하던 오류가 있었고, 타이밍과 관련된 오류가 좀 있었어요. 타이밍과 관련된 오류가 가장 까다로웠어요. 스케쥴러의 동작을 테스트 하기 위해서 일정한 시간을 지연시키는 코드가 있었거든요. 그런데 제 컴퓨터에서는 문제 없이 돌아가는데 CI서버에 올라가니까 지연되는 시간이 정말 종잡을 수 없이 튀어버렸어요. 스레드를 2초간 슬립시킨다고 정말로 컴퓨터가 딱 2초만 쉬었다가 다시 일을 하지는 않는 다는거야 학생들도 다 아는 사실이었지요. 아무리 그래도 CI서버도 컴퓨터는 컴퓨터고 나쁘지 않은 사양을 가지고 있는데 2초 슬립 시킨다고 5초 뒤에 일을 하지는 않는게 상식이잖아요. 그래봐야 밀리세컨드 단위일 거라고 생각했는데 가끔은 정말 대책없이 쉬어버리는거에요. 딱 하나만 있는게 아니라 슬립이 꽤 어려번 일어나니까 필연적으로 그 중에 한 개 이상은 계속 틀려버리는거에요.

생각을 조금 바꿔보자고 생각했어요. 1초에 한 번씩 돌아가는 스케쥴러가 2초 뒤에는 2번 더 실행된다고 가정했던 그 가정을 바꿔버리자. 2번 이상 실행된다고 가정하면 어떨까. 하지만 스케쥴러도 반드시 정확하게 1초에 한 번씩 실행되리라는 보장은 없었죠. 그렇다면 3초를 슬립시키고 2번 이상 실행된다고 가정하면 어떨까. 너무 널널한 조건을 주고 테스트 하는 것은 아닐까. 하지만 스케쥴러의 본질은 어쨌든 주기적으로 실행되는 것인데 이 정도 조건은 괜찮지 않을까.

지금까지 계속 진전이 없었던 것은, 어떻게든 여기서도 돌아가는 것을 저기서도 돌아가게 하려고 원인을 찾으려고 했기 때문이에요. 하지만 아예 저기서도 돌아가게 (여기서도 물론 잘 돌아가고) 코드를 바꾸면 어떨까. 1초에 한 번씩 돌아가야 되는 스케쥴러가 10초동안 5번밖에 안 돌았다면 그건 실패라고 해도 되겠지만, 3초동안 2번 이상 도는 것은 괜찮지 않을까. 좀 빡빡하게 하면 2.5초동안 2번 이상이라고 하면 되지 않을까. 아무리 지가 서버라고 해도 500밀리 세컨드 이상 지연시키지는 않지 않을까.

내 컴퓨터에서는 성공을 확인할 수 없었기 때문에 막판에 빌드를 꽤 많이 돌렸어요. 그러다가 어느 순간 아 이건 성공하겠구나 싶도록 조건을 줄 수 있었어요. 그 빌드를 돌리기 전에, DB접속과 관련된 실패를 잽싸게 수정했어요. 이왕이면 한 번에 다 성공시키고 싶었거든요.

그리고 스케쥴러가 잡고 있던 실패 2개와 DB접속과 관련된 실패 한 개가 모두 사라지면서 테스트는 성공하게 되었어요. 하지만 테스트가 다 성공한다고 반드시 빌드가 성공하는 것은 아니잖아요. 185개의 테스트 케이스 중 테스트가 하나라도 실패하면 빌드가 실패하는 것은 맞지만요. 여전히 쓰린 속을 진정시키면서 입사지원 할 때 합격자 확인하는 기분으로 빌드 결과를 살펴봤어요.

앞에서도 말했지만, 이 스크린샷은 조작된 것이 아니에요. 이거 찍으려고 안 돌아가는 테스트 케이스 다 주석처리 해버린 것도 아니에요. 어디 허드슨이 그렇게 허술한가요. 저기 보면 200개에 가까운 테스트 케이스가 돌아가고 있는게 다 나오잖아요. 어디 허드슨이 운빨로 빌드가 성공하는 툴인가요. 테스트 케이스 하나 얻어 걸려서 성공해본 적이 없네요. 200개에 달하는 테스트 케이스 하나하나를 다 만들거나 고치거나 해서 빌드를 돌리고 끝까지 성공 못하는 테스트 케이스 하나 하나를 다 성공시킨 결과라구요.

이쯤되면 누군가가 조건 반사적으로 물어볼 지도 모르겠네요. 왜 그렇게까지 애를 써서 한 번의 안정화된 빌드를 만들고 싶었냐고. 그냥 다음날 해도 되지 않냐고. '그저 저 한 번의 빌드를 성공시키고 싶었기 때문'은 아니에요. 여태까지 성공시킨 빌드가 한 두번도 아니었구요. 다만, 저는 그저...