22년 3월에 컴퓨터학부에 입학해서 C, Java, Python을 통해 처음으로 코딩을 하기 시작했고, 23년 7월부터 JavaScript와 React를 사용해서 지금까지 프론트엔드 개발을 하는 중이다.
https://hochi-dev.tistory.com/5
나는 왜 프론트엔드 개발자가 되어야 하는가
2024년 7월 기준, 필자는 프론트엔드 개발자가 되고 싶어 한다. 하지만 목적을 가지고 앞만 보고 달려갔을 뿐, 그 이유는 중요하게 생각하지 않았다. 뒤에서 나오는 이야기이지만, 나의 꿈이 프론
hochi-dev.tistory.com
대략 9개월 전에 컴퓨터학부에 입학하고, 프론트엔드를 하게된 사연에 대해서 글을 적은적이 있다. 그때는 나의 인생???에 대한 글을 적었다면 이번에는 지금까지 웹 개발을 하면서 직접 느낀 잘하는 개발자란 무엇일까, 그리고 나는 어떤 개발자가 되어야 하는지에 대해서 글을 적어볼려고 한다. (정확히는 잘하는 프론트엔드 개발자)
문제 해결을 잘하는 개발자??
개발자가 어떤 직업이라고 물으면 보통 "현실에 있는 문제를 프로그래밍으로 해결하는 직업"이라고 설명을 할 수 있다. 그러면 문제 해결 능력이 좋은 개발자는 잘하는 개발자일까?
내 생각에는 잘하는 개발자랑 문제 해결을 잘하는 사람은 아닌 것 같다.
개발자가 문제 해결을 하는 사람인데 문제 해결을 잘하는 사람이 잘하는 개발자가 아니다? 이게 뭔 소리인가 싶겠지만 잘하는 개발자가 문제 해결을 잘하는 것이 아니라, 문제 해결 능력은 모든 개발자의 필수 역량이라 생각한다.
개발자는 문제 해결을 잘하는것이 당연한 것이고, 단순히 문제 해결을 잘한다고 해서 그것이 잘하는 개발자는 아닌 것 같다.
물론 엄청나게 복잡한 문제를 해결하거나 매우 빠른 시간에 주어진 문제를 해결하는 것이 다른 사람보다 돋보일 수 있지만, 단순히 문제 해결 능력은 개발자라면 기본으로 갖춰야 할 소양일 뿐, 그것만으로 잘하는 개발자라 부르기에는 부족하지 않을까 싶다.
잘하는 개발자는 어떤 개발자일까
개발자라는 직업이 문제 해결을 하는 사람인데, 문제 해결을 잘한다고 잘하는 개발자가 아니라고 했다. 그러면 본인이 생각하는 잘하는 개발자란 어떤 개발자를 얘기하는 걸까?
아무나 읽을 수 있는 코드를 작성하는 사람
보통 프로젝트를 진행하면 혼자서 개발을 하지 않고 다른 사람들과 같이 작업을 하게 된다. 설령 혼자서 개발을 한다고 해도 미래의 나는 다른 사람이다. (정말 6개월 전에 내가 작성한 코드도 이해하기 쉽지 않다)
어쨌든, 개발을 하면서 내가 작성한 코드는 나만 보는 것이 아니라 다른 사람(미래의 나 포함) 이 같이 보는 것이다.
처음 개발을 시작할 때는 보통 내가 작성한 코드만 확인해서 잘 느끼지 못했지만 프로젝트의 규모가 커짐에 따라 다른 팀원이 작성한 코드를 내가 가져가서 사용하는 경우가 발생하고, 실제 운영을 하면서 팀원이 작성한 코드에서 버그가 발생한 경우 내가 대신 해결하여야 하는 경우도 많아지면서 읽기 쉬운 코드의 중요성을 느꼈다.
var a, b, c, d;
//
if ((a === b) && (c !== d)) {
//
}
위와 같은 조건문을 작성하는 코드가 있다고 생각해 보자. 물론 위의 코드에서는 변수명이 짧기 때문에 저렇게 작성해도 읽는 것이 어렵지 않다. 오히려 저렇게 변수명이 짧은 경우에는 저렇게 조건문을 작성하는 것이 더 읽기 편한 코드일 것이다.
하지만 가독성이 높은 코드를 작성한다 하면 저렇게 변수명을 짓지 않고 실제로는 엄청나게 긴 변수명이 나오게 될 것이다. 그러면 여러 비교 연산자를 사용하는 조건문이 예시보다 훨씬 길어질 것이고, 이는 실제로 조건을 이해하기 약간의 시간을 써야 할 것이다.
var a, b, c, d;
//
var isSameAandB = a === b;
var isNotSameCandD = c !== d;
if (isSameAandB && isNotSameCandD) {
//
}
조건문이 복잡한 경우 저렇게 boolean을 저장하는 변수를 따로 선언해서 미리 평가하고, 평가된 변수를 조건문에 넣으면 이전보다 코드를 더 빠른 시간에 이해할 수 있을 것이다.
var a, b, c, d;
//
var isSameAandB = a === b;
var isNotSameCandD = c !== d;
if ([isSameAandB, isNotSameCandD].every(true)) {
//
}
더 발전하면 조건문에서 && 연산자를 사용하는 것이 아니라 boolean 값을 배열에 저장하고, every 내장 함수를 통해서 배열 내에 있는 모든 값이 true인지 확인하는 방법으로도 표현할 수 있다.
&& 연산자를 사용한 조건문과 배열을 사용한 조건문을 비교해 보면 오히려 && 연산자를 사용한 조건문이 더 읽기 쉬워 보이기도 한다. 하지만 조건문의 피연산자가 저렇게 2개만 되지 않고 더 복잡해지면 어떻게 될까?
이렇게 모든 상황에서 조금이라도 더 읽기 쉬운 코드를 작성하는 사람이 잘하는 개발자가 아닐까라고 생각한다.
아무나 작성한 코드를 읽을 수 있는 사람
위에서는 아무나 읽을 수 있는 코드를 작성하는 사람이 잘하는 개발자라고 했다. 근데 아무나 작성한 코드를 읽을 수 있는 사람은 어떤 의미일까?
내가 아무나 읽을 수 있는 코드를 작성하더라도, 다른 사람은 아무나 읽지 못하는 코드를 작성할 수도 있다.
물론 가장 이상적인 것은 팀원들이 나보다 더 잘하는 개발자여서 내가 일기 쉬운 코드를 작성해 주는 것이다. 하지만 팀원이 나보다 실력이 부족해서 가독성이 높은 코드를 작성하지 못할 수도 있다. 또는 마감이 가까워 우선 빠르게 코드를 작성해야 하는 경우 가독성이 높은 코드를 기대할 수는 없을 것이다.
function foo() {
console.log('foo');
}
var bar = function f() {
console.log('bar');
}
foo();
bar();
위 코드의 동작 결과는 무엇일까? 정답은 'foo'가 출력된 이후 reference error가 발생한다. 그 이유는 함수 선언식과 함수 표현식에 차이가 있는데, 어쨌든 자바스크립트라는 언어가 이런 특이성들을 가지고 있기 때문에.... 다양한 코드들이 나올 수 있고 결과를 예측하기 어려운 경우도 많다.
위의 코드는 예시를 들기 위해 복잡하게 작성했지, 실제로는 저런 특이한 코드를 작성하는 사람이 있을까?
라이브러리 내부 코드들을 보면 저런 복잡한 코드들이 실제로 있다.
위에서 아무나 작성한 코드를 읽을 수 있어야 한다는 이유가 팀원이 가독성이 높지 않은 코드를 작성하지 못하는 경우라 했는데, 한 가지 더 이유를 얘기하면 라이브러리 내부 코들들 확인해야 하는 경우도 발생하기 때문이다.
프론트엔드 개발을 하면서 외부 라이브러리를 사용하는 경우가 상당히 많이 있고, 거의 라이브러리로 시작해서 라이브러리로 끝난다 하더라도 과언이 아니다. 라이브러리를 사용하기 위해서는 공식문서를 주로 참고하는데 간혹 공식문서를 봐도 원하는 사용법이 없는 경우도 있다. 이런 경우에는 라이브러리의 내부 코드를 직접 확인해서 참고해야 하는 경우도 발생한다.
라이브러리의 경우 복잡한 로직과 최적화를 구현하기 때문에 가독성이 높은 코드보다는 성능을 우선으로 작성하는 경우가 많다. 공식 문서를 확인해도 찾을 수 없는 기능에 대해서는 내부 코드를 직접 확인해야 할 수도 있기 때문에 어떤 코드도 읽을 수 있는 능력이 필요하다.
결론 : 아무나 읽을 수 있는 코드를 작성하고, 아무나 작성한 코드를 읽을 수 있는 사람
잘하는 개발자의 능력을 두 가지 이유를 들었는데, 그것을 조합하면 잘하는 개발자란 "아무나 읽을 수 있는 코드를 작성하고, 아무나 작성한 코드를 읽을 수 있는 사람"라고 할 수 있겠다.
물론 잘하는 개발자는 두 가지 이유 말고도 아주 다양한 것들이 있다. 협업에 능한 점이 있어야 하고, 사용자 경험을 높이는 것도 있을 것이고.
사람 마다도 많은 잘하는 개발자의 시야는 다양하게 존재하지만, 지금까지 개발을 하면서 본인이 느끼고 있는 잘하는 개발자란 저런 개발자가 아닐까 싶다.
가독성이 높은 코드를 작성하고, 복잡한 코드를 이해하기 위해서는 다른 거보다 언어 자체에 대한 기본기가 중요하다고 생각한다. 프론트엔드로서 다양한 기술들을 사용할 줄 알면 좋은 페이지를 만들 수 있겠지만, 단순히 보여주기 위한 페이지가 아닌 제대로 동작하기 위한 페이지를 만들기 위해서는 기본기를 잘 아는 것이 필요하겠다.