[Retrospective-2022] 개발자에게 정말 필요한 역량은 무엇일까? (Feat Siner)
사전지식
- Flyway : 데이터베이스 Migration tool.
데이터베이스의 버전을 관리 할 수 있는 도구 라고 생각하면 좋겠다.
이야기에서 툴의 이름이 나와 언급했지만 구체적인 툴의 정보를 요구하지 않음.
서론
이야기의 시작
2022년 09월 08일 테스트 전용 데이터베이스를 사용할 수 있는 환경을 구축하고 있었다.
환경 구축을 하면서 나오는 에러에 대해 구글링을 했지만, 내 환경에서는 해결법이 되지 않았고 시간은 어느새 2일이 지나있었다.
테스트 전용 환경 구축 트러블슈팅 : 해결중 … (해결 후 정리 하여 블로그 올릴 예정)
시간이 더이상 지체되면 더 늘어질 거 같아,
해당 프로젝트의 pm 이자 내 멘토 이자 사촌형인 Siner 에게 도움을 요청했고 흔쾌히 시간을 내줬다.
처음 내가 물어 봤던 내용은 “flyway 를 disable 했는데도 불구하고, flyway 가 동작한다. 이거 이상하다.”
지금 작성하면서도 굉장히 창피한 수준의 질문인 것 같다.
Siner 는 나에게 오히려 되물었다.
“해당 flyway 가 어디서 동작하는지 , 코드로 찾아갈 수 있어?”
나는 당황했다.
분명 나도 Flyway 에 대한 이해가 필요 할 걸 알고 있었고 공식 문서를 통해 flyway 가 어떤 툴인지,
어떻게 대충 동작하는지 에 대해서 봤기 때문에
파일의 이름으로 해당 파일을 인식하고 그에 대한 코드를 돌리는 식이 라는 것은 알았지만
그 내부적인 코드는 내가 구현 하지도 않았고 그 내용을 도대체 어디서 볼 수 있지?
라는 생각이 가장 먼저 들었다.
문제를 만났을 때 내가 대처했던 방법
내가 에러를 만나고 그것을 해결 하기 위한 프로세스를 리마인드 해보면
- 해당 오류 구글링
- 적용 -> 실패
- 오류 내용중 flyway keyword 찾아 다시 구글링 -> 적용 -> 실패
- 다시 구글링 -> 적용 -> 실패
- 반복
위 방법으로 당장의 눈앞에 문제는 해결 할 수 있지만,
결국 나에게 남는것은 해당 tool 의 사용법을 암기 하는 꼴이 된다.
본론
문제를 만났을 때 어떤 방식으로 접근 해야 할까?
내가 어떤 문제를 만났을 때, flyway 에 대해서 구글링 하고 무지성으로 적용 하는 것이 아니라
그 문제를 먼저 분석 할 필요가 있다.
예를 들어 flyway 에 대한 키워드로 문제가 발생 했다면 그냥 에러코드를 복붙 해서 구글에 붙이는 것이 아닌
왜 이런 문제가 발생 했는지 한번 생각해보고 이해해보는 시간이 필요하다.
그 이해한 것을 바탕으로 찾아 봐야 하는데,
- 첫번째 : 구글링
구글링이 나쁜 것은 아니지만,
구글링으로 해결이 되지 않을 때도 있고, 누군가 정리 놓아야만
내가 알 수 있다 라는 단점이 있다.
결국 구글링을 통한 문제 해결은 한계점이 있다.
어떻게 해결 할 것인가 ? 하나의 해결법 : 오픈소스
“세상의 모든것은 코드로 되어있다” 라는 마인드 셋
내가 맞닥뜨린 문제를 바탕으로 예시를 들어보자면,
나는 flyway 를 실행시키지 않고 싶은데, flyway 가 실행이 된다.
구글링을 통해 flyway 를 disable 시키는 방법을 알게 되었지만 어째서 인지 동작 하지 않는다.
결국 구글에서 제공해주는 정보가 없으니 아무것도 하지 못하는 바보가 되어버렸다.
flyway 도 코드이다.
우리는 flyway 를 disable 시키기 위한 방법 또는 flyway 가 어떻게 실행되는지를 알기 위해
구글에서 찾는 것이 아닌 해당 코드에서 찾을 수 있어야 한다.
flyway 는 구글로 동작하는게 아닌 해당 코드로 동작하는 프로그램이기 때문이다.
예시로 flyway 를 들었지만 우리가 사용하는 프로그램들은 모두 코드로 되어있다.
그리고 그 코드들은 대부분 github 같은 저장소에 오픈소스로 배포되어 있기 때문에
우리는 그 코드를 통해 우리가 쓰는 프로그램을 분석 할 수 있고, 더 나아가 내 프로그램에 맞게 튜닝 해서 사용 할 수도 있다.
구글링의 한계점을 오픈소스를 통해 깨 부술수 있다.
오픈소스 그래서 어떻게 찾아야해? - 구체적인 방법
- 먼저 문제가 발생 하면 해당 문제를 분석하고 어떻게 해결 할 건지 정해야한다.
- 나는 flyway 에서 “Please restore backups and roll back database and code!” 이러한 에러메세지를 넘겨 주었기 때문에
이 문장을 따라서 flyway 가 어떻게 실행 되었는지를 따라 가보려고 한다. - 찾고자 하는 메세지나 함수 들은 github 검색의 “in this repository” 로 간편하게 찾을 수 있다.
- 위 사진 처럼 해당 함수를 호출 하는 부분을 reference 로 타고타고 올라 갈 수 있다.
이렇게 github 에서도 찾을 수 있지만 ,
IDE 에서도 해당 라이브러리 내부 클래스로 볼 수도 있다.
더 편한 방법으로 사용하면 될 거 같다.
Intellij 파일 찾기 : cmd + shift + o
오픈 소스 장점
- 구글에서 정보를 찾는 입장에서 정보를 제공하는 입장이 될 수 있다.
- 현재 내가 처한 상황에서 최선의 선택을 할 수 있는 능력을 갖게 된다.
같은 프로그램을 사용하더라도, 어떤 사람이 사용 하면 좋은 퍼포먼스를 내고, 어떤 사람이 사용하면 내 서비스가 완전히 죽어버릴 수 있다.
그 차이는 내가 사용하는 프로그램이 어떻게 동작하는지 정확히 이해하고 사용하는 사람과 단순히 이용법만 외워서 쓰는 사람의 차이 라고 생각한다.
프로그램이 어떻게 동작하는지 좋은 블로그나 공식문서를 통해 운 좋게 알수는 있으나,
현재 처해진 상황이나 문제를 빠르게 정확하게 해결 하기 위해선 사용하는 프로그램을 직접 뜯어보는 능력이 필수적으로 요구 된다.
- 툴에 의존적이지 않게 된다.
구글링을 통해 어찌어찌 flyway 에러를 해결 했다고 가정하자.
flyway 가 이제 legacy 프로그램이 되어서 다른 프로그램으로 교체 할때, 그 해당 프로그램도 구글링으로 쳐보면서 환경을 구축 할 것인가?
만약 사용하고자 하는 프로그램이 나온지 얼마 안되어서 레퍼런스가 없을 경우, 오픈소스를 분석하는 능력이 있다면 어떤 툴을 쓰든 두렵지 않을 것 같다.
- 오픈소스 기여 가능.
왜 기업들이 오픈소스 기여한 사람들을 좋아하는지 알게 되었다.
결론
Siner 에게 많은 것을 배웠지만, 이번 주제 만큼은 정말 귀한 것을 배웠다고 생각한다.
개발자에게 정말 필요한 역량은 무엇일까? 라는 제목을 지은 이유는 필요한 역량중 많은 것이 있겠지만,
오픈소스를 뜯어보는 능력도 그중 하나가 되지 않을까 생각을 한다.
시간적 리소스가 부족한 경우, 오프소스를 뜯어 보는 것 보다 구글링이 더 효율적일 때도 있을 거라 생각한다.
모든 문제에 대해서 오픈소스를 뜯어보는 것은 하라고 해도 못할것 같다..
어느 한가지 방법이 좋다! 이 방법만 사용해라 라기 보다는
언젠가 구글링으로 해결 할 수 없는 문제를 마주칠 경우, 해결 할 수 있어야한다.
해결책으로 오픈소스를 뜯어서 파악 할 수 있는 능력이 있어야 한다. 그렇기에 미리 연습 해놓아야 한다. 라는 것이 핵심이다.
다음편은 직접 spring 오픈소스를 뜯어보면서 application.yml 이 어떻게 동작하게 되는지 실습 한 내용을 써보려고 한다.
Leave a comment