C 트레이딩 시스템 튜토리얼

트레이딩 시스템 코딩.
Justin Kuepper 저.
자동화 된 거래 시스템은 어떻게 생성됩니까?
이 튜토리얼에서는이 프로세스의 두 번째 및 세 번째 부분에 초점을 맞춰 설명합니다. 여기서 규칙은 거래 소프트웨어가 이해하고 사용할 수있는 코드로 변환됩니다.
장점과 단점.
자동화 된 시스템은 거래에서 감정과 바쁜 업무를 취하므로 전략 및 자금 관리 규칙을 개선하는 데 주력 할 수 있습니다. 수익성있는 시스템이 개발되면 중단되거나 시장 상황에 변화가 필요할 때까지 작업을 할 필요가 없습니다. 단점 :
시스템이 올바르게 코딩되고 테스트되지 않으면 큰 손실이 매우 빠르게 발생할 수 있습니다. 때로는 특정 규칙을 코드에 넣는 것이 불가능하기 때문에 자동화 된 거래 시스템을 개발하기가 어렵습니다. 이 자습서에서는 자동화 된 거래 시스템을 계획하고 설계하는 방법, 이 디자인을 컴퓨터가 이해할 수있는 코드로 변환하는 방법, 최적의 성능을 보장하기위한 계획을 테스트하는 방법 및 마지막으로 시스템을 사용하는 방법에 대해 학습합니다.

C ++ 거래 시스템 자습서
App Store를 통해 가져 오기 우리의 응용 프로그램 에서이 게시물을 읽으십시오!
간단한 C ++ 거래 시스템 데모.
내 거래 시스템 데모를 검토해야합니다. 그것은 다른 상인의 거래 흐름 (로그인 파일)을 구문 분석하고 몇 가지 중요한 기능을 계산하는 간단한 시스템을 구현했습니다.
코드 개선에 도움이되는 몇 가지 사항을 발견했습니다.
네임 스페이스 std를 사용하여 남용하지 마십시오.
모든 프로그램의 맨 위에 네임 스페이스 std를 사용하는 것은 좋지 않은 습관입니다. 특히 당신은 헤더 파일에서 그것을 사용해서는 안됩니다.
적절한 헤더를 사용하십시오.
대신에 stdint. h를 사용하는 대신 다음을 사용해야합니다.
이것은 헤더로부터의 것들을 전역 네임 스페이스가 아닌 std :: namespace에 넣고 나중에 두통을 저장합니다. (전역 네임 스페이스에 항목을 추가 할 수도 있지만 프로그래머는 구현 정의 동작에 의존하지 않아야합니다.)
사용되지 않는 변수를 제거하십시오.
이 코드는 여러 변수 (term, qty, nread)를 선언하지만 그와 아무런 관련이 없습니다. 컴파일러는 그렇게하도록 요청하는 방법을 알고 있다면 이런 종류의 문제를 찾는 데 도움이 될만큼 똑똑합니다.
마법의 숫자를 피하십시오.
설명이없는 번호가 포함 된 행은 대기중인 유지 보수 문제입니다. 예를 들어 코드에는 주석없이이 행이 포함됩니다.
그것들은 실제로 무작위가 아니지만 그 숫자의 중요성에 대한 힌트는 없습니다.
while (! fin. eof ())을 사용하지 마십시오.
while (! fin. eof ()) 또는 이와 동등한 것을 사용하는 코드를 작성하는 것은 거의 항상 오류입니다. 결정에 관심이있는 것은 데이터가 남아 있고 스트림의 끝이 아닌지 여부입니다. . 자세한 내용은이 질문을 참조하십시오.
쓸모없는 변수를 확산시키지 마십시오.
이 코드에는 현재이 라인 쌍이 포함됩니다.
악기 문자열은 다시 사용되지 않습니다. 왜 대신이 글을 쓰는 것이 좋을까요?
적절한 제어 흐름 구조를 사용하십시오.
main 내에서 코드는 msg_type 필드를 기반으로 데이터를 처리하는 방법을 결정합니다. 그것은 계단식 경우가 있습니다. else에 빈 마지막 else 절이 있습니다. 그러나 이것은 각 메시지가 다른 메시지 유형을 나타내는 switch 문으로 훨씬 명확하게 작성됩니다.
표준 알고리즘을 사용하십시오.
현재 코드에는 다음 시퀀스가 ​​포함됩니다.
그 목적은 가장 큰 거래량과 관련 거래자를 확인하는 것입니다. 그러나이 알고리즘은 이미 std :: max_element입니다.
반환 0을 생략하십시오.
C ++ 프로그램이 메인의 끝에 도달하면 컴파일러는 자동으로 0을 반환하는 코드를 생성하므로 return 0을 넣을 이유가 없습니다. 명시 적으로 메인의 끝에.
오브젝트를보다 완벽하게 사용하십시오.
코드에는 클래스가 있지만 OrderEntry 및 OrderAck와 같은 간단한 컨테이너가 거의 독점적으로 사용됩니다. 이제 main 내부에서 이러한 구조에 대해 수행중인 작업을 수행하기 위해 멤버 함수를 추가 한 경우 코드를 더 간단하고 쉽게 이해할 수 있습니다.

저 대기 시간 시스템에 C ++ 사용.
이 수업은 2016 년에 진행되었으며 역사적인 목적으로 만 온라인으로 진행됩니다.
& # 8220; 저 대기 시간 시스템에 C ++ 사용하기 & # 8221; Sherbrooke University의 Patrice Roy가 가르치는 이틀 간의 교육 과정입니다. 9 월 17 일 토요일과 일요일, 오전 9 시부 터 오후 5 시까 지 Meydenbauer에서 제공됩니다 (컨퍼런스 직전). 점심 식사가 포함되어 있습니다.
코스 설명.
게임 및 고주파수 거래와 같이 가장 까다로운 애플리케이션에서 요구되는 성능을 얻으려면 메인 스트림 C ++에서 찾을 수없는 저 대기 시간 기술을 숙달해야합니다.
이 클래스는 C ++로 저 대기 시간 시스템을 만드는 데 필요한 기술을 제공합니다.
낮은 대기 시간 제약 조건을 가진 시스템을위한 구성 요소를 개발하는 방법 예측할 수없는 성능을 가진 시스템을 개발하는 방법 특히 최악의 실행 시간이 작용하는 경우 어떻게 런타임시 대신 컴파일 타임에 계산을 수행 할 것인가? 프로그램의 공간 오버 헤드 메모리 관리를보다 효율적으로 만드는 방법 여러 가지 방법으로 캐시 메모리를 최대한 활용하는 방법 스마트 포인터를 최대한 활용하는 방법 휴대용 프로그램에서 프로그램의 성능을 측정하는 방법.
강조는 이식 가능한 코드에 적용되며 C ++ 11 / C ++ 14 기능을 사용합니다. 예는 측정으로 뒷받침되며 공개 토론이 권장됩니다.
전제 조건.
참가자는 C ++ 언어에 대한 중간 지식이 있어야합니다. 예측 가능한 & # 8212;와 함께 견고한 C ++ 코드에 중점을 둘 것입니다. 빠른 & # 8212; 런타임 동작.
이 과정에는 실습이 포함되어 있으므로 랩톱과 좋아하는 C ++ 11 / 14 개발 환경을 가져와야합니다.
코스 주제.
이 과정은 프로그래머가 지연 시간이 짧은 제약 조건에서 더 나은 성능 또는 안정적인 성능을 얻는 데 사용할 수있는 기술에 중점을 둡니다. 이 중요한 주제의 선택된 하위 집합을 다루는 섹션으로 세분됩니다. 각 섹션에서는 C ++ 11/14 기능에 중점을 두어 섹션 목표를 달성하는 데 도움이되는 C ++ 기능에 대해 설명합니다.
"저 대기 시간"이란 의미를 정의합니다. 실시간 시스템과의 유사점과 차이점에 대해 토론하십시오. 최악의 실행 시간 개념을 소개하고 측정 유틸리티 및 기법을 논의합니다. C ++ 프로그래밍의 탄력성 측면에 대해서는 여기에서 다룰 예정이지만, 이 과정은 반복되는 주제가 될 것입니다.
사용되는 C ++ 기능에는 static_assert, 유틸리티, 가변 템플릿 및 자동 유형 차감 메커니즘이 포함됩니다.
일부 C ++ 기능에는 지연 시간이 짧은 시스템 개발에 대한 단점이 거의없고 단점도 거의 없습니다. 이 섹션에서는 가장 관련성이 높은 것들을 탐색하고 사용합니다.
사용되는 C ++ 기능에는 unique_ptr 및 make_unique, constexpr, 자동 형식 공제 메커니즘, 형식 특성, enable_if, using 키워드의 흥미로운 사용법 및 이동 의미가 포함됩니다.
저 대기 시간 시스템에서주의가 필요한 C ++ 기능.
C ++ 기능은 대기 시간이 짧은 시스템에서 사용할 수 있지만 특별한주의 만하면 비용이 그 이익보다 높을 수 있습니다. 정보에 근거한 판단을 내리기 위해 합리적이고 측정에 기반한 접근 방식을 취할 것입니다.
사용되는 C ++ 기능에는 shared_ptr 및 make_shared, 예외, 다중 상속, RTTI 및 정의 된 대체가 포함됩니다. 또한 이러한 시스템에서 noexcept이 수행 할 수있는 역할에 대해서도 논의 할 것입니다.
저 대기 시간 시스템에서 표준 컨테이너 및 알고리즘 활용.
일부 회사는이 라이브러리가 제공하는 도구로는 요구 사항을 충족시킬 수 없다는 신념 때문에 일부 또는 모든 표준 컨테이너를 다시 작성합니다. 표준 라이브러리가 제공하는 컨테이너와 알고리즘을 최대한 활용하고 적절할 때 알고리즘을 향상시키는 방법을 모색하는 방법을 모색합니다.
동시성 및 병렬 프로그래밍.
대기 시간이 짧은 시스템에 대한 우려는 병렬 시스템과 동시 시스템의 시스템 문제를 여러 가지 방식으로 겹칩니다. 예를 들어 블로킹 작업 및 동기화 기능에 대한 의존도를 줄이는 것은이 두 영역에서 강력한 경향입니다.
사용되는 C ++ 기능에는 C ++ 11/14 스레드 및 원자 도구가 포함되지만 구성 요소가 이벤트에 적시에 대응할 수 있도록하는 사용 패턴에 중점을 둡니다.
C ++을 사용하면 프로그래머가 다양하고 흥미로운 방식으로 메모리 할당을 수동으로 관리 할 수 ​​있습니다. 지연 시간이 짧은 시스템을 구축 할 때 이러한 메커니즘을 우리의 이점으로 사용하는 방법을 모색 할 것입니다.
사용 된 C ++ 기능에는 C ++ 11 이전과 이후의 할당 자 작성 방법을 비롯하여 여러 가지 새로운 기능과 삭제 기능이 포함됩니다.
캐시 메모리 사용과 프로그램 성능에 미치는 영향에 대한 여러 가지 흥미로운 발표가있었습니다. 우리는이 질문의 뉘앙스를 예제로 살펴볼 것입니다.
사용되는 C ++ 기능에는 STL 컨테이너 및 알고리즘, 정렬 제어 메커니즘, 병렬 및 동시 프로그래밍 유틸리티가 포함됩니다.
물론 그렇게하는 것이 실용적 일 때 가장 빠른 프로그램은 아무 것도하지 않는 프로그램입니다. 우리는 메타 프로그래밍 기법과 작은 프로그램을 결합하여 계산을 컴파일 타임으로 이동시켜 그로 인해 이익을 얻는 방법을 모색 할 것입니다.
강사.
파트리스 로이 (Patrice Roy)는 전문적으로, 즐거움을 위해서, 또는 (대부분의 경우) 20 년 이상 동안 C ++로 노고왔다. 몇 년 동안 R & D를하고 군용 비행 시뮬레이터를 연구 한 후 그는 1998 년부터 학계로 전향하여 컴퓨터 과학을 가르치고 있습니다. 2005 년부터 그는 분야의 대학원생 및 전문가를 돕는 데보다 구체적으로 관여했습니다. 실시간 시스템 및 게임 프로그래밍을 통해 오늘날의 어려움에 직면 할 수있는 기술을 개발할 수 있습니다. 최근 몇 년 동안 C ++의 급속한 발전으로 그의 직업은 더욱 즐거워졌습니다.
그는 2014 년 말부터 ISO C ++ Standards Committee에 참여했으며 2015 년 말부터 ISO 프로그래밍 언어 취약성에 관여했습니다. 그는 5 명의 자녀를두고 있으며 그의 아내는 자신의 집에 지속적으로 변화하는 전화 번호가 있는지 확인합니다. 고양이, 개 및 기타 동물의

C ++로 코딩 된 거래 전략의 예
모든 거래 전략은 일련의 이벤트와 해당 이벤트에 대한 반응으로 나눌 수 있습니다. 반응은 무한히 복잡하고 다양해질 수 있지만 본질적으로 전략 작문은 정확히 간단히 적용됩니다. 사건의 종류와 빈도는이 전략이 시행 될 시장과 도구에 달려 있지만, 대부분의 시장에서 다음과 같은 다른 풍미가있을 것입니다.
사건의 종류.
시장 데이터 변경 & # 8211; 이것은 가격 변화 또는 크기 변화를 의미 할 수 있습니다. 마지막 거래 가격이 될 수도 있습니다. 교환에서 나온 보고서 & # 8211; 교환, 불합격 등의 확인서 주문 실행 & # ​​8211; 조기에 배치 된 주문의 일부 실행. 주문은 교환기로 전송됩니다. & # 8211; 어떤 책을 지키는 것은 아마도 위험 관리를 위해 교환 원에게 명령을 보낸 직후에해야 할 수도 있습니다. 간격 이벤트 & # 8211; 이것은 시장과 관련된 이벤트는 아니지만 정기적 인 간격으로 실행해야하는 로직과 같습니다. 예를 들면, 양초 형성. 새로운 포트폴리오로드 중 & # 8211; 새로운 포트폴리오가로드되면 이미 실행중인 다른 포트폴리오의 위험 한계가 변경 될 수 있으므로 주문 크기 등을 줄여야 할 필요가 있습니다. 사용자 매개 변수가 변경됩니다. 모든 전략에는 전략이 작동하는 프레임 워크를 정의하는 특정 사용자 입력 또는 매개 변수 집합이 필요합니다. 이것은 인용 주문 크기에서 전략이 취할 수있는 최대 노출까지 다양 할 수 있습니다. 이러한 매개 변수를 변경하면 일반적으로 재 계산의 일부 금액을 보증 할 수 있습니다.
연습으로 우리는 매우 간단한 전략을 살펴보고 전제를 사건에 대한 반응으로 어떻게 분해 할 수 있는지 살펴볼 수 있습니다. 본질적으로 다른 목적지에서 인용되는 동일한 악기가 이상적으로 같은 가치를 가져야한다는 사실에 기반한 순수한 재정 거래 전략을 고려해 보겠습니다. 하나의 교환에서 구매를 정당화하고 다른 교환에서 판매 할만큼 충분히 큰 가치에 불일치가있는 경우 그렇게합니다. 그래서 우리는 모든 매수와 매도에서 스프레드를 만들고 싶다고 말합니다. 따라서 제안 된 전략은 가격에 instr1을 인용하는 것입니다.
SellPrice = ask 2 + s.
여기서 buyprice와 sell prices는 instr1에서 구매 주문과 판매 주문의 가격입니다.
Bid1과 ask1은 instr1의 가격입니다.
Bid2와 ask2는 instr2의 가격입니다.
기본 논리는 구매 주문을 bid2-s에 일관되게 유지하고 ask2 +에 주문을 판매하는 것입니다. 매수 주문이 처형 될 때마다 bid2에서 instr2에 매도 주문을 보냅니다. 그래서 사실상,
bid2-s에서 구매하여 bid2 = & gt;에서 판매했습니다. 이 거래에서 벗어났다.
분명히 볼 수 있듯이 onMarketData 로직은 실제로 instr2의 시장 데이터에만 의존합니다.
마찬가지로 onExecution 논리는 instr1에서 주문 실행에 따라 달라집니다.
지금까지 좋은 소리. 이것은 일이 즉각적으로 일어나는 이상적인 세상에서 완벽 할 것입니다. 그러나 현실 세계에서 우리는 일정한 제약 하에서 운영됩니다. 그러한 제약이 있습니다.
주문이 교환기에 도착하는 데 제한된 시간이 걸립니다. 교환기가 주문을 확인하는 데 일정한 시간이 걸립니다. 승인 된 상태가 아닌 한 주문에 대체 요청을 보낼 수 없습니다.
이것은 분명히 사물을 변화시킵니다. 다음 일정을 고려하십시오.
T0 : 가격 b1 (= bid2 - s)로 주문 된 구매 주문
T1 : instr2가 눈금으로 이동합니다.
T2 : T0에서 보낸 주문을 확인했습니다.
T10 : 도구 2의 새로운 시장 데이터.
T1에서 우리 instr1의 구매 주문은 bid2 - 1 - s로 대체되어야합니다. 그러나 명령서가 승인되지 않았기 때문에 우리는 그것을 대체 할 수 없었고 주문은 여전히 ​​bid2-s에 머물렀고 새로운 시장 데이터가 T10에 올 때까지 거기에 머물러 있습니다. 확인 응답은 T2에 도착했습니다. 그러나 instr1의 인용은 instr2의 시장 데이터에만 의존하기로 결정했기 때문에 우리는 주문 (잘못된 가격으로 표시)을 대체하지 않았습니다. 즉, 이 순서가 T3이라고 말하면 실행됩니다.
bid2-s에서 instr1을 구입하십시오.
bid2 -1에서 instr2 판매 = & gt; 우리는 s-1 (s 대신)을 만들었습니다.
이를 피하기 위해 승인 보고서에도 대응할 수 있습니다.
그래서 새로운 의사 코드가 될 것입니다.
좋은 소식입니다. 물론 우리는 조금 더 깊이 파다. 다음 일정을 고려하십시오.
T0 : 구매 주문 O1이 가격 b1 (= bid2 - s)로 전송 됨
T1 : T0에서 보낸 주문을 확인했습니다.
T2 : 원래 오더 O1 실행. bid2에서 instr2에 발송 된 판매 주문을 처리합니다.
T3 : instr2 주문 실행. 실행 이후 instr2에 수행 된 작업은 없습니다.
T10 : 장비 2의 새로운 시장 데이터. instr1에서 보낸 새로운 구매 주문 O2.
T2와 T10에서 instr1에는 구매 주문서가 없습니다. 우리가 기회를 놓치고 있음을 의미합니다. 우리가 듣고있는 이벤트가 instr2에 대한 시장 데이터, instr1의 승인 및 instr1의 실행 이었기 때문에 우리는 T10에서 구매 주문을 처리합니다. 기회를 놓치지 않으려면 목록에 다른 이벤트를 추가하십시오. instr2의 실행. 결과적으로 의사 코드를 다음과 같이 수정할 것입니다.
지금까지 우리는 사형 집행이 완전히 또는 전혀 발생하지 않았다고 가정하고 있습니다. 부분적인 사형 집행은 깔끔한 논리에 웜의 깡통을 도입합니다. 이것은 우리가 존경해야하는 또 다른 제약 조건을 추가하기 때문입니다.
교체 할 때 우리는 거래소에 마지막 거래 시간이 무엇인지 말해야합니다. 마지막 거래 시간은 주문이 변경 (승인, 교체, 거래 등) 될 때마다 모든 교환기가 할당 한 타임 스탬프를 나타냅니다.
이제 이것은 다음 시나리오로 연결됩니다.
T0 : 구매 주문 O1이 가격 b1 (= bid2 - s)로 전송 됨
T1 : T0에서 보낸 주문을 확인했습니다. 마지막 트랜잭션 시간이 T1로 업데이트되었습니다.
T2 : instr2의 MarketData가 bid2 - 1로 변경됩니다. 가격을 bid2-1-s로 변경하기 위해 전송 된 요청 (T1을 최종 거래 시간으로 R1)을 대체하십시오.
T3 : R1이 교환에 도달하기 전에 원래 오더 O1의 부분 실행. 마지막 트랜잭션 시간이 교환 종료시 T3으로 업데이트되었습니다. bid2에서 instr2에 발송 된 판매 주문을 처리합니다. 주문이 미확인 상태 인 경우 instr1에서 보낸 대체 요청이 없습니다.
T4 : 교환은 마지막 트랜잭션 시간이 T3이지만 교체 요청이 T1과 함께 전송되기 때문에 주문이 거부되었습니다.
T10 : 장비 2의 새로운 시장 데이터. instr1에서 보낸 R2 요청을 대체하십시오.
T4와 T10 사이에서 instr1의 구매 주문은 여전히 ​​bid2-s (bid2-1-s 대신)에 있습니다. 다른 실행을 보게되면 미끄러질 수 있습니다. 우리는 반응하고 있기 때문에 적절한 가격으로 대체하지 않았습니다.
instr2에 대한 시장 데이터, instr1에 대한 승인, 사형 집행.
이제 알고리즘에 거부를 추가 할 수 있습니다.
지금까지 두 가지 매우 큰 가정을했습니다. 하나, 그 사건은 하나씩 일어난다. 사건에 대한 우리의 반응은 즉각적이다. 그러나 현실은 동시에 일어날 수 있습니다. 예를 들어 시장 데이터와 명령 중 하나가 실행되면 동시에 우리에게 도달 할 수 있습니다. 이것은 전략이 두 개의 서로 다른 스레드를 병렬로 실행한다는 것을 의미합니다. 마찬가지로 우리는 시장 데이터 이벤트에 대한 우리의 반응을 처리하는 동안 실행이 도착할 수도 있습니다. 이벤트를 병렬로 처리하는 경우 buyPosition 및 sellPosition과 같은 변수가 일관성이없는 상태 일 수 있으므로 구현에주의해야합니다. 다중 스레드 구현의 복잡성을 피하려면 연속적으로 이벤트를 순차적으로 처리 할 수 ​​있으며 비용은 대기 시간이됩니다. 우리는 멀티 쓰레딩 구현과 관련된 가장자리 사례와 다른 포스트에서 어떻게 우회 될 수 있는지 살펴볼 것입니다.
단일 스레드 구현에서도 매개 변수 변경과 같은 사용자 생성 이벤트는 아직 처리하지 않았습니다. 예를 들어, 사용자가 s의 값을 변경하기로 결정하면 어떻게 될까요? 우리는 다음 시장 이벤트가 우리의 견적을 적절한 가격으로 대체하기를 기다리는 대신에 그에 반응해야합니다. 이 게시물의 본질은 알고리즘 거래를위한 전략을 구현하기 전에 논리의 흐름을 더 자세히 파고 나누는 접근 방식을 소개하는 것입니다.
관련 게시물:
"C ++로 코딩 된 거래 전략의 예"에 대한 4 가지 생각
T2와 T10에서는 instr1에 구매 주문서가 없습니다. 우리가 기회를 놓치고 있음을 의미합니다. 우리가 듣고있는 이벤트가 instr2에 대한 시장 데이터, instr1의 승인 및 instr1의 실행 이었기 때문에 우리는 T10에서 구매 주문을 처리합니다. 기회를 놓치지 않으려면 목록에 다른 이벤트를 추가하십시오. instr2의 실행. & # 8221;
교환 2의 커버 오더가 실행되지 않아도 instr1을 실행해야한다고 여기에서 말하려고합니까?
instr1에 대한 승인 인 경우.
buyPrice = tick2.bid - s.
buyorder가 instr1에있는 경우.
그것을 buyPrice로 바꾸십시오.
buyPrice에서 새로운 주문을 보내십시오.
sellPrice = tick2.ask + s입니다.
sellorder가 instr2에있는 경우.
그것을 sellPrice로 바꾸십시오.
sellPrice에서 새 주문을 보내십시오.
instr1에서 구매 실행이 발생하면
instr2에 판매 주문을 보내십시오.
그렇지 않으면 판매가 isntr1에서 일어났습니다.
instr2에 주문서를 보내십시오.
실행이 instr2에 있으면 else입니다.
이것이 첫 번째 조건일까요? 실행이 instr2에있는 경우 instr1을 구매하거나 판매해서는 안됩니다. 맞습니까?
OnExecution 함수는 실행시에만 호출됩니다. 결과적으로 표지 실행이 발생했는지 여부에 대한이 검사는 암시 적입니다.
우리는 instr1에 대한 매수를 얻었을 수 있으며, 우리는 매도 주문 및 매도 주문을 instr1에 보냈고 커버 구매 주문서를 보냈습니다. 이제이 시나리오에서 판매 커버 주문에 대한 채우기가 발생하면 구매 커버 채우기가 아직 완료되지 않았을 수 있습니다. 우리의 알고리즘은 여전히 ​​OnMarketdata를 호출 할 것이고 그 함수는 채워지지 않은 커버 오더를 검사 할 것입니다. 이 경우에도 onExecution 함수는 변경되지 않습니다. 우리는 다음 게시물에서 이것을 상세히 설명 할 것입니다.