GHTS

Java의 경우 프로그램 안에 SQL 데이터베이스를 내장하는 선택지가 몇 개나 존재한다.

(HSQLDB, H2 및 Apache Derby등등)

Go언어의 경우 (NoSQL, K/V 저장소는 있어도) 마땅한 내장형 SQL 데이터베이스가 없어서 아쉽다고 느꼈는 데, 알고보니 약 2년 전에 이미 Go언어로 작성된 SQL 데이터베이스가 작성되었는 데, 모르고 있던 것일 뿐이었다.

검색의 생활화가 시급하다는 것 또 다시 깨닫는다.

C언어로 작성된 sqlite를 Go언어로 포팅한 것인데, 배포 편의성을 감안하면 아주 유용할 것 같다.

https://gitlab.com/cznic/sqlite

https://pkg.go.dev/modernc.org/sqlite

그동안 증권사 API는 MS-윈도우에 특화된 DLL, OLE, OCX등의 형태로 제공되는 경우가 대부분이어서, 시스템 독립적인 프로그래밍 언어로는 (특히, 사용자가 많은 Java는 심각할 정도로) 매매 시스템을 작성하기 힘든 면이 많았다.

이 블로그도 Go언어로 증권사 API를 호출하기 위해서 복잡다단한 단계를 거치다가 만들게 되었다.

그런데, 이제 프로그래밍 언어에 독립적인 REST로 형태로 제공되는 API가 생겨서 그런 제약 사항이 사라졌다.

https://apiportal.koreainvestment.com

Rust 책을 찾다가 분량이 작아서 샀는 데, 읽다보니 웹어셈블리(WebAssembly)에 대한 비중이 높다.

웹어셈블리는 소스코드에서 컴퓨터에서 실행되는 기계어로 전환되는 중간 단계인 자바나 C#의 바이트코드 개념이다.

실제로 자바나 C#처럼 웹브라우저 밖에서 독립적인 실행도 가능하다는 것을 알게 되었다.

오토캐드와 라이트룸이 웹어셈블리로 이식되어서 리눅스에서도 실행하는 것을 보면서 상당히 충격 먹었다.

화면 크기만 받쳐준다면 안드로이드, iOS 태블릿에서도 캐드하고 사진보정할 수 있다는 의미 아닌가?

만약 오피스 프로그램도 웹어셈블리로 이식되면 더 이상 PC의 존재 이유가 있을까?

최근 몇 년간 금융투자에 몰두하는 동안에 컴퓨터 및 프로그래밍 관련 분야에서 엄청난 기술 발전이 일어나는 것을 놓치고 있었던 것 같다.

Go언어는 버전별로 안정성에  큰 기복이 있는 듯 하다.

Go 1.17 출시 초기 버전을 적용하고,  장중에 매매 시스템에서 에러가 발생하면서 중단되는 현상을 몇 번 경험했고, 이후 안정성이 확보된 1.16으로 되돌아갔다.

Go 1.18의 경우 더 심각한 데, 1.18.2가 발표된 현재 시점까지 가장 기초적인 DLL 호출에서 에러가 발생하며 유닛 테스트도 통과하지 못한다.

그래서, 여전히 Go 1.16.15 버전에 머물러 있다.

예외 처리를 if문에 의존하는 Go언어 특성 상 Generics가 없는 1.16 버전으로는 코드 가독성이 떨어지는 지라,  코드 가독성 개선을 위해서 Go 1.18의 Generics 기능을 애타게 기다려온 입장에서, Go 1.18이 기본적인 DLL 호출에서조차 에러가 발생하는 상황이 실망스럽기 그지없다.

Go언어 특유의 빠른 컴파일 속도와 간결한 코드, 높은 개발 생산성 덕분에 어찌어찌 자동 매매 시스템 개발에 성공해서 운용하는 단계에 이르렀으므로, Go언어는 내 인생에서 소중한 존재임은 틀림없지만 현 시스템을 개선하는 데 장애물로 작용하는 것도 사실이다.

이럴 바에야 Go 언어의 대안을 찾아봐야 겠다는 생각이 들어서, Rust 언어를 공부하기 시작했다.

Rust 언어로 재개발 하는 데 성공하지 못하더라도, 이미 개발해 놓은 Go언어 시스템을 계속 사용하면 되므로, 어떻게든 성공시켜야 하던 절박함은 많이 줄어들었기에, Rust언어로 재개발을 완성할 때까지 끈질기게 진행할 수 있을 지는 모르겠다.

지금까지 공부한 바로는 Rust 언어도 try/catch/finally로 대표되는 예외처리 기능이 없고, 에러 발생 여부를 match문을 이용해서 일일이 확인해 줘야 하지만, 코드의 반복을 줄여주는 '?' 연산자가 존재하므로, 에러처리 때문에 코드 가독성이 낮아지던 Go언어에서의 문제는 없는 듯 하다.

그외 Generics/메모리 안정성/동시처리 등 여러가지 기능 면에서도 부족해 보이지 않는다.

다만, 변수 소유권 문제등 새로운 개념을 습득해야 하고, 예외처리를 제외한 나머지 코드 가독성은 Go언어보다 떨어지고, 컴파일 속도도 Go언어보다 많이 느리므로 개발 생산성도 낮을 텐데, 이 나이에 굳어버린 머리로 이런 단점을 극복해 낼 수 있을 지 모르겠다.

여러모로 Go 언어 1.18에서 기본적인 DLL 호출에서조차 에러가 발생하는 현 상황이 너무 안타깝다.

Go언어를 쓰면서 느끼는 가장 큰 불편은 '에러처리'이다.

try-catch 같은 예외처리 기능이 없으며, if문에서 일일이 에러발생 여부를 확인해야 한다.

if 반환값, 에러 := F실행할_함수(인수1, 인수2....); 에러 != nil {

<여기에서 에러처리....>

}

이 방식은 다음과 같은 문제점이 있다.

1. 실행할_함수()는 if문에 파묻혀서 잘 보이지 않는다.

2. 소스코드가 지저분해진다. 소스코드 중간중간에 if문이 끼어들어서 흐름을 끊어놓는다.

그럼에도 불구하고 장점도 있다.

1. 예상하지 못한 동작이 발생하는 것이 예방된다. -> 오작동이 치명적인 경우에는 장점이 된다.

2. 각 에러마다 정확한 개별 대응이 쉽다.

이런 장점에도 불구하고, if문을 사용하는 에러처리 패턴이 불편하게 느껴지는 것은 사실이다.

defer, recover, panic을 조합하면 예외처리 기능처럼 에러를 뭉뚱그려서 한 번에 처리할 수 있다.

try-catch문은 예외가 발생하면 실행이 중단되고, catch문 내용이 실행된다.

go언어에서는 panic이 발생하면 실행이 중단되고, defer문으로 등록한 함수가 실행된다.

실행 흐름은 다음과 같으며 소스 코드에서 번호를 매겨놨다.

1. 에러발생

2. 패닉발생

3. defer

4. recover

5. 에러처리

func F함수_정의(인수A, 인수B,...) {

defer func() {    // 3 : 함수 실행이 종료될 때 자동으로 실행된다. 패닉이 발생해도 실행된다.

if r := recover(); r != nil {    // 4 : recover함수를 실행해서 패닉된 경우 복구한다.

<여기에서 뭉뚱그려서 에러처리>

}

}()

.....

반환값, 에러 := F실행할_함수(인수1, 인수2....)

if 에러 != nil {    // 1 : 에러가 발생하면 패닉을 발생시켜서 함수의 실행을 종료하도록 한다.

panic(에러)    // 2  :  패닉이 발생하면 실행이 중단되고,  defer로 함수로 넘어간다.

}

....

}

언뜻 보면 소스코드가 오히려 더 복잡해진 느낌이다.

그러나, 다음 2개의 도우미 함수를 사용해서 반복되는 부분을 제거할 수 있게 된다.

func F에러2패닉(에러 error) {

if 에러 != nil {    // 에러가 발생하면 패닉 되도록 한다.

panic(에러)

}

}

func F패닉_처리(함수 func(r interface{}) {

if r := recover(); r != nil {    // 패닉이 발생한 경우 패닉을 복구하고 지정된 함수를 실행한다.

함수(r)

}

}

도우미 함수를 이용해서 소스코드를 간단하게 수정하면 다음처럼 된다.

func F함수_정의(인수A, 인수B,...) {

defer F패닉_처리(func(r interface{}) {

<여기에서 뭉뚱그려서 에러처리>

})

.....

반환값1, 에러 := F실행할_함수_1(인수1, 인수2....)

F에러2패닉(에러)    // 에러는 패닉으로 전환되고, defer에 등록된 패닉처리 함수가 실행됨.

// 여기까지만 보면 크게 좋은 점을 모르겠으나, 

// 처리해야 할 에러가 많아지면 이러한 방식의 장점이 드러난다.

....

반환값2, 에러 := F실행할_함수_2(인수1, 인수2....)

F에러2패닉(에러)

....

반환값3, 에러 := F실행할_함수_3(인수1, 인수2....)

F에러2패닉(에러)}

...

}

타 언어의 try-catch 방식의 예외처리문보아야 여전히 불편하긴 하지만,

if문을 사용해서 모든 에러를 일일이 확인하는 기존의 방식보다는 훨씬 간편하다.

GHTS에서는 lib.S예외처리{}.S실행() 으로 되어 있으며

S예외처리의 필드값을 변경하여 실행 옵션을 선택할 수 있다.

Go언어는 효율성을 추구하는 실용적인 프로그래밍 언어이다.

1. 개발 효율성 (혹은 생산성)

2. 실행 효율성 (멀티코어 CPU 활용)

이렇게 2가지의 효율성을 추구하는 대신 기능성은 포기했다.

go언어 창시자는 C++언어가 너무 복잡해서 go언어를 만들었기에

미니멀리즘의 극한을 추구하는 것으로 유명하다.

(어쩔 때는 그게 좀 과한 듯 하다.

 키워드 숫자를 줄이려고 interface가 가변형 자료형을 겸하는 것은 혼동을 유발하고,

 에러 처리를 if문으로 처리하니 상당히 불편하다.) 

개발자 생산성 향상을 위해서는 다음 특징을 가진다.

1. 빠른 컴파일.

2. 단순하지만 필수기능은 다 갖춘 문법.

3. 자동 메모리 관리

4. 유니코드 지원

5. 풍부한 표준 라이브러리 및 수많은 제3자 공개 라이브러리.

6 테스트, 테스트 커버리지, 동시 사용 데이터 충돌(레이스) 감지등 풍부 개발 도구 기본 내장

마지막으로...

7. 소스코드 자동 정리 (써보면 입이 떡 벌어진다. 소스 코드 들여쓰기로 분쟁이 생길 소지를 원천 봉쇄.)

하드웨어의 효율적 사용을 위해서 다음 특징을 가진다.

1. AOT 컴파일. (C, C++의 컴파일 개념. Java나 C#이 사용하는 JIT컴파일의 반대 개념.)

2. C보다 2배 정도 느리고, Java와는 비슷한 상당히 우수한 단일 스레드 실행 속도.

3. 멀티코어 CPU를 안전하고 효율적으로 사용하기 위한 독특한 기능 (goroutine, channel)

Go언어에서는 포기한 기능들은 다음과 같다.

1. 상속은 지원하지 않음. 대신 mixin을 지원.

2. 제너릭은 지원하지 않음. 대신, interface{}가 가변형 변수 역할을 함.

(제너릭 기능은 Go언어 창시자들이 미니멀리즘에 기반하여 의도적으로 배제한 것이 아니라,

 Go언어 창시자들이 기술적인 문제를 해결하지 못해서 아직 추가되지 못한 경우임.)

3. 에러 처리 구문이 취약함. 대신, defer문, recover()함수를 사용해서 panic상황에 대처 .

이러한 장단점이 혼합된 Go언어를 실제로 사용해 본 느낌과,

1. 기능성이 약간 부족하지만 오히려 간결해서 좋은 면도 있다.

   기능이 풍부하지 않지만 꼭 있어야 하는 기능들은 거의 다 있으며,

   반대로, 쓸데없는 기능이 없기 때문에 남이 개발한 소스 코드를 읽을 때도

   처음보는 기능을 접하는 경우는 거의 없다.

   그래서, 불러다 쓰는 제 3자 라이브러리가 의심스러우면 

    (저작권 문제가 없는 한도 내에서) 거리낌없이 소스 코드를 들여다보고 만지작 거리게 된다.

2. 개발 생산성이 확연하게 높아진다.

3. 실행속도 문제로 걱정할 일이 없다.

트위터가 서비스 초기에 루비(Ruby)언어를 사용했으나, 성능 상의 문제로 인해서 서비스 불안정의 어려움을 겪었고, 결국은 상당 부분을 Java와 Scala언어로 다시 개발해야 했다.

드롭박스도 서비스 초기에 파이썬(Python)언어를 사용했으나, 성능 상의 문제로 인해서 백엔드 상당 부분을 Go언어로 대체하였다.

트위터와 드롭박스의 공통점은 높은 개발 생산성을 얻기 위해서

루비(Ruby), 파이썬(Python)등 동적언어를 사용하였으나,

성능상의 문제로 인해서 동일한 기능을 실행 성능이 높은 정적 언어로 다시 작성했다는 것이다.

Go언어는 개발 생산성도 높고, 실행 성능도 상당히 높은 편이므로,

이러한 고민을 동시에 해결할 수 있으며,

무한 경쟁 시대에 비용 효율성 면에서 강점을 가진다.

(거대 S/W 기업이 된 구글이 자체적인 비용 절감 차원에서 만든 것 같다.)

그 대신에 포기해야 하는 것이 기능성인데, 

막상 써보면 기능이 심하게 부족하다고 느껴지지는 않는다.

물론, C++, Java, C#등을 사용하던 사람은

1. 변수 선언 순서가 반대임.

2. 에러 처리 구문이 없고 if문으로 처리함.

3. 제너릭이 없음

등의 장애물에 좌절하곤 하지만 

실제로 사용해보면 의외로 그럭저럭 쓸만 하다.

(Java도 1.4까지 Generic이 없었지만 다들 잘 썼다.)

Go언어를 가장 잘 설명하는 문구는  '모든 면에서 80%'이다.

파이썬(혹은 루비) 개발 효율성의 80%,

C++ 실행 효율성의 80% (사실은 50%이지만, 동적 언어보다 수백배 빠르므로 체감상 80%)

모든 면에서 약간씩 부족하고 아쉽지만,

비용절감의 면에서는 타의 추종을 불허하고,

여러모로 공동작업이 편하다.