무엇을? 어디까지?

모르는 것이 많으면 공부하면 된다고 생각했다.

그런데 우테코에서 어려웠던 것은 공부할 것이 없어서가 아니었다.

너무 많았다.

하나를 이해하려 하면 다른 모르는 것이 나왔고, 그것을 찾아보면 또 다른 개념이 필요했다. 지금 이걸 알아내는 것이 미션에 중요한지, 그저 내 호기심을 채우고 있는지 구분하기가 어려웠다.

내가 느렸던 이유를 단순히 지식이 부족해서라고만 설명하기는 어려웠다.

어디서 멈춰야 하는지 모르는 것이 꽤 큰 병목이 되었다.

어디까지 이해해야 할까?

장기에 DB를 연결하면서 JDBC를 처음 다뤘다.

이전에는 알고 있는 동작을 어떻게 코드로 옮길지 고민했다면, 이제는 코드에 등장한 객체가 왜 존재하는지부터 알아야 했다.

DBMS를 고르고, Java에서 연결하고, 데이터를 저장하는 것까지 모두 낯설었다.

당시 코드에 있던 ConnectionFactory 인터페이스만 보면 몇 줄 되지 않는다.

@FunctionalInterface
public interface ConnectionFactory {
    Connection getConnection() throws SQLException;
}

하지만 내게는 이 인터페이스를 왜 두어야 하는지부터 질문이었다.

트랜잭션을 실행할 동작을 콜백으로 받는 방법을 만나자 함수형 인터페이스와 람다까지 이어졌다. 장기 PR에 남긴 답글에도 이렇게 적었다.

동작 자체를 받아서 처리할 수 있으므로 코드의 가독성이 크게 올라갔지만, 그것을 호출하기 위한 람다를 이해하는 것에 시간을 많이 투자했습니다.

나는 내가 작성한 코드만큼은 이해하고 싶었다.

하지만 제출 기한이 있었고, 미션은 늦어졌다. 리뷰를 충분히 받지 못할 수도 있다는 연락도 받았다.

일단 돌아가는 코드로 리뷰를 요청하는 것이 맞았을까. 내 코드에 대해 최대한 이해하려고 시간을 쓰는 것이 맞았을까.

레벨1 인터뷰에서 그 질문에 명확히 답하지 못했다.

다만 무엇이 지금 중요한 정보인지 판단하는 능력이 필요하다는 것은 분명히 느낀다.

호기심을 금지?

나는 원래 먼저 구현하고 나중에 개선하는 편이었다.

직접 경험한 것이 내 것이 된다고 생각했고, 이해되지 않으면 AI에게 계속 이유를 물었다.

이 방식은 궁금증을 해결하는 데에는 도움이 됐다.

하지만 기초를 넓게 알아야 할 때에도 한 가지에 깊게 들어가곤 했다. 지금 필요한 전체 그림을 보기 전에 작은 부분을 오래 들여다봤다.

그래서 단순 호기심을 해소하기 위한 질문을 자제하려고 했고, 4월 개인 학습 과제에서는 상당히 강한 규칙을 정했다.

AI와 피드백을 통해서만 어떤 것이 중요한지 판단하고 시간을 투자

지금 보면 스스로의 판단을 너무 멀리 밀어낸 문장이다.

하지만 그때는 내가 중요한 것을 고를 수 없다는 불안이 컸다. 혼자 끝없이 파고드는 것보다, 누군가가 중요하다고 알려준 것에 시간을 쓰는 편이 안전하다고 생각했다.

학습 내용을 질문으로 정리하고 다음 날 답해보는 방식도 계획했다. 새 기술을 이전 방식과 비교해보려 했다가, 이것도 너무 깊게 들어가지는 말자고 덧붙였다.

멈추는 것도 판단

돌아보면 나는 공부를 많이 하면 이 불안도 사라질 것이라 기대했던 것 같다.

하지만 아는 것이 늘어날수록 새로 보이는 모르는 것도 많아졌다.

어디까지 알아야 하는지에 대한 질문은 공부가 부족해서 생긴 문제이기도 했지만, 배움이 계속되는 동안 함께 가져가야 할 질문이기도 했다.

지금도 누구에게나 적용할 수 있는 선을 긋기는 어렵다.

다만 어떤 선택을 하든 그 이유는 남겨보고 싶다.

지금 더 알아보는 이유가 실제로 내 판단을 바꾸기 위해서인지. 멈추는 이유가 중요하지 않아서인지, 어려워서 피하고 싶은 것인지.