-타울- 아는만큼 보인다.

flex 를 추억하며

타울 — Wed, 17 Dec 2025 11:18:51 +0900

오랜만에 Flex 카테고리에 글을 남기는 것 같다.

참 기억이 많이 나고, 추억도 많은 녀석이다.

처음 Flex 의 데모 사이트에서 유기적으로 움직이던 컴포넌트를 보고 받은 충격은 아직도 잊지 못한다

서버의 데이터를 실시간으로 화면에 보여주는 기술과, 마음대로 만들고 표현할 수 있는 그리드의 렌더러,

완벽하게 구현된 리치인터넷 환경...

동일한 코드를 데스크탑에서 실행 가능토록 Adobe Air... 그야말로 만능이었다.

(하지만 스마트폰에서는......)

이것이 한때 미래의 웹 기술이 될 거라는 확신이 있었고, 삽질도 정말 많이 했다. (몇 일 밤낮으로 고생을 했는지..)

개인적으로는 정말 애정이 많았고, 미련이 남은 기술이지만

여러가지 이유로 Flex 가 점차 사라지면서..나의 개발자로서 열정도 사라졌다.

심심해서 당시 데모사이트나, 이것저것 찾아봤는데.. 현재는 정말 볼 수 있는곳이 없어서 아쉽다 ..

AI 와 오랜만의 개발

타울 — Mon, 29 Sep 2025 10:21:14 +0900

자바 개발을 개빡쌔게 짧고 굵게 si 으로 4년정도 했었다...

그때는 모두 메뉴얼 또는 구글신과 네이버 형에게 도움을 받는게 최선이었고, 안풀리는 문제가 발생하면 수백건이 검색 된 검색 결과를 모두 참고하며 해결했다.

그리고 개발을 하지 않은지 언 15년이 훌쩍 지났고..

어느날 자바도 아니고, C# 으로 사내시스템을 만들어야하는 상황이 발생했다.

db모닝점검을 자동화하는 것을 구상했는데,

일단, 대상서버 등록, 점검항목(쿼리만), 대상서버와 점검항목 연결, 결과보기

이렇게 기능을 정의하고, 개발을 시작하려는데, 너무나 막막했다.. ㅋㅋ 자바도 아니고 c# 이고, 개발을 하지 않은지 15년이 지났으니, 당연했다.

다른 활용하는 방식이 많던데.. 내부 시스템은 인터넷이 안되고, 아직 회사에서 이런걸 지원하지 않는 상황이니.. git 이나 IDE 등에 연동은 하지 못하고, 인터넷이 가능한 PC 에서 ChatGPT 에게 질문으로만 개발을 시작했다.

그런데 이런 세상에 ㅋㅋㅋ 뭐 그냥 코드를 이해할 필요가 없다. (당연히 이해하면 좋다.)

다 만들어준다 ㅋㅋ

그리고 한달도 안된 상황에서 C#, RAZOR 구성으로 뚝딱 만들어졌다 ㅋㅋㅋ

내침김에 , mssql 의 일자별 스케쥴러 실행 이력을 gantt 차트 형식으로 보여주고, 해당 bar 를 누르면 과거 소요시간 추이도 그래프로 보여주는 화면도 개발했다.

상태에 따라 필터링을 하는 것도 javascript 화면단으로 처리 했다.

gantt 차트도 좋은 라이브러리 없나 조금 구글신을 돌려보다가, 그냥 GPT 를 통해 만들어버렸다. 와아... ㅋㅋㅋ

15년전 개발할때는 이렇게 간단하게 할수 없었고, 시도조차 하기 어려운 일이었다.

지금 해당 코드의 50% 이상을 이해하지 못한다 ㅋㅋ(솔직히 보지도 않았다.)

하지만, 잘 돌아가고 있다!! 그럼 된거다 ㅎㅎ

돼지 목에 진주 목걸이..

타울 — Tue, 8 Jul 2025 13:37:25 +0900

지금 다니는 회사에 이직한지 2년정도 되었는데, 시스템 중에 업무관리를 redmine 을 사용하고 있어서 반가웠다..

redmine 이 한물 가긴 했지만, 많은 곳에서 여전히 유용하게 사용된다.

하지만 얼마되지 않아 드는 생각은... 여기에 누가 도입 하자고 했을까? 라는 궁금증이 생겼다

여기 분위기를 봤을때 도저히 불가능한 일이기 때문이다. ㅋ

일단... Remine 을 제대로 활용을 거의 못한다...할 생각이 없다 ㅋㅋ (메일로 사용방법에 대한 팁을 공유해도 소용이 없다.)

나중에 알아보니 개발팀에서 도입한것도 아니다. (심지어 외부 업체를 통해 설치를.... ㅋㅋ)

이왕 설치해줄거면 git도 연동해주지.여튼 소스 관리도 팀마다, 프로젝트마다 제각각이었지만 겨우 git 으로 통일 되는중이다. ㅋㅋ

일단.. 대부분 개발자가 사람들이 스크립트를 그냥 올린다. wiki 문법으로 표시되어 알아볼수가 없지만 다들 별로 신경쓰지 않는다.

하지만 이런 문제는 애교수준이다.

시작일자와 종료일자 관리가 안되서, 업무의 일정을 전혀 알 수가 없다. 종료 시키지 않는 일감도 수두룩 하고..

담당자를 바꿔가며 사용한다.(소요시간 기능을 사용한다면 괜찮겠지만.. 단 한명도 본적이 없다 ㅋㅋㅋ )

상황이 이래서 본인이 어떤 업무에 어떤 일을 했었는지. 그리고 얼마만큼의 시간을 소요 했는지 전혀 알 수 없다...

이런 상황인데. 꾸역꾸역 사용은 하고 있다 ㅋㅋㅋ

이 와중에 jira 를 도입했으면 좋겠다고 말하는 사람도 더러 나왔다. (redmine 도 제대로 못쓰는 마당에 jira 를??...)

갑자기, 업무관리를 한다며, 별도 프로그램을 만들고 있다 ㅋㅋ

그런데 이 프로그램 동작 방식이 신박하다 ㅋㅋ

redmine의 일감 번호를 프로그램에 등록한다. 그리고 시작일 종료일, 소요시간, 담당자를 다시 입력하도록 하는 프로그램이다..

사람마다 redmine 사용법이 달라서 만든다는데.. (심지어 개발자가 5-6 명이 몇 개월째 만들고 있다 ㅋㅋ)

너무나 신박하지 않나? ㅋㅋ redmine 표준 사용법을 교육하는게 더 낫지 않을까?? ㅋㅋㅋ

redmine 을 잘 써보자고 방법과 함께 전체 메일도 보내봤지만, 그 어떤 리더도 움직이지 않는다 ㅋㅋㅋ

아무리 봐도 이건 리더들이 가장 큰 문제다 ㅋ

사내 위키사이트를 갑자기 만들고 오픈하더니 위키에 모든 것을 정리하라고 한다..

난 이미 redmine 위키에 이것 저것 정리를 엄청나게 했는데..

.(redmine 위키도 나 혼자 썼다, 더군다나 여기에 정리하고 있으면 그걸 왜 정리하냐는 사람들이.... )

redmine 만 제대로 사용해도 될 일들을 만들어서 하고 있다 ㅋㅋㅋ

더군다나 업무의 연장성을 본다면 redmine 만 사용하는것이 훨씬 좋은 선택일텐데...왜 이러는지 모르겠다..

최종 목표는 redmine 을 걷어 내는게 목적이라는 말도 들리던데.... 왜?

나의 이 회사 생활은 redmine 의 운명과 같이 할 것 같다 ㅋㅋ

PostgreSQL collation 설정(대소문자/악센트/전각반각 등, 정렬순서)

타울 — Thu, 20 Oct 2022 19:40:27 +0900

추가내용,..

LIKE 검색이나, 문자열 함수 등을 사용이 불가능해집니다.

PostgreSQL 에서 Collation 관련 이슈..

https://www.postgresql.org/docs/current/collation.html : PG 메뉴얼

https://www.unicode.org/reports/tr10/ : Unicode® Technical Standard #10

https://unicode-org.github.io/icu/ : ICU 문서

https://webcache.googleusercontent.com/search?q=cache:W2Mex4SS0ygJ:https://postgresql.verite.pro/blog/2019/10/14/nondeterministic-collations.html&cd=1&hl=ko&ct=clnk&gl=kr

PostgreSQL 에서는 대소문자 등 구분하는 문제로 엄청 골치아펐는데.. 알고보니.. 컬레이션을 지원한다!!!!
오히려 컬레이션에 관해서는 maria나 ms 보다 비교도 안되게 많은 것을 지원하는것 같다.. (힌트는 진짜 지원하지 않는다 ㅋㅋ. )...
수많은 곳을 검색하고 메뉴얼대로 해도 안되서, 포기하고 있었다..

수많은 곳에서 ilike 또는 upper 와 FBI 만 알려주고. 메뉴얼대로 해도 안되서 반포기상태였다.(오죽했으면 1년만에 티스토리에 로그인을 해서 글을 남기고 있다.....)

ilike, upper, fbi, mapping 방식들은 계속 검색이나 성능 문제들이 계속 나올것이고.. (꼼수를 쓰면 계속 발목 잡힌다..)
글로벌 서비스인경우 악센트, 전각반각, 일본어(히나가라/카나)는 해결할 수 없다. (다른 dbms는 모두 컬레이션 설정을 통해 설정할 수 있다.) .. 단순하게 공백 문자만 봐도 종류가 한두개가 아니다..

하지만.. 결론은.. PG 도 다른 DBMS 와 마찮가지로 컬레이션을 설정할 수 있었다!!!! .(지금 너무 멀리와버렸는데... 큰일났다 진짜.... 진심.... )
(왜 메뉴얼대로는 안되는지 모르겠지만..이 부분은 더 확인을 해야한다..)

아래 테스트는 편의상 컬럼단위로 설정했지만.. database 또는 스키마 단위로 설정이 가능할것이다.

먼저 메뉴얼에 있는 예시는 아래와 같은데.. 이건 내 환경에선 안된다... ..

CREATE COLLATION case_insensitive (
provider = icu,
locale = 'und-u-ks-level2',  
deterministic = false
);

그래서 다시 찾은게 있는데...

요기서 찾은대로 하니깐 된다... (https://dba.stackexchange.com/questions/255780/case-insensitive-collation-still-comparing-case-sensitive 왜 이런 중요한 내용이 메뉴얼엔 없을까??)

>> 하지만.. 메뉴얼대로 하는게 더 많은 것을 지원하는같다.. 더 찾아봐야 함.

CREATE COLLATION collat_ci2 (

provider = 'icu',
locale = '@colStrength=Primary',
deterministic = false
);

UTS10-D4. Primary Weight: The first collation weight in a collation element.

A primary weight is also called the Level 1 weight. Level 1 is also abbreviated as L1.

UTS10-D5. Secondary Weight: The second collation weight in a collation element.

A secondary weight is also called the Level 2 weight. Level 2 is also abbreviated as L2.

UTS10-D6. Tertiary Weight: The third collation weight in a collation element.

A tertiary weight is also called the Level 3 weight. Level 3 is also abbreviated as L3.

UTS10-D7. Quaternary Weight: The fourth collation weight in a collation element.

A quaternary weight is also called the Level 4 weight. Level 4 is also abbreviated as L4.

Table 2. Comparison Levels

Level Description Examples
L1 Base characters role < roles < rule
L2 Accents role < rôle < roles
L3 Case/Variants role < Role < rôle
L4 Punctuation role < “role” < Role
Ln Identical role < ro□le < “role”

레벨에 따라 설정것이 다른것 같은데... 일단 가장높은 단계로 설정하니 모든게 해결된다..

테스트 코드

CREATE COLLATION collat_ci2 (

provider = 'icu',
locale = '@colStrength=Primary',
deterministic = false
);

CREATE TABLE names(
first_name varchar(10) collate collat_ci2,
last_name varchar(10) collate collat_ci2
);

insert into names values
('Anton','Eggeｒ'),
('Anton','EggeＲ'),
('Berta','egger'),
('Berta','egger'),
('Conrad','Egger');

insert into names values
('Anton','cote'),
('Anton','coté'),
('Anton','côte'),
('Conrad','côté');

조회결과

select * from names where last_name= 'egger'

first_name last_name
Anton Egger
Berta egger
Conrad Egger
Anton Eggeｒ
Anton EggeＲ

Select * from names where last_name= 'cote'
first_name last_name
Anton cote
Anton coté
Anton côte
Conrad côté

공백(whitespace) 대한 언급이 있지만, 뒷공백 무시에 대한 이야기는 아닌것 같음.
- 다른 dbms의 경우 varchar 타입일때 뒷공백이 제거되는데, pg 는 text 타입으로 생성되면서, 뒷공백이 무시되는건 아닌것 같음.. 하지만 더 찾아보면 될수도 ㅋㅋㅋ

정렬순서

pg 메뉴얼에 정렬순서도 바꿀수 있는 옵션이 있음. 예를들면.. 소문자가 대문자보다 먼저 정렬순서를 바꿀수 있다던지...
dbms 를 변경하고, 정렬순서가 달라진다는 민원을 해결할 수 있을까? ㅎㅎ

내용추가...

그런데 like 검색은 안된다?????? 아... PG놈들 ... 만들다 말았네...

https://stackoverflow.com/questions/71663281/postgresql-case-insensitive-and-accent-insensitive-search

이와 관련된 블로거 게시글

https://www.cybertec-postgresql.com/en/case-insensitive-pattern-matching-in-postgresql/

[PostgreSQL] Sequence의 조금 다른 Cache 특성.

타울 — Wed, 1 Dec 2021 17:32:59 +0900

시퀀스의 cache 설정은 세션레벨에서 동작 함.

즉, cache 100 으로 설정했을때,

1번 세션에서 nextval하면 1이 표시되고

2번 세션에서 netxtval 하면 101 이 표시된다...

메뉴얼에는 관련내용을 cache 쪽에 설명을 하지 않고 notes 에 남겨놨다..

Unexpected results might be obtained if a cache setting greater than one is used for a sequence object that will be used concurrently by multiple sessions. Each session will allocate and cache successive sequence values during one access to the sequence object and increase the sequence object's last_value accordingly. Then, the next cache-1 uses of nextval within that session simply return the preallocated values without touching the sequence object. So, any numbers allocated but not used within a session will be lost when that session ends, resulting in "holes" in the sequence.

https://www.postgresql.org/docs/9.5/sql-createsequence.html

PostgreSQL Partition 과 plan_cache_mode 파라미터.

타울 — Wed, 1 Dec 2021 17:21:16 +0900

테이블에 리스트 파티션을 약 8000여개 생성 (이렇게 사용하는곳이 없을줄 알았는데..우리가 이렇게 씀.)

현상

Loop 등을 수행하는데 5-6 번째에서 한참동안 멈춰있다가 실행 또는 db 비정상 종료 됨.
메모리가 계속 증가

이슈1

쿼리를 작성할때 파티션 테이블의 파티션 기준에 대한 조건이 항상 있어야 함.
후행 테이블일때 조인 조건으로 받아먹는건 의미 없음(비결정적으로 판단하여 모든 파티션을 읽는 실행계획이 생성됨)
메모리 사용량이 계속 증가하는 현상과 함께 심한 경우 db 가 비정상종료되는 경우도 발생함.

이슈2

모든 파티션 조건을 추가해도, 같은 쿼리가 여러번 (5-6)수행되면, 내부적으로 실행계획을 재사용하기 위해 플랜을 생성하게 되는데, 이때 또 이슈 1과 같은 현상이 발생 함.
해결하기 위해 환경변수를 설정해야 함. set plan_cache_mode = 'force_custom_plan
특히 파라미터를 설정하지 않으면 같은 원인으로 프로시져 내부에서 loop 를 돌리거나 했을때 파티션 테이블이 사용되면 5-6번째에 멈추는 현상이 발생한다.

plan_cache_mode( enum)

준비된 명령문(예: PL/pgSQL에 의해 명시적으로 준비되거나 암시적으로 생성됨)은 사용자 정의 또는 일반 계획을 사용하여 실행할 수 있습니다. 사용자 지정 계획은 특정 매개변수 값 집합을 사용하여 실행할 때마다 새로 만들어지는 반면 일반 계획은 매개변수 값에 의존하지 않으며 실행 전반에 걸쳐 재사용할 수 있습니다. 따라서 일반 계획을 사용하면 계획 시간이 절약되지만 이상적인 계획이 매개변수 값에 크게 의존하는 경우 일반 계획은 비효율적일 수 있습니다. 이러한 옵션 사이의 선택은 일반적으로 자동으로 이루어지지만 로 재정의할 수 있습니다 plan_cache_mode. 허용되는 값은 auto(기본값) force_custom_plan및 force_generic_plan입니다. 이 설정은 캐시된 계획이 준비될 때가 아니라 실행할 때 고려됩니다. 자세한 내용은 준비를 참조하십시오

https://www.postgresql.org/docs/12/runtime-config-query.html

[MARIADB] COLLATE 관련 설정..

타울 — Fri, 28 Jun 2019 19:19:18 +0900

기존 MS 에서 LIKE '%keyword%' 로 동작하는 기능을 MARIADB 의 mroonga(전문검색) 으로 사용하기 위해 테스트 중에 발생한 일들은 기록함.

CREATE TABLE `TEST` (

`COM_CODE` varchar(6) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,

`HID` bigint(20) DEFAULT NULL,

.....

PRIMARY KEY (`COM_CODE`,`PROD_CD`)

) ENGINE=Mroonga DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='ENGINE "INNODB", flags "TABLE_HASH_KEY|KEY_LARGE"';

다국어 테스트 검색

문제가 발생한 원인은 collation 과 관련있다.
기본적으로 maria 는 utf8_general_ci 를 사용한다.
이 utf8_general_ci 는 일본어 가타카타/히나가라 그리고 전각/반각을 모두 다른 문자로 인식한다.

ms 는 별도로 구분하지 않는다. like 검색을 수행하면 모두 동일한 문자로 인식하고 검색된다..

일본어 검색 이슈로 collation를 utf8_unicode_ci 으로 변경했는데
MARIADB 를 utf8_unicode_ci 으로 구성함으로써 다음 문제들이 발생했다.

서로 다른 collation 인 테이블 조인시 에러 발생

이미 서비스중인 다른 테이블은 utf8_general_ci 으로 생성되었기 때문에 변경이 어렵다.
해결책으로 on 절의 드라이빙 테이블의 조건에 COLLATE utf8_general_ci 으로 드리븐 테이블의 collate 에 맞게 변경해주면 된다.. 하지만. 통계에 따라 조인 순서가 변경되어야 하는 경우 문제가 될 수 있다.

Procedure 호출시 session 레벨의 collation은 utf8_general_ci인데 테이블이 utf8_unicode_ci 라면, input parameter 가 조건으로 사용될 때 에러 발생

input param 에COLLATE utf8_unicode_ci 를 붙여주면 해결된다.
사용자는 utf8_general_ci으로 호출했지만, procedure 내부에서 utf8_unicode_ci 으로 변환해서 사용한다.

하지만, 위 두가지 문제로 그냥 utf8_general_ci으로 결정되었다.

일본어의 경우 매우 까다롭기 때문에, 아에 처음부터 히라가나/가타카나 중 하나만 사용하게 제한해야 하며, 전각과 반각도 동일하게 제한해야 한다.
만약 일본 고객이 증가하면, 기존 데이터 마이그레이션도 고려해야 할 것 같다.

[MARIA] 전문검색 (COLLATE, MS비교, BULK DML, 악센트, 대소문자,전각/반각, 일본어 가나)

데이터 마이그레이션 이슈

ms 에서는 ⓐ와 a 를 다른 문자로 인식하지만, utf8_unicode_ci 에서는 같은 문자로 인식한다. 따라서 ms 의 데이터를 maria 으로 마이그레이션을 진행하는데 충돌키 오류가 발생한다.
①, 1 도 마찬가지이다. 애초에 pk 컬럼에 이런 데이터를 허용한것도 문제지만;;;;;;;;;;;
이것도 unicode 으로 못간 이유 중에 하나다.

collation 설정은 대/소문자 구분에나 영향이 있는 줄 알았는데

단순히 정렬순서만 영향이 있는게 아니라서 함부로 결정할 수 있는 속성이 아니다.

이런 면에서 MS 에서 이해가 안되는 점이 있다.

먼저 기본적으로 MS 는 일본어의 가타카나/히라가나 그리고 전각/반각을 구분하지 않고 검색해준다. 그런데 ⓐ와 a 는 다른문자로 검색된다 ;;;; 뭔 차이일까..

buffer pool dump & import (메모리 채우기)

타울 — Thu, 13 Dec 2018 14:27:34 +0900

버퍼풀에 캐시된 페이지 정보를 내려받고 로드할 수 있는 기능으로, 운영중에도 가능하고, 재기동시 자동으로 동작하도록 설정 할 수 있다.

내려받는 것은 페이지 주소만 작은 텍스트 파일로 받기 때문에 운영중에 수행해도 관계없지만, 로드하는 것은 실제 데이터파일에서 페이지를 읽어 메모리에 올리기 때문에 주의해야 한다.

10.2 부터는 재기동시 자동으로 이 기능을 사용하며 innodb_buffer_pool_dump_pct = 25% 으로 설정되었다..

아래 파라미터를 참고하여 사용하자. (10.2.2 부터는 기본적으로 사용한다)

innodb_buffer_pool_dump_at_shutdown

innodb_buffer_pool_dump_now

innodb_buffer_pool_dump_pct

innodb_buffer_pool_load_at_startup

innodb_buffer_pool_load_now

[MSSQL] HASH 조인 제약 (메시지8622)

타울 — Thu, 13 Dec 2018 14:21:19 +0900

hash 조인 조인 조건이 where 절 등에 사용되는 등 특정 케이스에서 아래와 같이 오류가 발생한다.

하단 보미네 님의 자료를 참고하자..

메시지 8622, 수준 16, 상태 1, 줄 2

이 쿼리에 정의된 힌트로 인해 쿼리 프로세서에서 쿼리 계획을 생성할 수 없습니다. 힌트를 지정하거나 SET FORCEPLAN을 사용하지 않고 쿼리를 다시 전송하십시오.

문법적인 오류가 아닌데 사용자에게 런타임에 오류를 표시하는지 이해가 안된다... 알아서 회피해서 결과를 보여주면 될것 같은데...

이 문제는 2012, 2017 에서는 발생하지 않는다.

참고자료: http://sqlsql.tistory.com/101 [보미네]

메크로 기능으로 HTML 를 위키 (WIKI) 에 표시하기.

타울 — Wed, 8 Feb 2017 11:39:24 +0900

레드마인 버전 : 2.6

위키에서 HTML가 즉시 표시가 안되기 때문에 메크로를 사용해야한다.

1. macros.rb 파일에 아래 소스를 넣는다.

- 하단에 macro 들이 모여있는 곳이 있다. 중간에 넣어주자..

{redmine_home}\apps\redmine\htdocs\lib\redmine\wiki_formatting\macros.rb

desc "Insert html" + "\n\n" + " !{{html\n<HTML CODE HERE>\n}}" 
macro :html do |obj, args, text|
    return unless User.current.allowed_to?(:edit_wiki_pages, @project)
    text.html_safe
end

2. redmine manager 툴을 이용하여 레드마인 프로세스 재기동

3. 위키 작성

- {{hmlt( )}} 구문을 사용한다.

{{html(
    html 소스
  )}}

모든 테그를 테스트를 하지 않았지만, table 테그는 잘 표시된다.

레드마인 위키에 표를 그리는 과정은 정말 힘들다.

간단한 표는 간단하지만 복잡한 표는 그리기도 힘들지만, 편집하는것도 만만치 않다.

메크로 참고 : http://www.redmine.org/boards/2/topics/2677