유 영모(slackbeck)https://www.linkedin.com/in/youngmo-yoo-aa78b4131

나는 지난 몇 년간 개발자를 코칭 하며 ‘프론트냐 백엔드냐’를 고민하는 당신에게 , 개발자를 코칭하며 배운 7 가지 , 장애는 우리의 문제다 등의 글을 썼다. 코칭 과정에서 개발자들이 성장에 대해 관심이 많다는 것을 알 수 있었다. 관심이 많은 만큼이나 스스로 성장이 정체된다고 느꼈을 때 고민이 크다. 하지만 안타까운 점은 자신이 왜 정체되는지 원인을 잘 찾지 못한다는 것이다. 나는 연차가 많아도 실력이 3~4년 차 정도의 사람들을 자주 본다. 이분들의 공통적인 특징은 학습을 하려 하지 않고 변화를 좋아하지 않는다는 것이다. 왜 그렇게 되었을까? 내 나름대로 추정해 보면 성장이 정체되었다고 느꼈을 때 원인을 찾지 못하고(않고) 성장이 멈춘 체 시간이 흐르면서 처음에는 성장을 하지 못하는다는 불안감이 점점 익숙함으로 바뀌고 그러한 익숙함은 현실에 안주를 불러 결국 경력이 늘어나도 성장이 멈춰 있게 된 것은 아닐까? 그렇다면...

ETag는 Entity Tag의 줄임말이다. Entity라는 말이 생소할 수도 있는데 Entity는 HTTP 메시지(Messages)와 연관이 있다. HTTP 메시지와 Entity HTTP 메시지는 HTTP 통신상에서 웹 서버와 클라이언트가 서로 주고받는 것을 의미한다. 클라이언트가 웹 서버로 보내는 메시지를 요청 메시지(Request Messages)라고 부르며, 웹 서버가 요청에 의해 클라언트에게 보내는 메시지를 응답 메시지(Response Messages)라고 부른다. [caption id="attachment_29284" align="aligncenter" width="600"] 출처: HTTP The Definitive Guide - 10 page[/caption] Entity는 HTTP 메시지의 일부를 말하는데 메시지는 Entity를 감싸 만든다. 즉 메시지는 컨테이너로 Entity는 화물로 비유할 수 있다. 아래 그림은 HTTP 메시지에서 Entity 영역을 보여준다. [caption id="attachment_29285" align="aligncenter" width="600"]...

MSA 환경에서 일하는 Front-end 개발자들을 만나면 나는 종종 이런 말을 듣는다. 주문서 화면을 만들 때 4~5개를 호출해서 조합해야 했어요. - 개발자 A 기부 상세 화면을 만드는데 같은 기부 번호로 여러 API를 호출해서 조합하고 있어요 - 개발자 B 벡엑드 개발자분이 API를 너무 잘 개 만들어 놔서 하나의 화면을 만들때 여러 번 호출하는게 너무 불편합니다. 에러 처리하기도 그렇고요. 한 번의 호출로 만들어 달라고 요청했는데 거부 당했습니다. - 개발자 C 무엇이 문제인가?...

몇 개월 동안 애정을 가지고 개발한 서비스가 있었다. 계약이 종료됨에 따라 인수인계를 해야 하는 상황이 되었고 인수인계 과정에서 알게 된 것은 만든 서비스를 버리려 한다는 사실이었다. 마이크로서비스 아키텍처를 차용하여 별도 서비스로 만들었지만 누군가는 그것을 모놀리스로 합치려 하고 있었고, 태블릿 기기에서 사용하도록 만들었지만 누군가는 그것을 PC 데스크톱으로 만들려 하고 있었다. 의도한 설계와 전혀 다른 방향으로 전개되고 있었다....

나는 Go에서 Error가 발생할 때 Stack Trace를 함께 출력하는 ‘ Golang Error Stack Trace와 로깅 ’ 라는 글을 쓴 적이 있다. 하지만 시스템을 운영하면서 Panic을 Recover한 경우 Error Stack Trace가 출력되지 않는다는 것을 발견했다. 이 글은 ‘ Golang Error Stack Trace와 로깅 ’ 에 이어지는 글로 Panic을 Recover한 경우에도 Stack Trace를 출력하는 방법을 소개한다. Panic 우선 Go에서는 Java와 같은 Exception이 없다. 명시적으로 Error를 전달하여 처리하며 관용적으로 마지막 반환 값을 사용한다. 아래 코드를 보면 f1 함수를 호출할 때 반환 값의 error가 nil 이 아니면 error가 발생한 것이다....

내가 주니어 시절에 있었던 일이다. 입사 한지 얼마 되지 않았던 상황에서 코드를 수정해야 할 일이 생겼고 수정한 코드를 운영에 배포했다. 그리고 일주일이 지난 후, 특정 옵션 상품이 장바구니에 담기지 않는다고 연락이 왔다. 배포 당시에 문제를 발견하지 못하고 일주일 간 장애가 발생한 것이었다. 다른 팀 기획자에게 전화가 왔으며, 추궁이 이어졌다. 황급히 문제를 파악하고 긴급 배포를 한 후 나에게 남은 일은 장애 보고서를 쓰는 일이었다. 기분이 착잡했다. 그것도 그럴 것이...

나는 ‘ 개발자를 코칭하며 배운 7 가지 ’ 라는 제목의 글을 쓴 적이 있는데 내가 코칭한 대부분의 개발자들이 토로하는 고민이 있었다. 프론트를 해야 할지 백엔드를 해야 할지 잘 모르겠어요. 내 경험에 의하면 많은 이들이 자신에게 물어야 할 질문을 남에게 묻는다. 왜 그럴까? 자신이 무엇을 좋아하는지, 무엇을 하고 싶은지 잘 모르기 때문이다. 그래서 자신에게 해야 할 질문을 남에게 한다. 그렇지만 그 답답한 마음을 왜 모르겠는가. 그래서 나는 서부른 조언보다는 대화에서 스스로 힌트라도 찾을 수 있도록 충분히 들어 주는 편이다. 그럼에도 불구하고 ‘프론트냐 백엔드냐’를 고민하는 이들에게 작은 도움이라도 되길 바라는 마음으로 이 글을 쓴다....

나는 2020년 10월을 시작으로 지금까지 여러 명의 개발자들을 코칭하고 있다. 초보 코치로써 약 1년 5개월 동안 배운 것을 정리했다. 1. 코치는 그저 거들 뿐이다 함께 개발을 하면서 코칭을 하다보니 해결하기 어려운 문제를 만나면 내가 주도적으로 해결했다. 결과적으로 내게 의존성이 높아졌으며 어려운 문제가 생기면 나를 찾았다. 보다 본질적인 문제는 코치가 아닌 개발자 본인이 성장하지 못한다는 것이었다. 성장은 자신이 주도적으로 문제를 해결해 가며 겪는 수 많은 실수와 실패의 집합이다. 다른 사람이 문제를 해결해 버리면 단기적으로 좋을지 모르겠지만 장기적으로는 성장의 기회가 사라진다....

나는 최근 몇 년 간 Golang(이하 Go)을 사용하고 있지만 이전에는 주로 Java로 개발했었다. Java는 오류를 Exception으로 다루며 오류가 발생하면 개발자가 별도 처리하지 않아도 Strack Trace를 출력한다. 아래 그림을 보자. C의 23줄에서 오류가 발생한 상황이다. Stack Trace로 표현하면 아래와 같다. 오류와 어떤 경로로 발생했는지 보여주는 것이다. C의 C-1 함수 23 줄에서 오류 발생 B의 B-1 함수가 C의 C-1 함수 호출 A가 B의 B-1 함수 호출 Go에서는 오류를 Error로 다룬다. 아쉽게도...

요즘은 프론트엔드, 백엔드 등으로 개발이 분업화 되었고 또한 최근 많은 곳에서 마이크로서비스 아키텍처 Microservice Architecture 를 도입하면서 하나의 언어가 아닌 여러 언어로 개발하는 것이 추세인 듯하다. 여러 언어로 개발하다 보면 테스트 커버리지와 코드 코드 정적 분석 Static program analysis 결과를 각각 보면 매우 불편한데 통합하여 한곳에서 볼 수 있으면 편할 것 이다. SonarSouce 에서 만든 SonarQube 는 코드를 분석하여 중복, 테스트 커버리지, 코드 복잡도, 버그, 보안 취약성 등을 보여주는 도구이다. 특히...