<div id="readability-page-1" class="page"><div><h3 id="1-미래에-만날-문제를-준비하는-시간">1. 미래에 만날 문제를 준비하는 시간</h3>
<p>﻿늘 문제를 해결하기 위한 문제 주도의 학습을 강조해 왔지만, 그 반대도 의미 있다. 문제는 아직 만나지 못했지만 기술을 쌓아가는 것이다. 이 과정은 초등교육부터 대학교육까지 많이 받아와서 잘 알고 있다. 무엇에 쓰일지 지금 알지 못하지만 공부하는 것이다. 과정의 아쉬운 점은 문제 주도로 학습할 때 보다 열정이나 집중도가 떨어진다는 것이다. 실존하는 문제가 있으면 기술 학습에 훨씬 더 집중하게 된다. 그러나 균형있는 생각이 필요하다. 분명하게 경험하는 또다른 관점은 기술이나 지식이 있으면 문제가 보인다는 것이다. 모르면 문제 자체가 안보이는 경우가 많다. 그래서 좀 따분하지만 미래에 무슨 문제를 해결하게 될지 지금 모르더라도 진득하게 공부하는 것이 필요하기도 한 것 같다.</p>
<h3 id="2-새로운-기술을-만나는-여행">2. 새로운 기술을 만나는 여행</h3>
<p>AWS가 2006년도에 서비스를 시작했다는 내용을 책에서 읽는다. 나는 2009년에 회사에서 개발자로 일하기 시작했는데 지금까지 현업에서 AWS를 제대로 활용해 본 적이 없다. 여러 이유가 있지만 새로운 기술을 잘 활용하지 못하고 있는 나를 마주한다. 2006년에 나와 대중화된 서비스를 한 번도 제대로 활용해 본적이 없다니… 새로운 기술들을 탐험하고 여행하듯 경험해 봐야 겠다는 생각이 든다. 여행이라고 생각하니 심장이 두근두근하다.</p>
<h3 id="3-나-자신을-러버덕으로">3. 나 자신을 러버덕으로</h3>
<p>오늘 GPT와 러버덕 디버깅을 해보았다. 뭔가 문맥에 대해 설명할게 너무 많은 느낌을 받는다. 문득 나 자신을 러버덕으로 삼는게 더 효과적이란 느낌을 받는다. 나라는 러버덕에게는 즉시 문제로 뛰어들면 된다. 그리고 문제를 해결하는데 필요한 문맥을 스스로 더 설명하면 된다. 아무리 고도화된 AI라도 지금 나 자신보다 문맥에 대해 잘 이해하지는 못한다. 모르겠다 미래에는 나보다 내 상황을 잘 아는 AI가 등장할지도… </p>
<h3 id="4-숨겨진-문맥이-없고-단순한-규약이-있는-코드">4. 숨겨진 문맥이 없고, 단순한 규약이 있는 코드</h3>
<p>어떤 코드를 확장해 나갈 때 숨겨진 문맥을 알아야 코드를 작성할 수 있으면 좋지 않은 것 같다. 직관적으로 이거면 이거가 되도록 코드를 확장할 수 있으면 좋음을 느낀다. </p>
<h3 id="5-인터페이스를-어디에-둘-것인가">5. 인터페이스를 어디에 둘 것인가?</h3>
<p>종종 어떤 인터페이스를 인터페이스를 구현하는 클래스가 있는 패키지에 함께 두어야 하는지 아니면 인터페이스를 참조하는 클래스와 함께 두어야 하는지 답을 잘못했는데 SOLID 원칙, 특히 제어의 역전원칙을 이해하면서 답이 분명해 졌다. 답은 인터페이스 변경을 주도하는 참조하는 클래스와 함께 두는게 좋다. 자신이 참조할 인터페이스를 스스로 결정하고 자신에 의해 제어되길 바라는 외부 클래스들은 이 인터페이스에 의존하기 때문이다. 즉 외부 클래스에는 변경의 주도권이 없다. 패키지를 정리하면서 공부가 되었다. 좋다. 인터페이스 위치가 애매하다면 질문해 보자. 누가 변경의 주도권을 가지고 있는가?</p></div></div>

Joo's Work

JooSing

1. 미래에 만날 문제를 준비하는 시간
﻿늘 문제를 해결하기 위한 문제 주도의 학습을 강조해 왔지만, 그 반대도 의미 있다. 문제는 아직 만나지 못했지만 기술을 쌓아가는 것이다. 이 과정은 초등교육부터 대학교육까지 많이 받아와서 잘 알고 있다. 무엇에 쓰일지 지금 알지 못하지만 공부하는 것이다. 과정의 아쉬운 점은 문제 주도로 학습할 때 보다 열정이나 집중도가 떨어진다는 것이다. 실존하는 문제가 있으면 기술 학습에 훨씬 더 집중하게 된다. 그러나 균형있는 생각이 필요하다. 분명하게 경험하는 또다른 관점은 기술이나 지식이 있으면 문제가 보인다는 것이다. 모르면 문제 자체가 안보이는 경우가 많다. 그래서 좀 따분하지만 미래에 무슨 문제를 해결하게 될지 지금 모르더라도 진득하게 공부하는 것이 필요하기도 한 것 같다.
2. 새로운 기술을 만나는 여행
AWS가 2006년도에 서비스를 시작했다는 내용을 책에서 읽는다. 나는 2009년에 회사에서 개발자로 일하기 시작했는데 지금까지 현업에서 AWS를 제대로 활용해 본 적이 없다. 여러 이유가 있지만 새로운 기술을 잘 활용하지 못하고 있는 나를 마주한다. 2006년에 나와 대중화된 서비스를 한 번도 제대로 활용해 본적이 없다니… 새로운 기술들을 탐험하고 여행하듯 경험해 봐야 겠다는 생각이 든다. 여행이라고 생각하니 심장이 두근두근하다.
3. 나 자신을 러버덕으로
오늘 GPT와 러버덕 디버깅을 해보았다. 뭔가 문맥에 대해 설명할게 너무 많은 느낌을 받는다. 문득 나 자신을 러버덕으로 삼는게 더 효과적이란 느낌을 받는다. 나라는 러버덕에게는 즉시 문제로 뛰어들면 된다. 그리고 문제를 해결하는데 필요한 문맥을 스스로 더 설명하면 된다. 아무리 고도화된 AI라도 지금 나 자신보다 문맥에 대해 잘 이해하지는 못한다. 모르겠다 미래에는 나보다 내 상황을 잘 아는 AI가 등장할지도… 
4. 숨겨진 문맥이 없고, 단순한 규약이 있는 코드
어떤 코드를 확장해 나갈 때 숨겨진 문맥을 알아야 코드를 작성할 수 있으면 좋지 않은 것 같다. 직관적으로 이거면 이거가 되도록 코드를 확장할 수 있으면 좋음을 느낀다. 
5. 인터페이스를 어디에 둘 것인가?
종종 어떤 인터페이스를 인터페이스를 구현하는 클래스가 있는 패키지에 함께 두어야 하는지 아니면 인터페이스를 참조하는 클래스와 함께 두어야 하는지 답을 잘못했는데 SOLID 원칙, 특히 제어의 역전원칙을 이해하면서 답이 분명해 졌다. 답은 인터페이스 변경을 주도하는 참조하는 클래스와 함께 두는게 좋다. 자신이 참조할 인터페이스를 스스로 결정하고 자신에 의해 제어되길 바라는 외부 클래스들은 이 인터페이스에 의존하기 때문이다. 즉 외부 클래스에는 변경의 주도권이 없다. 패키지를 정리하면서 공부가 되었다. 좋다. 인터페이스 위치가 애매하다면 질문해 보자. 누가 변경의 주도권을 가지고 있는가?

개발일기 #99 : 새로운 기술을 만나는 여행

댓글