해킹에서 리버스엔지니어링은 개념, 원리의 이해보단 자세한 분석에 가깝다고 생각합니다.

알고리즘에선 코드의 분석도 필요하지만 개념의 이해가 더 중요하다고 생각합니다.

제가 한참 api에 관심이 있던 시기에는

함수 내부적인 것까지 뜯어가면서 공부해본 적은 있네요. 그런데 이건 특이한 케이스고요.

보통은 책 보시면서 개념 좀 이해하고 문제를 푸시는 게 전형적이지 않나.. 싶어요. 제 생각은 그래요.

종만북에 문제 해결 전략에.. 3종 셋트 있지 않나요?

전 흔한 JM북도 없긴 하지만요.

굳이 나쁘다. 좋다. 안 중요하다. 중요하다. 이렇게 나눌 문제는 아닌 거 같고요.

그건 상황에 따라서 달라지지 않나 싶고요.

남이 짜 놓은 레퍼런스 보고 (어떻게 설계하는 지) 배워보겠다. 나쁘지 않을 거 같네요.

저는 다른 사람의 코드를 참조하는 걸 매우 긍정적으로 생각합니다.

특히 어떤 알고리즘을 처음 짜다보면 막막할 때가 많은데, 이럴 때 다른 사람들의 코드를 보는 건 꽤 도움이 된다고 생각합니다.

알고리즘을 이해하는 것과 구현하는 것은 다른 문제기 때문에, 다른 사람들의 코드는 책만으로는 알 수 없는 내용들이 담겨 있기도 합니다.

다만, 원리를 확실히 이해하고 자신의 것으로 만드시는 게 중요할 것 같습니다.

저는 새로운 알고리즘을 구현할 일이 있을 때, 다음 과정을 거칩니다.

1. 구글이나 위키피디아에서 알고리즘이 어떤 과정으로 동작하는지 검색하고 찾아봅니다. (종만북 수준의 알고리즘이라면 종만북이나 다른 한글 자료로도 충분할 거라고 생각합니다만, 그것보다 고난이도의 알고리즘은 한글 자룔르 찾기 어렵기 때문에 구글에서 검색할 수밖에 없습니다.)

2. 알고리즘을 직접 구현해 봅니다. 이 단계에서는 다른 사람의 코드를 참조하지 않습니다. 저는 깔끔한 구현을 세우는 게 익숙하지는 않지만, 그래도 최대한 깔끔하게 구현하려고 노력해 봅니다. 복잡한 알고리즘이라면 150~200줄까지도 나오기도 합니다.

3. 다른 사람의 코드를 살펴봅니다. 참조하는 코드는 보통 실행 시간이 가장 빠른 코드이지만, 경우에 따라서는 최대한 짧은 코드를 참조하는 경우도 있습니다. 보통 제 초안이 150줄 정도 나오는 알고리즘은 다른 사람들이 줄이고 줄여서 4~50줄 정도로 만들어 놓은 경우가 많습니다. 이 코드를 한줄씩 뜯어보면서 동작을 확인하고, 구현의 아이디어를 이해합니다. 이 과정에서 코드의 길이가 짧아질 수도 있고, 알고리즘의 실행 시간 (주로 상수)가 줄어들기도 합니다.

4. 2와 3에서 본 아이디어들을 종합해, 최대한 제가 구현하기 쉬운 방법으로 다시 한번 구현해 봅니다. 다른 사람의 구현을 참조했더라도 0인덱스/1인덱스 사용이나 변수명, 그 외 자잘한 코딩 스타일 등에서 자신에게 맞춰야 할 부분이 있습니다. 이 단계에서는 이런 부분들을 저에게 맞추는 데 초점을 두고 구현해 봅니다. 

5. 이 코드를 여러 문제에서 사용해 봅니다. 알고리즘이 어려워질수록 그 알고리즘을 사용하는 문제도 적어지기 때문에, 다음 문제를 볼때쯤이면 이전 코드를 까먹을 수도 있습니다. 저는 북마크에 중요한 코드들을 담아놓고, 잊어버릴 때마다 다시 참조하는 편입니다. 이렇게 다시 구현하는 과정에서 코드가 점점 개선되기도 합니다. 저는 코드의 난이도에 따라 5~20문제 정도를 풀어본다면 구현 방법을 어느 정도 기억할 수 있었던 것 같습니다. (물론 그 이상을 푼다면 더 좋습니다. 인덱스 트리같은 수백번씩 나오는 자료구조는 이런 과정을 거친다면 거의 최적에 가까운 구현을 할 수 있겠죠.)