<div id="readability-page-1" class="page"><div><p>Image by&nbsp;<a href="https://pixabay.com/ko/users/sanctumdigital-10596213/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=5655110">Roy N</a> from <a href="https://pixabay.com/ko//?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=1728448">Pixabay</a></p>
<p><img src="https://velog.velcdn.com/images/joosing/post/a3daee7a-38c6-4b05-83dd-a2b8b7f5bb3d/image.png"></p>
<h2 id="상향식으로-접근-시작">상향식으로 접근 시작</h2>
<p>사용자가 특정한 타입의 데이터를 입력하면 시스템이 예외를 밷어냈다. 버그라고 할 수 있지만 명시적으로 지원하지 않는 데이터 타입이라 새로운 기능을 추가하는 작업으로 접근했다. 이 문제에 접근하며 상향식 접근법을 선택했다. 바닥에 있는 제품 코드부터, 기술까지 배경을 이해하고 점점 문제에 접근해 나가기로 한 것이다. 기술적인 배경에 대해 모르는게 너무 많아 문제가 뭔지 감을 잡기 어려웠다. 그래서 처음에 Hadoop, Hive, Parquet 같은 기술들에 대해 공부를 시작했다. 기본적인 개념만 이해하려고 달려들었지만 공부해야 할 것들이 너무 많았고, 코드를 읽다보니 처음 만나는 라이브러리들이 계속 등장했다. 몇 일 되지 않아 쓰나미처럼 몰려오는 기술 요소들에 잠식되었고 제어할 수 없는 많은 정보에 나는 넉다운 된 것 같다. 이 방법은 뭔가 잘못되었음을 직감했다.</p>
<p>잠시 고민했다. 새로운 방향이 필요하다. 이대로 나아가는 건 뭔가 잘못되었다. </p>
<h2 id="선택의-이유">선택의 이유</h2>
<p>몇 일 전 이슈를 할당받고 프로젝트를 클론한 뒤 빌드가 되도록 만드는데 애썻던 시점이 생각났다. 프로젝트 빌드에 성공한 뒤 테스트 환경에서 실행해 보려고 했는데 역시나 여러 의존 시스템들이 함께 로드되고 설정되어야 가능한 일임을 알았다. 이 때 나는 테스트 가능한 런타임 환경을 구성하는 대신 코드를 살펴보고 기반 기술에 대해 먼저 이해하기로 결정했다. 첫째 이유는 런타임 환경 구성 역시 문서화되어 있거나 쉽게 구성할 수 있도록 시스템화 되어 있지 않아 쉽지 않겠단 생각이 들었던 것 같다. 문제가 뭔지도 모른채 런타임 환경 구축으로 시작부터 진을 빼고 싶지 않았던 것 같다. 둘째 더 중요한 이유는 이슈 자체가 기술적인 데이터 타입 지원과 관련된 문제라 코드를 읽고 어떤 문맥에서 문제가 발생하는지 알아야 겠다고 생각했기 때문이다. </p>
<h2 id="선택을-회고하며">선택을 회고하며</h2>
<p>첫 번째 결정은 다소 성급한 마음에서 나온 것 같다. 런타임 환경을 만드는데 삽질이 예상되지만 어찌되었든 언젠가 해야 테스트가 가능하니 미룰 일은 아니었다. 오히려 런타임 환경을 미리 구축해 두면 내가 코드를 수정해 두고 즉시 컴퓨터의 옳은 피드백을 받을 수 있어 좋다. 나는 이때 빨리 문제에 대해 딥다이브 하고 싶었던 것 같다. 문제가 뭔지 코드 속에서 얼른 보고 싶었던 것 같다. 두 번째 결정은 옳은 결정이라고 생각한다. 다만 나아가다가 벽을 만난 것 뿐이다. 낙심하지 말라고 스스로에게 말해주고 싶다. 벽을 만났더니 새로운 길이 보였다. 나는 아차 싶어 예외가 어디에서 나왔는지 살펴보았다. 이제 큰 흐름을 조금 알았으니 여기서 왜 죽는지에 포커스를 맞추어 그것을 이해하는데 필요한 학습에 집중할 필요가 있겠다. </p>
<h2 id="방향-전환의-때">방향 전환의 때</h2>
<p>‘함께 자라기’라는 책에서 전문가는 문제를 대할 때 상향식, 하향식 접근법을 왔다갔다 한다고 한다. 하수는 한 가지 방법만을 고집한다고 했다. (함께 자리기 해당 파트를 읽고 정리한 <a href="https://velog.io/@joosing/%ED%95%A8%EA%BB%98%EC%9E%90%EB%9D%BC%EA%B8%B0-%EB%AA%A9%ED%91%9C%EA%B0%80-%EB%B6%84%EB%AA%85%ED%9E%88-%EB%B3%B4%EC%9D%B4%EC%A7%80-%EC%95%8A%EB%8A%94-%EB%AC%B8%EC%A0%9C%EB%A5%BC-%EB%A7%8C%EB%82%A0-%EB%95%8C">블로그 글</a>이다) 최근에 김영한님이 인프콘과 <a href="https://youtu.be/_HTj5b59Em0?si=S3qZaEorzZ0V1A-J">EO영상</a>에서 똑같이 ‘구체화와 추상화 왔다갔다 하기’를 강조하고 계신 것을 보고 더욱 공감했던 것 같다. 나는 처음 문제를 마주하며 상향식 문제 접근법을 취했다. 사용하는 기술과 전체 코드를 파악함으로 문제에 접근하려 한 것이다. 이때 벽을 만났다. 너무 많은 정보에 넉다운 되었고 문제 해결에 진짜 필요한 정보만 뾰족하게 포커싱해야 할 필요가 느껴졌다. 이제 하향식으로 전환할 때이다. 문제가 발생한 코드에서 이제 시작하는 거다. 그리고 코드가 실행가능하도록 만들고 코드를 직접 실행하면서 코드의 진짜 상태를 위에서 내려다 보며 하나씩 확인해 볼 차례다. </p>
<h2 id="다양한-문제">다양한 문제</h2>
<p>이런 생각을 하다가 <a href="https://velog.io/@joosing/is-the-sha256-hash-different">직전에 해결한 해시 계산 관련 이슈</a>가 생각났다. Cython 모듈에서 해싱 함수를 구현하고 있었는데 이 문제를 해결하기 위해 Cython에 대해 깊이 공부하지 않았다. 그냥 어떻게 빌드되고 실행될 수 있고 무슨 목적으로 사용하는 라이브러리 인지 개념만 이해한 이후에 즉시 제품을 실행해서 문제를 재현해 보았다. 그리고 런타임 환경에서 코드 한 줄 한 줄을 확인하며 어디서 부터 결과가 틀어지는지 찾아내었다. 모든 코드를 읽으며 이해하려 노력하지 않았고 모든 기술을 다 이해하려 하지 않았다. 단지 문제를 드러내는데 필요한 상태만 확인했고 그렇게 생각보다 어렵지 않게 문제를 찾아 해결한 것 같다. 지금 이제 그렇게 할 때이다. 이 문제도 처음부터 그렇게 했어야 한다고 생각하지는 않는다. 이번에는 그때와 문제의 성격이 다른 것 같다. 그때는 단순한 해시를 계산하는 기능이었지만 이번에는 훨씬 복잡한 일을 하고 있어 지난번과 같은 전략을 취할 수는 없었다고 생각한다.</p>
<h2 id="다양한-접근">다양한 접근</h2>
<p>문제는 다양한 추상화 수준과 문맥을 가지고 있다. 절대적으로 이렇게 해야하는 해법은 없는 것 같다. 그때는 그랬고 지금은 이렇다. 다만 문제가 보이지 않을 때는 바닥부터 훓어가며 문제를 찾는다. 그러다 보면 바닥이 너무 넓어 한계를 오늘 처럼 만난다. 그러면 다시 전체를 조금 정리한 후 꼭대기로 올라가 문제에서부터 다시 아래를 내려다 보며 문제를 파해쳐 나가면 된다. 그러다 보면 다시 기저에 있는 어떤 지식을 몰라 문제 해결이 어려워지는 시점을 만날텐데 그때 다시 아래로 내려가 부족한 부분을 채우고, 이렇게 왔다갔다 하다보면 문제를 해결하게 되는 것 같다.</p>
<h2 id="위로">위로</h2>
<p>지난주 마음이 어려웠던 것 같다. 남의 코드를 이렇게 뒤지고 있는 내 모습이 안쓰럽기도 하고, 이렇게 남의 코드를 이해하려 애쓰며 시간을 허비하고 있는 건 아닌지 고민도 되었다. 내가 작성한 내 코드 위에서 능숙하게 디버깅을 하던 지난 시간도 떠올랐다. 그래서 약간 낙심되었던 것 같은데 스스로에게 위로의 말을 건낸다. 나는 아주 자연스러운 디버깅 과정을 거쳐온 것이고 잘못한 것이 아니다. 잘했다. </p>
<p>오늘 나의 디버깅 과정을 회고해 본 이 시간은 무척 값지다는 생각이 든다. 엔지니어링은 참 오묘한 일인 것 같다.</p></div></div>

Joo's Work

JooSing

Image by Roy N from Pixabay
상향식으로 접근 시작
사용자가 특정한 타입의 데이터를 입력하면 시스템이 예외를 밷어냈다. 버그라고 할 수 있지만 명시적으로 지원하지 않는 데이터 타입이라 새로운 기능을 추가하는 작업으로 접근했다. 이 문제에 접근하며 상향식 접근법을 선택했다. 바닥에 있는 제품 코드부터, 기술까지 배경을 이해하고 점점 문제에 접근해 나가기로 한 것이다. 기술적인 배경에 대해 모르는게 너무 많아 문제가 뭔지 감을 잡기 어려웠다. 그래서 처음에 Hadoop, Hive, Parquet 같은 기술들에 대해 공부를 시작했다. 기본적인 개념만 이해하려고 달려들었지만 공부해야 할 것들이 너무 많았고, 코드를 읽다보니 처음 만나는 라이브러리들이 계속 등장했다. 몇 일 되지 않아 쓰나미처럼 몰려오는 기술 요소들에 잠식되었고 제어할 수 없는 많은 정보에 나는 넉다운 된 것 같다. 이 방법은 뭔가 잘못되었음을 직감했다.
잠시 고민했다. 새로운 방향이 필요하다. 이대로 나아가는 건 뭔가 잘못되었다. 
선택의 이유
몇 일 전 이슈를 할당받고 프로젝트를 클론한 뒤 빌드가 되도록 만드는데 애썻던 시점이 생각났다. 프로젝트 빌드에 성공한 뒤 테스트 환경에서 실행해 보려고 했는데 역시나 여러 의존 시스템들이 함께 로드되고 설정되어야 가능한 일임을 알았다. 이 때 나는 테스트 가능한 런타임 환경을 구성하는 대신 코드를 살펴보고 기반 기술에 대해 먼저 이해하기로 결정했다. 첫째 이유는 런타임 환경 구성 역시 문서화되어 있거나 쉽게 구성할 수 있도록 시스템화 되어 있지 않아 쉽지 않겠단 생각이 들었던 것 같다. 문제가 뭔지도 모른채 런타임 환경 구축으로 시작부터 진을 빼고 싶지 않았던 것 같다. 둘째 더 중요한 이유는 이슈 자체가 기술적인 데이터 타입 지원과 관련된 문제라 코드를 읽고 어떤 문맥에서 문제가 발생하는지 알아야 겠다고 생각했기 때문이다. 
선택을 회고하며
첫 번째 결정은 다소 성급한 마음에서 나온 것 같다. 런타임 환경을 만드는데 삽질이 예상되지만 어찌되었든 언젠가 해야 테스트가 가능하니 미룰 일은 아니었다. 오히려 런타임 환경을 미리 구축해 두면 내가 코드를 수정해 두고 즉시 컴퓨터의 옳은 피드백을 받을 수 있어 좋다. 나는 이때 빨리 문제에 대해 딥다이브 하고 싶었던 것 같다. 문제가 뭔지 코드 속에서 얼른 보고 싶었던 것 같다. 두 번째 결정은 옳은 결정이라고 생각한다. 다만 나아가다가 벽을 만난 것 뿐이다. 낙심하지 말라고 스스로에게 말해주고 싶다. 벽을 만났더니 새로운 길이 보였다. 나는 아차 싶어 예외가 어디에서 나왔는지 살펴보았다. 이제 큰 흐름을 조금 알았으니 여기서 왜 죽는지에 포커스를 맞추어 그것을 이해하는데 필요한 학습에 집중할 필요가 있겠다. 
방향 전환의 때
‘함께 자라기’라는 책에서 전문가는 문제를 대할 때 상향식, 하향식 접근법을 왔다갔다 한다고 한다. 하수는 한 가지 방법만을 고집한다고 했다. (함께 자리기 해당 파트를 읽고 정리한 블로그 글이다) 최근에 김영한님이 인프콘과 EO영상에서 똑같이 ‘구체화와 추상화 왔다갔다 하기’를 강조하고 계신 것을 보고 더욱 공감했던 것 같다. 나는 처음 문제를 마주하며 상향식 문제 접근법을 취했다. 사용하는 기술과 전체 코드를 파악함으로 문제에 접근하려 한 것이다. 이때 벽을 만났다. 너무 많은 정보에 넉다운 되었고 문제 해결에 진짜 필요한 정보만 뾰족하게 포커싱해야 할 필요가 느껴졌다. 이제 하향식으로 전환할 때이다. 문제가 발생한 코드에서 이제 시작하는 거다. 그리고 코드가 실행가능하도록 만들고 코드를 직접 실행하면서 코드의 진짜 상태를 위에서 내려다 보며 하나씩 확인해 볼 차례다. 
다양한 문제
이런 생각을 하다가 직전에 해결한 해시 계산 관련 이슈가 생각났다. Cython 모듈에서 해싱 함수를 구현하고 있었는데 이 문제를 해결하기 위해 Cython에 대해 깊이 공부하지 않았다. 그냥 어떻게 빌드되고 실행될 수 있고 무슨 목적으로 사용하는 라이브러리 인지 개념만 이해한 이후에 즉시 제품을 실행해서 문제를 재현해 보았다. 그리고 런타임 환경에서 코드 한 줄 한 줄을 확인하며 어디서 부터 결과가 틀어지는지 찾아내었다. 모든 코드를 읽으며 이해하려 노력하지 않았고 모든 기술을 다 이해하려 하지 않았다. 단지 문제를 드러내는데 필요한 상태만 확인했고 그렇게 생각보다 어렵지 않게 문제를 찾아 해결한 것 같다. 지금 이제 그렇게 할 때이다. 이 문제도 처음부터 그렇게 했어야 한다고 생각하지는 않는다. 이번에는 그때와 문제의 성격이 다른 것 같다. 그때는 단순한 해시를 계산하는 기능이었지만 이번에는 훨씬 복잡한 일을 하고 있어 지난번과 같은 전략을 취할 수는 없었다고 생각한다.
다양한 접근
문제는 다양한 추상화 수준과 문맥을 가지고 있다. 절대적으로 이렇게 해야하는 해법은 없는 것 같다. 그때는 그랬고 지금은 이렇다. 다만 문제가 보이지 않을 때는 바닥부터 훓어가며 문제를 찾는다. 그러다 보면 바닥이 너무 넓어 한계를 오늘 처럼 만난다. 그러면 다시 전체를 조금 정리한 후 꼭대기로 올라가 문제에서부터 다시 아래를 내려다 보며 문제를 파해쳐 나가면 된다. 그러다 보면 다시 기저에 있는 어떤 지식을 몰라 문제 해결이 어려워지는 시점을 만날텐데 그때 다시 아래로 내려가 부족한 부분을 채우고, 이렇게 왔다갔다 하다보면 문제를 해결하게 되는 것 같다.
위로
지난주 마음이 어려웠던 것 같다. 남의 코드를 이렇게 뒤지고 있는 내 모습이 안쓰럽기도 하고, 이렇게 남의 코드를 이해하려 애쓰며 시간을 허비하고 있는 건 아닌지 고민도 되었다. 내가 작성한 내 코드 위에서 능숙하게 디버깅을 하던 지난 시간도 떠올랐다. 그래서 약간 낙심되었던 것 같은데 스스로에게 위로의 말을 건낸다. 나는 아주 자연스러운 디버깅 과정을 거쳐온 것이고 잘못한 것이 아니다. 잘했다. 
오늘 나의 디버깅 과정을 회고해 본 이 시간은 무척 값지다는 생각이 든다. 엔지니어링은 참 오묘한 일인 것 같다.

(회고) 레거시 코드의 문제를 다루는 자세

댓글