개발자를 코칭하며 배운 7 가지

나는 2020년 10월을 시작으로 지금까지 여러 명의 개발자들을 코칭하고 있다. 초보 코치로써 약 1년 5개월 동안 배운 것을 정리했다. 1. 코치는 그저 거들 뿐이다 함께 개발을 하면서 코칭을 하다보니 해결하기 어려운 문제를 만나면 내가 주도적으로 해결했다. 결과적으로 내게 의존성이 높아졌으며 어려운 문제가 생기면 나를 찾았다. 보다 본질적인 문제는 코치가 아닌

데이터 분석에 필요한 자질은 뭘까?

빅데이터가 대세 키워드였던 몇 년 전까지만 해도 하둡 등의 인프라가 모든 것을 해결해줄 듯한 분위기였다면, 알파고 이후엔 수학 및 통계학, 그리고 그런 지식에 기반한 모델링 능력이 필수 자질로 꼽히는 세상이 되었다.   광고, 추천, 번역, 금융 등 많은 분야에서 그런 자질을 요구한다. 열거한 분야들의 공통점은 최종 목적이 결국 돈이라는 것. 돈을

가변 Context 클래스는 신중하게 사용하자

요즘 라이브 서비스의 레거시 코드 리팩터링을 하고 있다. 흔히 가변 상태를 관리하는 Context 클래스가 레거시 코드에 있는 건 새삼스럽지 않았지만, 과도하게 사용하고 있어서 정리가 필요했다.   가변 상태 Context 사용 시 문제점 가변 상태를 가지는 Context 클래스가 2, 3개도 도 아니고 10개쯤 되면 과하다고 생각한다. 이렇게 많은 Context 클래스들이 서로 물고

Golang Error Stack Trace와 로깅

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

자바 직렬화(Java Object Serialization)에 유연성 더하기

자바 객체를 영속화하는 방법의 하나로 자바 직렬화를 사용할 수 있다. 단순하게는 Serializable 인터페이스를 구현하거나 더 확장성 있는 방법으로는 Externalizable 인터페이스를 구현하는 것을 선택할 수 있고, 자바 직렬화에 종속되지 않는 다른 방법을 선택할 수도 있다. 일단, Serializable 인터페이스를 구현한 클래스의 인스턴스가 외부 저장소에 영속화되면 호환성을 유지하면서 해당 클래스의 필드를 수정하기는 어렵다.

log4j 보안 취약점 동작원리 및 jenkins 서버 확인 방법

최근 log4j의 보안 취약점이 크게 이슈가 되고 있습니다. 많은 개발자나 운영자들이 이 조치를 위해 정신이 없을것 같아 간단하게 글로 남겨 봅니다. log4j는 자바를 사용하는 많은 프로젝트에 사용되기 때문에 직접 개발한 코드 뿐만 아니라 자바 개발된 서버 사이드 솔루션들도 모두 점검을 해봐야 합니다. 일반적으로 가장 많이 사용되는 자바로 개발된 서버 사이드

정규표현식 몰라도 된다

5일 중 3일을 정규표현식에 할애한 과정을 진행하다가 아차(?) 싶었던 첫 강의가 생각난다. 그렇게 정규표현식 비중을 줄이고 줄여서 현재 정규표현식 과정은 반나절 정도(..) 그럼에도 빠지지 않는 질문이 쉬운 정규표현식? 대체 방법? 정규표현식이 쉬워지는 방법은 많이 써보는 수밖에 없다 보니 정규표현식을 사용하지 않고 원하는 테이블 구조를 만드는 방법에 대한 고민을 자주 한다.

화려한 디자인을 가진 중국 이커머스앱에 대한 고찰

ㅤ ㅤ  중국 앱 디자인 업무를 맡으면서 레퍼런스를 찾아보기 위해 처음 중국 앱 디자인을 봤었을 때가 떠오른다. 한국이나 미국과 다른 화려한 색감과 화려한 인터랙션 그리고 빽빽한 느낌때문에 놀랐던 경험이 있다. 그래서 중국 앱은 어떤 점이 다른지 알아보기 위해 특징들을 적어보았다. ㅤㅤ [중국 이커머스 앱 디자인의 특징] 1. 빽빽함 (요소들이 빽빽하게

아키텍트

트레이드오프와 아키텍트 그리고 개발자의 소통 문제

브런치에서 뉴스를 빠르고 유익하게 소비하는 사례로 썼던 글을 popit의 주요 독자들이 흥미로워 할 주제라 생각에 이곳에도 옮겨봅니다. 두 가지 이야기를 하려고 합니다. * 트레이드오프 즉, 상충관계에 대한 생각 * 개발자에게 아키텍트로 나아가는 길 먼저 트레이드오프는 과거 제가 소프트웨어 아키텍트로 일할 때, 가장 자주 다루던 개념이자 주요 관심사였습니다. 서로 다른 이해관계를 갖는 참여자

2년만에 써보기 환경에 적응하는 독서 전략 개선

독서 중인 책의 흐름을 통해 내 행동 관찰하기 이후에 2년만에 비슷한 글을 다시 씁니다. 산만해진 독서 환경 전처럼 묘사해보려고 했는데 잘 되지 않습니다. 6월 즈음에 한번 그려보다가 포기한 그림이 노트북 바탕화면에 남아 있더군요. 사실 이 글은 '이 파일은 뭐지?' 하고 내가 만들고도 무엇인지 모르는 파일을 열었다가 기억이 되살아나

Golang 테스트 커버리지 측정과 코드 정적 분석 그리고 SonarQube

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

Golang 인터페이스와 단위 테스트

테스트 자동화Test automation의 일환으로 필자는 Golang으로 테스트 코드를 작성할 때 먼저 통합 테스트Integration Test[1]를 작성한다. 통합 테스트 코드를 작성하다 보면 주요 테스트 시나리오 외의 케이스를 촘촘하게 테스트 하기 어려운데 그 이유는 테스트 실행 비용(예. 웹 서버, 데이터베이스 등등)이 비싸고 비슷한 케이스를 작성하다 보면 코드 중복이 많이