앞 글에서는 하위 레이어에서 error를 어떻게 반환할지에 대해 다뤘습니다. 이번 글에서는 반환받은 error를 상위 함수에서는 어떻게 처리할지에 대한 고민과 그 결과를 이야기하려고 합니다.고민하위 레이어에서 올라온 error를 처리할 때 두 가지 고민이 있었습니다.어디까지 error를 올릴 것인가error를 어떻게 처리할 것인가첫 번째 글에서 이야기했듯, V1에서는 error와 함께 error code를 올리며 모든 지점에서 로그를 남겼습니다.그리고 하위 레이어에서 올라온 error가 어떤 것인지 구분할 수 있는 방법이 없었기 때문에 대안으로 code를 사용했습니다.하위 레이어에서 반환하는 code 제거앞에서 사용한 code의 값은 실제 API 응답으로 사용되는 값이었기 때문에, 비즈니스 로직의 결과로 얻어야 하는 값을 DB 레이어에서 생성함으로 인해 DB 레이어에 비즈니스 로직이 침투할 가능성이 있었습니다. 실제로 V1의 코드에서 DB 레이어에 비즈니스 로직이 포함된 경우도 있었습니다.이렇게 비즈니스 로직이 DB 레이어에 침투할 가능성을 차단하고 명확하게 역할을 구분하기 위해 DB 레이어에서 code를 반환하지 않게 할 방법이 필요했습니다.error 처리하위 레이어에서 반환하는 code를 제거한다면 상위 레이어에서 error가 어떤 것인지 구분할 수 있는 다른 방법이 필요했습니다. 또한, 해당 error가 정상적인 경우인지 아닌지 판단할 수 있는 비즈니스 로직을 담은 곳에서 최종적으로 error를 어떻게 처리하고 응답을 만들지 고민이 필요했습니다.개발 과정하위 레이어에서 반환하는 code 제거우선 기존의 (result, code, error)를 반환하는 구조에서, code를 제거하고 (result, error)만 반환하는 구조로 변경했습니다.변경된 코드// DB Layerfunc (db *mongo.Collection) FindFoo() (Foo, error) { // ... result, err := db.Find() if err != nil { return result, errUtils.Wrap(err) } return result, nil}그 결과, 하위 레이어에서는 단순히 error를 래핑하여 반환하고, 비즈니스 로직이 담긴 곳에서 해당 error를 처리합니다.// Service(business logic) Layerfunc DoService() error { // ... result, err := dbLayer.FindFoo() if err != nil { if errUtils.IsNotFoundError(err) { // 404 response } // 500 response } return nil}DB 레이어에서의 error 구분에는 이전에 MongoDB 추상화에서 개발한 함수를 이용했습니다. DB 레이어에서 발생하지 않거나 각 서버만이 가지고 있는 error는 github.com/pkg/er

안녕하세요, 만 2년차 개발자로 클로바노트 서버를 개발하고 있는 김준하입니다. 이 글의 시리즈에서는 클로바노트 V2를 개발하며 팀 내부 코드 구조를 개선한 이야기를 해보려 합니다. 최대한 누구나 이해하기 쉽게 설명하려 노력했지만 코드에 대한 내용이 어느 정도 있다 보니 Golang을 한 번이라도 접해보신 분이면 좀 더 이해하기 쉬울 것 같습니다.미야자키 하야오 감독의 영화 “그대들은 어떻게 살 것인가”를 아시나요?호불호가 갈리는 영화지만 저는 즐겁게 관람했습니다. 어떠한 정답을 직접 관객에게 주려고 하지 않고 본인의 삶을 풀어낸 회고록 같은 영화였습니다. “나는 이렇게 살았고, 이런 것을 후회하고 깨달았는데, 그래서 그대들은 어떻게 살 것인가요?” 이렇게 질문을 던지는 듯했습니다.맞습니다. 영화 제목을 변형해서 이 글의 제목을 지어보았습니다. 제가 현재 팀에서 처음으로 Golang을 접하고 Golang으로 API 서버를 개발하면서 겪었던 고민과 결과물을 여려분께 소개하려 합니다. 제가 영화 제목을 변형했듯이 이 글의 내용은 저의 개발 일대기입니다. 여러분이 “이 사람은 이런 생각을 했고 이렇게 문제를 해결했구나” 하며 읽어주시면 좋겠습니다.시작하기 전에글을 시작하기 앞서, 제가 고민했던 부분이 더 잘 이해되도록 Golang의 몇 가지 특징과 컨벤션을 소개하겠습니다.Don’t panicGolang을 처음 접한 사람들에게 가장 크게 눈에 띄는 부분은 error에 관한 부분입니다. Java 같은 언어는 예외(exception)를 try/catch로 처리하는 방식을 사용하지만 Golang에는 try/catch가 없습니다. try/catch와 비슷한 panic/recover가 있기는 하지만, Golang에는 Don’t panic이라는 가장 중요한 컨벤션이 있습니다. error를 처리할 때는 panic을 사용하지 말고 error 자체를 반환하라는 것입니다.func openFile(fn string) error { f, err := os.Open(fn) if err != nil { return err // panic(err) // don't panic! } defer f.Close() return nil}func main() { // 잘못된 파일명을 넣음 if err := openFile("Invalid.txt"); err != nil { fmt.Println(err) }}panic은 프로그램이 종료되어야 마땅한 상황(stack overflow, OOM 등)에만 사용되어야 하며 recover를 통해 프로그램을 되살릴 수 있습니다.Errors are valuepanic이 사용되어야 하는 상황을 제외하면 error를 값으로 취급하는 접근 방식을 취합니다.Values can be programmed, and since errors are values, errors can be programmed.출처: The Go Blog값(value)은 변수나 상수에 할당하거나 조작

앞서 인코더와 라이브 서비스에 관한 내용을 다뤘는데요.이번 편에서는 플레이어 백엔드 서버와 로그 수집 분석에 대해 다뤄보고자 합니다. 아직 '우당탕탕~ 영상 서비스 개발기 2탄 : 인코더와 라이브 서비스' 편을 보지 못하셨다면 아래 글을 클릭해 주세요! ▶️ 우당탕탕~ 영상 서비스 개발기 2탄 : 인코더와 라이브 서비스 우당탕탕~ 영상 서비스 개발기 2탄 : 인코더와 라이브 서비스앞서 영상 서비스 어드민, VODKA에 관한 내용을 다뤘는데요. 이번 편에서는 영상 서비스 인코더와 라이브 서비스에 대해 다뤄보고자 합니다. 아직 '우당탕탕~ 영상 서비스 개발기 1탄 : 어드민, VODKkakaoentertainment-tech.tistory.com    오늘도 화목한 영상서비스개발팀   [Chater 5] 플레이어 백엔드 서버 VODKA(CMS) 백엔드 API부터 Player 백엔드 API까지 다양한 기능의 API를 개발합니다. 해당 챕터에서는 백엔드 API를 개발할 때 어떤 기술과 Framework를 사용했는지, 어떤 고민이 있었고 어떻게 해결해 나갔는지에 대해 설명하고자 합니다. 1.  Go VS Java 첫 시작은 위에서 설명한 VODKA(CMS)의 백엔드 API 개발부터 시작되었습니다. 이번 프로젝트는 GCP를 활용하여 개발을 진행하였습니다. VODKA는 내부에서만 사용하는 Admin 툴이다 보니 트래픽이 높지 않고, 비교적 간단한 CRUD 형태의 백엔드 서버를 개발하면 될 것으로 생각했기에 다른 환경에서는 사용해보지 못한 GCP의 Serverless 서비스인 Cloud Function이나 Cloud run을 사용해 보면 좋겠다는 의견이 나왔습니다. 단, Serverless를 이용하게 되면 Cold Start 시간문제가 발생하는데, 이 때문에 과거 백엔드 API 구성 시 주로 사용했던 Java + Spring boot를 사용하지 못한다는 결론이 나왔습니다. Cold Starts in Google Cloud Functions (https://mikhail.io/serverless/coldstarts/gcp/)Cold Starts in Google Cloud Functions (https://mikhail.io/serverless/coldstarts/gcp/) 위 그림에서 보이듯이 기본 Java만 사용한다면 Cold Start 시간이 오래 걸리지 않습니다. 하지만 대부분 Java로 웹 프로젝트를 생성할 때는 Framework로 Spring을 사용하게 됩니다. Serverless 기반에서 Spring으로 프로젝트를 구성하고 첫 호출을 하게 되면 Spring의 기동시간만큼 딜레이(일반적으로 약 ~30초)가 발생하기 때문에 Cold Start 이슈가 발생합니다. 이러한 이유로 성능적으로 문제가 되지 않는 Go를 고려하게 되었습니다. Go 언어의 장점은 아래와 같습니다1️⃣ 빠른 컴파일과 실행 속도Go는 컴파일 시간이 빠르며, 실행 속도도 빠릅니다. 이는 Go 언어의 특징 중 하나인 병행성(Concurrency)과 관련이 있습니다. 또한, Go는