“나는 지금까지 어떻게 개발해왔을까?” 와 “뭘 중요하게 생각할까?” 라는 주제로 정리해보려고 한다.
필자는 개발할때 가장 중요하게 생각하는 목록으로는 아래와 같다.
1.
동기부여(왜 만들려고 하냐?, 어떤 도움이 될까?)
2.
어떻게 만들 것인가?
3.
피드백
동기부여
혼자 뭘 만들고 고치고 하다 보면 왜 만들어야 하는지에 대해 잊을때가 많이 있었다. 처음에는 왜? 라는 질문을 잊고 만들어도 된다고 생각했던 적이 있었다. 오히려 왜?라는 질문 보다는 기술에 좀 더 치중했다. 하지만 어느날 유튜브를 보던 중에 배달의 민족 ceo님? 이 나오셔서 이런 말씀을 했다. “개발을 하려고 생각하기 보다 개발을 안하고 해결할 수 있는 방향이 제일 좋다. 그리고 개발을 할꺼면 가장 심플하게 개발하는 것이 제일 좋다고” 그 때 뭔가 느낄 수 있었다. 아 지금까지 이걸 만들기 위해서 소잡던 칼로 닭을 잡고 있었구나. 하고 그리고 동기부여에 대해서도 다시 생각할 수 있었다. “잘된 동기부여는 곧 개발의 범위를 정할 수 있다”라는 것을.. 개발이란게 범위가 참 넓다. 그래서 뭘 선택하고 왜 이걸써야하고 이런걸 보다보면 끝이 안났었다. 그래서 내가 소잡던 칼로 닭을 잡고 있었던 것이다. 그만큼의 노력과 내 피로도를 녹여가면서... 무엇보다 범위 설정이라는게 이 곳에서 말하고 싶었던 것이었다. 동기부여는 곧 범위를 잡을 수 있는 힘을 준다. 그래서 범위를 잘 잡기 위해서 왜? 어떤 도움이 될까?를 제일 중요하게 생각했다.
어떻게 만들 것인가?
기술적인 이야기가 될 수 있고 개념적인 이야기가 될 수 있다. 근데 필자 같은 경우에는 후자를 더 많이 생각하는 것 같다. 일단 먼저 본론으로 가기전에 기술적인 이야기에 대해서 설명하겠다. 예를 들자면 DB를 어떤 걸 쓸까? jpa가 좋은가? jpa를 쓴다면 왜 jpa를 써야하는가? 이런 이야기다. 하지만 본론으로 돌아와 개념적인 이야기를 한다면 사용자에게 어떤 환경을 제공할 것인가? 예를 들자면 사용자 친화적인 환경? 사용자 친화적이란 것의 범위는 어디까지로 정할까? 다양한 서비스를 제공할까? 아니면 반대로 일부 사용자에게 친화적인 환경으로 개발할 것인가? 예를 들면 API서버같은.. 그런 느낌이다. 이걸 중요하게 생각하는 이유는 코드를 쳐야하는걸 줄여준다. 사용자 친화적이란 말은 그만큼 다양한 서비스를 제공해야 하고 내가 쳐야하는 코드가 많아진단 이야기다. 하지만 불친절하고 정적이라면 그만큼 맞춰야할 제약조건이 적어진다. 왜냐하면 그 이상의 기능을 제공하지 않으면 그만이니깐. 그래서 이걸 중요하게 생각했다.
피드백
무엇이든 피드백은 중요하다. 그게 잘하는 사람에 받든 아니면 스스로 피드백을 하든. 동기부여도 잘되고 어떻게 만들지도 결정했다고 가정하면 늘 피드백 한다. 그럼 좀 더 구체화 시킬 수 있는 것 같다. 모든 문장한줄한줄마다 왜라는 문장을 달아본다. 그럼 안보이던게 보이고 보이던게 새롭게 보일때가 생겼던 것 같다. 그걸 처음으로 이뤄냈던게 모던자바인 액션을 정리할때다 아직도 기억하는것이 있다. 그건 아래의 사진으로 첨부했다. 이렇듯 왜? 라는 질문을 통해 스스로 피드백하는게 제일 중요하였다.
왜? 라는 질문으로 내가 모르는 걸 찾았다. 여기가 시작이었던 것 같다.
이 세가지는 절대로 놓지 않으려 노력한다. 물론 까먹을때도 있다. 그래도 내가 개발을 할때 가장 중요하게 생각하는 세 가지다.
그리고 이 세 가지가 다 된다면 기술을 선택하는 편이다.
1.
동기부여에 해당하는 문제를 해결하려면 무슨 기술이 있을까?
2.
어떤 걸 사용하면 좋을까?
3.
이게 다른 것에 비해서 왜 좋을까?
4.
어떻게 하면 이 예제? 말고 다른 방식을 적용할 수 있을까?
이 네 가지를 계속 반복하며 만드는 것 같다. 큰 서비스를 만든적 없기 때문에 현재 수준 이전 까지는 대부분 쉽게 배울 수 있고 바로 활용할 수 있는 걸 좀 더 큰 중점으로 둔 것 같다. 하지만 이제 와서 생각해보니 쉽게? 보다는 동기부여에 해당되는 문제를 좀 더 잘 해결할 수 있는 기술을 선택하는 것 같다.
필자는 지금까지 개발하면서 제일 많이 느끼고 지금도 지키려고 노력하는 것들이다. 사실 좀 허무할 수 있다. 어떤 기술을 쓰고 어떻게 만들면 좋고 이런 이야기를 하는 것이 아니기 때문이다. 필자가 대단한 개발을 하는 사람도 아니고 잘하는 것도 아니다. 하지만 믿고 있는 한 가지는 어떤 기술을 쓰고, 어떻게 만들면 좋고 이런 것은 결론이 존재하기 힘들다(물론 결론이 있는 경우가 있지만 시간은 흐르고 기술도 변한다 그 점을 예로 드는 거다). 그렇지만 동기부여는 끝이 있다(내가 정하는 범위기 때문이다). 내가 개발하는 범위는 끝이 존재한다(내가 단언한다면). 내가 생각하는 도움의 수준은 끝이 존재한다. 이렇듯 동기부여에서 이야기한 배민 ceo?님이 이야기하신 개발을 안하는 방법, 한다면 심플하게 하는 방법을 제시하는 것이고 필자가 개발해온 방법이자 팁이다.
자 이제 개발하는 방법은 알았으니 필자가 학습하는 방법을 알아보자.
1.
구글을 킨다.
2.
키워드를 검색한다.
3.
찾는다.
4.
해본다.
a.
안된다. 다시 1
5.
된다.
6.
왜 되는지 찾는다.
7.
내가 원하는 방식으로 바꿔본다.
a.
안된다. 다시 1
8.
다른 방식을 찾아본다.
a.
없다. 그럼 거기서 스톱
9.
있다.
10.
7을 기반으로 해본다.
a.
안된다. 8
11.
된다.
12.
반복..
정말로 심플하다.
근데 중심이 되는 생각은 늘 존재한다. 그건 바로 학습 커브를 어떻게 하면 줄일까? 이다.
처음 스프링을 공부할때로 거슬러 올라가면 사실 자바 8에 대한 지식이 거의 없었다. 그래서 스프링이 왜 돌아가는지 뭘 위해 만들어졌는지 몰랐다. 그래서 검색했다. 스프링을 공부하는 방법을 그러다가 토비의 스프링을 알게 되고 이걸 보기 위한 선행지식을 검색했다. 그러던 도중 스프링부트가 자바 8이상의 버전을 지원하고 있다는 걸 알 수 있었다. 이를 통해서 “아하 자바 8이상을 지원한다는건 이유가 있을거다.” 하고 생각했다. 그런데 어느정도 맞았다. 덕분에 토비의 스프링을 볼때 큰 어려움이 없었다(자바 코드를 읽는데). 이렇듯 먼저 검색하고 검색한 키워드를 기반으로 선행지식을 먼저 공부해보려고 한다. 이게 중심이 되어 지금까지 온 것 같다.
그래서 이어지는 것이 자료 구조 이다. 자료구조를 공부하는 이유는 알고리즘도 존재한다. 하지만 좀 더 큰 관심사는 스프링에서의 자료 구조 적용이다. 뭐 예를 들자면 검색? 아니면 성능? 자료구조를 안다면 좀 더 접근하기 쉬운 문제가 될 수 있다. 그런데 검색하는 건 쿼리 던지는 거 말곤 아직 아는게 없다. 성능? 데이터를 저장할 때 뭘 써야하는지는 대충알지만 왜 이거지? 라는 것은 대답하기 힘들다. 이렇듯 이걸 대답하고 다음에 배울 수 있는 것들에 대해 학습 커브가 줄일려고 하는 생각을 중심으로 위의 플로우를 반복한다.
.. 아까 내용을 좀 더 이어서 해온 노력
지금까지의 삽질도 전부 이 다음에 배울 학습커브를 줄이기 위한 노력들? 인 것이다. 엑셀을 내가 쓰기 편한 형태로 만들어 놓는다면 언제든 다른 예제에도 엑셀 라이브러리를 적용시킬 수 있다(다른 방식을 적용해서 학습테스트를 만들기 편하다). 아래는 내가 람다를 이용한 도메인 전용언어를 만들어 본 예제다. 그 당시 lol을 많이 해서 롤의 스펠을 찍는걸 도메인 언어로 변경해봤다. 그런데 마지막 작업이 실패해서 결국 노션에는 올리지 못했다. 대충 아래에보이는 방식을 다 만들려고 했다. 모든 방식 조합이 실패했다. 어렵더라.
대충 이만큼 만들었다. 전부 보여주기 힘드니 별로도 첨부 해두겠다.
결론적으로 개발을 어떻게 하면 잘할까? 에 대해서 생각하다가 알아낸 나만의 방식은 아래의 리스트와 같았다. 나도 처음 시작할땐 어느정도 해야할까? 최신기술을 공부하면 그것이 잘하는 것일까? 이런 생각을 많이 했다. 하지만 시간이 지나고 삽질경력이 쌓이면서 느낄 수 있었던 것은 결국 빨리 배울 수 있는 것이 내 동기부여를 해결하는 가장 좋은 방법이라는 걸 알았다.
1.
학습 커브를 줄이기 위한 공부를 한다.
2.
위를 반복한다.
별첨
빼먹은게 있었다. 필자의 경우 역사를 엄청 좋아한다. 왜 나온지 아니깐 기억이 잘나더라 그래서 왜 나온지에 대해 앵간하면 찾아보는 편인 것 같다.
젤 기억에 남는 왜 사과문
젤 기억에 남는 잘못된 역사 DTO와 VO
이건 어디서 youtube 의 개발자 컨퍼런스에서 봤다. 이게 반대로 적혀 있어서 책에서 javaEE6? 이책인가? 거기서 잘못적혀서 지금까지 헷갈리는 사람이 많다고 했다.
자바의 어원 제임스 고슬링이 커피좋아해서
제임스 고슬링은 소녀시대 팬이다. ㅋㅋ
스프링의 어원은
자바엔터프라이즈 시스템이 추운 겨울처럼 코딩하기 힘들었는데 자바 개발자들에게 봄이 왔다는 의미에서 스프링이 된 걸로 안다(봄이 아니라 거의 냉동고 수준이다).
POJO의 어원은
Plain Old Java Object의 약자이며 평범하고 오래된 자바 객체이다. 심플하다. ㅋㅋ
등등