들어가며
무척 더운 여름날, 연중님이 내게 인프콘 티켓을 양도해주겠다고 하셨다. 새로 입사한 회사의 OJT 과정 때문에 휴가를 낼 수 없다는 이유였다. 정말 가고 싶었던 터라 나는 흔쾌히 티켓을 양도받고 연차를 사용했다. 그리고 마침내 인프콘에 입성했다.
인프콘 방문 목적
스탬프를 찍거나 굿즈를 받거나 네트워킹 세션에는 큰 관심이 없었다. 티켓을 양도받은 터라 네트워킹 세션에 참여하면 내가 티켓을 양도받았다는 사실을 계속 이야기해야 할 텐데, 그것도 번거로웠고 무엇보다 날이 너무 더웠다. 오로지 발표 세션에서 조금이나마 배우고 영감을 얻고 싶었다. 그것이 나의 인프콘 방문 목적이었다.
발표 세션
양질의 발표가 너무 많았지만 모든 것을 들을 수는 없었기 때문에 전날에 미리 계획을 세워 갔다. 그런데 새벽에 갑자기 장애가 발생해서 이를 해결하느라 잠을 못 잤고, 결국 첫 번째 세션에는 아예 참가하지 못했다. (그런데 마이크 타이슨이 말했지, 누구나 그럴싸한 계획은 있다고)
또한 널널한 개발자님과 한기용님의 발표 세션도 생략했다. 앞서 말했듯 날씨가 너무 더웠고, 두 분의 강연은 영상 매체를 통해 이미 여러 번 들었던 터라(널널한 개발자팀의 강좌만 4개나 들었다) 이번에는 나중에 영상으로 보기로 했다. (실제로 한 번 듣고 싶었는데 이것까지 들었으면 몸살이 났을 것 같다.)
디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기
실리콘밸리의 스타트업 개발자인 배휘동님의 세션이었다.
내용인 즉슨 고수들의 문제 해결(디버깅) 어떤 인지적 과정이 있었을까를 살펴봤더니 공통점이 있었고, 이를 5단계 훈련법으로 나누어 의식적으로 훈련하자는 것이다.
5단계 가이드 훈련법
- 사전
- 작업을 위한 계획 세우기 (시간 분배 등)
- 적절하게 멈추고 회고하기
- 산책을 하거나 주변을 알리거나 한 번
- 적절하게 멈추고 회고하기
- 작업을 위한 계획 세우기 (시간 분배 등)
- 반복(5단계지만 왔다갔다 할 수 있음)
- 문제 정의
- 이정표 만들기, “내가 지금 어떤 문제를 풀려고 하는거지?”
- 사전에 작업 계획 세울 때 함께 할 때도 많음
- 중간회고할 때마다 메타인지를 켜주는 등불. ‘내가 지금 뭐하고 있었지?’
- 다른 사람에게 문제에 대해 설명하고 공유할 때도 유용
- 이게 없으면 당장 중요하지 않은 문제에 빠져들 수 있음.
- 정상 동작 정의
- 심적 표상 만들기. ‘정상적인 환경에서는 어떤 조건에서, 어떤 순서로, 어떤 일들이 벌어져야 하는가?’
- 현재 벌어지는 일을 관찰 + 관찰한 정보 및 이미 알고 있는 정보 적어보기
- 올바른 동작을 테스트 코드처럼 적어보기
- 올바른 동작을 정의하지 못하겠다면 그걸 정의하기 위한 추가 정보를 여러 소스에서 수집해야 함.
- 도움 요청, Git History, 공식문서, 구글링, GPT 등..
- 올바른 동작을 정의하지 못하겠다면 그걸 정의하기 위한 추가 정보를 여러 소스에서 수집해야 함.
- 최소 재현 환경 구축하며 관찰
- 직접 재현하기: 문제가 있는 부분을 어떻게 핀포인트하여 격리시킬까?
- 가능하다면 문제 발생 시점을 정확히 확인(에러 모니터링, Git, Slack)
- 문제가 발생했던 사용자의 환경과 동작을 그대로 따라함 (세션 리플레이)
- 격리하며 패턴 관찰 9조건을 무조건 참으로 만들거나, 정상이 될 때까지 하나씩 지우거나, 빈 프로젝트에서 시작하여 비정상이 될때까지 나아가거나…)
- 내 환경에서 재연이 안된다면 재현 조건 파악을 위한 추가 정보를 여러 소스에서 수집해야 함.
- 로그 심기, 사용자 인터뷰 등
- 내 환경에서 재연이 안된다면 재현 조건 파악을 위한 추가 정보를 여러 소스에서 수집해야 함.
- 차이를 발생시키는 다양한 원인 탐색
- 머릿속 지도 펼치기. ‘두 환경의 차이가 어디에서 왔을까?’
- 추상적이든 구체적이든 떠오르는대로 적어보기 (이 부분이 문제다, 이 요소가 문제다, 이게 이렇게 되어야 맞는데 등)
- 도메인 경험이 많을수록 첫번째 옵션이 진실일 가능성이 높으나, 주니어는 훈련을위해서라도 3개 정도는 적어보는 게 좋음
- 다양한 옵션을 적기 어렵다면 추가 정보
- 가설 설정 및 검증
- 옵션을 검증 가능한 가설 형태로 문장화
- A가 B로 되어있는게 C 현상의 원인이라면, B를 B’로 변경했을 때 C가 C’로 바뀌어야 한다
- 실제로 작은 변경을 가하면서 가설대로 현상이 변하는지 관찰
- 이 과정에서 문제가 전이됐으면 시간 다시 잡고 1단계부터 재시작
- 가설이 틀렸다면 오히려 좋음 무엇 떄문인지 적어보고 다음 가설로 넘어감
- 끝내 해결하지 못했으면 이게 제일 위험함. 동료에게 묻거나 등
- 옵션을 검증 가능한 가설 형태로 문장화
- 문제 정의
이 문제 해결 과정은 사실 내가 트러블 슈팅때 실제로 하고 있었다는 것을 인식하며 한 번 놀랐고, 이걸 프로세스화 한 배기동님의 명쾌함에 한 번 놀랐다.
혹시 당신은 데이터를 모르는 백엔드 개발자 인가요?
아임웹의 백앤드 엔지니어 & 데이터 엔지니어이신 김지호님의 세션이었다.
백엔드 개발자와 데이터 엔지니어 업무를 병행하면서 각 직책에 따라 데이터를 바라보는 관점을 설명해주셨다. 축약하자면, 백엔드 개발자는 행 단위로 데이터를 보고 데이터 엔지니어는 열 단위로 데이터를 본다는 것이었는데, 그 점이 매우 흥미로웠다.
사실 이전에 주변의 데이터 사이언티스트님과 소주 한 잔 기울이며 DB에 대해 이야기를 나눈 적이 있었는데, 그때도 비슷한 말씀을 하셨다. 이는 파케이, Avro 등의 열 단위 데이터 포맷의 압축률이 높은 것을 생각해보면 어찌 보면 당연한 일이다.
이외에도 예시를 바탕으로 데이터의 물리적인 삭제에 대한 논의, 데이터 무결성에 대한 논의 등을 이어갔는데, 어렵지 않고 쏙쏙 이해가 되어 좋았다.
클린 스프링: 스프링 개발자를 위한 클린코드 전략
토비의 스프링의 저자 토비님의 책
이 세션은 모두를 완전히 속였다. 그러니까 이 세션에서는 스프링에 대해 2분 이상 이야기 하지 않는다. 포커스는 "클린"에 있었다.
클린 코드가 강조하는 것은 아래와 같으며
- 읽기 좋은 코드
- 이해하기 좋은 코드
- 확장하기 좋은 코드
- 유지보수하기 좋은 코드
이 대원칙을 위배하지 않았을 때 클린 코드는 생산성과 결코 대척점에 설 수 없다는 것이 강의의 핵심 내용이었다. 그러고는 "삼체 문제"에 대해 설명하셨다.
삼체 문제란 세 개의 천체 문제로, 비선형적이고 일반적인 해를 가지지 않아 예측이 매우 어렵다는 문제를 뜻한다. 그럼 클린 코드의 원칙인 유지 보수성과 생산성과 더불어 나머지 하나의 천체는 무엇일까? 바로 "팀워크"이다.
이 일련의 시나리오를 정말 막힘 없이 술술 풀어나가시는데, 이분은 정말 천재 같다는 생각이 들었다.
객체지향은 여전히 유용한가?
마지막으로 들었던 세션은 오브젝트의 저자 조영호님의 세션이었다.
아마 우리 나라에서 객체 지향에 대하여 가장 권위자(?)가 아니실까 하는 분이며, 아니나 다를까 객체 지향의 유효성에 대하여 이야기 하셨다.
사실 특정 기술이나 패러다임이 "유효한가?" 라는 질문에 대한 답은 명쾌하다. "그럴수도 있고 아닐수도 있다" 정도일 것이다.
대개 그것이 유효성에 대한 의심을 받기 시작한다는 것은 그와 반대되는 혹은 비슷한 다양한 패러다임이 등장하기 때문이다. 다시 말해 정답이 없는 의견들이 있는데 그 의견이 오래 되었다는 이유 하나로 소히말해 레거시한, 오래된 것으로 치부되는 것이다.
조영호님도 같은 말씀을 하셨다. 개발자로 성장하기 위해서는 저런 질문보다 더 나은 질문이 필요하다고 말씀하셨다. 그 질문은 무엇일까? 한 번 생각해보길 바란다.
그 질문은 바로 "객체 지향은 언제 유효한가요?" 이다. 모든 기술과 학문과 이야기는 나름대로의 쓸모를 가진다. 다만 그것의 쓸모가 언제인지를 인지하고 올바르게 도구화 하는것이 중요할 뿐이다.
이 강의가 좋았던 점은 여기에서 그치지 않는다. 직접 장바구니와 카트라는 간단한 예제 클래스 두개를 가지고 할인 정책 요구사항이 변화함에 따라 절차 지향적, 객체 지향적 패러다임 각각에서 이것이 어떤 형태로 리팩토링 되어야 하는가를 코드단으로 보여준다.
코드를 모두 보여줄 순 없겠지만 자바에서 객체 지향은 거의 열에 아홉은 다형성을 사용하도록 되어있다. 중심이 되는 핵심 기능을 인터페이스로 분리하여 그 기능의 여러 타입을 구현체로 분리하는 것이다.
반면에 절차 지향은 어떨까? 간단하다. switch문이나 if문으로 분기 처리 하는것이다.
객체 지향은 동일한 속성의 타입 추가에 매우 효과적이고 절차 지향은 특정 기능 추가에 매우 효과적이다. 가령 객체 지향에서 타입이 100개가 있는데 기능이 하나 추가되면 각 타입에 해당하는 구현체 100개 모두에 그 기능을 추가 개발 해주어야 하고, 절차 지향은 분기문이 100개가 생길 수 있다는 것이다.
이제 "그거 효과 있나요?" 라는 질문은 넣어두자.
"그거 언제 효과 있나요?"
마치며
오랜만에 개발 컨퍼런스에 와서 여러 개발자님들과 내적 연대감도 느끼고 훌륭한 선배 개발자님들의 가르침도 받았다.
나도 언젠가 저 강단에 서는날이 오길 기대하며 이만 글을 마친다. (연중님 감사합니다. 술 살게요)
들어가며
무척 더운 여름날, 연중님이 내게 인프콘 티켓을 양도해주겠다고 하셨다. 새로 입사한 회사의 OJT 과정 때문에 휴가를 낼 수 없다는 이유였다. 정말 가고 싶었던 터라 나는 흔쾌히 티켓을 양도받고 연차를 사용했다. 그리고 마침내 인프콘에 입성했다.
인프콘 방문 목적
스탬프를 찍거나 굿즈를 받거나 네트워킹 세션에는 큰 관심이 없었다. 티켓을 양도받은 터라 네트워킹 세션에 참여하면 내가 티켓을 양도받았다는 사실을 계속 이야기해야 할 텐데, 그것도 번거로웠고 무엇보다 날이 너무 더웠다. 오로지 발표 세션에서 조금이나마 배우고 영감을 얻고 싶었다. 그것이 나의 인프콘 방문 목적이었다.
발표 세션
양질의 발표가 너무 많았지만 모든 것을 들을 수는 없었기 때문에 전날에 미리 계획을 세워 갔다. 그런데 새벽에 갑자기 장애가 발생해서 이를 해결하느라 잠을 못 잤고, 결국 첫 번째 세션에는 아예 참가하지 못했다. (그런데 마이크 타이슨이 말했지, 누구나 그럴싸한 계획은 있다고)
또한 널널한 개발자님과 한기용님의 발표 세션도 생략했다. 앞서 말했듯 날씨가 너무 더웠고, 두 분의 강연은 영상 매체를 통해 이미 여러 번 들었던 터라(널널한 개발자팀의 강좌만 4개나 들었다) 이번에는 나중에 영상으로 보기로 했다. (실제로 한 번 듣고 싶었는데 이것까지 들었으면 몸살이 났을 것 같다.)
디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기
실리콘밸리의 스타트업 개발자인 배휘동님의 세션이었다.
내용인 즉슨 고수들의 문제 해결(디버깅) 어떤 인지적 과정이 있었을까를 살펴봤더니 공통점이 있었고, 이를 5단계 훈련법으로 나누어 의식적으로 훈련하자는 것이다.
5단계 가이드 훈련법
- 사전
- 작업을 위한 계획 세우기 (시간 분배 등)
- 적절하게 멈추고 회고하기
- 산책을 하거나 주변을 알리거나 한 번
- 적절하게 멈추고 회고하기
- 작업을 위한 계획 세우기 (시간 분배 등)
- 반복(5단계지만 왔다갔다 할 수 있음)
- 문제 정의
- 이정표 만들기, “내가 지금 어떤 문제를 풀려고 하는거지?”
- 사전에 작업 계획 세울 때 함께 할 때도 많음
- 중간회고할 때마다 메타인지를 켜주는 등불. ‘내가 지금 뭐하고 있었지?’
- 다른 사람에게 문제에 대해 설명하고 공유할 때도 유용
- 이게 없으면 당장 중요하지 않은 문제에 빠져들 수 있음.
- 정상 동작 정의
- 심적 표상 만들기. ‘정상적인 환경에서는 어떤 조건에서, 어떤 순서로, 어떤 일들이 벌어져야 하는가?’
- 현재 벌어지는 일을 관찰 + 관찰한 정보 및 이미 알고 있는 정보 적어보기
- 올바른 동작을 테스트 코드처럼 적어보기
- 올바른 동작을 정의하지 못하겠다면 그걸 정의하기 위한 추가 정보를 여러 소스에서 수집해야 함.
- 도움 요청, Git History, 공식문서, 구글링, GPT 등..
- 올바른 동작을 정의하지 못하겠다면 그걸 정의하기 위한 추가 정보를 여러 소스에서 수집해야 함.
- 최소 재현 환경 구축하며 관찰
- 직접 재현하기: 문제가 있는 부분을 어떻게 핀포인트하여 격리시킬까?
- 가능하다면 문제 발생 시점을 정확히 확인(에러 모니터링, Git, Slack)
- 문제가 발생했던 사용자의 환경과 동작을 그대로 따라함 (세션 리플레이)
- 격리하며 패턴 관찰 9조건을 무조건 참으로 만들거나, 정상이 될 때까지 하나씩 지우거나, 빈 프로젝트에서 시작하여 비정상이 될때까지 나아가거나…)
- 내 환경에서 재연이 안된다면 재현 조건 파악을 위한 추가 정보를 여러 소스에서 수집해야 함.
- 로그 심기, 사용자 인터뷰 등
- 내 환경에서 재연이 안된다면 재현 조건 파악을 위한 추가 정보를 여러 소스에서 수집해야 함.
- 차이를 발생시키는 다양한 원인 탐색
- 머릿속 지도 펼치기. ‘두 환경의 차이가 어디에서 왔을까?’
- 추상적이든 구체적이든 떠오르는대로 적어보기 (이 부분이 문제다, 이 요소가 문제다, 이게 이렇게 되어야 맞는데 등)
- 도메인 경험이 많을수록 첫번째 옵션이 진실일 가능성이 높으나, 주니어는 훈련을위해서라도 3개 정도는 적어보는 게 좋음
- 다양한 옵션을 적기 어렵다면 추가 정보
- 가설 설정 및 검증
- 옵션을 검증 가능한 가설 형태로 문장화
- A가 B로 되어있는게 C 현상의 원인이라면, B를 B’로 변경했을 때 C가 C’로 바뀌어야 한다
- 실제로 작은 변경을 가하면서 가설대로 현상이 변하는지 관찰
- 이 과정에서 문제가 전이됐으면 시간 다시 잡고 1단계부터 재시작
- 가설이 틀렸다면 오히려 좋음 무엇 떄문인지 적어보고 다음 가설로 넘어감
- 끝내 해결하지 못했으면 이게 제일 위험함. 동료에게 묻거나 등
- 옵션을 검증 가능한 가설 형태로 문장화
- 문제 정의
이 문제 해결 과정은 사실 내가 트러블 슈팅때 실제로 하고 있었다는 것을 인식하며 한 번 놀랐고, 이걸 프로세스화 한 배기동님의 명쾌함에 한 번 놀랐다.
혹시 당신은 데이터를 모르는 백엔드 개발자 인가요?
아임웹의 백앤드 엔지니어 & 데이터 엔지니어이신 김지호님의 세션이었다.
백엔드 개발자와 데이터 엔지니어 업무를 병행하면서 각 직책에 따라 데이터를 바라보는 관점을 설명해주셨다. 축약하자면, 백엔드 개발자는 행 단위로 데이터를 보고 데이터 엔지니어는 열 단위로 데이터를 본다는 것이었는데, 그 점이 매우 흥미로웠다.
사실 이전에 주변의 데이터 사이언티스트님과 소주 한 잔 기울이며 DB에 대해 이야기를 나눈 적이 있었는데, 그때도 비슷한 말씀을 하셨다. 이는 파케이, Avro 등의 열 단위 데이터 포맷의 압축률이 높은 것을 생각해보면 어찌 보면 당연한 일이다.
이외에도 예시를 바탕으로 데이터의 물리적인 삭제에 대한 논의, 데이터 무결성에 대한 논의 등을 이어갔는데, 어렵지 않고 쏙쏙 이해가 되어 좋았다.
클린 스프링: 스프링 개발자를 위한 클린코드 전략
토비의 스프링의 저자 토비님의 책
이 세션은 모두를 완전히 속였다. 그러니까 이 세션에서는 스프링에 대해 2분 이상 이야기 하지 않는다. 포커스는 "클린"에 있었다.
클린 코드가 강조하는 것은 아래와 같으며
- 읽기 좋은 코드
- 이해하기 좋은 코드
- 확장하기 좋은 코드
- 유지보수하기 좋은 코드
이 대원칙을 위배하지 않았을 때 클린 코드는 생산성과 결코 대척점에 설 수 없다는 것이 강의의 핵심 내용이었다. 그러고는 "삼체 문제"에 대해 설명하셨다.
삼체 문제란 세 개의 천체 문제로, 비선형적이고 일반적인 해를 가지지 않아 예측이 매우 어렵다는 문제를 뜻한다. 그럼 클린 코드의 원칙인 유지 보수성과 생산성과 더불어 나머지 하나의 천체는 무엇일까? 바로 "팀워크"이다.
이 일련의 시나리오를 정말 막힘 없이 술술 풀어나가시는데, 이분은 정말 천재 같다는 생각이 들었다.
객체지향은 여전히 유용한가?
마지막으로 들었던 세션은 오브젝트의 저자 조영호님의 세션이었다.
아마 우리 나라에서 객체 지향에 대하여 가장 권위자(?)가 아니실까 하는 분이며, 아니나 다를까 객체 지향의 유효성에 대하여 이야기 하셨다.
사실 특정 기술이나 패러다임이 "유효한가?" 라는 질문에 대한 답은 명쾌하다. "그럴수도 있고 아닐수도 있다" 정도일 것이다.
대개 그것이 유효성에 대한 의심을 받기 시작한다는 것은 그와 반대되는 혹은 비슷한 다양한 패러다임이 등장하기 때문이다. 다시 말해 정답이 없는 의견들이 있는데 그 의견이 오래 되었다는 이유 하나로 소히말해 레거시한, 오래된 것으로 치부되는 것이다.
조영호님도 같은 말씀을 하셨다. 개발자로 성장하기 위해서는 저런 질문보다 더 나은 질문이 필요하다고 말씀하셨다. 그 질문은 무엇일까? 한 번 생각해보길 바란다.
그 질문은 바로 "객체 지향은 언제 유효한가요?" 이다. 모든 기술과 학문과 이야기는 나름대로의 쓸모를 가진다. 다만 그것의 쓸모가 언제인지를 인지하고 올바르게 도구화 하는것이 중요할 뿐이다.
이 강의가 좋았던 점은 여기에서 그치지 않는다. 직접 장바구니와 카트라는 간단한 예제 클래스 두개를 가지고 할인 정책 요구사항이 변화함에 따라 절차 지향적, 객체 지향적 패러다임 각각에서 이것이 어떤 형태로 리팩토링 되어야 하는가를 코드단으로 보여준다.
코드를 모두 보여줄 순 없겠지만 자바에서 객체 지향은 거의 열에 아홉은 다형성을 사용하도록 되어있다. 중심이 되는 핵심 기능을 인터페이스로 분리하여 그 기능의 여러 타입을 구현체로 분리하는 것이다.
반면에 절차 지향은 어떨까? 간단하다. switch문이나 if문으로 분기 처리 하는것이다.
객체 지향은 동일한 속성의 타입 추가에 매우 효과적이고 절차 지향은 특정 기능 추가에 매우 효과적이다. 가령 객체 지향에서 타입이 100개가 있는데 기능이 하나 추가되면 각 타입에 해당하는 구현체 100개 모두에 그 기능을 추가 개발 해주어야 하고, 절차 지향은 분기문이 100개가 생길 수 있다는 것이다.
이제 "그거 효과 있나요?" 라는 질문은 넣어두자.
"그거 언제 효과 있나요?"
마치며
오랜만에 개발 컨퍼런스에 와서 여러 개발자님들과 내적 연대감도 느끼고 훌륭한 선배 개발자님들의 가르침도 받았다.
나도 언젠가 저 강단에 서는날이 오길 기대하며 이만 글을 마친다. (연중님 감사합니다. 술 살게요)
