대체거래소후기

나는 증권사 IT 매매팀에 꽤 오래있었다. 여태까지 내가 작성한 코드들이 이제 거의 모든 로직에 들어가 있다.

작년부터 대체거래소 NXT 적용하기 위해 역대급으로 바쁜 프로젝트를 얼마전 끝냈다. 시스템을 깊이 아는 상태였어도 이 프로젝트를 진행하는게 상당히 힘들었기 때문에 굉장히 인상적이였다. 그래서 후기를 남기고자 한다.

SOR

NXT 거래소가 생기면서 특이하게 SOR주문이 생겼다. 각 증권사가 해야할 일은 고객에게 최대한 유리하도록 주문집행 하는 시스템을 갖추는 것이다. 상황에 따라 KRX, NXT 양 거래소로 분할되거나 둘 중 하나를 선택하여 주식주문을 집행하게 된다.

이 시스템을 갖추는데 각 증권사들은 3가지의 방식중 하나로 선택했다.

  1. 자체개발 (대단하다…)
  2. N.. 제품
  3. K.. 제품

우리는 K.. 제품을 사용했다.

주문집행의 역할은?

주문집행의 역할은 어디까지나 원장이라는 시각이면 K , SOR에 위임하는 시각이면 N 이다. 이는 각 증권사의 관점에 따라 혹은 제품선택에 따라 달라지는 부분인데 담당자들의 많은 고민이 있었을 것 같다.

주문관리

K를 선택시 SOR주문의 자녀주문 관리는 원장에서 직접 하여야 한다. SOR시스템의 판단을 받고 이후 주문관리를 시작하게 되는데 여기서 SOR 첫 도입시 이슈가 되었던 Split 정정에 대한 이슈가 있다.

TXT
SOR주문 30주 ( KRX  20주 , NXT  10주 )
=> 정정판단  KRX 10주, NXT 20주 
SOR정정 30주 ( KRX 10,  KRX10취소 -> NXT신규,  NXT정정10)

이 내용은 SOR정정시에 자녀주문에 대해 2->3개로 Split 되며 정정이 반복될때
계속 Split 이 될수 있다는 내용이다. 이론상으로는 주문수량만큼 전부 Split이다. (100주면 자녀주문 100개)

사실 이 내용은 취소 -> 신규(Merge) 를 정정으로 본다면 주문 1개에 대해 상수개의 자녀주문으로 고정된다. 심지어는 걍 부모주문 레코드에 전부 담아 컬럼만 추가하여 설계하는 것도 가능하다. (초고속 시스템 적용시?)

자동테스트

SOR주문관리모듈을 작성하는데 거의 수백페이지짜리 판타지 소설을 썻다. 양도 양이지만 케이스가 워낙 다양하기 때문에 놓치는 구간이 있다면 엄청난 사고가 일어날 것이다. 따라서 이부분은 테스트 자동화를 한뒤 수량이 전부 맞을때까지 계속 반복하며 수정했다.

  1. SOR 및 양거래소를 주문관리모듈과 격리 : 연결하지 않는다. 순수하게 주문관리모듈만 테스트한다.
  2. SOR의 결과값과 각 거래소가 주는 전문의 순서를 정하여 케이스를 만든다. (140개 정도)
  3. 모듈 수정시마다 테스트 자동수행 모-자 주문 수량 점검

생 파이썬으로 테스트 스크립트를 작성했다. 주문과 전문 순서는 json 으로 정의한다.

JSON
{
    "title": "New Order Case 1",
    "desc": "..... ",
    "prgm": [
        {
            "type": "order",
            "sby": "buy",
            "qty": 10,
            "ratio": 0.5
        },
        {
            "type": "kcfm",
            "qty": 5
        },
        {
            "type": "ncfm",
            "qty": 5
        }
    ]
}
  • 매수주문 10주 분할 50%
  • KRX 확인 5
  • NXT 확인 5

이런식이다. 문제가 없어야 하는 케이스이지만 거래소의 정정, 거부,자동취소 등으로 깊숙히 들어가게 되면 전문을 나열하는 경우의 수가 많아지게 된다.

‘Split 정정시 원주문 체결로 실정정수량 적게수신 및 상대거래소 대비 잉여수량 관리’

이런 경우도 있다. 이는 사실 사람이 꼼꼼하게 보기 어렵다. 위와 같은 json파일을 잔뜩 만들고 전부 수행, 전문 하나하나마다 내부 서비스를 하나씩 호출하며 그 시점의 모-자 주문 수량 querying 리포트를 만든다. Expectation과 리포트를 비교하여 오차가 있으면 문제가 있는 것이다.

이러니 SOR주문관리모듈에서 테스트코드가 차지하는 비중이 25%를 넘어버렸다. 스크립트를 제외하고도 말이다.

개인적으로 머리가 좋지 않아. 실제 2달 넘게 계속 문제가 있었으며 고통을 받으며 2달하고도 2주지난 시점에 수량이 맞아가기 시작했다.

프로젝트 중반부터 현업테스터들이 투입되기 시작했는데. 이 주문관리 부분은 현업테스트 커버리지보다 훨씬 넓게 테스트 및 확인 되었을거라고 생각이 든다.

프로젝트

거래소 하나 들여오는 거대한 프로젝트인 만큼 매매팀 뿐 아니라 그냥 거의 모든팀이 대응 투입 되었다. 비록 우리팀이 신규로 도입해야하는것이 많았지만 절대적인 양으로 볼때 시세, 매체 쪽도 만만치 않게 꽤 많았다고 볼 수 있다.

고로 프로젝트가 제대로 진행이 되려면 데이터 소스를 관리하는 우리쪽이 최대한 빨리 완성시켜 안정화를 시킨뒤에 매체와 조회서비스 쪽 지원사격을 해야했다.

팀워크

NXT 실시간 주문 부분만 뚫어놓고 바로 SOR주문관리모듈 작성하기 시작했다. 하지만 여기서 병목이 걸려버렸는데 이때 잔여 전문처리 개발 및 배치개발 등등 팀원이 할일을 효율적으로 나누어 동시에 처리하였다. SOR관리모듈을 만들어놓고 보니 모든 잔여전문들이 완료되어 테스트 진입하게 되는 것을 보며 이게 바로 팀워크란 것을 느꼇다. 이는 25년 들어 폭탄이 떨어지며 우리팀이 마비가 되기전까지 수월하게 잘 진행되었다.

NXT

KRX를 다루며 불편했던 점들을 NXT 도입시 개선하려 했는데 그중 하나는 스펙문서다. KRX의 스펙은 우리회사의 단어로 바꾸어 정의해서 쓰고 있는데. 문제점이 있다. 매칭이 하나도 안된다. 분명 거래소 문서와 같이 길이에 맞게 잘려진 로그를 보고있어도 위치를 바로 찾을수 없다. 그래서 위에서부터 칸을 세며 몇번째인지 다시 세어야 한다.

그래서 나름 짬?이 된답시고 매매팀에 선포를 했다.

  1. 스펙문서의 구조는 해당 문서의 영문명칭을 그대로 사용한다.
  2. 스펙문서를 웹에서 바로 조회할수 있도록 만들겠다.

이를 위해 파이썬을 사용했는데 openpyxl을 쓰니 쉽게 되었다.

TXT
Excel -> Json -> Html
  • vscode 등에서 venv 모드로 설치하면 깔끔하게 해당 라이브러리만 세팅 가능

이 과정을 거쳐 웹페이지를 만들고 서버에 올렸다. 여기에 전문을 긁어다가 넣으면 자동으로 잘라 내주는 기능까지도 추가했다.

이런 짓을 할수 있었던 이유는 프로젝트 초기에는 비교적 여유가 많았기 때문이였다. 25년 들어서 말도 안되게 바빠졌지만

웃긴건 KRX에서 재처리 오류가 더 많이 나왔고 NXT용 전문 잘라내주는 기능을 KRX 전문에 적용하여 더 많이 써먹었다. 그냥 두 거래소 스펙이 똑같다는 얘기다.

NXT.2

프로젝트 중반 현업테스터 충원 및 TFT 구성으로 어수선할때 얘기다. NXT 측에서 부하를 발생시켜 달라고 요청했고 파이썬으로 만들어놓은 벌크주문 쏘아대는 스크립트로 주문을 NXT에 쏟아부었다. 그래도 우리시스템은 느려서 간에 기별도 안갔겠지만…

그리고 다음날도 또 요청이 오길래 주문을 발주했는데 종목이 거부가 발생했다! NXT에 물어보니 KRX보다 몇십% 거래량이 더 많으면 다음날 차단된다고 했다.

???

아니 쏴달라고 해서 쏴준건데. 왜 차단을 하는거지?
황당해 하고 있는데 오늘은 주문을 안쏘냐는 문의전화가 왔다 하하 아무래도 팀이 달랐겠지, 지금 생각해보니 미안하지만 그땐 그냥 무시했다.

무한굴레의 테스터들

프로젝트 중반 주문관리 및 NXT 처리가 얼추 완성이 되고 화면 및 매체등의 개발 진행이 조금 되었을때 테스터들이 회사 각 부서 지점에서 뽑혀와 아예 자리까지 새로 만들어 테스트를 시작했다.

아마 오자마자 500페이지도 넘는 요건서를 보고 경악했을 것이다. 요건에 대한 부분은 사실 나도 테스트를 지원하면서 잡아나가자는 러프한 마인드였기 때문에 처음 시작하자마자 쏟아지는 결함세례에 정신이 번뜩 들며 후회막심이였다.

그리고 이분들은 24후반부터 ~25년 3월 끝날때까지 똑같은것을 계속 반복해서 체크하는 엄청난 일을 하시게 된다.

채팅방에서만 보다가 직접 얼굴로 본적은 마지막날이였는데 내가 “이미 고쳐졌다고 보고 OK찍고 넘어갔다가 다음날 다시 안되면 스트레스 받으셨겠어요” 물어봤더니 그런것보다는 우리가 자꾸 지적하고 트집잡는 사람이 된것 같아 미안한 마음이 컷더란다. 이렇게 착한 사람들이라니.. 가끔씩 내가 채팅방에 틱틱 대었었나? 걱정이 들었다. 독성말투를 쓰지 않았을까 걱정이다.

Market Making 과 금감원

NXT 테스트 기간동안 거래소에서는 각 증권사에 전용종목을 배정해 주었다. 그래서 나름 다른 증권사의 종목을 건들지 말아야겠다. 다짐했는데. 첫날부터 끝날때까지 우리 종목은 특정 몇개 회원사가 끝까지 겐세이?를 놓았다.

하지만 어쩌겠는가 거래소가 그냥 권고한 것일뿐이지 강제로 막은것도 아니고 ‘나는 관대하니까 그냥 넘어가겠다. 상호 확증 파괴 같은것은 하지 말자.’ 마음을 먹었다.

금감원이 실사 나오는 날에는 현업부서 전체가 긴장하며 지원이 필요하다고 도움을 요청했다. 전용종목에다가 호가를 이리저리 깔아주면 Taker/Maker 시나리오 설명을 시연하며 할수 있다는 것이였다.

그래서 간단한 maket making 스크립트를 짯다.

  1. XX 증권사가 깔아놓은 잔량을 Cleaning 작업
  2. 엄두도 못내도록 대포와 같이 한방에 잔량 넣었다 뺏다 하며 위력 과시

일단 한방에 주문을 팍 깔아놓는 것은 무조건 Async로 주문을 날려야한다. 심지어 멀티스레드로도 제어하기 힘들다. Non-blocking 요청을 해야한다. 이후에 다시 한번에 응답을 받아 주문번호를 모은뒤에 다시 Async로 한번에 날리면 일제 취소가 된다.

TXT
Cleaning 알고리즘
1. 내가 깔아놓을 매도호가 건수만큼 많은 매수 주문수량을 채워서 순차적으로 위로 올린다.
2. 위로 올라간 위치 (매도10호가)에서 다시 매도수량을 채워서 순차적으로 아래로 내린다.
3. 아래 위치(매수10호가)에서 다시 올린다. 
4. 일제 취소
  • VI가 걸리지 말아야 한다.
  • 현재가는 유지시킨다.

두조건을 만족시키며 XX 증권사 잔량을 치워버릴수 있는 방식이다.

이런 기능이 있었지만 냉철한 금감원 직원은 우리의 어떤 일체의 도움을 받지 않고 본인이 케이스를 찾아서 직접 매매한뒤 증적자료를 요구하였다.

고로 Making 스크립트는 딱 한번 쓰이고 용도를 다하게 되었다.

부하

처음에는 거대한 프로젝트의 격?을 세우기 위해 솔직히 그럴싸해 보이기 위해 접근했던 마음이 있었지만, 테스트를 진행하면서 마음이 바뀌게 된다.

TXT
        - Read => 0
-------+- Read => 0
0000000 - Read =>
-------+- Read => 0
        - Read =>

최대 TPS? 가 도대체 뭐지?

“버틸수 있는 최대한계” 이런 말은 관점에 따라 참 다양한 것 같다. 이런 테스트를 진행하면 시니어의 “실제로 해봤어?” 물음에 참 할말이 없어지는 부분이다.

주문서버 1대에 수십만TPS 가 가능할까? 가능하다. 테스트 클라이언트 수백대로 그냥 몇만개 주문 1초에 쏟아버리면 되지 않겠는가? 대기큐에 쌓여 몇분간 하염없이 기다리다가 뭐 5분뒤 처리되면 이 시스템의 최대TPS는 수십만TPS에 평균응답 5분이 된다. 매우 응답속도는 느리지만 수십만tps를 처리한 시스템이 된다.

이런 상황에서 중요한 부분이 빠졌는데

  • “평균처리속도 30ms 일때 이 시스템이 처리가능한 1000 TPS”
  • “아니 50ms까진 봐주자 1200TPS”

즉 대기가 없거나 있더라도 매우 짧아 납득 가능한 응답속도를 기준으로 TPS는 정해져야 하는 것이다.

이렇게 팩트기반으로 응답속도 기준 조건을 조정할때 처리가능한 TPS는 급속도로 떨어지며 “이게 맞아? 우리가 너무 못만들었나?” 부끄러움이 올라오기 시작한다.

아무리 쥐어짜도 복잡한 비즈니스는 변하지 않으며 돈에 민감한 부분이니 데이터 정합성은 양보해선 안되는 영역이다. 그리고 바로 성능과 상충이 된다. 매매팀에 있을동안 계속 괴롭힐 문제이다.

DB락 속도는 성능지표에 포함되어야 하나? 그리고 대역폭

부하테스트는 간단하게도 거창하게도 할수 있지만 목적은 동일하다. 부하를 주고 어딘가에 이상이 있는지 찾아보는 일이다.

밀어붙이다보면 어떤 임계점에서 갑자기 성능이 떨어진다. 평균처리속도가 늦어지며 이 영향으로 락이 길어진다.

구간별로 측정해보았을때 락 시간이 결정적이다. 이를 제외한 나머지 시간은 준수하다. 락시간만 99.99% 를 차지하는 상황이 되었다.

  • 프로그램이 느린것이 아니다. 락기반 처리가능량보다 투입량이 더 많아서 그런것이다.
  • 락이 유발되는 지점도 중요한 포인트이다. 매우 의미있다.

두가지 의견이 상반되어 고민이 깊어진다. 뭐가 맞는 것일까?

그리고 시스템쪽의 분석결과 IO대역폭 초과로 전체 네트워크 성능저하가 유발된 것을 알게되었다.

디비서버도 넉넉하고 빠르고, 서버도 넉넉하고 빠르지만 락이 늘어나며 느려지는 기이한 원인은 뜬금없이 테스트환경의 네트워크 용량이 부족했기 때문이였다. 세상에 그리고 나는 운영용량은 훨씬 넓다는 말에 안도했다가도 주문이 이정도로 대역폭 차지할 정도면 수십배로 사용량이 많은 TOP 서비스들은 ??? 의문이 들며 그만 정신을 잃고 말았다.

뮤텍스와 Lock-Free

SOR과 통신하는 프로세스는 TCP로 바로 붙는데 주문이 끝나버린 것이 아니므로 이 요청은 Sync로 동작한다. 결국 Send, Recv는 짝을 이뤄야 하며 SOR 서버 헬스체크를 하는 백그라운드 스레드랑 경합한다.

C
lock(&mutex);
send(...);
recv(...);
unlock(&mutex);

간단하게 뮤텍스 가드로 처리후 평상시나 적당한 강도로 주문집행시에도 문제없음을 확인했으나 대규모 부하를 발생시키니 0.001% 확률로 TCP버퍼가 깨지는 이상한 현상이 발생했다.

가드를 뚫고 짝이 맞지 않게 Send 된것을 발견했다.

재현불가, 하지만 현상은 있다.

뮤텍스 리소스가 부족하다는 원인밖에 없는데 서버스펙을 생각할때 말이 안된다. 하지만 잠재적 리스크를 감수할수 없으므로 해결책을 찾아야했다.

부하상황은 사실 통신이 매우 잘 이루어지고 있는 상황으로 굳이 헬스체크가 필요없다. 따라서 헬스체크는 최근 호출 타임스탬프가 몇초 이내라면 굳이 호출하지 않는 식으로 로직을 바꾸었다.

Lock-Free 함수들로 Store , Load 를 하며 시간체크 방식으로 바꾸니 수십만건의 전문이 버퍼깨지는것 없이 100% 처리되었다.

세상에… 주문업무를 하며 atomic 계열 함수를 써본다니 말이 되는가? 요번이 처음이자 마지막으로 다시는 없을 것 같다.

장애

예측된 장애위험 그리고 LB

모두의 관심사는 SOR이였다. 윗선이든 아래든 모든 주제는 SOR이였고 따라서 “보고"를 위해서라도 장애 대책이 있어야 했다. 이부분은 굉장히 잘 정리가 되었다. 이 구조는 깔끔했다.

SOR과 통신하는 각 개별 프로세스들은 연결이 끊어지면 스스로 복구하기 위해 최대한 노력한다. 이게 바로 상태이다. 특별히 상태값을 정의하지 않아도 노력하는 행위자체가 상태가 된다. 이는 자연스럽게 LB와 연관된다.

TXT
"노오력하세요~"

준비된 자가 쟁취한다. 연결이 끊어진 친구는 복구중이라 준비가 되지 않았다. 남은 친구들이 경쟁하여 SOR요청을 받아가는데 부분/전체 장애가 있더라도 최대한 경쟁적으로 쟁취를 하다보면 자연스럽게 효율적으로 배분이 된다.

예측된 부분은 참 터무니없다. 이는 “보고"와 관련이 깊은데 보고전략중 하나는 터무니 없는 상황에서도 대처가 된다는 점을 강조함으로서 윗선에 안전하다는 인식을 강화하는 것이다.

  • “어떤 미친놈이 서버실에 쳐들어와 네트워크 랜선을 뽑아도 우린 금방 복구됩니다!”
  • “불이나서 서버가 죽어버려도 살아있는 놈이 최대한 처리해줍니다!”

하지만 윗분들은 다 안다. 괜히 그자리까지 올라갔겠는가? 아마도 귀엽게 보며 맘껏 떠들어보라 했을 것이다. 그리고 뒤로는 몰래 다른 개발자를 시켜 교차검증할 것이다.

상호불신이 안전하다.

FEP개발자 분들은 절대로 장애를 내지 않는걸로 유명하다. 애초에 그런 성향의 사람들이 다 FEP하는것 같다. 그래서 주문개발하는 나는 사실 FEP가 안전하다고 가정하고 넘어간 로직들이 좀 있었다. 이후 코드리뷰 시 보면 “그럴 일은 없겠지만 만의 하나라도 0.0001% 확률로 FEP가 실수를 했다면?”

  • “음 KRX로 이미 쐈는데 주문을 롤백해 버렸군 하하하”
  • “재처리 할때마다 계속 NXT로 주문 쏘네?”

말도안되는 미친상황이 발생할 수 있다.

나의 신앙심과는 별개로 억지로라도 의심병을 갖고 다른부분을 믿지 않는 것. 매매팀의 덕목이다.

SOR K제품도 마찬가지다. 내가 봤을때 이 시스템은 옛날 스타일과 요즘?스타일이 섞여 있는데. 10여년전 만들어둔 어떤 틀에 NXT 도입으로 최근에 판단엔진을 얹혀놓은것 같다. 구조는 깔끔하고 장애포인트가 적다. 하지만 시세가 특정상황이 될때 잠재된 로지컬 오류가 있다면?

위 예측된 위험같이 미친놈이 랜선을 뽑아 누구나 다 알아챌수 있는 화려한 장애가 아니라 조금씩 조금씩 잠식되어 정신차려보면 망해가고 있는 상황이 더 무서운 법이다.

불신의 끝, Postgre SQL 과 데드튜플

포스트그리엘SQL은 내가 아주 좋아하는 DBMS이다. 그런데 회사에 도입한다?면 글쎄 좀 그런듯? 증권사 주문 Update가 쏟아질때 데드튜플이 많이 생길수 밖에 없다. 자주문 관리모듈을 만들며 느낀건 이건 정말 업데이트가 많다는 점이였다. Vacuum 관리를 잘 해야하는데 이런게 최적화가 되나 싶다.

  • 자주문 분할 정정확인 거래소간 경쟁적인 업데이트
  • 삥주문-체결 대량 발생시 체결수량 업데이트

진짜 문제는 데드튜플이 인덱스에 잡힌다는 점일 것이다. vacuum으로 정리하려고 해도 워낙 많이 쌓이면 시간이 걸리며 이 시간이 걸림으로 다시 더 많이 쌓이고 또 vacuum 속도가 느려지는 악순환이 발생할수 있다.

내가 N제품 마지막 미팅 (SOR을 선정전 각 증권사에 설명하고 논의하는 자리)의 기억이 맞다면 PSQL 기반인 시스템인데 내 특유의 의심병이 도지면서 불안감이 커지기 시작했다. 그때까지만 해도 무조건 이 N제품 선택해야하는줄 알고 있었다. 아무 설명도 없이 나보고 갔다 오라길래..

하지만 내 테크지식은 20년 이전 옛날로 고정되었으며 이미 다 해결된 이슈일수 있다. 그리고 NXT시장이 열리며 오전8시~저녁8시까지 거래량을 더 분산 시켰으므로 순간적으로 쏠리는 현상을 줄였을 수도 있다.

혹은 우리처럼 주문의 컬럼으로 수량을 갱신하지 않고 이벤트를 전부 기록해 놓은다음 스냅샷 시점부터 순차적으로 읽어 계산하는 이벤트소싱 패턴으로 처리했을수도 있다.

하지만 내 마음속 불안감은 해소되지 않았고 이후 다른 제품 미팅하며 컨셉이 다양한걸 보며 일단 N은 피하자는 생각이 들었다.

근거는 달랐지만 결론은 같았다. 내 편견에 의한 불안감이였든, 윗선에서 검증된 회사를 선호하는 것이였든, 또 누구는 비용을 우선으로 생각했든. 결론은 같았다. 누구도 말은 꺼내지 않았고 분명 선택지가 있는 “보고"가 있었지만 다들 느꼈을 것이다. 이미 처음부터 이렇게 흘러갔을 것이란걸.

이행 , 첫날

처음엔 자신감이 있었더라도 오픈일이 다가오며 자신감은 점점 사라지고 무서워지며 마지막엔 기도밖에 할게 없었다.

장애 포인트는 너무도 많고 대비책을 세운 부분이 아닌 부분에서 터질까 조마조마한 상황이다.

타 증권사들은 도대체 어떻게 한 것일까? 우리만 이렇게 바쁘고 힘들고 무서워했던 것인가? 우리가 땀뻘뻘흘리며 고생할때 되게 쉽고 가볍게 툭 쿨하게 끝내는 이미지만 떠오른다.

이행일날 이슈

증권사마다 상황이 달라 Go, Back 못하는 회사도 있다고 한다. 우리는 거래소가 Back을 해도 예전 거랑 호환이 되도록 했기때문에 그냥 Go 였지만 거래소의 선언을 지켜볼수 밖에 없는 증권사들도 있었다고 했다.

그리고 저녁에 드디어 NXT의 선언이 나오고 전 증권사들의 직원들은 KRX의 잔디에 시선이 쏠리게 되었다.

그리고….

계속 연기되었다. 회의가 길어진다며 저녁 7시부터 아마 밤 9시넘어서까지 계속 기달렸던것 같다. 어떤 증권사 분의 절규?가 보이고 너무도 안타까워 힘내라고 엄지척 좋아요를 눌러주었는데 바로 파바밧 좋아요 수가 50개나 올라가버렸다.

다들 이렇게나 기다렸구나 , 끝내기를 기다렸구나. 답답하구나.

낮에 있었던 이상했던 증적자료가 회사에 떠돈다. 거래소간 장운영중 꼭 맞춰줘야 할 부분이 있는데 서로 맞지 않는다는 증거였다.

여태 회사 입사하고 나서 단 한번도 거래소가 틀린적을 본적이 없다. 그래서 당연히 우리 시세 문제였겠지. SOR문제였겠지 일시적으로 그렇게 보이는거겠지. 하지만 진짜였다. 어떤 부분에서 안맞는 부분이 발견된거고 KRX가 괜히 욕먹게 된 상황이다. 일부러 시간 끈거 아니고 진짜 이상해서 그런건데 ㅎㅎ

결국 KRX와 NXT간 엄청난 논쟁?이 있지 않았을까 한다. 결국은 Go

첫날

긴장감이 넘쳐났던 첫날은 준비한것보다는 좀 힘빠지게 거래량이 매우 적고 (10종목뿐) 투자자들도 눈치보기로 많이 주문을 내지 않았다. 그리고 너무도 아무렇지도 않게 조용히 넘어갔다.

뭔가 빵빵 터져서 존재감을 알려야되나? 하지만 증권사 분들 누구도 첫빠따가 되는것을 원치 않을 것이다.

몇 증권사에 대한 노골적인 악의가 보이는 기사를 보며 참 기분나쁘겠다는 생각도 들었다.