2022년 5월 26일 힐링페이퍼의 한 개발자 분과 연이 있어 회사 바로 옆 까페 크리에이터 클럽이라는 곳에서 만남을 가지게 되었다.
다수의 질문들을 미리 뽑아갔지만 준비한 질문들에 대한 답은 많이 얻지 못하였다. 하지만 그보다 더 값진 내용들을 듣고 보았기 때문에 회고를 통해 정리하려 한다.
가장 먼저 생각나는 주제는 바로 CS 나 네트워크 자료구조 같은 내용의 중요성에 대해서 대화를 하였다.
현재의 나는 이런부분이 중요하다 라고는 생각하지만 정작 왜 중요한지에 대해 깨닫지 못한 상태라 굉장히 궁금한 내용이였다.
그분께서 하나의 예시를 들어주셨는데 궁금증이 말끔히 해결되어서 이를 공유하려고 한다.
이러한 문제가 있다. 입력값으로 문자열을 입력받고 , 이 문자열을 integer 로 변환 하는 프로그램을 작성한다고 생각 해보자.
다만 제약조건이 있다. 언어 에서 제공하는 함수를 쓰면 안된다. 예를 들어 자바에서는 Integer.parseInt() 메서드를 제공해주는데 이를 통해 문자열을 int 형태로 바꿔줄수 있다. 이러한 메서드를 사용할 수 없다는게 제약조건이다.
그래서 나는 대답했다. 저는 charAt() 메서드를 통해 한글자 한글자씩 읽어서 처리 할 거같습니다. 개발자님이 물어봤다. "그래 그건 알겠어. 그럼 어떻게 구현할래?" 나는 이렇게 대답했다. 당장에 생각나는 건 parseInt 를 사용하지 못하니까 .equals() 를 통해 0~9 까지 case 문을 통해 숫자를 integer 형태로 변환 하는건데 좋지 않은 코드인거같습니다.
문제점이 보이는가?
이런 나에게 2가지 조언을 해주셨다. 자신은 charAt() 이 먼저 떠오르지 않았다 라고 말했다. 자신은 이 문제를 보았을때 이 프로그램에서 어떤 예외가 있을지 먼저 생각했다고 했다. 즉 문자열이라하면 숫자 뿐만이 아니라 공백 또는 글자 들이 많기 때문이다.
결론은 프로그램이든 요구사항이든 어떠한 task 가 나에게 왔을때 그것을 코드적으로 구현하기 전에 , 사람의 관점에서 그 요구사항을 충분히 이해하고 예외사항들을 생각하면서 어떤 방식으로 해결할지를 생각하는게 먼저이고 코딩하는것보다 더 많이 시간을 투자해야할 사항이라는 것을 깨달았다.
현 우아한형제들의 CEO이신 김범준 님의 말이 생각이 났다. 개발자를 코딩하는 사람으로 생각하지 않았으면 좋겠다. 엘리베이터를 기다리는게 너무 지루하다. 라는 요구사항 피드백이 들어왔을때 개발자들은 이 엘리베이터를 얼마나 빨리 운행시킬수 있는지 성능적으로 개선을 해야겠다. 라고 생각을 할 수 있다. 바로 지금의 나처럼.
하지만 코드를 수정하기 전에 먼저 주어진 문제를 어떻게 해결할지 근본적으로 생각하는 게 중요하다. 엘리베이터 기다리는 시간이 지루하니 , 엘리베이터에 거울을 만들어 그 지루함을 달래는 방식으로 해결 한다 라든가 등등의 문제를 코딩으로만 해결하는 시야가 좁은 사람이 되지 않아야겠다 라고 생각했는데 실제로 경험하니 한층 더 느껴졌다.
여러 사람마다 자신이 생각하는 개발자의 개념이 다르겠지만 , 개발자는 결국 문제를 해결 하는 사람이라고 생각한다. 그 방법중 한개가 코딩이고 그 코딩에 국한되어 있는 사람이 아니라 폭넓게 볼수 있는 시야를 가진 개발자가 되어야 겠다고 한번 더 느꼈다.
글이 길어졌는데 첫번째로 이런 문제 접근 방법에 대해서 말씀을 해주셨고 , 두번째는 자료구조 CS 등의 중요성이다.
내가 생각한 방법은 case 문을 통해 일일이 조건문을 만들었지만 이는 코딩테스트에는 합격할수 있지만 회사에는 불합격할 것이라고 하셨다.
이문제의 포인트는 char 와 String을 근본적으로 이해하고 있느냐를 물어보는 문제이다.
자바에서의 char 는 문자를 저장하는거 같지만 실제로는 정수값(유니코드) 값을 저장하기 때문에 int 형 값의 유니코드값 범위를 조건으로 확인해준다면 case 문을 10개 작성하는것보다는 훨씬 효율적인 코드를 작성 할 수 있을것이다.
이러한 부분에서 자료구조 CS 네트워크 같은 기본지식을 알아야 하고 이는 연차가 쌓이면 쌓일수록 차이가 더 나게 된다고 하셨다. 더하여, 연차가 쌓일수록 사실 개발하는 시간보다는 팀에 대해 피드백을 해주고 리뷰 해주고 코딩 라인은 적어지되 좀더 중요한 여러 군데에 영향을 미치는 코드를 작성하게 된다고 하셨다.
또 하나의 주제는 reputation 을 쌓아라 이다. git 이나 stackoverflow 에서 전세계적으로 기여를 하면서 repuatation 을 쌓는게 중요하다고 하셨다. git 에는 라이브러리들이 많다. 그러한 라이브러리 들을 내가 오픈소스로 개발하는 것도 좋고 , 이미 만들어져 있는 소스들을 pull request 를 통해서 기여하는 것이 자신의 reputation 을 만드는데 효과적이라고 하셨다.
더하여 모르는 사람들이 쓴 블로그를 참고하는 것보다는 doc 문서 또는 실제 시초가 되는 문서를 찾아서 어렵더라도 그 글을 읽는것이 좋다고 하셨다. 사실 한국어로 되어있지 않은게 있을수도 있고 어려운 내용을 잘 정리한 글들이 있을수는 있지만 , 알맹이만 까먹는 것과 내가 직접 까서 먹는거는 또 다르다고 하셨다.
공부를 해야하는 접근 방식에 대해서 배웠다. 어떤 것을 공부하든 얘의 원론적인 내용을 파고 들어야한다. 단순히 겉모습 , 사용법이 아니라 이러한 기술이 나오게 된 배경은 무엇이 있는지 이 기술을 내가 왜 써야하는지 이 기술이 왜 이제서야 쓰게 되었는지 등을 알면 나중에 내 의견을 말할때나 회의를 할 때 좀 더 논리적으로 설명 할 수 있게 된다. 단순히 사용법을 아는 개발자와 깊게 알고 있는 개발자는 조금만 대화를 나누어도 쉽게 구분이 간다고 한다. 마틴 파울러 같은 분을 트위터에 팔로우하고 쓰는 글들을 읽고 그러한 문구들을 인용한다면 나의 의견에 조금 더 힘을 실어줄수 있다고 한다.
사실 오픈소스에 기여 한다는 거 자체에는 신경을 쓰지 않고 살았다. 당장에 공부할 내용들이 굉장히 많고 이런것들을 정리하는 것 조차 버겁기 때문에 어떤 라이브러리에 대해서 내가 기여를 한다? 라는 거 자체에 생각이 없었지만 이부분에 대해서 도전을 하고 오픈소스 기여에 대한 회고를 또 한번 작성하려고 한다.
지인분을 따라서 힐링페이퍼 회사 라운지를 살짝 구경했다. 굉장히 좋았고 그곳에 있는 개발자들이 연예인 같이 느껴졌다. 사실 힐링페이퍼의 "원희"님, "규원"님 팬이라 지나가다 한번 볼수 있나 라는 기대를 했지만 아쉽게도 못봤다.아무튼 다시 한번 동기부여를 느끼는 계기가 되었고 소중한 시간을 내주신 개발자님께 다시한번 이글을 통해 감사함을 표한다.
기억에 가장 남았던 내용들을 정리해보았다.
이 글을 읽고 긍정적인 영향을 받았으면 좋겠다.
