🚀 항해 플러스 최종 회고
혼자 방향성 없이 공부하는 것에 한계를 느꼈다.
주변 사람들과 미디어를 통해 다양한 이야기를 듣게 된다. 기본적인 언어 능력, 데이터베이스 지식, 네트워크, CS 등등... 물론 이 모든 것이 중요하다고 생각한다. 하지만 어디서부터 시작해야 할지 막막해서 그저 손에 잡히는 대로 공부했다. 그러면서도 '내가 올바른 방향으로 가고 있는 걸까?'라는 질문을 끊임없이 스스로에게 던졌던 것 같다.
깨달은 것들
항해 플러스를 마치며, 가장 기억에 남은 것들을 정리해보려고 한다.
- 백엔드 개발자로서의 방향성을 확립
- 효과적인 피드백 방법
방향성
여기서 '백엔드 개발자로서의 방향성'이 가장 필요로 했었다. 그 이유는 스스로 방향을 어떻게 설정해야 할지 몰랐기 때문이다. 이번 항해 플러스를 통해 확실히 깨달았다. 나 자신이 무언가 방향을 잡고 가는 것을 어려워 한다는 것을
스스로의 방향을 잡을 수 없었다. 그 이유에 대해 곰곰히 생각해 봤는데, 스스로 어떤 개발자가 되어야 겠다는 구체적인 목표가 없어서 그러지 않았을까?
구체적인 목표가 없었기도 했지만, 이러한 인사이트를 줄 환경이 아니기도 했었다. 때문에 이런 환경을 만들 필요성을 느꼈고, 항해 플러스라는 과정을 시작했다.
피드백에 대한 생각
코치님과 항플 동기분들을 피드백에 대한 올바른 마음가짐을 배웠다.
이번 과정을 통해 나는 피드백을 못한다는 사실을 이번 과정을 통해 확실히 깨달았다. 결론부터 말하자면, 지금까지 내가 했던 피드백은 기분에 따라 상대방을 배려하지 않았다는 것이다.
그렇다면 올바른 피드백은 무엇일까? 상대방을 배려하는 것이 올바른 피드백인가? 그렇다면 배려란 무엇일까?
배려라는 사전적 의미부터 알아보자. 배려란 상대방을 존중하는 것이다. 즉, 내 생각과 기분이 우선이 되는 것이 아니라, 상대방의 생각을 존중하는 것이 배려라고 생각한다.
지금까지 회사에서 내가 해왔던 피드백은 배려가 빠진, 내 기분만을 이야기 했던거 같다. 일례로 내가 알고 있는 지식을 상대방이 모를 때 '이것도 모르세요?'라는 기분을 내며, 내 딴에는 친절이라고 생각했던거 같다.
나 스스로 많이 부족한 사람이라고 생각한다. 그렇기 때문에 내가 알고 있는 지식을 상대방이 모를 때, 더욱 모질게 대했던거 같다.
내가 생각하는 좋은 피드백
이일만(토비) 개발자님의 인프콘 20204 섹션에서 "여러분이 친절하셨으면 좋겠습니다."라는 말이 생각이 났다. 이 말을 듣고 나 자신에게 "나는 친절한가?"라는 물음이 생겼다. 누군가에게 친절하기 위해서는 교양이 필요하며, 교양은 그냥 생기는 것이 아니라고 하셨다.
'교양'있는 개발자
자신의 말을 하더라도 다른 사람의 기분을 나쁘지 않게 하는 것토비님이 말하셨듯이 나쁜 피드백이라도 자신의 말을 할 줄 알아야 한다. 추가로 내 기분에 따라 이야기해서는 안된다고 생각한다. 상대방에 입장에서 생각할 줄 알아야 하며, 이를 항상 자각하여 말을 해야한다. 즉, 교양은 쌓기 위해서는 훈련이 필요하다.
좋은 사람은 그냥되는 것이 아니라, 좋은 사람이 될 수 있도록 노력해야 하는 것이 아닐까? 물론, 주변에 좋은 사람이 많다면 쉽겠지만 저절로 좋은 사람이 되는 것은 아니라고 생각한다. 결국 나 스스로가 노력하여 좋은 사람으로 거듭나야 한다.
트러블 슈팅
가장 기억에 남은 주차에서 내가 겪은 트러블 슈팅에 대해 발표했었다.
인덱스를 통한 쿼리 최적화 작업이 가장 기억에 남았다.
쿼리 성능 체크를 위해 1,000만 건의 데이터를 조회하였다. 예를 들어, 아래와 같은 사용자 테이블이 있고 1,000만건의 사용자 정보가 있다고 가정하겠다.
| Column | Type | Description |
|---|---|---|
| id | String | PK |
| realname | String | 사용자이름 |
| nickname | String | 닉네임 |
| password | String | 비밀번호 |
| birth | Datetime | 생년월일 |
| createdDate | Datetime | 생성일 |
사용자 정보를 조회하는 SELECT id, realname, nickname, birth, createdDate FROM users WHERE realname=? 쿼리를 실행했을 때, 인덱스 유무에 따른 성능 차이를 확인한다.
CREATE INDEX idx_realname(realname);당연히 인덱스를 사용하면 성능이 개선될 줄 알았지만, 그렇지 않았다.
이유는 인덱스 컬럼 외에 컬럼들을 가져오기 때문이다. 인덱스로 지정된 realname 컬럼은 인덱스에서 바로 가져올 수 있지만, id, nickname, birth, createdDate 컬럼은 인덱스로 지정되어 있지 않고 테이블 즉, Disk에 저장되어 있기 때문이다.
따라서, 스토리지 엔진은 인덱스로 해당 컬럼을 빠르게 찾은 후 나머지 컬럼(id, nickname, etc..)을 조회하기 위해 인덱스에 저장된 디스크 주소를 이용하여 실제 디스크에 접근하게 된다. 1,000만건의 데이터에서 수행된다면 그 만큼 지연 시간이 발생하게 되는 것이다.
실제로 테스트했을 때, 쿼리 옵티마이저는 100만건의 데이터에서 인덱스를 사용하지만, 1,000만건의 데이터가 적재되어 있는 환경에서는 인덱스를 사용하지 않았다. 쿼리 옵티마이저는 환경에 따라 인덱스를 사용하는 랜덤 접근을 사용할지, 또는 인덱스를 사용하지 않는 순차 접근을 사용할지 판단한다.
해결 방법
인덱스를 사용하지만, 결국 디스크 I/O가 발생하게 된다. 때문에 Covering Index를 사용하여 디스크 접근 자체를 막는 방법을 생각했다. 하지만, 이 방법 또한 문제가 있는데, 만약 범위 조건이 추가된다면? 예를 들어 WHERE birth > ? AND birth < ? 라는 범위 조건이 추가될 경우, 인덱스에는 그닥 효율적이게 동작하지는 않았다.
인덱스에서 범위 조건이 왜 효율적으로 동작하지 않는지는 아직 연구중이다..
두 번째 방법은 조건을 추가하여 인덱스에서 가져오는 데이터를 최소화하는 것이다. 조회된 데이터가 줄어들면 디스크 I/O도 줄어들기 때문에 효율적인 방법이라고 생각했다. 예를 들어, WHERE realname=? 조건에서 AND status=?라는 상태 조건을 추가하여 인덱스에서 조회되는 데이터를 최소하하는 방법을 생각했다.
결론
이번 트러블 슈팅을 통해서 다음과 같은 사실을 알았다.
- Disk 접근을 최소화해야 한다.
- Root에서 Leaf 노드까지 도달하는 횟수를 줄여야 한다.
- 인덱스에서 많은 부분을 필터링해야 효율이 좋다.
이번 트러블 슈팅을 통해 문제에 대해 깊이있게 탐구하였고, 이를 해결하기 위한 다양한 방법들을 시도하여 검증해 볼 수 있었다.
과정 중에 들었던 내용 중 "지독하게 검증하라"는 말이 인상 갚었다. 이를 실천하여 문제에 대한 가설을 세우고 검증하는 경험이 중요한 것 같다.
앞으로의 마음가짐
항해 플러스를 통해 정말 많은 것을 배웠다. TDD, 아키텍처, 동시성, 로깅 및 모니터링 등 기술적인 부분에서 성장했다고 느낀다. 무엇보다도, 동기들과 코치님들을 통해 개발자로서 가져야 할 마음가짐과 철학에 대해 많은 것을 배울 수 있었다.
랜덤 코드 리뷰 시간에 데이터베이스 문제를 깊이 탐구하신 분이 계셨다. "어떻게 그렇게 깊이 있게 문제를 다루셨나요?"라고 여쭤봤는데, 그분은 문제를 파악하기 위해 밤낮을 가리지 않고 끝까지 원인을 찾아내셨다고 말씀하셨다. 그 말을 듣고 나는 아직 많이 부족하다는 생각이 들었다.
멘토링을 통해 들은 말 중 "현상을 보고 조치를 취하라"와 "내가 다루고 있는 문제에 대해 변호사가 되어라"는 조언이 떠올랐습니다. 매우 당연한 말처럼 들리지만, 이 두 가지 규칙을 내가 얼마나 잘 실천하고 있는지 생각하게 되었다.
개인적으로 정말 열심히 했다고 생각했지만, 아직 많이 부족하다는 것을 동기들과의 대화를 통해 깨달았고, 코치님들과 이야기하면서 많은 인사이트를 얻었다. 과제를 수행하면서 자신감도 얻을 수 있었다. 모든 과정이 불안하고 힘들기도 했지만, 그 덕분에 내일이 기대되는 사람이 될 수 있었고, 앞으로도 그런 사람이 되기 위해 계속 노력하려 한다.
