생계 때문에 개발을 시작했다. 그런데 왜 아직 개발하고 있을까 | RE:개발자 #15

 

 

생계 때문에 시작한 개발이 왜 재미있어졌을까.

웹소설 작가 경험부터 정보처리기사, Security Lens, README, AI 활용까지 Coder Legion 개발자 인터뷰에 답하며 내가 배우고 개발하는 방식을 돌아봤다.

 

며칠 전 Coder Legion의 Developer Stories 인터뷰 제안을 받았다.

 

처음에는 개발 경험에 대한 질문 몇 개에 답하면 되는 일이라고 생각했다.

그런데 질문에 하나씩 답하다 보니 생각보다 자주 멈추게 됐다.

 

왜 개발자가 됐는지.

 

왜 나는 이론을 외우는 것보다 직접 만들면서 배우는 게 잘 맞는지.

 

AI를 어떻게 사용하고 싶은지.

 

그리고 앞으로 어떤 개발자가 되고 싶은지.

 

개발 이야기를 하고 있었는데, 이상하게도 개발자가 되기 전의 나까지 다시 돌아보게 됐다.

---

사실 개발은 생계 때문에 시작했다

처음부터 프로그래밍을 좋아했던 것은 아니다.

솔직히 말하면 시작한 이유는 꽤 현실적이었다.

 

먹고살기 위해서였다. 취직을 위해서였다.

 

개발 공부를 시작한 것도 불과 몇 년 전이다.

 

그때는 지금처럼 AI가 개발 과정 전체에 자연스럽게 들어와 있지도 않았다.

한국에서 취업을 생각했을 때 Java와 Spring을 사용하는 회사가 많았고, 특히 기업과 공공 프로젝트에서 많이 사용되고 있었다.

그래서 Java와 Spring을 선택했다.

처음 선택에는 거창한 철학 같은 것은 없었다.

 

그런데 개발을 배우다 보니 예상하지 못했던 곳에서 재미를 발견했다.

나는 개발자가 되기 전에 웹소설 두 작품을 유료 연재한 경험이 있다.

어느 순간 소설과 프로그래밍이 생각보다 많이 닮아 있다는 느낌을 받았다.

 

소설을 쓸 때는 세계관을 만든다.

그 안의 규칙을 정하고, 캐릭터들은 그 규칙 안에서 움직인다.

프로그래밍도 비슷했다.

언어의 규칙이 있고, 네트워크의 규칙이 있고, 데이터와 비즈니스 로직의 규칙이 있다.

 

그리고 개발자는 그 안에서 시스템과 사용자가 움직일 수 있는 흐름을 만든다.

그때부터 프로그래밍이 단순히 생계를 위한 기술만은 아니게 됐다.

---

내가 사용자라면?

소설을 쓰던 습관도 아직 남아 있다.

시간적인 여유가 있다면 개발하면서 여러 상황을 상상하는 편이다.

내가 사용자라면 어떨까?
이 분야를 전혀 모르는 사람이라면?
예상하지 못한 방식으로 이 기능을 사용한다면?

 

물론 일정이 급하면 이런 생각을 충분히 하지 못 할 때도 있다.

그래도 여러 사람과 여러 상황을 머릿속에서 한번 시뮬레이션해보는 습관은 개발자가 된 지금도 꽤 많이 남아 있다.

어쩌면 내가 소설에서 캐릭터를 움직이던 방식과 크게 다르지 않은지도 모르겠다.

---

외운 건 잊었는데, 에러는 기억했다

최근 정보처리기사 시험을 다시 준비하면서 한 가지를 명확하게 깨달았다.

 

나는 암기만으로 배우는 방식과 잘 맞지 않는다.

 

시험을 위해 외운 이론은 시간이 지나면 생각보다 쉽게 잊어버렸다.

그런데 이상하게도 회사에서 직접 겪었던 에러는 기억하고 있었다.

 

어떤 문제가 발생했는지.

왜 발생했는지.

무엇을 바꿨더니 해결됐는지.

시간이 지나도 그 과정은 꽤 오래 남았다.

그때 알았다.

 

내게는 지식을 외우는 것보다 문제와 지식을 연결하는 과정이 필요했다.

마침 AI 개발 공모전을 발견했고, 다시 직접 개발을 시작했다.

모든 것을 공부하고 나서 만들려고 하기보다는 일단 만들기 시작하고, 필요한 것이 생기면 그때 공부했다.

 

요즘 내가 자주 사용하는 표현인 Learning by Shipping도 거기서 나왔다.

나에게는 결국

공부 → 개발

 

보다는

개발 → 문제 발생 → 공부 → 해결 → 다시 개발

 

이라는 순서가 더 잘 맞았다.

 

문제를 직접 겪고, 실수하고, 원인을 찾고, 수정하고, 결국 무언가를 배포까지 해봤다면 그때 배운 것은 쉽게 잊어버리지 않는다.

→ 에러는 없어졌는데, 나는 아직 이해하지 못했다 | RE:개발자 #14

 

---

머릿속의 제품과 실제 제품 사이

Security Lens를 만들면서도 비슷한 경험을 했다.

처음 머릿속에 있던 제품은 꽤 단순했다.

사진을 올린다.

OCR이 정확하게 텍스트를 추출한다.

개인정보와 위험 요소를 찾아낸다.

사용자는 결과를 확인한다.

끝.

하지만 실제로 만들자 전혀 그렇게 단순하지 않았다.

실제 이미지에서는 OCR 정확도가 내가 기대했던 만큼 항상 안정적이지 않았다.

테스트를 하면 할수록 부족한 부분이 계속 보였다.

그래서 핵심 기능이 처음 작동했을 때도

거의 다 만들었다.

 

라는 생각보다

이제 시작인데 고칠 게 너무 많은데?
그런데 마감은 얼마 안 남았는데?

 

라는 생각이 먼저 들었다.

내가 머릿속에서 상상했던 제품과 실제로 내가 배포할 수 있는 제품 사이에는 생각보다 큰 거리가 있었다.

 

그때 기능을 만드는 것과 실제로 출시하는 것은 다른 능력이라는 걸 조금씩 알게 됐다.

→ 기능이 된다고 제품이 되는 건 아니었다 | RE:개발자 #9

---

README를 쓰다가 기능을 지우고 싶어졌다

README를 작성할 때도 재미있는 일이 있었다.

처음에는 단순히 프로젝트 설명서를 만든다고 생각했다.

 

그런데 생각보다 글이 길어졌다.

 

기능을 하나씩 설명하면서 개발할 때 내가 얼마나 이 문제 저 문제로 이동했는지도 보이기 시작했다.

일단 작동시키고, 나중에 구조를 정리하는 방식으로 개발한 흔적도 많이 보였다.

그리고 어떤 기능을 설명하다가 갑자기 이런 생각도 들었다.

이 기능, 사실 없어도 되는 거 아닌가?

 

코딩할 때는 만드는 것에 집중하느라 보이지 않았던 것이, 글로 설명하려고 하자 보이기 시작했다.

 

그 순간 README가 단순한 문서가 아니라 제품을 다시 검토하는 도구가 됐다.

내가 만든 것을 남에게 설명할 수 없다면, 어쩌면 나도 그것을 충분히 정리하지 못한 것일 수 있다.

---

AI에게 바로 "만들어줘"라고 하지 않으려는 이유

요즘은 개발하면서 AI를 정말 많이 사용한다.

다만 가능하면 처음부터

이거 만들어줘.

 

라고 말하지 않으려고 한다.

내가 모르는 것이 있다면 먼저 무엇이 궁금한지 설명한다.

왜 궁금한지 말하고, 내가 이해하고 있는 연결 관계가 맞는지도 확인한다.

그리고 설명을 들은 다음에 구현을 도와달라고 하거나, 내가 작성한 코드를 검토해달라고 한다.

AI는 점점 더 많은 지식을 제공할 것이고, 실제로 할 수 있는 행동의 범위도 계속 넓어질 것이다.

 

그래서 오히려 나는 질문하고 판단하는 부분을 놓치지 않는 것이 중요하다고 생각한다.

AI가 내 생각을 대신하는 도구가 아니라, 내 생각을 더 멀리 가져가는 도구였으면 한다.

→ AI가 코드를 대신 써줄수록, 나는 더 알아야 했다.

---

질문에 답하다 보니 알게 된 것

아직 Coder Legion의 공식 Developer Story는 공개되지 않았다.

내가 보낸 답변을 바탕으로 에디터가 글을 만들고, 공개 전에 다시 검토하는 과정이 남아 있다.

완성된 인터뷰가 나오면 그때 다시 소개해보려고 한다.

 

그런데 이번 인터뷰에서 가장 기억에 남은 것은 결과물보다 질문에 답하는 과정이었다.

나는 개발을 생계 때문에 시작했다.

 

하지만 지금은 단순히 코드를 작성하는 사람으로만 남고 싶지는 않다.

문제를 이해하고,

무엇을 만들지 결정하고,

필요한 기술을 선택하고,

실제로 만들고,

배포하고,

다른 사람이 사용할 수 있는 형태까지 가져가는 개발자가 되고 싶다.

돌아보니 그런 방향은 어느 날 갑자기 정한 것이 아니었다.

지금까지 내가 겪었던 실패와 에러, 만들었던 프로젝트, 그리고 글을 쓰는 과정 속에서 조금씩 만들어지고 있었다.

어쩌면 내가 어떤 개발자가 되고 싶은지는 이미 내가 해왔던 일들 안에 들어 있었는지도 모르겠다.