개발 실력 늘리는 법은 함수 암기가 아니었습니다 - 제가 개발 블로그를 시작한 이유

 

 

"그 함수들 다 외우면 실력 느는 거죠?"
"굳이 옛날 얘기까지 알아야 하나요. 쓸 줄만 알면 되잖아요."
"새로 나온 기술, 그냥 쓸 줄만 알면 되는 거 아니에요?"

 

 

저도 신입 때는 똑같이 생각했습니다. 언어 하나를 잘한다는 건 곧 그 언어의 함수와 문법을 얼마나 많이 외웠느냐의 문제라고 믿었거든요. 그런데 13년 정도 개발을 해 오면서, 제 실력이 눈에 띄게 올라간 구간은 함수를 더 많이 외웠을 때가 아니었습니다. 오히려 그 언어가 왜 태어났고, 어떤 문제를 풀려고 만들어졌는지를 알게 됐을 때였어요. 좀 이상하게 들릴 수도 있는데, 역사를 알고 나니 사용법이 더 잘 외워지더군요.

이 글은 거창한 개발론이 아닙니다. 그냥 제가 왜 이 블로그를 시작했는지, 그리고 왜 굳이 '개발의 역사'라는, 인기도 별로 없는 주제를 붙잡고 있는지에 대한 이야기입니다. 함수는 잘 외우는데 실력이 안 느는 것 같아 답답한 분이라면, 한 번쯤 읽어볼 만할 거예요.

📋 목차

1. 신입 때 저는 '어떻게든 돌아가게'만 짰습니다
2. "개발은 철학이다"라는 한마디
3. 그래서 공부 순서를 바꿨습니다 - NoSQL과 ORM 이야기
4. 동료를 가르치다 확실해진 것
5. 사용법은 넘치는데, 역사는 아무도 안 알려줍니다
6. 마무리

1. 신입 때 저는 '어떻게든 돌아가게'만 짰습니다

2012년에 웹 개발자로 일을 시작했습니다. 그때 제 코드를 한마디로 표현하면, 어떻게든 돌아가게 만든 코드였어요. 에러만 안 나면 됐고, 화면에 원하는 게 뜨면 그걸로 끝이었습니다. 검색해서 나온 코드를 붙여넣고, 동작하면 다음 작업으로 넘어가고. 솔직히 그게 개발인 줄 알았습니다.

물론 그렇게 해도 일은 굴러갑니다. 신입에게 맡기는 일이라는 게 대부분 그 정도 수준이기도 했고요. 그런데 시간이 지나도 제가 만든 코드가 '왜' 그렇게 동작하는지는 설명을 못 했어요. 누가 "이거 왜 이렇게 짰어요?"라고 물으면 "음... 이렇게 하니까 되던데요"가 제 대답이었습니다. 지금 생각하면 좀 부끄럽죠.

 

 

📌 그때 제 착각

함수를 많이 외우면 실력이 는다고 믿었습니다.

그래서 레퍼런스 문서를 달달 외우려고도 해 봤어요.

그런데 외운 함수는 안 쓰면 금방 잊어버렸고,

정작 새로운 문제 앞에서는 어떤 함수를 꺼내 써야 할지 감이 안 잡혔습니다.

 

2. "개발은 철학이다"라는 한마디

전환점은 의외로 별거 아니었습니다. 어느 선배가 지나가는 말처럼 "개발은 결국 철학이다"라고 한 적이 있어요. 당시엔 무슨 말인가 싶었습니다. 코드 짜는 일에 무슨 철학이냐고요. 그런데 그 말이 계속 머릿속에 남더군요.

그래서 한번 해 봤습니다. 새 언어나 기술을 공부할 때, 바로 문법부터 보지 않고 순서를 바꿔 봤어요. 이 언어가 언제, 왜 만들어졌는지. 그전에는 뭘 쓰고 있었고 어떤 점이 불편해서 새로 나왔는지. 강점이 뭐고, 그래서 어떤 상황에 쓰라고 만든 건지. 이걸 먼저 보고 나서 문법으로 들어갔습니다.

효과는 생각보다 빨리 나타났습니다. 예전엔 그냥 외워야 했던 문법들이, '아 그래서 이렇게 생겼구나'로 바뀌더라고요. 외우는 게 아니라 납득이 되니까 기억에 오래 남았습니다. 그리고 더 중요한 변화가 있었는데, 적재적소에 쓸 줄 알게 됐다는 거예요. 이 기술은 이럴 때 쓰는 거라는 감이 생기니까, 도구를 고르는 안목 자체가 달라졌습니다.

3. 그래서 공부 순서를 바꿨습니다 - NoSQL과 ORM 이야기

제일 와닿았던 게 데이터베이스 쪽이었습니다. NoSQL이 한창 화제가 되던 시절이 있었어요. 다들 "이제 관계형 DB는 한물갔다, 앞으로는 NoSQL이다" 하면서 분위기에 휩쓸리던 때였죠. 저도 처음엔 이걸 무작정 따라가야 하나 싶었습니다.

그런데 NoSQL이 왜 태어났는지를 알고 나니 그림이 달라졌습니다. 2000년대 중반, 구글이나 아마존 같은 곳에서 인터넷 데이터가 감당 안 될 만큼 폭증하던 게 발단이었어요. 기존 관계형 DB는 용량을 늘리려면 서버 한 대를 더 좋은 걸로 갈아 끼우는 수직 확장밖에 답이 없었는데, 그 방식으로는 도저히 못 버틸 규모가 된 겁니다. 그래서 구글은 Bigtable(2006년), 아마존은 Dynamo(2007년) 같은 걸 논문으로 내놓으면서, 데이터를 여러 서버에 흩뿌리는 분산 구조를 택했죠. 대신 관계형 DB가 보장하던 엄격한 일관성(ACID)을 일부 내려놓는 거래를 한 거고요.

 

 

💡 그래서 알게 된 것

NoSQL은 관계형 DB보다 '좋은' 게 아니라,

어마어마한 규모와 유연한 구조가 필요한 특정 문제를 풀려고 나온 도구였습니다.

출신을 알고 나니 유행을 좇아 무작정 갈아탈 게 아니라,

내 서비스 상황에 맞을 때만 꺼내 쓰면 된다는 판단이 서더군요.

 

 

ORM도 비슷했습니다. 처음 봤을 땐 "그냥 SQL 쓰면 되지 왜 굳이?" 싶었거든요. 그런데 ORM이 등장한 이유를 알고 나서 생각이 바뀌었습니다. 객체지향 언어는 클래스와 객체로 세상을 보는데, 관계형 DB는 테이블과 행으로 데이터를 봅니다. 이 둘이 서로 안 맞아서 생기는 골치 아픈 간극을 임피던스 불일치라고 부르는데, 원래 전자공학에서 회로 성질이 안 맞을 때 쓰던 말을 그대로 가져온 거예요. 객체를 매번 손으로 테이블 행에 맞춰 바꿔 넣는 반복 작업이 지긋지긋했고, ORM은 그 변환을 자동으로 대신해 주려고 나온 겁니다.

여기서 한 가지가 더 보였습니다. ORM이 왜 생겼는지를 알면 거꾸로 그 한계도 보이거든요. 서로 다른 두 세계를 이어 주는 다리에는 비용이 따르기 마련이라, 복잡한 조회 같은 건 차라리 SQL을 직접 쓰는 게 나을 때가 있습니다. 그래서 저는 평소엔 ORM에 맡기되 무거운 쿼리는 직접 손대는 식으로 가려 쓰게 됐어요. 도구가 태어난 사정을 알면, 언제 기대고 언제 내려놔야 하는지까지 같이 따라옵니다. 이런 경험이 한두 번이 아니다 보니, 공부 순서를 바꾼 게 우연이 아니었다는 확신이 들더군요.

4. 동료를 가르치다 확실해진 것

혼자만의 착각일 수도 있으니, 동료들한테 알려줄 때 한번 실험을 해 봤습니다. 그냥 "이건 이렇게 쓰는 거예요"라고 사용법만 알려주는 대신, "이게 왜 이렇게 생겼냐면요"를 같이 붙여서 설명해 본 거죠.

결과가 꽤 분명했습니다. 사용법만 들은 사람은 며칠 뒤에 다시 물어보는 경우가 많았어요. 반면에 배경까지 같이 들은 사람은, 정확한 문법은 좀 까먹어도 "아, 이게 그거 때문에 이렇게 쓰는 거였죠?" 하면서 스스로 답을 찾아갔습니다. 외운 게 아니라 이해를 한 거니까 응용이 됐던 거예요.

가르치는 입장에서도 좋았습니다. 역사와 맥락을 같이 설명하려면 저부터 제대로 알아야 하니까, 결국 제 공부가 한 번 더 되더라고요. 누군가에게 설명할 수 있을 만큼 알아야 진짜 아는 거라는 말, 그게 빈말이 아니었습니다.

5. 사용법은 넘치는데, 역사는 아무도 안 알려줍니다

그러다 한 가지가 눈에 들어왔습니다. 인터넷에 사용법을 알려주는 글은 정말 차고 넘칩니다. "이 함수 이렇게 쓰세요", "이 에러는 이렇게 고치세요" 같은 글은 검색하면 수십 개씩 나와요. 그런데 정작 "이 언어가 왜 이렇게 설계됐는지", "이 기술이 어떤 불편함을 풀려고 태어났는지"를 차근차근 짚어주는 글은 의외로 드물었습니다.

다들 사용법은 압니다. 그건 검색하면 되니까요. 하지만 그 도구가 왜 이런 모양이 됐는지를 알려주는 사람은 잘 없습니다. 저는 바로 그 지점이, 제가 실력이 늘었던 진짜 이유였다고 생각하거든요. 그래서 이 빈자리를 메워 보자는 마음으로 블로그를 시작했습니다.

물론 이게 정답이라고 우길 생각은 없습니다. 누군가는 일단 많이 짜 보는 게 최고라고 할 거고, 그 말도 맞아요. 다만 적어도 저한테는, 도구의 출신과 사정을 먼저 아는 방식이 가장 잘 맞았습니다. 그리고 저 같은 사람이 한 명쯤은 더 있지 않을까 싶어서요.

마무리

제가 이 블로그에서 굳이 옛날 얘기, 언어의 탄생 배경, 기술의 역사 같은 걸 자꾸 꺼내는 이유가 여기에 있습니다. 함수를 외우는 건 누구나 검색으로 할 수 있지만, 그 도구가 왜 태어났는지를 알면 사용법은 덤으로 따라온다는 걸 직접 겪었기 때문이에요. 적어도 제 13년은 그랬습니다.

자주 묻는 질문

개발 실력을 늘리려면 함수를 많이 외우는 게 좋을까요?

외워 두면 당장은 편하지만, 안 쓰면 금방 잊어버리고 새로운 문제 앞에서는 응용도 잘 안 됩니다. 개인적으로는 그 기능이 왜 만들어졌는지를 먼저 이해하는 쪽이 기억에도 오래 남고, 적재적소에 꺼내 쓰는 데 더 도움이 됐습니다.

기술의 역사나 등장 배경을 아는 게 실무에 도움이 되나요?

저한테는 그랬습니다. NoSQL이나 ORM이 왜 나왔는지를 알면 그게 '더 좋은 도구'가 아니라 특정 상황을 풀려고 나온 도구라는 게 보여서, 언제 쓰고 언제 안 써도 되는지 판단이 서거든요. 다만 이건 제 경험일 뿐 모두에게 정답은 아닐 수 있습니다.

신입 개발자는 무엇부터 공부하는 게 좋을까요?

정답이 하나라고 생각하진 않습니다. 일단 많이 짜 보는 것도 분명 좋은 방법이고요. 저는 새 기술을 만나면 문법보다 '왜 생겼는지'부터 보는 순서가 잘 맞았는데, 함수 암기만으로 실력이 잘 안 느는 것 같다면 이 방식도 한 번 시도해 보시길 권합니다.