올해 1학기에 들어설 때 세웠던 계획이 총 5가지 였다.

8월 22일 기준으로 2.5가지 진행을 완료했다.
소수점이 나온 이유는 정보처리기사 필기를 이제 끝냈기 때문…
앞으로 실기까지 붙어야 3가지를 완성했다고 말할 수 있겠다.
진행하면서 겪었던 해프닝이나 느꼈던 점들에 대해 기록하기 위해 오랜만에 글을 써본다.

지난번에 성공적으로 졸업작품을 진행할 것정보처리기사 자격증 취득 에 대해 포스팅해보았고, 이번엔 국가근로 아르바이트에 대해 포스팅을 남긴다.

국가근로 아르바이트

국가근로 아르바이트는 2020년 3월 9일부터 본격적으로 시작됐다. 3월 첫 주에 코로나로 인해 아르바이트가 성사될지 안될지 미지수인 상황이었는데, 극적이게도 3월 6일에 첫 출근해서 안전교육을 이수하고 9일부터 업무를 진행했다.
원래 주 업무는 네이버 블로그 포스팅이었다.
네이버 검색량 조회 사이트에서 핫한 키워드를 잡아내고, 그 키워드를 이용해서 포스트를 작성하기! 포스트에 사용된 키워드가 핫할수록 블로그의 방문자 수가 증가하고, 블로그의 방문자 수와 조회수가 늘을 수록 광고를 게제했을 때 조회수가 늘어나는 수익구조를 가지고 있었다.
덕분에 “안녕하세요 이웃님들~” 하는 전형적인 네이버 블로그 아줌마스러운 포스팅을 내가 직접 써볼 수 있었지 ㅋ_ㅋ

재밌게도 이 기업은 블로그 관리 뿐만 아니라 홈페이지 호스팅 서버 운영, 홈페이지 개발 및 유지보수 관리도 도맡고 있었는데 마침 개발자가 퇴사한 모양이었다. 매니저님이 고객사로부터 오는 홈페이지 관리 항의 전화에 쩔쩔매고 계셨는데, 우연찮게 내가 그 일을 해결했다. (아마 간단하게 홈페이지의 팝업창을 내리는 일이었던 걸로 기억한다.)
그 후 대표님께서 내 전공에 관심을 보이시더니 PHP로 개발을 해본적이 있냐 물으셨다.
학과 프로젝트로 백엔드 개발은 여러 차례 해봤어도, PHP로 프론트엔드 개발은 학부 3학년 때 데이터베이스 과제로 잠깐 만져본게 전부였기 때문에 자신은 없었지만, ‘일단 해보고 후회한다.’ 마인드 + 퇴사한 개발자와 커넥트 해주겠다는 대표님의 약속 + 블로그 포스팅보다는 훨씬 유익한 경험이 될 것 이라는 생각 덕분에 해보겠다고 말씀드리고 3월 20일부터 계약서를 작성하고 PHP 개발업무가 시작되었다.

3월 20일부터 8월 12일까지 손을 거쳐간 사이트는 총 11개 였는데, 걔중에 기억나는 것들은

  • A정형외과
  • B문화원
  • C스터디
  • D당 D시당
  • E신문
  • F에듀

정도가 있는 것 같다.

A정형외과

A정형외과 사이트는 전달 받을 당시, 기존 도메인 A.com 에서 도메인 계약기간이 만료된 줄 모르고 있다가 중국업체한테 도메인을 빼앗겨서 A.co.kr로 도메인을 이전 했는데, 그 후에 사이트의 모든 이미지 경로가 손상되어 사이트가 온통 흰색 박스로 도배되어 있었다.
“이미지 파일의 경로가 예전 도메인을 베이스로 잡혀있을거고, 그걸 전부 새 도메인으로 바꾸면 간단하게 해결되겠네!”
라고 행복회로를 굴려봤지만, 그렇게 쉽게 해결될 일이었으면 나한테 던져주지 않으셨겠지 ㅎㅎ..
워드프레스로 작성된 사이트였기 때문에 워드프레스 설정 페이지로 접속해서 플러그인을 이용해 모든 이미지 파일의 경로를 새 도메인으로 바꾸는 작업을 진행했는데, 사이트에 아무런 변화도 일어나지 않았다. ‘워드프레스나 플러그인의 버전이 서로 안맞아서 호환이 안되나?’ 하는 생각에 다르게 시도해봤지만 여전히 요지부동이었다.
플러그인이 안먹혔으므로 DB에 접속해서 직접 경로를 수정하는 것으로 계획을 변경하게 되었다. DB는 PHP 기반이었기 떄문에 PHP디렉토리를 뒤져보다가 찾아낸 DB설정 파일을 이용해 접속할 수 있었다. DB에 접속해보니 다행히도 옛날 도메인으로 저장되어 있는 이미지 파일 경로들이 수두룩하게 보였다.
LIKE ‘%.com%’ 쿼리문을 이용하면 쉽게 해결이 가능할거라 생각했기에 행복회로가 다시 한 번 불탔지만, 역시 해결되지 않았다!
‘도대체 .com 으로 되어있는 이미지파일들의 경로는 무엇이었으며, 나는 그걸 바꿨는데도 달라지는게 없을까?’ 하는 생각에 머리에 열이 빡 차올랐던걸로 기억한다.
이미 여기까지 접근하는데 일주일 가까이가 소모 되었었기 때문에 반쯤 포기상태였는데, 의자에 축 늘어진 채로 워드프레스 설정 페이지를 이리저리 클릭해보다가 뜬금 없는 기능을 발견한다. 바로 메인페이지를 게시글처럼 작성하는 기능이었는데, 이 기능을 조사하다 알게된 점이 A정형외과의 메인페이지가 일반적인 웹 사이트들의 화면 아니라, 포스팅 기능을 이용해 작성된 화면이었던 것이다.
즉 내가 DB에서 바꾼 이미지들의 경로는 포스팅 기능에서 불러올 수 있는 이미지들의 경로를 바꾼 것이고, 경로가 바뀐 이미지들을 다시 불러와서 저장해야 메인페이지에 수정이 되었던 것!
기쁜 마음으로 메인페이지를 수정한 후에 새로고침을 눌러보니 알록달록 사진들이 보였다.

문제는 메인페이지 뿐만 아니라 모든 페이지가 저 형식으로 작성된 것이었기 때문에 계속 반복작업을 진행해야했는데, 이미지 파일명들이 모두 들쑥날쑥에 어디에 어떤 이미지가 배치되어야 하는지 전혀 알 방도가 없었기 때문에 다른 페이지들은 클라이언트가 직접 보고 결정하셔야 한다는 말씀을 드리고 마무리 짓게 되었다.

B문화원

B문화원은 코로나 시국에도 어찌 그리 이벤트들이 많은지, 일주일에 두 번씩은 “팝업 올려주세요.”, “팝업 내려주세요.” 하고 연락이 왔던 것 같다.
차라리 팝업 게시기간이라도 정해줬으면 날짜 카운트해서 띄울지 말지를 입력해두고 나중에 일괄적으로 주석처리를 했을 것 같은데, 여긴 그냥 인스턴스식으로 개발자한테 시키는 곳이었다! 아마 담당자분의 연세가 좀 있으셔서 그렇지 않았을까… 생각해본다.
처음에는 간단한 것들만 요청이 왔는데, 5월 말부터는 사업이 변경된 것들이 있다고 “사이트 메뉴바를 바꿔달라”, “새로운 게시판을 추가해달라” 등의 요청으로 점차 난이도가 높아졌다.
속으로 ‘5월 씩이나 돼서 사업이 변경되나?’ 하는 의문을 가졌지만, 25살 풋내기 입장에서 이런 경험이 얼마나 귀한가 느끼면서 까라면 까야지 식으로 일을 진행했다.
사이트 메뉴바를 바꿀 때 겪었던 문제점은 사이트 메뉴바가 텍스트가 아닌 이미지로 이루어져있었다는 건데, 이 때문에 메뉴바를 수정해달라 할 때마다 포토샵으로 메뉴바를 새로 만드느라 꽤나 애를 먹었다. 그나마 내가 포토샵을 만질 줄 알아서 다행이었지…
(상단 메뉴바 + 사이드 메뉴바라서 작업량이 두 배!)

6월 말일 쯤에는 “관리자만 게시글 작성이 가능한 게시판을 새로 개설해달라.” 라는 요청을 전달 받았었다. 기존 관리자만 게시글 작성이 가능한 다른 게시판을 참고하기 위해서 관리자 계정을 전달 받아 로그인을 했는데, 관리자 계정임에도 게시글 작성이 불가능 했다. 생각해 본 바로는 관리자가 게시글을 작성하는 전용 페이지가 따로 있는 것 같아 B문화원 담당자분께 “혹시 기존에 어떻게 글을 작성하셨었는지, 관리자 전용 페이지가 따로 있지 않는지”에 대해 질문을 드렸는데, 그런건 일절 없었고 B문화원 홈페이지에서 작성해왔었다고 못을 박으셨다. 하지만 담당자분의 말을 온전히 믿을 수는 없었다. (클라이언트는 컴퓨터를 잘 모를 수도 있다는 걸 항상 염두에 두어야 하니까.)
담당자분이 없던 버튼을 직접 만들어서 게시글을 작성했을리는 없고, 있던 버튼이 갑자기 사라졌을리도 없었을 터였다. 혹시 몰라 PHP 디렉토리 하위를 뒤져보니 admin 디렉토리가 존재했다. 그대로 도메인 뒤에 /admin 을 붙여서 접속해보니 관리자 로그인 페이지가 접속됐다. -_-….
그렇게 접속한 관리자 전용 페이지에서 다른 게시판을 참고해서 새로운 게시판 개설을 완료했다. 관리자 페이지 찾는데에 3시간, 게시판 개설에 1시간!
항상 클라이언트의 경력이나 환경을 고려해서 클라이언트의 요구사항을 해석해야한다는 걸 배운 사례였다.

C스터디

C스터디는 여러가지 게시물을 수정했던 것 외에 가장 인상적으로 남는 사건이 하나 있었는데, 이전에 포스팅했었던 개발 가이드 탐색의 중요성과 업무효율 이 그 주인공이다!

D당 D시당

D당 D시당 사이트는…. 사실 프론트엔드 쪽보다는 대부분 포토샵을 이용해 사진을 수정해서 업로드하는 업무들이었다. ‘개발자 = 사이트를 관리하는 사람 = 사진 던져주면 알아서 편집할 줄 아는 사람’ 으로 인식되어 있는 곳이었다. ‘포토샵을 다룰줄 몰랐다면 애먹지 않았을까?’ 싶은게 많았다.
여기서도 클라이언트들이 개발자를 어떻게 생각하는지 어렴풋이 알 수 있었다.

E신문

너무 노후화된 워드프레스 기반 사이트. A정형외과 사이트 문제를 해결한 시점에서 이 사이트를 다시 봤다면 쉽게 이해하고 처리했겠지만, E신문 사이트를 먼저 접했었다.
그 때문에 처음엔 상단 로고 하나 바꾸는데에 거의 반나절을 소모했던 것 같다. 일을 그만두기 직전인 8월 첫째주엔 2주간 게시되는 홍보배너를 등록해놓고 왔었는데, 날짜를 비교해서 배너가 내려가도록 했었다. 만약 지금까지도 그 코드가 남아있다면 매번 페이지를 로드할 때마다 날짜비교를 할텐데, 다른 개발자가 그걸 발견해서 처리했을지 궁금하긴 하다. (부장님께 다음 개발자에게 알려주어야 한다고 이야기했지만, 한 귀로 듣고 한 귀로 흘리신 것 같았다. 차라리 서버에다가 트리거를 하나 등록해 놓을 걸 그랬나?)

F에듀

내 손길도 가장 많이 거쳤고, 스트레스도 가장 많이 받았던, 애증관계에 할 말 많은 사이트 F에듀.
우선 아래에 예시로 든 코드부터 보자.

<?
$iis="select * from student ";
$ii=$_GET[id];$iis=$iis+"'"+$ii+"'";$r=mysql_query($iis);
while($row=mysql_fetch_array($r)){
    ...
}
?>

모든 소스코드의 상태가 저렇게 엉망이었다. 골이 심하게 울렸다.
앞선 다른 사이트들에 비해 변수나 함수명에 문제가 너무 많았다. 그리고 불필요한 함수나 라이브러리 호출이 너무 잦았다.

F에듀는 퇴사했던 개발자가 퇴사 직전까지 만졌던 사이트라고 했다. 시간순서 상 가장 마지막에 만진 사이트라는 것인데, 왜 앞서 만졌던 사이트들보다 더 나쁜 상태로 남아있었을까?
도저히 이해할 수가 없어서 매니저님께 현재 사이트의 상태에 대해 말씀드렸다. 그랬더니 사이트가 엉망인 전말을 들려주셨다.

앞서 개발된 사이트들은 모두 쇼핑몰 사이트 솔루션을 이용해 개발해왔다.
F에듀 역시 쇼핑몰 사이트 솔루션을 이용해 개발을 진행했다.
F에듀 사이트 담당자가 점점 어려운걸 요구했다.
개발자는 다른 사이트들도 문제없이 잘 개발해왔었으므로, 모든 요구사항에 “가능하죠!” 라는 말과 함께 개발을 진행했다.
어느 순간 개발자는 한계에 봉착하고, 잠수를 탔다.

참으로 화려한 과거를 가진 사이트였던 것!
그래도 이런 사이트를 경험해 보는 것 역시 좋은 경험이 될 것이라는 생각을 갖고 유지보수에 착수했다. 한 가지씩 해결하기 시작하자 쏟아지는 요구사항들…

요구사항

발견 + 수정은 요구사항은 없었지만 유지보수 단계에서 내가 발견해서 처리한 사항들, 수정은 최초 요구사항 정의서를 전달 받았을 때 기록되어 있던 내용들이었다. 그리고 추가기능은 내가 요구사항 정의서를 하나씩 해결하기 시작하자 담당자분께서 신나서 추가하신 것들…
완료는 말 그대로 처리한 사항들이고, 대기는 대부분 현금결제관련이나, 기존 DB테이블 구조가 너무 지저분하게 잡혀있어서 도저히 해결할 수 없는 것들을 기록해둔 것이다.

사실상 유지보수보다는 새로 개발하는 경우가 잦았다. 대표적으로 기억나는 구현 기능 몇 가지를 적어보면 게시판, 시험지, 오답노트, 재시험이 있다.

게시판
게시판에서 3일 이내 게시된 글은 new 아이콘 등재, 3일이 지난 게시글은 new 아이콘 제거하는 기능이 껍데기만 구현되어 new 아이콘이 항상 등재되어 있었다. 아마 날짜 비교 방법을 몰라서 구현 못했던 걸로 예상됬는데 날짜 비교 로직을 추가하니 바로 완성되었었다. 이 기능을 구현하면서 퇴사한 개발자 커넥에 대한 기대감이 사라졌다.

시험지
수학문제 시험지에 각 문항마다 상단에 정답률이 표기되어 있었는데 이 수치가 실제 정답률이 아니라 의미없는 상수값이었다. 실제 정답률이 표기되도록 바꾸려고 DB의 시험지 테이블을 참고했는데, 시험지 구조가 무언가 이상했다. 정답률을 구할 생각이라면 문항별로 데이터를 삽입하고 이를 묶어서 시험지로 구현했어야할터인데 문항 테이블은 존재하지 않고 모두 시험지 테이블에서 관리 되고 있었다.
찬찬히 음미하며 테이블 컬럼들을 살펴보니, 시험지 테이블 안에 모든 문항을 “|” 기호로 구분하여 저장하고 있었다. 즉, 정답률이 저장되는 공간이 전혀 없었다.
구조가 저러니 당연히 채점 후 정답률이 기록될 수 없었고, 정답률을 기록할 수 없으니 껍데기만 만들고 저장해둔 것이었다.
시험지 테이블을 한참 보면서 ‘다 밀어버리고 테이블을 새로 만들까?’ 라고 고민해보았는데, 이미 테이블이 생성된지 1년이 더 넘어서 학생들이 시험을 응시한 기록이 저장되어 있었다. 학생들 시험 응시 기록을 모두 백업하고 새로 테이블을 작성해서 이를 옮겨담을 수 있다면 참 좋겠지만, 다른 테이블에서 시험지 테이블을 얼마나 참조하고 있을지 알 수도 없었고, 이미 수많은 php소스코드 파일에서 해당 테이블 구조를 사용중이었다. 차라리 홈페이지 구축을 처음부터 다시하는게 더 빠를터였다.
결국 시험지 테이블의 구조를 유지한 채로 매번 시험지를 불러올 때마다, 동일한 분류코드를 가진 시험지채점 기록을 모두 가져와서 채점을 진행하고 정답률을 포기하는 형태로 구현하게 되었다.
지금 생각해도 죄책감이 드는 방식인데, 별다른 방법이 떠오르지 않았다… 프론트엔드도 자료구조와 알고리즘에 빠삭해야한다는 걸 여기서 깨달았다.

오답노트와 재시험
채점과 정답률을 해결하니 이번에는 오답노트를 구현해달라는 요청을 받았다. 채점 기록은 저장되지만 오답노트용 테이블이 따로 존재하지 않는데, 어떻게 해야할지 난감했다.
심지어 오답노트는 껍데기 페이지도 구현하지 않은 상태였다. 아마 오답노트를 구현하는 시점 쯤에서 개발자가 잠수를 탄게 아닌가 예상해본다.
다행히 떠오른 방법은 페이지 로드시 DB를 탐색을 진행하고, 탐색 결과에 오답노트 데이터가 존재하지 않으면 시험지채점 테이블에서 사용자와 날짜 기준으로 정렬 후 모든 채점기록을 가져와서 오답노트 데이터를 만든 후 DB에 저장, 탐색 결과에 오답노트 데이터가 존재한다면 그걸 불러오는 것으로, 곧장 오답노트 테이블과 재시험 테이블을 생성하고 구현할 수 있었다. 신기했던 점은 껍데기 페이지가 구현되어 있지 않은 오답노트와 재시험을 새로만드는데 걸린 시간이 시험지 정답률을 수정하는데 걸린 시간의 1/3 정도였는데, 어지럽게 작성되어 있는 변수명들을 보며 “이게 무슨 뜻일까…” 하고 해석하는 과정 없이 구상한대로 바로바로 작성해나가니 금세 구현할 수 있었다.

그 외에도 시험지 대-중-소 분류가 제대로 되지 않았던 것이나, 학교별 기출문제 검색시 난이도에 따라 구별되도록 하는 것, 학생레벨 구분, 시험지 프린트 시 학생들이 모두 겹쳐서 나오던 것 분할 등 다양한 요구사항들을 음미했던 것 같다. 매 기능을 구현할 때마다 골치가 아팠지만, 하나씩 해결할 때마다 담당자분이 감탄하시는 모습을 보며 만족감과 쾌감을 느끼고 계속 진행했던 것 같다.

불행히도 그런 사이트 담당자님에 대한 기억이 좋게 남아있지는 않은데, 평일, 주말, 밤낮을 가리지 않고 전화를 거셨다. 주말에 밤 9시에 “잠깐만 통화 가능하냐” 면서 결국 20분 가까이 통화했던 사건 이후에는 평일 오전~오후 이외의 통화는 모두 거절했다. 그랬더니 계약 종료 후 인수인계를 위해 만난 다른회사 개발자분이 “그렇게 전화를 안받으셨다면서요?” 라면서 농담하시더라.

결론은?

퇴사한(잠수탄) 개발자는 결국 만나보지 못했고, 주먹구구식으로 하나씩 부딪혀가며 진행하다가 계약기간이 만료되고 자격증 준비를 위해 그만 두었다. 대부분의 클라이언트들이 개발자를 어떻게 생각하는지에 대해 체험 해볼 수 있었고, 프론트엔드 관련 실력도 많이 늘은 것 같다. 일을 진행하는 동안 매니저님께서 정말 많은 편의를 봐주셨고, 덕분에 불편함 없이 몰두해서 일할 수 있었던 것 같다. 다시 한 번 감사드립니다!

가장 값진 경험은, 현재 대부분의 프로그램이나 서비스는 개발자보다 수명이 길고, 개발에 참여하지 않은 개발자가 유지보수를 이어받는 케이스가 흔하다는 것. 이 때문에 산출물의 유무가 매우 중요하고, 산출물 없는 에일리언 코드는 정말 작업하기 어렵다는 것. 또한 에일리언 코드가 되더라도 “단순하고, 보기좋고, 알기쉽게” 작성하는 것이 개발자들 간의 예의이자 바로 실력이라는 것을 배울 수 있었다.

대학교 졸업을 앞두고 참 많은 걸 경험한 귀중한 시간이었다. 1학기 알차게 잘 보낸 것 같다. 끝!

댓글남기기