Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

Recommended Posts

이안 바커 (Ian Barker)"The Story Of The $800 Million Dollar Bug Report" 을 번역했습니다. (원문 작성: 2023년 1월, 최종 번역: 2024년 1월)

윈도우 개발을 롤러코스터를 타는 것처럼 흥분되고 긴장감 넘치는 일이라고 생각하는 사람은 많지 않다. 우리 소프트웨어 개발자들 역시 스릴을 추구하지 않는 것으로 알려져 있다. 따뜻하고 안전하게 편안하게 비치는 모니터 불빛과 딸깍거리는 키보드 쪽를 향해 몸을 숙이고 지낸다. 우리가 가끔 한번씩 실수로 만든 버그는 기껏해야 겨우 불편한 대화로 이어질 뿐이다. 그렇다. 때로는 그 버그가 고객에게 손해를 끼칠 수도 있다. 하지만, 오늘 소개할 델파이 개발자 David Bolton의 엔터프라이즈 기고는 차원이 완전히 다른 값비싼 오류에 대한 이야기이다. David은 8억 달러 버그를 수정했던 경험을 전해준다. 이럴 수가...부담을 가질 필요는 없다!

목차


델파이는 어떻게 석유 거래 소프트웨어의 흐름을 원활하게 만드는가

석유는 세계에서 가장 많이 거래되는 원자재다. 나는 미국 최고 은행의 런던 카나리 워프(Canary Wharf) 지사에 있는 원자재 소프트웨어 부서에서 근무했다. 직원 6만 명이 전 세계에서 근무하는 은행이었다. 우리 팀은 네 명으로 구성되어 있었다. 주 업무는 석유 거래 비즈니스 운영이 계속될 수 있도록 소프트웨어 패치, 버그 해결, 새로운 기능 추가 등의 작업을 하는 것이었다.

특히, 델파이로 작성된 두 개의 거래 애플리케이션을 관리했다. 트레이더가 사용하는 시스템은 거래 입력을 위한 것으로, 약 160만 줄의 코드로 구성되어 있었다. 거래는 주로 실물 석유 거래 위주였지만, 선물이나 옵션과 같은 일부 파생상품도 포함되었다.

이 애플리케이션은 2-티어 애플리케이션인데 메인인 거래 입력 애플리케이션은 MTS(Microsoft transaction Server)를 실행하는 서버와 통신하는 구조였다 30개의 COM 서버 프로그램이 MTS 아래에서 실행되었다. 트레이더가 거래를 저장하면, 서버 프로그램 하나가 올라와서 그 한 가지 거래 유형을 처리했다. 모두 델파이로 작성되어 있었는데, 코드의 길이는 보통 2만에서 3만 줄에 정도였다.

MTS 아래에서 실행되기 때문에 높은 회복탄력성을 갖추고 있었다. 버그가 발생하면, MTS는 문제가 되는 COM 오브젝트를 종료하고, 필요하면 다른 오브젝트가 다시 시작한다. 또한, 이 아키텍처는 여러 거래를 모두 한 번에 저장할수도 있었다. 이 경우 저장은 병렬로 처리되었다.  보통 20에서 30명의 트레이더들이 동시에 거래를 입력하고 저장했다.

XML이 정말 세계 금융을 운영하고 있는가?

메인 애플리케이션은 거래를 커다란 XML파일로 저장했는데, 길이가 수백 줄인 경우도 있었다. XML 파일들은 관련 COM서버로 전달되고, COM 서버는 XML 파일을 읽은 다음, 커다란 SQL 트랜잭션을 만든다. 그 안에는 INSERT와 UPDATE 여러 개가 들어간다. 이 트랜잭션은 Sybase ASE 12 데이터 베이스(Sybase 기반이며, SQL 서버와 매우 유사)에서 실행되었으며, 거래가 저장되고 나면, 메인 애플리케이션이 업데이트 되었다. 

데이터베이스 관리를 위해 무엇을 사용했나?

큰 기업이라서 좋은 점 중 하나는 직원들에게 큰 기업용 도구들이 제공된다는 점이다; 우리는 DBArtisan을 사용해서 데이터 베이스의 모든 관리 작성을 수행했다. 나는 이 작업에서 수많은 SQL을 작성했다. DBArtisan 작업들을 기록하고 그 안에서 실행된 SQL을 획득 할 수 있어 작업이 훨씬 쉬웠다.

나는 두개의 코드 기반을 병합하라는 요청을 받았었다. 이 두개는 처음에 하나였는데, 10년 전에 나누어져서 지속되 온 것들이었다. 즉, 이 두 폴더 트리에는 각각 약 800개의 파일이 들어 있었는데, 그 중에서 어디가 다른지를 파악해야 한다는 말이었다. 나는 델파이 애플리케이션을 작성했는데, Araxis Merge(COM 서버로 사용할 수 있는 엔터프라이즈 파일 비교 유틸리티)를 사용해 모든 폴더와 파일을 비교하는 작업을 처리하는 것이었다. 그 결과,  몇 주간라는 시간을 절약할 수 있었다. 

석유 거래는 상당히 복잡할 수 있다. 유조선이 정유소에 연료를 하역하는 데에는 며칠이 걸릴 수 있는데, 그 기간 동안 다. 석유의 가치는 계속 달라진다. 계약 가격은 각 날짜의 시장 마감 가격인데, 그 날짜의 기준은 석유가 완전히 하역되고 소유권이 명시적으로 이전되는 시점이다. 그 후에는, 그 계약 가격을 사용하여 가치가 정해진다.

어떤 다른 애플리케이션을 작업했는가?

우리가 관리한 두 번째 델파이 애플리케이션은 PLServer였는데, 약 120만 줄의 델파이 코드로 이루어져 있었다. 서로 다른 석유 데스크에서는 각각 PLServer를 실행하여 하루 모든 거래를 처리하고 모든 평가를 수행한 후 손익 수치를 계산했다. 트레이더들은 매일 오후 6시에서 8시 사이에 이 작업을 했다. 거래량이 많을 때는 한 시간 정도 걸리는 경우도 있었다.

일일 마감된 손익 수치는 관리자에게 전달되고, 그 다음날 해당 은행의 게시판에 공개되었다. 그렇기 때문에 이 수치 산출은 반드시 수행되어야 했다. 몇 년 동안은 모든 것이 순조로웠지만, 어느날 "8억 달러짜리 버그"가 발견되었다.

8억 달러짜리 버그라니!

나는 PLServer를 유지 관리했다. PLServer는 모든 종류의 로깅 기능을 내장하고 있어 버그를 매우 빠르게 찾아 수정할 수 있었다. 99.9% 완벽하게 작동했다. 그런데, 어느 날 우리는 어느 한 데스크의 PLServer에서 전날 밤 예상보다 8억 달러 더 많은 수익이 나왔다는 메세지를 받았다. 이 문제는 그 은행의 이사회에서 매우 빠르게 통보되었다. 따라서 이를 신속하게 해결해야 한다는 압박감이 컸다. 이 엄청난 이익이 사실이었으면 좋았겠지만, 이 수치는 완전히 잘못 산출된 것이었다. 관리자들은 이것을 수작업으로 보정해야 했다. 그래서 내가 문제를 찾아 해결해 주기를 기대했다.

그 다음 몇 일동안 저녁마다, 나는 트레이더가 승인하는 즉시 바로 내 데스크탑 컴퓨터에서 델파이 IDE를 사용해 해당 데스크의 PLServer를 실행했다. 실제로 운영되는 프로그램을 그런 식으로 실행하는 것은 약간 이상한 일이었다. 하지만 긴급한 상황이었기 때문에 어쩔 수 없었다. 버그를 찾는 데 며칠이 걸렸다. 그 이유는 하루에 한 번 밖에 실행할 수 없었기 때문이었다. 이 문제를 해결하기 위해 나는 잘라서 하나씩 정복하는 방법(divide and conquer)을 사용했다.

버그를 추적해 냈는가?

결국 버그를 잡아냈다. divide by zero 예외가 발생했는데, 이로 인해 매우 중요한 코드 부분을 그냥 건너뛰었기 때문이었다. 그 특정 거래는 일본 엔화로 가치가 매겨진 것이었다. 정상적이라면 이 가치는 달러로 변환 되어야 했다. 그 당시 환율은 달러당 140엔 정도였다.

예를 들어, 거래의 가치가 10,000엔이라고 가정해보자. value := Value_in_Yen/Yen_rate; 에 의해 71.25 USD가 되어야 옳았다. 하지만, 그 전까지는 이 예외에 걸린적이 한번도 없었다. 그런데, 이번에는 외환 변환 처리를 건너뛰다보니 그 엔화 총액이 그대로 미화 총액으로 취급되었던 것이다. 예를 들어, 10,000엔이 아니라 미화 10,000 달러로 처리되었다. 즉, 140배나 큰 금액이 된 것이었다. 

divide by zero 오류는 절대 발생하면 안되는 버그이다. 나중에 밝혀진 바로는, 트레이더들이 새로운 유형의 거래를 도입했는데 우리에게 알리지 않았었다. 그리고, 이 거래는 거래 기간이 0일이었기 때문에 그 예외가 발생한 것이었다. 그 전에는 거래 기간이 0일인 거래가 없었다. 따라서 날짜 길이로 나누는 나눗셈 안에 0으로 나누는 경우를 점검하지 않았었다. 나는 나눗셈에 점점을 추가하고, 수정 사항(fix)을 테스트한 후 다음날 실제로 운영되도록 릴리스(release) 했다.

델파이는 8억 달러짜리 버그를 추적하는 데 어떻게 도움이 되었는가?

델파이를 사용하면 코드 디버깅 작업을 단순해진다. 심지어 이처럼 대규모 애플리케이션도 코드를 변경하고 컴파일하고, 다시 실행하기까지 1분이 채 걸리지 않는다. 내 동료는 C++로 프로그래밍하는데 편집, 컴파일, 재실행까지 하는데 최소 5분에서 10분 걸렸을 것이다. 그 동료는 나의 짧은 컴파일 시간을 부러워했다.

COM 서버 및 델파이에서 마이크로소프트의 Dynamic Virtual Channels 사용하기

전형적으로, COM(윈도우 컴포넌트 객체 모델)을 사용하는 애플리케이션은 C++로 개발한다. 하지만 C++는 꽤 어려운 언어이고, 구문도 매우 어렵다. 델파이는 COM 서버, 자동화 서버 등등 COM을 사용하는 복잡한 애플리케이션을 만들 수 있는 유일한 프로그래밍 언어다. 델파이의 타입 라이브러리 에디터가 가끔은 조금 까다롭다는 점 말고는, 내가 아는 한 작업이 C++보다 훨씬 더 간단하다.

나는 마이크로소프트의 Dynamic Virtual Channels를 성공적으로 구현했다. 이것은 멀티 스레드 COM 서버를 생성하는 작업에 관여하는데, 그 COM서버에서는 세 가지 인터페이스를 구현했다. Virtual channels 참조. 이를 통해, RDP 세션 안에서 실행되는 프로그램은 내 컴퓨터에 있는 프로그램들과 통신할 수 있다. 나는 이 모든 것을 델파이로 작성했고 성공적으로 배포했다.

 

이 글은 기업용 대형 애플리케이션에 대한 기고 경연 대회(Enterprise Article challenge)에 제출된 것이다. 만약 여러분도 델파이, C++빌더 또는 RAD 스튜디오를 사용하여 만든 훌륭한 엔터프라이즈 제품과 프로젝트에 대해 이야기하고 싶은 성공 사례가 있다면 연락을 주기 바란다.

한국 개발자는 데브기어의 델파이 사례 기고 행사에 참여하세요!

이 댓글 링크
다른 사이트에 공유하기

  • 4주 후...

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.