상상초월의 디지털 발암제, 오즈리포트 7

넥사크로 이후로 다시 한번 더 까는 글을 쓰게 되었습니다. 그나마 넥사크로보다는 훨씬 나은 프로그램이라고 믿어왔는데 점점 현실을 알게 되니 서론에서만 존댓말을 쓰고 본문 들어가자마자 바로 반말에 쌍욕으로 시작을 끊을 것입니다. 오늘 이 포스팅을 작성하게 된 이유는 욕하려고입니다.

 

국내 소프트웨어가 전체 이렇지는 않는다... 라고 믿어왔던 저에게 변명하지 말라는 마인드를 가지게 만든 두번째이자 사실상 결정타입니다. 가장 최근 국내성과현황 중 괄목할만한 성장을 이끌어낸 곳이라고 믿어온 곳이 티맥스소프트라는 확신을 가지게 만든 이유로 그나마 오즈리포트가 못해도 2군은 하겠지 싶었는데 완전 3류라는 사실을 알게 된 이후로는 티맥스소프트를 원탑으로 꼽게 만들었습니다. 소프트라기보다는 티맥스가 1군급이 틀림없다는 확신을 가지게 된 데는 리눅스 기반의 티맥스 OS 가 작정하고 윈도우 UI와 유사하게 내놓은 작정하고 내놓은 모양새에 굉장히 호감이 가서 그렇긴 하지만 적어도 저런 노력을 하는데 오즈리포트가 저 선을 같이 한다고 하면 주저없이 소송에 휘말릴 위험을 감수해서라도 더 강하게 논합니다. 성과는 뽑아놓고 노력을 논하는거냐고.

 

적어도 티맥스 OS가 완전한 운영체제도 아니고 리눅스의 개조판으로 만들어졌다는 점에서는 완전한 운영체제의 제작이 아닌 리눅스의 파생형 운영체제가 나온것 아니냐는 실망감을 느끼긴 했지만(거기다 32비트) 적어도 국내 공무기관이나 사무소 등에서 사용할 수 있는 만큼의 최소한의 운용이 가능한 운영체제가 나왔다는 점에서는 두손넓게 벌려 자리에서 일어나 얼마든지 기립박수를 쳐줄 만 하다고 느꼈습니다. 운영체제를 자체능력으로 만들 수 있는 나라는 미국 외에는 없을꺼라는 자체적인 고정관념이 드디어 깨지는 믿기지 않는 미래가 왔다는 체감을 받았거든요. 그런 변화를 티맥스가 스스로 뼈를 깎고 직원의 건강도 깎였겠지만 그 결실을 볼 수가 있는 산물과 성과가 나왔다는점을 느꼈을 때 도대체 오즈리포트는 뭐 했냐. 티맥스가 눈에 보이는 변화를 꾀하는동안 너네제품이 넘버링이 바뀌는데 투자한 노력에 비해 보이는 성과가 도대체 뭐가 있냐 한마디가 나왔습니다.

 

이제부터 본론으로 들어가겠습니다. 맨 윗 문단에서도 언급했다시피, 여기서부터는 철저하게 반말투, 상투적인 욕설을 완벽하게 곁들일 것입니다.

---

---

미친 새끼.

쓰다보면 개발자가 들을 수도 있는 욕설이자 개발자가 개발사에게 할 수 있는 가장 솔직한 심경표현이 될 것이다. 프로그램의 완성도가 높아보이도록 완벽하게 연기를 하는 이런 미친 프로그램이 더도 있어서도 안되고 덜도 있어서도 안된다. 타 프로그램과의 완성도 비교 자체를 아예 논할 수 없는 수준으로 개판이다. 어느 정도냐면 독보적이다, 압도적이다가 가장 약하게 표현한 수준이다.

 

도저히 쓰라고 만든 프로그램도 아니고 이걸 돈받고 판다는건 더더욱 양심이 없어보인다. 자유도 아니고 무료고 아니고 버젓이 엄연한 상용이 과연 이따구 퀄리티로 돈받고 팔아먹어도 되는건가에 무궁무진한 의문점을 가지게 만든다. 하다하다 넥사크로가 생산성이라도 있는 채로 그렇게 욕을 쳐하게 만드는데 이건 심지어 생산성이 서식완성에 한정되어있는 주제에 미친 프로그램마냥 악성코드로써의 역할을 묵묵히 수행하는 제대로 정체목적을 정의할 수가 없는 프로그램이다.

 

그런 와중에 라이센스 관리 로직은 철저하다. 오죽 리포팅 서식에라도 저정도 신경을 써줬으면 얼마나 좋아. 할 생각이 없으면 그만 접던가.

아님 업종변경을 하던가.

 

눈에 보이는것만 해도 너무 많아 해당 포스팅에서 전부를 나열하기는 힘들 수준이다. 있냐 없냐 검증의 문제가 아니라 하나도 빠짐없이 모두 떠올리느냐 몇개 떠올리지 못하느냐의 레벨이라서.

 

안그래도 비염있는데다 사무실도 환기를 함부로 할 수 없는 구조란다. 거기다 코로나 사태까지 겹쳐서 실내에서도 마스크를 쓰는데 숨도 제대로 못쉬고 그놈의 마스크가 콧등까지 누르느라 비염이 슬슬 축농증으로 발전될 가능성이 아주 높아 도저히 참을 수가 없는 지경이 되어버렸지만 지금의 이 상태가 되기까지 애초에 오즈리포트만으로도 도달할 수 있는 분노레벨이다. 그냥 속도 차이가 있을 뿐.

 

하나하나 까보도록 한다.

---

0. 실행환경

JRE 1.5 버전이 필요하다. 지금 자바가 14까지 나온 시점에서 한국이 안정성있고 기능 충분하다는 이유로 1.7에서 1.8에서 머무르고 있는데 이하버전은 절대로 안되지만 무려 이상버전도 절대로 안되고 무조건 1.5버전의 JRE가 있어야만 설치 및 이용이 가능하다!!

---

1. 개발프로그램과 문서서식프로그램의 애매한 경계선

리포팅 툴로써 제대로 사용하기 위한 2개의 구성요소를 모두 제대로 다룰 줄 알아야 하는데 대표적으로 Query Designer, Report Designer 2개 요소가 있다. 이 중 Query Designer는 쿼리를 직접 입력하든 스크립트로 입력하든 SQL의 중추적인 기본개념을 확실하게 알아야 사용이 가능하다는 점에서 철저한 개발프로그램, Report Designer는 MS워드 2007을 기반으로 한 데이터기반 문서서식 프로그램이다.

 

쿼리를 실행하여 얻는 데이터셋을 기반으로 문서를 자동서식 및 데이터표시하도록 한다는 개념에서 출발해 Query Designer의 .odi 파일, Report Designer의 .ozr 파일을 철저히 구분해 작업에 혼란이 오지 않도록 미리 대비한 것 까지는 좋았지만 문제는 그 개념의 식별기준단위가 파일이라는 점이다. 프로그램최적화 문제와 관련해서는 8번 항목에서 다시 언급하겠지만 일단 이 오즈리포트의 각 구성요소별로 에디터 프로그램이 실행되고 사용가능한 상태가 되기까지 기다려야 하는 시간이 너무 심각하게 오래 걸린다. 프로그램 자체의 최적화가 개판인데다 무려 64비트 환경이 제법 잘 구축되고 거의 표준이다시피 한 상황에서 고집스러운 32비트의 프로그램을 사용해야한다. 느려터질 수 밖에 없는 구조가 여실없이 드러난다. 싱글코어만 죽어라 갈궈대니 속도가 제대로 붙을 리가. 어느정도냐면 그냥 SSD를 달고도 HDD의 속도를 체감해야만 한다. 이건 해결방법이 전혀 없다.

 

그리고 데이터를 가지고 서식을 이용해 데이터표시를 완성시킨다는 개념을 충분히 포괄하려면 리포트 디자이너를 개발프로그램에 넣어야하는지 문서서식프로그램에 넣어야하는지 굉장히 혼란스럽다. 더군다나 리포트 디자이너에서도 컴포넌트를 효율적으로 다루기 위한 오즈스크립트도 제공하고있기에 더더욱 문서서식에서 거리가 벌어져있지만 정작 쿼리를 다루는 기능 일체를 쿼리 디자이너에 맡겨버려서 리포트 디자이너가 개발프로그램인지 문서서식프로그램인지를 논하는 기준이 SQL vs 문서서식이 아니라 자바스크립트 vs 문서서식이라는 해괴한 구조가 벌어져서이다. 하다하다 이런말을 하게 될 줄은 상상도 몰랐지만. 별 이상한 문서서식 프로그램도 다 본다. 스크립트를 이용한 문서서식은 생전처음보는 수준이다. 그렇다고 스크립트가 생산성이 좋아서 문서서식에서 하지 못했던 기능들을 모두 커버할 수 있는 마법의 문물이냐면 그것도 아니다. 바로 아래 다음 문단인 2번 문단에서 스크립트의 문제점을 꼼꼼히 따져볼 것이다.

 

때문에 결론은 쿼리디자이너는 철저한 개발프로그램인 반면 데이터셋만 가지고 오면 그 다음은 철저하게 리포트 디자이너가 바톤을 넘겨받아 나머지를 모두 처리해야하는데 문서서식도 아니고 스크립트 개발 프로그램도 아닌 정체성 모호함에서 프로그램의 사용방법이 이미 루비콘 강을 넘어가버렸다. 개발하다가 서식하고 서식하다가 개발하고의 정신없는 프로그램이 과연 서식인지 리포트인지. 매번 키보드보다 마우스를 더 죽도록 붙들고 개발해야했던 초보 개발자가 대안을 제시한다. 이딴 쓰레기를 라이센스비용 내고 쓸 바에 차라리 아예 리포트 자체를 오즈리포트 쓰지 말고 HTML5로 개별구성해버리는게 훨씬 더 좋지 않을까. 요즘 은 브라우저도 pdf저장은 인쇄창에서 지원하고 html가 필요하면 그냥 Ctrl S 하면 되고 엑셀이 필요하면 그냥 드래그 드롭을 허용만 해주면 알아서 카피떠주는 엑셀의 지능화도 눈부시게 올라가있는 상태인데 말이다. 왜 써야하는가 이거부터 제대로 된 답이 나오지 않는다면 오즈리포트를 철저하게 거부해야한다. 고객에게 왜 오즈리포트를 쓰면 안되는지를 잘 설득하는것이 HTML5 시대에 넘어온 이상 IT기업의 기초역량이라고 할 수 있을 것이다.

---

2. 토나오는 독자규격 오즈스크립트

자바스크립트 기반의 오즈스크립트를 사용하는데 아니나다를까 독자규격이다. 기본적인 문법은 모두 자바스크립트를 기반으로, 사용하는 느낌은 아마 타입이 Object일 뿐이지 구분이 명확한 타입스크립트를 사용하는 느낌이다. 그런데 이거. 애초에 사용할 필요가 없어야하는 물건이다.

 

기본적인 스프링의 MVC패턴을 오즈리포트와 비교해가면서 분석해보면

(빨간 색은 동일한 로직이지만 순서에 변화가 있는 경우)

 

01. 클릭을 통한 JSP -> 서버 요청전달

02. 정당하고 올바른 요청인지, 요청을 승인하기 위한 적정한 인증과 권한이 확인되었는지 검증

03. 컨트롤러와 서비스를 통한 데이터 확보 및 분별

04. 클라이언트에게 데이터를 전달

클라이언트

05. 요청에 기준한 데이터를 응답받아 JSP 또는 자바스크립트를 통해 가시적인 데이터로 구성 및 디자인

06. profit

 

오즈리포트

01. 클릭을 통한 JSP -> 서버 요청전달

02. 정당하고 올바른 요청인지, 요청을 승인하기 위한 적정한 인증과 권한이 확인되었는지 검증

03. 컨트롤러와 서비스를 통한 데이터 확보 및 분별

04. 클라이언트에게 데이터를 전달

05. 요청에 기준한 데이터를 응답받아 JSP 또는 자바스크립트를 통해 가시적인 데이터로 구성 및 디자인

06. profit

클라이언트

07. 울며 겨자먹기로 받는데 서식데이터까지 싹 다 포함된 리포트를 받아 출력하느라 엄청 느려터진 속도를 자랑

 

사용자에게 데이터만 넘겨주면 되는 것을 무려 서식프로퍼티까지 싹 다 포함해서 클라이언트에게 넘겨준다. 거기다 서식프로퍼티는 한번 설정되면 동적인 데이터도 아니고 무려 정적인 XML로 관리되는 충격과 공포의 데이터이기 때문에 여기에 유연성을 부여하자고 들어간 것이 바로 오즈스크립트이다. (에디트프로그램으로 그냥 실행이 된다. 직접 확인해보자) 어떤 경우에는 표시를 하고 어떤 경우에는 표시를 하지 않는다던가, 어떤 경우에는 텍스트의 본문을 바꿀 필요가 있을 때 사용한다던가 하는 경우이다. 무려 이게 JSP 위에서 돌아간다. 좋게 보자면 JSP에서 실행할 수 있는 자바스크립트의 기능 + 오즈리포트가 지원하는 오즈스크립트의 기능과 같은 구조가 될 수 있겠지만 전혀 그럴 수가 없는게 뷰어에서는 뷰어만 제공할 뿐 자바스크립트의 기능은 리포트 뷰어가 독점한다!! 정작 뷰어라서 사용자가 사용할 수 있는건 하나도 없지만 그런 와중에 개발자가 손댈 수 있는것 조차도 없다. 차라리 저런 문서를 HTML 브라우저에서 띄운 다음에 자바스크립트로 조작해버리는것이 훨씬 속도가 빠르다. 안그래도 요즘 느려서 곳곳에서 빼고있다는 제이쿼리(jQuery)를 이용해서 작업을 처리해도 오즈리포트보다는 빠르다.

 

오즈스크립트가 사용할 수 있는 기능이 많냐면 그렇지도 않다. F1를 눌러 도움말 창을 띄우면 여타 국산프로그램들이 하나같이 전부 다 똑같지만 요즘 추세에 브라우저 띄우고 웹문서를 통한 도큐먼테이션을 제공하는것도 아니고 그냥 옛날 공식인 도움말 창을 띄워 제공하는것인 주제에 하는짓이 놀랍도록 넥사크로와 똑같다... 함수 이름만 제공하고 어떤 컴포넌트에서 사용되는지 아규먼트가 어떤것들을 받는 구조인지 결과리턴이 있는지 없는지의 명세를 요약에서 전혀 제공하지 않고 상세함수설명 페이지까지 들어가야 겨우 확인하는 정신나간 요약을 제공한다!! 이 쯤 되면 할말이 없다. 저런 꼴이 나오는건 한마디로 정의한다. 왜 저렇게 정신나간 상태로 만들어졌는가. 정신나간 정신병자들이 만들었으니 정신나간 상태가 만들어지는건 당연한거 아닌가.

 

OnInitialize, OnStart, OnEnd 같은 스크립트 실행을 구분하기 위한 주기를 철저하게 나눠놓은것은 의미가 있다고 쳐도, 정작 도큐먼테이션에 들어가서 각각의 함수마다 어느 주기에 실행할 수 있는지는 검색이 지원되지 않는다. 매 함수마다 상세페이지로 들어가서 실행 가능한 생명주기를 직접 찾아야 한다. 컴포넌트가 생성되었을 때인지, 데이터가 바인딩되기 전인지, 데이터가 바인딩된 다음인지, 완전하게 로드가 끝난 다음인지의 실행기준이 엄격한데 검색에서는 편의성을 엿바꿔먹어버린 대충 촌스러운 편의성이다. 스크립트의 신뢰도가 얼마나 높은지까지는 모든 함수를 테스트하지 못해 확답을 하기가 힘들다고 쳐도 사용하는 단계에서부터 머리에 비듬이 생긴다. 혓바닥에 설태가 낀다. 몸이 그냥 가렵다. 스크립트가 워낙 더러워서 그렇다.

---

3. 서식을 매번 엿바꿔먹는 사용자 경험

놀라운 기능이 아닐 수 없다. 에디터 전체설정으로 들어가도 디폴트 설정으로 정할 수 있는 서식기능이 하나도 없다. 매번 항상 컴포넌트를 새로 설정해서 배치하면 항상 맑은 고딕을 사용하도록 강제한다. 텍스트 크기도 강제되어있고 정렬도 강제된다. 디폴트 설정이 매번 마우스를 이용해서 번거롭게 바꾸는 생산성을 정면으로 거스르는 이상한 용도로 자리잡았다. 웃긴게. 키보드로 이렇게 저렇게 할 방법이 귀찮더라도 있다면 여기에 적진 않았을 것이다. 엄연히 말하자면 키보드로 가능은 하다. 그런데 그 단축키가 Ctrl을 기반으로 알파벳 키를 동시에 눌러 해결하는 방식이 아닌, Alt 키를 눌러 각 항목마다 알파벳 키가 어떤 기능을 하는지에 대한 툴팁이 나타난 상태에서 다루는 방식인데다 못해도 MS워드나 한글워드를 사용해봤다면 잘 알 것이다. 폰트 이름이 콤보박스에 나란하게 쌓여있는 틈새에서 맞는 폰트를 직접 찾아 클릭하는 형식으로 폰트를 변경한다는것.

 

무슨 말이냐. 그냥 마우스를 쓰라는 소리다. 웃기려고 하는게 아니라 진짜다.

 

컴포넌트들의 개별적인 서식변경이 귀찮다면 하나의 컴포넌트 그룹을 원형을 먼저 만든 다음 원형을 Ctrl C로 복사해서 텍스트만 바꾸고 필요한것들만 서식을 바꾸도록 해야한다. 이런 와중에 지원되는 Ctrl CV의 힘이 강력하다는건 최악 중에서 최선인지라 정말 고맙지만 애초에 이 기능에 절대적으로 의존하도록 문서작성프로그램 치고는 키보드 지원 환경이 정말 열악하다는것이 참아줄 수가 없다.

 

웃긴건, 단순히 텍스트에만 해당하는 서식이 강제되는것이 아니다. 애초에 밴드나 컴포넌트같은 개념들도 텍스트와 마찬가지로 디폴트 설정같은 것이 전혀 없어 마우스로 일일이 위치를 선정해 배치를 한 다음 엿같은 디폴트 서식들을 모두 마우스로 바꿔줘야한다. 심지어는 밴드와 컴포넌트를 배치하는데 기준선 자석기능도 없고 눈에는 대충 선이 잘 맞은거 같은데 무려 실수단위 0.001이 어긋난 경우 때문에 리포트가 지저분해지는 경우도 있다. 혹시라도 마우스클릭 미스로 컴포넌트를 드래그해버렸다? 당장 Ctrl Z를 돌려야한다. 그정도로 민감도는 극악으로 높으면서 편의성은 단 1도 제공 안되는 멍청한 프로그램이다. 무려 시리즈 넘버링이 8까지 올라갔는데도 2020년에 2007을 베이스로 사용하는 프로그램이 말이다. 쓸데없이 고객이 퍼블리셔 경력이라도 있다던가 너무 꼼꼼하게 깐깐한 성격이라서 눈에 보이는 1픽셀의 오차도 안봐준다면 다름아닌 오즈리포트때문에 지옥문이 열린다는 것이다. 특히나 서식프로그램을 가장한 쓰레기프로그램이기 때문에 개발자가 아닌 디자이너 혹은 퍼블리셔가 프로그램을 잡게 된다면 그건 실적을 핑계로 당신을 해고하려는 회사의 계획이다.

 

민감도가 너무 심각해서 드래그할때마다 다른 컴포넌트들과 상대적인 레이아웃 배치를 일관성 있게 무분별한 자석을 제공해서 되려 불편해진 MS PowerPoint와 완전하게 대척점에 서있는 프로그램이 오즈 리포트이다. 그나마 파워포인트는 사용자가 필요할때 무분별한 자석선 중에서 필요한걸 취사선택해서 깔끔하게 정리라도 할 수 있지 오즈리포트 이 병신같은 프로그램은 A4용지기준 가로길이가 27.xxx 라는걸 일일이 다 기억해서 좌우 여백 3씩 빼려면 27.xxx 에서 3을 빼서 직접 폭의 넓이를 24.xxx 처럼 지정해야한다는 정신나간 개념의 문서서식을 자랑한다.

 

다른거 다 집어치우고, 문서서식 작성하는데 굳이 실수부 사칙연산을 해야할 필요가 있을까? 그럴 필요를 완전히 없애버린건 넘쳐난다. 리브레오피스 네이버오피스 VS코드 서브라임텍스트 에디트플러스 MS워드 하다못해 한글까지. 워드패드 메모장도 이딴 병신짓은 안한다. 이런 기능은 없어서 제공 못할것 같아요라고 말할 수 있는 케이스가 전혀 이상한데서나 터지고 정작 생산성을 깎아먹고 트러블을 일으킬 수 있는 케이스는 오히려 실수부까지 계산해서 일어날 수 있도록 개방성을 활~짝 해놓은 상태다.

 

활~짝

 

하는짓이 어째 왜저렇게 넥사크로랑 똑같냐 이건 뭐 병신병신열매를 쳐먹은것도 아니고.

 

거기다 한술 더 떠 뷰어의 기능도 정말 어처구니가 없는게 리포트 디자이너에서 미리보기를 실행하면 항상 미리보기를 담당하는 창이 고정된 위치에 고정된 크기로만 나온다. 제발 좀 듀얼모니터 쓰고 있으니까 작업중인 모니터에서 창 뜨라고 드래그를 해도 보란듯이 무시한다. 위치만 무시하는게 아니라 크기도. 항상 정사각형 픽셀로 미리보기 창이 떠서 꼭 A4규격 기준 가로로 해도 세로로 해도 컨텐츠가 짤리도록 미리보기를 실행한다. 현업에서 선임자들이 항상 강조하고 강조하는것 중 하나인 하드코딩 하지 마라는 이유가 무엇인지를 포시에스는 전혀 모른다. 웃긴건 미리보기 창을 여는 로직은 파일 > 미리보기 밖에 없다. 하드코딩하기에 인력과 시간이 많이 필요한것도 아니고 고작 하나의 버튼으로만 호출되면서 하나의 기능만 수행하고 있는데 그걸 안고친다?? 그것도 시리즈 넘버링이 8까지 되었으면서 여태 이걸???

---

4. 최종결론적으로 HTML이 아니다

리포트뷰어가 매개가 되어 서버와 클라이언트간의 파일교환을 전제로 리포트를 출력한다. 교환 단위는 말할것도 없이 XML이다. 데이터 교환 방식 중에서도 비동기 서버요청이 대세가 된 시점에서 가장 무겁다는 이유로 외면받아온 XML을 아직도.

 

도대체 어떻게 프로그램을 짜고 어떻게 리포트뷰어를 마크업 했는지는 몰라도 리포트를 로딩하는동안 프로그래스 바가 진행되는 과정 중에는 무려 DevTools가 열리지 않는다!! 두가지 케이스를 가지고 예상할 수 있는데

 

1. 자바스크립트가 스크립트를 실행하는동안 지속적인 데이터통신이 브라우저 창을 응답없음으로 만들어버린 사례

2. HTML이 아닌 사례

 

그런데 요즘은 아무리 응답없이 심해도 DevTools가 열리기는 한다. 브라우저를 넘어 아예 프로세스 자체가 응답없음이 아닌 이상 어지간해선 열린다. 그런데 오즈리포트뷰어는 프로그래스 바가 나타나서 완전하게 로드가 종료될 때까지 철저하게 안열린다. 도대체 얼마나 빡센 프로세스를 진행하길래? 그것도 어플리케이션도 아닌 일개 웹페이지가? 그것도 자바스크립트로??

 

그런데 이미 정답이 나왔다. 프로그램은 먹통으로 만들어놓고 정작 프로그래스바는 아주 유연하게 잘 움직인다. 의도적으로 DevTools를 열리는것을 방해하는 장치가 있다는 것이다. 아니면 프로그래스바가 움직여야 할 순간에만 스크립트가 정지하고 움직인 다음에 다시 스크립트가 동작하는 방식을 사용할 수도 있었겠지만 정작 그랬으면 프로그래스바가 움직이는 찰나의 순간조차도 DevTools가 열려야한다. 즉, 차단이 아주 잘 되어있다.

 

HTML5에 이르러 샌드박스가 철저하게 잘 구현되어있는데 이 말은 웹페이지 자체가 얼마나 강한 락을 걸었는지에 상관없이 브라우저는 이 문서의 내부구조를 DevTools로 볼 수가 있다. 페이지에서 일어나는 어떠한 현상도 사용자의 컴퓨터에 환경간섭을 할 수 없고 브라우저의 사용자설정 또한 건드릴 수 없고 모든 웹페이지는 브라우저의 언더 컨트롤에 있어야 하는데 오즈리포트는 이 조건에 도전장을 내세운 케이스로 볼 수 있다.

 

즉, 미친놈들이다.

 

넥사크로도 마찬가지고 HTML5 까지 나왔는데 아직까지도 도전장을 내밀고있는 ......들이었다. 씨발 있는 그대로 좀 써먹으면 어디가 덫나냐 병신새끼들이. 애초에 사용법도 굳이 진행중인 프로젝트에 첨가만 하면 되는 형식이 아니라 톰캣같은 컨테이너가 있으면 아예 오즈리포트 전용의 컨텍스트를 하나 더 등록해서 사용하라는 말도안되는 형식이라는게 더 웃긴다. 굳이 앞서서 서비스하기 위해 시대를 타고 태어난 스프링이 저런 촌스러운 프로젝트에 계속 발목이 잡히고 개발시간이 잡히고 디버깅시간이 잡히고 개발운영간 환경차이 비교하는 시간이 발목잡힌다. PHP도 마찬가지였을 것이다. ASP도 마찬가지였을 것이다. 독보적으로 뒤쳐진 버전을 베이스로 열어야하는 저 쓰레기같은 솔루션이 아직도 현역이라고 생각하면 도저히 제 시간 안에 프로젝트를 완성할 수 없을거라는 위험한 불안감이 가장 먼저 몸을 꿰뚫는다.

---

5. 정신나간 오즈테크넷의 웹디자인과 질의응답게시판 레이아웃 & UX

말이 필요없다 직접 가서 보자.

http://oztn.net/(새창으로 열림)

 

상상초월을 체험하는 방법

1. 상단 검색바에서 1020030014 검색 후 OZ Report Q&A 를 클릭하고 페이지를 들어간다. (1020030014는 내부오류임을 뜻하는 오류코드이다.)

 

도착지에 제대로 도착했다면 여기서 가히 상상초월의 UX를 경험하게 될 것이다. 여태껏 한번도 본 적이 없는 게시판 모델이다. 다른건 다 넘어가고 3번항목만으로 5번문단을 채워보도록 하겠다.

 

1. 보통 HTML 기반으로 게시판을 짰다면 스크롤바가 생겨도 브라우저가 보여주는 HTML 바디 자체의 스크롤바를 통해 스크롤을 하는데 이 멍청한 게시판은 포스트를 보여주는곳 자체를 바디로 잠가놓고 그 안에서 스크롤을 돌리도록 해놓았다.

2. 거기다 포스트의 구성이 질문포스트 > 답변포스트 형식으로 되어있는데 이를 구분하기 위한 구분자가 [re]라는 텍스트가 제목에 붙는것이 고작이다. left padding을 따로 지정해준것도 아니고 색으로 별도지정해서 답변임을 확인할 수 있는 장치가 아니다.

3. 정신나간새끼임을 대변하는 정신나간 스크롤바

4. 질문을 올리려는데 프로젝트명 공개가 필수사항이다. 보안서약서도 서명하고 함부로 발설할 수 없는 프로젝트에서는 사실상 질문을 받지않겠다는 정책. 대충적어도 답변은 해준다고 넘어갈 생각이면 required=true는 왜 걸은 것이냐.

 

3번...... 정신나간새끼임을 대변하는 정신나간 스크롤바... 웃긴건 저 사이트가 검색을 하지 않았을 때의 게시판과 검색을 했을때의 게시판이 다르다. 무려 2개의 게시판이 있고 통상이냐 검색이냐에 따라 다른 게시판을 사용하고 있는데 유독 검색 게시판만 그지같고 병신같은 UI로 무장되어있다. 굉장히 숏한 스크롤바도 병신같은데 무려 게시판의 최상단을 보고있는데도 가운데에 위치한 스크롤바, 위 아래로 움직이려면 스크롤바를 위 아래 끝까지 움직여야하는 병신같은 인터페이스, 그냥 스크롤바가 아니라 스크롤 스위쳐(Switcher)에 해당하는 병신같은 컴포넌트다. 이것만 봐도 오즈리포트에서 다룰 수 있는 컴포넌트의 상태까지 예측이 가능하다는건 이쯤되면 과학이다.

 

게시판이 2개인 이유는 변명금지다. 매일매일 올라오는 질의응답글에 절대로 서비스가 지연되지 않고 신속함을 보이려는 눈속임용과 검색을 불편하게 만들어 자사 기술관련부서나 연구소에 일을 증량시키게 되는 루트를 차단하기 위함이다. 하나의 게시판만 만들어서 검색값이 포함되느냐 아니나 조건절만 붙이면 바로 조회되는 구조를 굳이 2개의 게시글로 만든것은 납득할 수가 없다. 저런 멍청한 게시판구조가 옛날구조이고 검색을 하지 않은 통상 게시판이 신규구조라서 어쩔 수가 없었다는 변명은 절대로 금지다. 신규게시판을 만들어놓고 구형게시판을 바꾸지 않았다는건 그냥 게시판작업하기 싫다는 뜻이다. 돈은 편하게 벌고싶고 우리는 신작 기술개발에만 전념할테니 라이센스비용을 지불하고 우리 프로그램을 사용하고싶으면 묻지말고 알아서 잘 헤쳐나가 해결하라는 노오오오력형 답변의 암묵적 정의이다. 다시 한 번 말하지만 변명금지다.

 

다른 개발자들에게 설문조사나 해봤나 모르겠다. 저딴 게시판 상태가지고 개발하고싶은 개발자가 있는지. 하나라도 제대로 막혀서 개발진척도가 0%가 되어버리는 순간부터 과연 개발하고싶은지. 솔루션부터가 생겨먹은게 10주년 Aniversary 이벤트에서 쉰내 나는것처럼 보이는데 도대체 그 기간동안 뭘 하고 뭘 장점으로 내세우는건지 도저히 이해가 안된다. 그조차도 물어보는거 제대로 찾을 수나 있으면 모를까 게시판도 통상게시판이 아니라 검색게시판을 적극 활용할텐데 본인이 쓴 글이나 제대로 찾게 도와주는것도 아니고 차라리 통상게시판에서 페이지 하나하나 훑어보고 넘어가는게 더 나을것 같은 거지같은 게시판 모델을 사용하는거면 도대체 왜 검색기능을 넣은건지도 이해가 안되고 이걸 개선할 생각조차 아예 안하는건지 진심으로 묻고싶다. 어플리케이션도 완성도가 개거지같아서 더이상 개발하기도 싫고 퇴사생각까지 할 정도인데 웹사이트도 이따구면 똑바로 할 생각이 없는거다. 분명 변명금지라고 했다 고쳤으면 진작에 고치고도 남을 사이트를 여지껏 방치한것인지 최근에 만든게 저 꼬라지인지는 몰라도 아는 웹사이트 제작 에이전시 업체 저렴하게 하나 소개시켜주고싶은 심정이다 전에 다니던 회사라고 문정동 테라타워에 ......가 있거든.

 

솔루션 만들어파는데 웹사이트 태클 걸지마라고? 내가 직접 웹사이트 취약점 진단 해줄까? 진단해서 나오는거 전부 다 여기서 까발라볼까?

---

6. 쓸데없는 기능에만 충실하고 정작 제대로된 기능은 적재적소에 하나도 빠짐없이 모두 빠져있는 얼탱이없는 기능구성

한번은 오즈 리포트라고 부르는 심각한 질병에 앓은 적이 있었는데 무슨 증상이었는가 하면 하나의 데이터밴드에 테이블을 넣고 그 테이블 안에 들어가는 데이터를 한정된 크기를 벗어나게 될 경우 초과된 텍스트를 잘라버리는 기능을 찾고 있었다. 그런데 그런 역할을 수행하기 위한 기능을 도저히 찾을 수 없어 무려 2일이나 시간을 허비한 적이 있었다. 같은 사무실에서 오즈리포트를 어느정도 사용해본 적이 있는 작업자조차 그런 기능은 찾아본 적 없어서 모르겠다고 방어하는 상황. 5번 문단에서 신랄하게 깠던 질의응답 게시판은 무조건 회원만이 글을 남길 수가 있어 사용하지 않기로 했다. 여기서 지정된 공간을 넘어가면 내용물을 잘라버리는 역할을 담당하는 기능의 이름을 유추하시오(3점)

 

정답은 클립핑 (드래그로 확인)

 

미친놈들이 Cut도 아니고 Truncate도 아니고 저딴 명칭으로 독자규격의 신화를 써내려갈 줄은 전혀 예상도 못했다. 오즈리포트를 사용하는동안에 반드시 명심해야하는것은 오즈리포트는 한글만 믿을 수 있다. 한글화는 절대로 믿어선 안된다 수준이다. 그래 Cut은 Ctrl X랑 겹친다고 생각해서 그렇다고 치자 저거는 도대체 어디서 나온 어휘냐 암만 생각해도 사무실에서 컴퓨터로 작업하다 클립이 보이기라도 하면 클립가지고 도대체 어떻게 본문을 잘라낸다는건지 이해가 안가서 하루를 어리둥절하게 보내겠다 아니 어원도 없어 역사도 없어 근본도 없어 개념도 없어 네이밍을 저따구로 지어내리라고는 설마설마 개발자들도 언어가 다르니까 상호간에 개념설명하는게 엿같아서 용어 통일시켜가는 와중에 아직도 점유율 파이만 이끌어내면 용어 좃꼴리는대로 바꿀 수 있다는 욕심 때문에 저러나 싶다

 

문서서식이니까 CSS같은건 절대로 할 수 없는것 정도는 안다. 그런데 왜 폭 높이에 %가 없는지는 이해할 수가 없다. 솔직히 말해라 그냥 돈 날로벌고싶은거지? 29.xxx 같은 최대가로폭을 굳이 마우스드래그도 귀찮아서 100% 하면 될 것을 굳이 저 수치 제대로 틀리지 않고 기억해서 매번 바꿀때마다 일일이 ,도 아니고 .까지 제대로 타이핑해서 컴포넌트 레이아웃을 마쳐야하는게 얼마나 고역적이고 이거때문에 다른데서는 금방 끝낼 작업 오즈리포트에서만 몇시간을 잡아먹는지 모른다. 이런 작업만 10페이지 정도밖에 안되는거라면 그냥 10분 정도지만 20장 분량에 장당 컴포넌트가 아주 많거나 하기라도 하면...

 

디자인 얘기는 여기서 끝내겠다. 어차피 깔 곳은 쿼리디자이너에서도 너무나도 많다. 쿼리 디자이너쪽에서도 문제가 비슷하게 보고된 것이 있다. 바로 패러미터 받는 부분인데 패러미터를 받을 때 타입을 지정하는 방법을 가능하면 타입 종류에 상관없이 모두 VARCHAR로 받을 것을 권장한다. number는 to_number(cast), date는 to_date(str_to_date)로 쓰는 수 밖에 없다. 쿼리디자이너에서 패러미터를 전달받아 쿼리문에 바인딩하는 ##문법은 설정을 통해 IBatis처럼 ##을 그대로 사용할 수도 있고 MyBatis처럼 ${} 으로도 바꿀 수 있지만 중요한 것은 여기서 어떤 패턴으로 신규정의해서 패러미터를 바인딩하든 실제 쿼리가 돌아가는 방법은 prepareStatement가 아니라 스크립트 방식을 따른다. 텍스트 안에 싱글따옴표, 더블따옴표가 있든 없든 그대로 반영해서 쿼리실행을 때려버린다. 충격적이다. SQL Injection의 희망(?)이 보인다.

(2020.04.11. 일자 확인결과 비권한자도 ID값만 알면 얼마든지 권한여부에 상관없이 조회가 가능하다. 이를 막으려면 기존 프로젝트가 DB에 접속하는 DB커넥션과 별개의 조회전용 DB 접속 어카운트를 별도로 관리해야한다. ID값을 알아내는것 자체가 말이 안되지만 스프링 시큐리티가 적용된 관공서 기준 프로젝트만 해도 이런 취약점이 나와서는 안된다. 실제로 관공서 프로젝트 중 보안취약점 점검에서 걸리는 항목이다. 한가지 사족을 달자면 사용하겠다는 계약 때문에 보안취약점 점검에서 빼주는거지 오즈리포트 사용하는것 자체가 톰캣 JSP 방식을 사용하는 것이기 때문에 스프링 프레임워크 환경 구축 조건 자체에서 '심각'등급으로 걸러진다.)

 

에러관리도 엉망이다. SQL에서 문법에러가 난 것인지, 타입 캐스팅 에러가 난 것인지, 패러미터 연결과정에서 타입 캐스팅이 미스난 것인지, 패러미터 연결과정의 오타문제인지 구체적인 내용을 일절 알려주지 않는다. 가장 흔한 내부 쿼리실행에러인 1020030014조차도 너무 포괄적이라 그냥 상당시간 할애해서 무엇이 문제인지 직접 찾는 수 밖에 없다. 그리고 십중팔구 숫자만으로 이루어져있는 String 패러미터를 분명히 VARCHAR로 지정했음에도 불구하고 멋대로 Int로 캐스팅하는 문제가 있다. Select #result# from dual 해놓고 result에 "1"을 넣었는데 리턴 결과가 Number 1이 반환되는거. 씨발 개발자가 하라는대로 움직이는 프로그램 만들면 직원한테 주는 월급이 덧나냐 무슨 프로그램이 이것 하나 저것 하나 할 때마다 프로그램이 개발자한테 덤벼들어 뭐하자는거야

 

분명히 preparedStatement 안쓰고 패러미터를 key=value 형식으로 넘겨주는대로 replace나 replaceAll 하니까 저렇게 되는거지 쿼리를 질의어가 아니라 스크립트로 쓰는 수준이 개인도 아니고 회사가 가지고있는게 현실이라니 하다하다 정말 끔찍하다 두뇌가지고 사회를 지켜가면서 살아가는 현대사회 인간들을 인터넷 또라이 멍청이로 만들어가는 페이스북의 존재보다도 저게 훨씬 더 끔찍하다. 무슨 더 월드야 시간의 흐름이 멈췄어 도대체 돌아가는게 몇년전 메커니즘이야 아니 도대체 언제까지 개발자가 number타입 varchar타입 하나하나 맞춰가면서 쿼리문을 동적구성해야하는데 쓸데도 없는 디자인모드같은걸 아직도 세일즈포인트로 내세우고자빠졌고 동적쿼리 하려면 쓸데도 없는 고물상에서도 돈주고 처리해달라 해야 할 오즈스크립트나 공부해야하고 뭐 이거 포시에스왕국 입국심사냐 이게

---

7. 극악의 발적화와 왜있는지 모를 구성요소

본격적으로 왜 쓰는지 알 수 없는 솔루션. 웹서비스에 붙여서 쓰는데 어떤 형태의 웹서비스가 되었건 복창터지는 답답한 속도를 자랑한다. 위에서 언급했듯이 기본적으로 32비트 프로그램이라는점부터 가장 치명적인 설계미스, 그런데 아마 하는 꼬라지 보니 몇년씩이나 같은 실수를 반복한 것 같다.

 

이 속도문제가 가장 두드러질 때가 언제냐면 똑같은 서식으로 2장 3장 n장으로 구성되어있는 상태에서 모든 페이지에 똑같은 컴포넌트들에게 동일한 수정을 취해줘야 할 때. 수정을 적용하기 위해 각 페이지를 호출하는것조차 눈뜨고 봐줄 수가 없을 정도로 꼴불견수준의 속도를 자랑한다. 혹시나 페이지 수가 꽤 많아 초기 로딩부터 고생 좀 해야할 것 같은 파일이라면 그날로 업무는 끝장이다. 30장이면 초기로딩이 10분까지 지나가버릴 수 있다.

 

리포트디자이너도 저 꼬라지인데 쿼리 디자이너라고 예외일까? 이쪽도 만만치 않다 쿼리셋이 많으면 이쪽도 곡소리 혹은 비명이 들린다. 현대적인 컴퓨터에서 무려 윈도우 95시절의 속도가 나온다!!!

 

거기다가 이상한 구조를 가지고 있는 탓에 정말 답이 없기로는 전설적인데 쿼리디자이너에서 쿼리에 수정이 발생했을 경우 쿼리 디자이너에서 반드시 쿼리를 1회 실행해야한다. 그러지 않으면 쿼리를 수정했는데도 이전의 리절트셋 형태와 호환이 되지 않는다는 멍청한 오류를 내뿜는다!! 왜그런가 싶어서 확인을 해봤더니 쿼리디자이너 역시 XML 기반의 데이터로 관리를 하는데 쿼리는 쿼리대로, 컬럼정보와 데이터타입은 쿼리를 실행한 결과값을 기반으로 XML에 새로 다시 작성하는 방식을 취하고 있다. 그러니까

 

SELECT 
    'VAL1' AS KEY1, 
    'VAL2' AS KEY2, 
    'VAL3' AS KEY3 
FROM 
    DUAL

 

를 돌려서 KEY1, KEY2, KEY3 이라는 메타데이터를 가지고 있는데

 

SELECT 
    'VAL1' AS KEY1, 
    'VAL2' AS KEY2, 
    'VAL3' AS KEY3, 
    'VAL4' AS KEY4 
FROM 
    DUAL

 

와 같은 형식으로 리절트셋의 형식이 달라지는 변화가 생기면 이 쿼리를 반드시 1회 실행을 해줘야 쿼리디자이너의 XML값에 컬럼정보가 새로 갱신된다는 뜻이다. 저렇게 단순한 쿼리라면 저까짓거 그냥 할 수도 있겠지만 만약에 패러미터의 존재여부에 따라 동적으로 WHERE 검색조건이 추가되거나 형태가 달라지는 등의 아주 복잡한 쿼리라면? 패러미터의 존재유무에 따라 각 컬럼에서 검색조건을 천차만별로 달리 할 수 있다면? 동적 변수를 쿼리에 반영하는 구간이 너무 많아 쿼리를 실행하기 전에 패러미터를 임의바인딩하는 소요시간이 더 길다면? UNION 쿼리라면???

 

어찌저찌 해서 겨우 쿼리를 완성해냈다고 해도 리포트디자이너에서 새로 파일연결을 갱신해줘야 한다. 쿼리디자이너만 새로고친다고 끝이 아니다. 거기다 오즈리포트를 바닥으로 내다꽂아버리는데 전혀 주저할 필요도 없는 결정적인 쓰레기가 바로 여기서 나타나는데, 기존에 존재했던 컬럼이 만약 이름이 바뀌기라도 한다면 기존에 리포트디자이너에서 할당되었었던 모든 공간들의 데이터바인딩이 일괄 해제된다!! 무슨 말인고 하니 

 

KEY1	KEY2	KEY3
VAL1	VAL2	VAL3

 

와 같이 이미 리포트 서식이 완성되어있는 경우 만약에 'KEY3'이라는 열의 밸류 이름이 바뀌기라도 하면 (예를 들어 'KEY03'으로 바뀌기라도 한다면) 모든 테이블과 고정테이블, 차트에서의 데이터바인딩이 보기좋게 해제된다!! 왜인고 하니 식별자가 프로그램에서 식별하기 위해 생성하는 id값을 사용하는게 아니라 이름 그 자체를 식별자로 사용하고 있기 때문이다!!! 국산 프로그램 수준... 이룸 바꾼다고 식별정보를 못찾는다.

 

테이블을 사용하게 될 경우 테이블에 적용시킬 수 있는 프로퍼티 중에 '페이지 넘기기'라는 기능이 있는데 이 기능의 설명은 프로그램 내부에서도 쉽게 찾아볼 수가 있다. 다음 테이블이나 데이터셋이 등장하게 되는 경우 다음 페이지에서 출력한다는 기능인데 이거 그냥 새로 리포트 페이지 만들어서 거기에다가 새로 테이블 세팅하면 된다 뭐하러 프로퍼티로 쉽게 구현할 수 있는걸 남겨놨는지 이해할 수가 없다. 정작 고쳐야할것들은 냅두고 저런 쓸모없는 기능만 역사의 한 켠을 차지했으리라 생각하니 정말 사람 지능이 높고 낮음에 따라 일어날 수 있는 사건의 격차가 너무 잔인하게 크다는 현실에 너무 충격을 받을 지경이다. 이쯤되면 저정도는 그냥 문닫는걸 넘어서 지능이 없다고 봐야지......

---

8. 철저하게 전자정부프레임워크와 따로노는 개발환경

오즈리포트 하나를 프로젝트에 세팅해 연동을 하려면 톰캣기반인 경우 하나의 컨텍스트에 기존 프로젝트와 오즈리포트 컨텍스트를 묶어서 배포하는것이 불가능하다. 톰캣 컨테이너 설정에 별개의 컨텍스트를 하나 더 신규로 등록해야하고 기존 프로젝트와 도메인 포트가 동일해야한다는 조건 하에 새로운 컨텍스트를 파서 거기에 오즈리포트를 연동시켜주는 형식으로 사용하는것이 일반적인 사용 방법이다.

 

바로 이것 때문에 개발자의 치신경과 치열이 뒤틀리는 어마어마한 스트레스를 받는다. 스프링 프로젝트는 스프링에서 감당되는 모든 오류를 끝까지 스택트레이스하고 어디에서 어떤 유형으로 에러가 발생하는것인지 반드시 추적할 수 있지만 이 개같은 오즈리포트는 무려 설치가 아닌 연동이라는 함정 때문에 어떤 에러로그와 에러리포트를 받아볼 수 없다. 확인하려면 오즈리포트의 쿼리디자이너 또는 리포트디자이너에서 로컬서버로그 보기 기능을 이용해서 별개의 메모장 파일에 기록된 히스토리를 보는 수 밖에 없는데 철저하게 이클립스와 스프링 프레임워크의 손을 떠나있다. 그렇다고 PHP에서 확인이 가능한 로직이냐. 그것도 아니다. PHP도 로그기록 보는건 아예 별개의 작업이다.

 

작업이 순수하게 합쳐지지 않고, 그렇다고 억지로 하나로 볼 수도 없는 기묘한 기능과 존재목적 때문에 하는 작업량만 2배, 디버깅효율은 1/200 수준으로 떨어져버렸다. 애써 잘나가던 개발 오즈리포트가 남은시간을 전부 다 증발시켜버릴 수 있기 때문에 리포트작업에 들어가기 앞서 기존에 하던 작업은 최대한 신속하고 시간적여유를 많이 확보한 다음에 들어가야한다. 그렇지 않고서는 리포트작업이 기존작업을 마치지도 못하게 만들고 최종점검을 완전히 망쳐버릴것이다. 고객한테 시연하는 자리에서 개쪽당하고싶지 않으면 아예 오즈리포트는 요구사항을 정리하는 단계에서 아주 단호하게 선을 그어야한다.

 

여기까지가 꽤 순하게 한 설명이다. 이제부터는 어떠한 개발자도 참을 수 없는 현실에 대해 얘기하고자 한다.

 

도대체 왜 이걸 할까. 요즘 관공서 프로젝트는 전자정부프레임워크를 기반으로 요구하고, 그렇지 않아도 국내 IT는 기간상 정리마감수순에 접하는 PHP를 빼고는 상당수 스프링프로젝트를 기반으로 돌아가는데 이거 한다고 과연 개발자들 커리어가 쌓일까? 전혀 안쌓인다. 솔루션 자체가 스프링이 아닌 톰캣 JSP 기반이고 이거 하나 제대로 이해하는데 어마어마한 시간이 들어간다. 내가 할 일도 많은데 더러운 소스코드 사용법까지 전부 숙지해야한다. 말할 것도 없는 오즈스크립트가 대표적이다. 연동을 시킨다 한들 만지는건 고작 리포트 뷰어.jsp 파일이 유일한데 그 안에서 손대는건 html도 아니고 그냥 자바스크립트다. jsp라고 스크립틀릿 쓰는것도 아니고 그냥 자바스크립트만 만진다. 그리고 .odi 파일과 .ozr 파일은 위에서도 말했듯이 프로그래밍도 아니고 코딩도 아닌 문서서식. 거기에서 쓰는걸 기껏 쳐줘봐야 SQL이 고작. 오즈스크립트는 한번이라도 만져본 적이 있다면 반박할 수 없을 것이다. 단 1도 생산성이 없는 거지같은 스크립트이자 존재목적이 완벽한 프로그램의 작동이 아닌 그냥 고객이 요구사항을 몇개 더 추가하는 만족 충족용에 불과하다는 것을. 그 어느 누구도 반기지 않고 그냥 이런 기능 있으면 이런거 저런거 자질구레한거 몇개만 더 수정해주시면 안돼요? 하면서 그냥 일하는 척을 제공하기 위한 탁상행정용 스크립트라는 것을.

 

하는사람들도 몇번씩은 생각해봤을꺼 아닌가. 이게 커리어에 도움이 되는지. 생각한 적이 한번이라도 있는 개발자들에게 묻는다. 그런 생각 할 만한 가치가 있는 프로그램인가? 그냥 이건 오즈리포트 만들고 포시에스가 자기만족에 딸치는 프로그램밖에 안되잖아. SQL을 스크립트처럼 다루는 탓에 변수바인딩에서 타입이 안맞는다는 오류를 수십번 목격한 사람들, 패러미터 이름에 오타 없이 잘 쳤는데 알고보니 .odi 파일에서 패러미터를 받기로 한 정의에서 누락되었거나 뷰어 jsp파일에서 패러미터를 넘겨주기로 코딩되어있지 않는 상황에 이마 탁 친 사람들, 1020030014번 해결못해서 하루 날렸던 사람들 합치면 100.0%일꺼 아냐? 실수형으로 치면 100.00000000000001% 나오겠네

 

거기다 이클립스 사용하는사람들은 분명히 파일을 수정하고 이클립스가 파일 변경을 감지해서 자동배포해줄 줄 알았는데 끝까지 배포를 안해서 버전관리에 낚여서 수정헛탕만 수십번을 친 사람들도 있을테고. 복수경로에 존재하는 파일들 하나하나 열려고만 하는것조차도 리포지토리 경로가 다르다고 이곳 저곳 설정하다보니 파일관리가 엉망이 되어버린 적도 있을테고. .odi 파일 수정했는데 .ozr 파일에서 변경점이 반영안되서 수정이 수십번 누락된 적도 있을테고 컴포넌트 특히 테이블에서 각 셀 한칸마다 컴포넌트 이름 지정도 안하고 바로 사용할텐데 몇몇개 컬럼명 바뀐다고 데이터바인딩이 어긋났다는데 TableValue01 TableValue02 이것들 바인딩 바로 잡으라는 오류에 도대체 어디에서 터진건지 헤멨던 사람들도 분명히 있을텐데 경험이 있는 사람이 아니라 그런적 단 한번도 없다는 사람들을 찾는게 더 빠르겠다 셀 다중선택해서 폭을 동일하게 하는것조차도 한번에 클리어가 안되고 그놈의 컴포넌트는 한번 클릭하면 바로바로 반응하는것도 아니고 기어이 뭐 CPU 뺑글이를 몇바퀴를 돌리는지 1초인지 1.2초인지 2초인지 일일이 세게끔 더럽게 느려터진 퍼포먼스며 기능이 똑바로 돌아간다 한들 시간문제는 또 어쩌자고. 기업의 이윤창출에 시간이 달려있는거 아나 모르나 지들이 만드는 프로그램이 그렇게까지 발목을 잡는데 도대체 시리즈 넘버링이 올라가는동안 이부분 손 안보고 뭐한거야?

 

여태껏 개발의 주 목적이 도대체 뭔지 한번도 생각 안했나? 복잡한 과정 오류 없고 신속하고 신뢰성 있게 빨리 처리하려고 여태 어셈블리 알골 코볼 하스켈 C언어 자바 여태 이렇게 발전해왔더니 뭐 오류뜨는건 니잘못입니다 불만있으면 바이너리 수정 해볼테면 해봐라 덤벼드는 프로그램이 개발자한테 도발하고 도전장을 내미는데 왜 쓰는지 진심 모르겠다. 이정도면 치신경 치열 망가지는게 당연한거지 정작 중요한 프로그램을 놔두고 여기에 더 몰두해야할 프로그램같으면 애초에 도입도 안하는데. 오즈리포트하는 사람들 댓글로 이야기나 한번 해봐요 국내에서 리포팅 툴 중에서 그나마 쓸만하다는 수준이 도대체 퓨어 자바를 개발하는것에 있어서 어느정도의 노동력이 필요한건지. 내 기준에는 퓨어 자바로 뭔가를 개발하는것보다 한 600%는 더 시간을 투자해야할거 같은데.

---

시간과 비용의 문제를 최대한 획기적으로 줄이고 신뢰도를 극한까지 올려 정보화사회의 서막을 열었더니 이 프로그램은 그 시절에서 완전하게 멈춰있는것을 알 수가 있다. 여태 프로그램의 개발방향과 프로그램의 존재의의조차 완전하게 잘못되어있는 프로그램이라는걸. 개발편의와 성능향상에 포커스가 없어도 1도 없는 잘못된 방향인데다 그 방향성이 개발자가 늙어뒤지든 혈압올라뒤지든 1도 신경안쓰고 그냥 최종사용자 고객들이 pdf기능 추가해주세요 보안기능 추가해주세요 이딴거 요구사항만 골라서 받느라 점점 개발자에게 하중되는 개발피지컬이 낭비만 되고있고 그마저도 GUI라도 손봤으면 모를까 도구 하나하나에 마우스를 올려 툴팁내용을 보면서 무슨 기능인지 확인하고 쓰려고 해도 어처구니 없게도 툴팁에 기능명만 있지 기능 설명은 전혀 없다.

 

그뿐이랴. DB커넥션을 만들어서 쿼리를 조회하는것조차도 너무 느려터졌다. 하다하다 이클립스에서 .sql 파일을 만들어서 각 쿼리마다 커넥션을 따로따로 만들어서 실행하는것보다도 훨씬 느려터졌다. Class.forName 방식으로 오즈리포트에서 일일이 만들어서 연결을 확인하고 그 정보를 가져와 XML형태로 내부가공해서 사용하는것은 사실상 확정이지만 그걸 감안해도 너무 느린데다가 프로그램 내에서 일체 자동화된 기능을 제공하지 않는다는점을 보면 도대체 이게 지금 시대에 쓰는 프로그램이 맞나를 수십번 수백번을 의심하게 만든다. 두 말 안하고 마우스 없으면 개발 못하는 쓰레기 프로그램이다. 접근성은 개판이요 편의성은 호박엿이요 기능성은 구멍난양말이요 완성도는 두꺼비집이요 이따구로 돈을 받아쳐먹는 포시에스가 프로그램에서 로직 하나 수정한거가지고 딸치는 느낌은 딸근 하나로 장미란 뺨치는 역도선수나 되시겠다.

 

개발 수준이 저따구인데 무슨 수로 개발자들에게 솔루션이라고 다가오는걸까. 염치라도 있으면 국내 1위라는 수식어도 안달겠다 현실을 알면 우리 툴 쓰기 힘들긴 한데 그래도 리포팅 툴 필요하면 이거라도 좀 써주시면 안될까요 굽신굽신해도 모자랄 새끼들이 무슨 정신나간새끼 마냥 점유율 1위를 논하고 엔터프라이즈를 논하는거야 변할 줄 모르는 새끼들한테 과연 존중과 감사가 필요할까

 

아, 이 글을 마치면서 마지막으로 경고하는데 치신경과 치열이 망가질 것을 반드시 각오하라. 입에 쌍욕이 붙는것가지고 끝나는 레벨이 아니다. 수준이 떨어져도 너무 떨어진다. 쓸 이유가 없고 그냥 리포트를 HTML 기반으로 프린터에 기본 스풀링 맡겨버리고 보이는대로 그냥 브리핑하라고 하는것이 훨씬 더 HTML5 표준적이고 인쇄용지 낭비도 덜 하시겠다. 현대사회에서 조금이라도 지성인으로 남고 사회에 헌신적으로 남고싶으면 민폐나 끼치는 그 체질부터나 고치고 시작하라고 진심으로 말해주고싶다 왜 존재의의를 너네들이 아니라 개발자가 찾아줘야하는건데