컴퓨터 공학의 특성

하나, 하나의 전공 지식을 처음 학습할 때는 힘들었지만, 결국 이런 것들이 모여야 다음 스텝을 나아갈 수 있다 👍

최근 면접 준비를 진행하면서, CS 공부를 다시 하고 있다. CS 를 복습하면서 드는 생각은 컴퓨터 공학은 몇 가지 다른 분야의 지식이 쌓였을 때 새로운 스테이지가 열리는 것 같은 기분이 들었다. DB, OS, Network 등 모두 별개의 학문이라고 처음에는 생각했지만, 각 분야에 대한 지식이 어느정도 쌓이고 나면 각 학문의 공통점이 보이기 시작하면서 각 분야가 서로 유기적으로 묶여있다는 느낌을 받을 수 있다. 또한 OS 에서 제시하는 문제에 대한 해결책을 DB 에서도 동일하게 사용하는 것을 발견하며, 각 학문에 대한 인사이트를 더 깊게 가져갈 수 있었다.

처음 CS 를 공부하면 스프링과 같은 조금 더 실용적인, 실무적인 학습보다 재미가 많이 없다. IT 특성 상 기술이 빨리 바뀌고 변화하는데 굳이 옛날 기술에 많은 시간을 할애해서 배워야 하는지, 의문을 많이 품었던 것 같다. 결국 새로운 기술도 기존의 기술의 좋은 점은 계승하고, 나쁜 점은 해결하며 만들어진 기술의 연장선이다. CS 를 깊게 배운다면, 새로운 기술을 더 빨리 배울 수 있을 것이고 더 깊게 배울 수 있을 것이다.

📌 개발은 게임의 전직 시스템과 비슷하다. 내가 좋아하는 하나의 스킬만 찍는다고 해서, 다음 클래스로 전직할 수 없다. 다음 클래스로 넘어가기 위해서는 다른 스킬들이 요구하는 최소 조건도 만족해야 한다.

주니어 그 이상

시장에서 요구하는 주니어 이상의 능력은 무엇일까 🤔

나는 주니어 이상으로 나아가기 위해 필요한 능력 중 하나는 나무가 아닌 숲을 보는 능력이라고 생각한다. 백엔드 분야의 기술의 깊이를 계속해서 파는 것도 하나의 경쟁력이 될 수 있고, 이것만으로 주니어 이상으로 나아갈 수 있다고도 생각한다. 하지만 시장의 요구는 조금 다르다고 생각한다. 정확하게 말하면 이것은 과다하다 라고 말할 수 있을 것 같다. 우리 시장에서 하나의 기술에 대한 엄청 깊은 기술적 이해를 가진 사람을 소화할 수 있는 기업이 몇이나 될까. 대부분은 어느정도의 기술적 깊이면 충분히 주니어 이상의 능력을 할 수 있는 환경이라고 생각한다.

나무가 아닌 숲을 본다는 것은 시스템을 전반적으로 보는 것을 의미한다. 여러가지 기술이 융합되었을 때 발생할 수 있는 영향들과 현재의 문제를 기술 하나하나의 디테일로 해결하기 보다, 시스템 전반적인 구조와 기술의 조합으로 문제를 해결할 수 있는 능력이 주니어 이상의 레벨에서 요구하는 능력이라고 생각한다. 결국 이렇게 되기 위해서는 새로운 분야에 대한 학습을 주저하지 않아야 된다. 설령 자신이 백엔드 개발자라도 리액트를 공부하는 것을 시간아깝다고 생각할 필요가 없다는 것이다. 이번에 Togg 라는 프로젝트를 진행하면서, 처음으로 리액트로 프론트를 구현했다. 이 과정에서 처음에는 그냥 이 시간에 백엔드를 더 고도화하는게 더 좋지 않을까 라고 많이 생각했지만, 프론트를 구현한 경험이 백엔드 경험과 융합되어 새로운 시야와 관점을 가져다주는 것을 알 수 있었다.

📌 커리어를 시작하고 나서도, 내가 하고 싶은 일만 할 수 없을 것이다. 결국 개발자는 프로그래밍으로 문제를 해결하는 사람이다. 프로그래밍의 범위는 백엔드, 프론트엔드, 데브옵스 등으로 한정되지 않는다.

📝 피드백

Togg

학자형 보다는 야생형 ❗️

이번주는 대부분 Togg 라는 프로젝트를 구현하고 학습하는 것에 많은 시간을 보냈다. 이 경험으로 알 수 있었던 것은 개발 공부는 학자형이 아닌 야생형으로 하는 것이 더 효율적이라는 점이다. 영한님 강의를 통해 이런 말을 처음 알 수 있었다. 이후 영한님의 말씀대로 커리를 진행했지만, 이것은 결국 야생형이 아니고 야생형을 위한 학자형 공부 방식이었던 것 같다. 정말 새로운 어떤 주제를 누구의 도움도 없이 혼자의 힘으로 구현할려고 노력하고, 부족한 점을 느낀 후 그 부분을 채우기 위해 이론적 공부를 하는 것이 진짜 야생형 공부 방식인 것 같다.

결국 개발자가 이론적 지식을 학습하는 이유는 현실의 다양한 문제의 해결방법으로 적용하기 위해서이다. 결국 이 과정에서 우리가 키워야할 능력은 어떤 문제에 어떤 해결책을 적용할지 판단할 수 있는 능력이다. 이론적 지식을 평가하는 5지선다 시험은 만점을 받지만, 실무에서 마주한 문제에 대해 이론적 지식을 기반으로 적절한 해결책을 낼 수 없다면 이론적 지식을 학습할 이유가 있을까. 이런 능력을 키워줄 수 있는 효과적인 학습 방법이 야생형 공부 방식인 것 같다. 앞으로 어떤 이론 지식을 깊게 공부하기 위해서는 학습을 위한 다양한 토이 프로젝트를 진행하고, 이후 이론적 공부를 하는 방식으로 학습을 진행하려고 한다.

📌 개발자는 시간적 제약에서 비교적 자유롭게 연구를 하는 연구직이 아니다. 개발자는 제한된 시간에 최선의 해결책을 내야한다.

토스 코딩 테스트 합격

드디어 코테에 합격해봤다... 👍

처음으로 기업 코딩 테스트에 합격했다. 내가 붙은 코테는 데브코스가 전부였는데, 그 동안의 노력을 인정받는 것 같아 행복하다. 하지만 합격의 기쁨도 잠시 1차 면접에 대한 부담감이 몰려왔다. 처음에는 어떤 특별한 일을 해야할까 안절부절했지만, 하루동안 고민한 결과는 그냥 하던대로 하자 였다. 처음에는 아직 엄청 부족한 내가 어떻게 1차 면접을 준비할지 부담감이 앞섰는데, 결론적으로 어차피 모든 일은 완벽히 준비될 수 없다는 것이다. 어떤 일이든 준비를 많이 해도 막상 그 일이 다가오면 준비가 덜 된 것 같이 느껴진다. 원래 하던 것을 꾸준히 하면서, 내가 했던 프로젝트를 정리하고, CS 에 대해 복습하는 시간을 추가하면 될 것 같다. 면접이라고 생각하기 보다 멘토링 받을 수 있는, 나의 현재 위치를 객관적으로 검증받을 수 있는 시간이라고 생각하며 면접까지 남은 기간동안 최선을 다해 준비해야 겠다.

📌 현재까지의 나를 솔직하게 보여주고, 앞으로의 나를 기대하게 만들자.

Togg(Toss + Guenwoo = Great)

프로젝트의 크기에 집중하기 보다 작은 개념 하나라도 진득히 느껴보자 ❗️

토스 서술형에서 나왔던 개념들을 실전 프로젝트를 통해 공부해보면 좋을 것 같아, 주제를 잡고 개발을 시작했다. 토스 합격이 발표되기 전에 이미 프로젝트를 기획하고 개발을 시작하고 있었는데, 합격이 되서 해당 프로젝트의 무게감이 달라졌다. 😂

이번 프로젝트를 통해서 이론적 지식들을 실제로 경험해보고 느껴보는 것이 목표다. 많은 기술을 적용하여 서비스를 개발하기 보다 정말 필요한 기술들만 적용하고, 내가 학습하고자 하는 영역에만 집중하여 개발해보려고 한다.

📌 개발자에게 최고의 학습 방법은 개발이 아닐까.

📝 피드백

Spring Security

진짜 너무 어렵다... 개인적으로 Spring 시리즈 중에서 가장 Top 급의 난이도인 것 같다.. 😭

Togg 프로젝트에서 유저를 식별하기 위해 OAuth2 + JWT 를 활용하여 회원가입과 로그인을 구현했다. 해당 기술을 구현할 때, 정말 어려웠던 것 같다. 기본적으로 어떤 에러가 발생했을 때 디버깅하는 것이 너무 어렵다고 생각했다. 수많은 Spring Security 필터 속에서 어느 필터에서 문제가 발생하는지 파악해야 했다.

구체적인 예로 CSRF 설정을 비활성화 해주지 않아, Access Token 을 헤더에 잘 넣어줬음에도 불구하고 인증이 제대로 이루어지지 않고, /login 으로 리다이렉트 되는 문제가 발생했다. 해당 문제의 경우 Get 요청일 땐 잘 되고 Post 요청일 때만 문제가 발생하여 더욱더 찾기가 힘들었던 것 같다. 에러가 발생하는 것이 아닌 요청한 URL 을 컨트롤러가 잡지 못하고, 계속 /login 으로 리다이렉트되어, 어떤 필터가 이런 발칙한 일을 하는지 찾아야 했다. 호출된 trace 를 역으로 타고 들어가서 문제를 찾으려 했지만 너무 많은 필터의 흐름 속에 결국 내 머리가 버티지 못했다.

힘겨운 디버깅 속에 문제를 해결했지만, 이 과정에서 Spring Security 에 대한 근본적인 학습을 제대로 해야겠다고 생각했다. 단순히 생각했을 때, 스프링에서 /login 을 리다이렉트 시킨다는 것은 인증이 제대로 이루어지지 않았다는 것이고, 인증이 제대로 이루어지지 않은 것이라면 Jwt 인증 필터가 제대로 작동하지 않거나, 앞선 필터에서 403 권한 에러를 발생시켰을 것이다. 결국 Spring Security 의 기본이 탄탄했다면, 금방 문제를 해결했을 것 같다.

📌 이렇게 개발을 통해 어떤 부분이 부족한지 뼈저리게 느꼈다면, 이제 이론 공부를 시작해야 할 때다. 이것이 야생형 학습 스타일이 아닐까.

토스 코딩 테스트

알고리즘 뿐만 아니라 CS 도 시작해야 겠다... 🥲

이번 주는 정말 바빳다. 기본적인 데브코스 커리큘럼 외에도, UMC 프로젝트와 정처기 필기 시험 준비, 토스 코딩 테스트를 병행해야 했다. 토스 코딩 테스트는 기존 코테와 다르게 서술형 5문제가 추가되었다. 처음 보는 유형에 당황했지만, 그래도 최선을 다해 풀었고 나름 만족스러운 시험이 되었다. 물론 아쉬운 것이 전혀 없는 것은 아니다. 서술형에 약 1시간 정도의 시간을 쓰다보니 알고리즘 풀 시간을 적절하게 남기지 못한 것 같다.

하지만 항상 코딩 테스트에서 반도 못풀었던 것을 생각하면, 많이 성장했다고 생각한다. 7문제 중 3문제를 풀었고, 1문제는 진짜 5분만 더 있었어도 풀었을 것 같다.😂 서술형도 4문제를 적었기 때문에 내 실력 대비 나름 선방했다고 생각한다. 물론 나의 서술형 답안은...

이 시험을 보면서, CS 를 빨리 시작해야겠다고 생각했다. 서술형을 풀면서 나의 CS 지식이 많이 휘발되었음을 느꼈다. 하반기 기술 면접 대비로 8월 부터 시작하려 했지만, 지금 부터 조금씩 해나가야 겠다고 다짐했다 ❗️

📌 코딩 테스트 통과도 얼마 남지 않았다.

정보 처리 기사 필기

누가 이틀만 보면 된다고 하였는가... 양이 진짜 엄청 많다... 😭

CS 기술 면접을 대비할겸 같이 준비하기 위해 3차 필기 시험을 신청했다. 물론 필기는 그냥 치고, 실기 시험을 대비하면서 본격적으로 공부하려 했다. 주위에 동기들이 대부분 2일 ~ 3일 이면 충분하다고 하여 금요일 저녁에 조금 보고, 토스 코테가 끝난 후 토요일 저녁부터 다시 보기 시작했다. 그런데 생각보다 진도는 안나가고, 양은 어마무시 했다. 시험장 가는 지하철 안에서도 책과 펜을 들고, 문제를 풀었다. 다행이 문제 은행식이라 생각보다 통과하는 것은 어렵지 않았지만, 결과적으로 내 머리에 남은 것은 많이 없다. 😀 평균 81점으로 통과했지만, 너무 급하게 하여 휘발 예정이다..

정처기 필기를 공부하면서 느낀 것은 생각보다 내용이 괜찮다는 것과 피상적이었던 CS 지식이 어느정도 유기적으로 맞춰진다는 느낌이었다. 정처기가 더 이상 개발자에게 과거와 같은 스펙의 크기도 아니고, 변화가 빠른 IT 학문 특성상, 이런 자격증 시험은 고리타분한 것이라고 생각했다. 하지만 내용을 살펴보니 생각보다 괜찮은 내용들이 많았고, 개발을 하면서 생겼던 기술적 모호함들이 어느정도 해결되었다.

📌 정보 처리 기사 실기와 CS 기술 면접을 함께 준비하자.

📝 피드백

꾸준함의 가치

절대 안될 것 같았던 코딩 테스트도 조금씩 실력이 늘어나는 것이 느껴진다 🔥

프로그래머스 LV2 도 이제 거의 다 풀었다. 앞으로 약 두 달 동안, LV2 복습과 LV3, 4 풀이를 모두 진행할 생각이다. 꾸준하게 하다보면, 두 달 뒤에는 안정적으로 코딩 테스트를 통과하는 실력이 만들어 지지 않을까 생각한다. 👍

📌 하반기 코딩 테스트를 뿌셔보자.

getter 를 지양하자

객체지향 생활 체조 원칙 7 : getter / setter / 프로퍼티를 쓰지 않는다. 📝

어제 다른 데브코스 동기분에게 질문을 받았다. 바로 toDto 의 책임이 Domain 에 있는 것이 적절한지 Dto 에 있는 것이 적절한지 였다. 코드는 아래와 같다.

@Override
public VoucherDto convertVoucherDto() {
    String voucherId = String.valueOf(this.voucherId);
    String discountAmount = String.valueOf(this.fixedAmount);
    return new VoucherDto(voucherId, discountAmount, "fix");
}

FixedAmountVoucher 라는 도메인 클래스에 해당 메서드가 존재한다. 즉, Domain 이 DTO 로 변환하는 책임을 가지고 있는 것이다. 이와 같이 설계한 이유가 getter 사용을 최소화 하기 위함이라고 하셨다. 해당 책임이 DTO 에 있다면, Domain 에 getter 클래스를 사용해야 하기 때문에 객체지향 생활 체조 원칙을 위반하는 것이라고 생각하셨다. 질문을 정리하면 다음과 같다.

• 문제 상황 : toDto 의 책임은 누가 가져야 하는가
• 질문자 분의 생각 : Domain 에 getter 를 만들지 않기 위해서 DTO 에 두는 것이 맞다.
• 근거 : 클린 코드, 객체지향 생활 체조 원칙

📌 객체의 책임은 적절한가, 정말 getter 는 절대로 사용하면 안되는 것인가.

🧑‍🏫 나의 답변

SRP(단일 책임의 원칙)

Domain 의 코드는 언제 변할까 🧐

위와 같이 toDto 의 책임이 Domain 에 존재하게 되면, Domain 은 언제 변경될까. 먼저 Domain 자체의 요구사항이 변경될 때 코드가 변경될 것이다. 또한 DTO 의 필드가 변경될 때도 Domain 코드가 변경된다. 즉, Domain 은 현재 서로 다른 두 가지의 책임 을 가지고 있다고 생각된다.

1. Domain 의 요구사항에 대한 책임
2. DTO 로 변환해야 하는 책임

이는 객체지향의 5가지 원칙 중 하나인 SRP 를 위반한다.

📌 여러가지 책임을 가지고 있다는 것은 하나의 클래스를 변경해야 하는 이유가 여러가지 존재하는 것을 의미한다.

자주 변하지 않는 것이 자주 변하는 것에 의존하지 말자

DTO 는 Domain 에 비해 많이 변경되는 클래스이다 ❗️

DTO 는 계층 간 데이터 교환을 하기 위해 사용하는 객체로서, API 스펙, 요구사항 변경 등에 따라 자주 변경되는 클래스이다. 자주 변하는 DTO 클래스를 자주 변하지 않는 Domain 클래스가 의존하게 되면, Domain 은 DTO 때문에 많은 변경 지점이 발생한다. 만약 반대로 DTO 가 Domain 을 의존한다면, DTO 는 Domain 이 변경됨에 따라 발생하는 변경 지점이 훨씬 적다.

📌 변경 지점을 최소화하는 것이 변화에 가장 유연하게 대처할 수 있는 방법이다.

getter 를 사용할 수 밖에 없는 곳이 분명히 존재한다

getter 를 무조건 사용하지 않을 수 있을까. 만약 그랬다면 Java 에서 이미 deprecated... 😅

getter 를 사용할 수 밖에 없는 로직이 분명히 존재한다. 결국 getter 는 객체의 필드값을 꺼내는 역할을 하는데, 콘솔에서 Domain 의 데이터를 출력해야 하거나, DTO 에 Domain 의 데이터를 담아야 할 때는 무조건 써야한다. 객체지향 생활 체조 원칙은 다소 과격한 이론이라고 생각... 여러 클린 코드 책에서 말하는 getter 를 지양하자는 말은 비지니스 로직에서 라는 말이 생략된 것이라고 생각한다. 비지니스 로직에서 getter 가 사용되면, 중복되는 코드가 발생하기 쉽고 객체가 행위를 하지 않는 구조체 역할을 할 가능성이 높아지기 때문이다.

📌 비지니스 로직에서 getter 를 사용하지 말자.

정리

toDto 는 Domain 이 아닌 DTO 에 존재하는 것이 더 좋다. 👍

답변을 하는 과정에서 나도 객체의 책임에 대해 한번 더 생각해보게 되었고, 생각하다보니 이 내용은 한 번 정리하여 공유하면 좋다고 생각했다. 남을 도와주는 것은 결국 돌고돌아 나를 도와주는 일이라는 문구를 본적이 있다. 이 말을 가장 잘 느낄 수 있는 것이 배움을 공유하는 것이 아닐까 생각한다 😃

📌 누군가에게 쉽게 설명하기 위해서는 내가 어렵게 공부해야 한다.

벌써 데브코스 한 달차

아직 할게 산덤이인데....😭

6월 1일에 OT를 시작하여 벌써 6월의 마지막인 30일이 되었다. 정말 시간이 가장 소중한 자원이라는 것을 다시 한 번 깨닳게 된다. 그 동안 PRE 팀을 거쳐 NEW 팀까지 다양한 사람들을 만났다. 다양한 사람들과 함께 소통하고 대화하는 것이 특히 좋았는데, 같은 관심사를 가진 사람들과 함께 모여있으니 자연스럽게 대화도 잘 되는 것 같았다. 좋은 회사를 가야하는 이유...

또한 현재 Java, DB, Spring Basic(~ AOP)까지 학습을 진행했다. 뭐 많이 한게 없다고 생각했는데, 돌이켜보니 뭘 많이 했다고 느껴진다. 역시 부트캠프 클라스... 이전에 학습을 계속 진행했던 부분이라 아직까지는 복습과 더 깊게 학습하는 것을 목표로 하고 있지만, 나중에 AWS 와 같이 거의 해보지 않은 영역을 학습하게 되면 상당히 힘든 시간이 될 것이라고 생각한다. 이때는 정말 계획과 우선순위가 중요 할 것 같다. 한 달 동안 진행해보니, 단기간에 정말 많은 학습량이 존재한다. 한정된 시간 속에서 내가 확실하게 학습해야 할 부분에 집중해야지, 쏟아지는 학습의 파도 속에서 생존할 수 있다.

이번주 오프라인 강의장을 방문하여, 처음 받아본 명찰이다. 아주 간지가 춸춸난다. 👍 이 날 하루종일 비가 왔고, 왕복 2시간 30분이 걸렸지만, 이 사진 한 장으로 모든 피로가 풀리는 것 같았다. 왜 사람들이 취업하면, 명찰 사진을 그렇게나 올리는지 바로 이해 완료

📌 시간에 끌려다니지 않고, 내가 시간을 끌고다니기 위해서는 계획과 우선순위가 중요하다.

📝 피드백

미뤄지는 알고리즘

어차피 코딩 테스트 못뚫으면, 아무 의미 없다 !! 😤

AOP, 트랜잭션 전파, Logging 등 처음 학습하는 개념들이 나오기 시작하니 전 보다 강의를 학습하는 시간이 길어졌다. 처음 학습하는 것이기도 하고 개념의 난이도가 조금 높다보니, 자연스럽게 내가 싫어하는 알고리즘을 미루게 되었다. 그렇게나 다짐했는데, 이 멍청한 새ㄲ..

회고록을 통해 지난 일주일을 반성하면서, 다시 정신차리고 알고리즘을 꾸준히 학습해야겠다.

📌 아무리 하기 싫은 것이라도, 습관이 되면 별생각 없이 할 수 있게 된다.

20대의 하루와 80대의 하루는 같지 않다

데브코스의 6개월은 취업 준비 기간 중 가장 값진 시간이다. 🔥

흔히 누군가의 노력을 평가할 때, 시간의 양이 많이 사용된다. 예를 들어, 하루에 18시간 공부한 것은 열심히 한 것이고, 하루에 6시간 한 것은 열심히 하지 않았다고 말한다. 이와 비슷한 논리로, "앞으로 시간이 많다", "나는 아직 젊다" 등의 말은 모두 시간의 양적인 측면만 바라본다.

하지만 우리는 시간의 질도 함께 고려해야 한다. 20대의 하루와 80대의 하루는 같지 않다. 시간의 양적인 측면에서만 바라본다면 두 시간은 같지만, 20대의 시간이 훨씬 더 잠재 가능성있는 시간이라는 것은 모두가 동의할 것이다. 이런 측면에서 현재 데브코스의 6개월은 너무나도 값진 시간이다. 현재 3주차까지 진행하면서 업계의 실력있는 개발자 분들의 말과 특강을 듣고, 열정있는 사람들과 하나의 목표와 하나의 공간에서 몰입하며 성장하는 경험을 했기 때문이다. 😃

📌 현재는 다른 무엇보다 데브코스에 몰입해야하는 시기이다.

📝 피드백

정답은 이미 알고있다

내가 해야될 일과 방향은 이미 충분히 알고있다. 그냥 이대로 굳건히 나아가자. 🎋

최근 멘토님들과 이야기를 진행하면서 느낀 내용이다. 이미 어떻게 해야하는지 알고 있음에도 불구하고, 계속 내가 가고있는 방향이 맞는지 확인하려 했다. 취준의 특성상 불안정한 마음 상태라서 이해는 되지만, 결코 도움이 되지는 않는다고 생각한다. 그만 찡찡대자 😭 내가 정한 방향이 맞다면, 나를 믿고 굳건히 나아가는 연습도 중요한 것 같다.

현재 내가 판단한 우선순위에 맞게 최소한 6개월 정도 굳건히 나아가다 보면 좋을 결과가 있을 것이다. 👍

📌 고민은 길게하는 것이 아니고 깊게하는 것이다. 길게하다 보면 기회의 타이밍을 놓치게 된다. 깊게 생각했다면 나를 믿고 앞으로 나아가자.

과도한 선행 학습

학창 시절 초등학교 6학년 때, 고등학교 1학년 선행을 진행했었다. 어디가서 어깨에 힘들어가는 것은 좋았으나, 돌이켜 보면 결국 피상적인 공식 몇 개를 암기한 것이었다... 🥲

학창시절에는 각 학년별 학습 범위가 정해져 있어서 선행 학습의 유무가 확실했다. 하지만 개발자를 준비하면서 개발에 대한 연차별 학습 범위는 마땅히 정해진 것이 없다. 그 결과 취업을 위해 막연히 MSA, 헥사고날 아키텍처 등 신입에게 요구되는 능력이 아닌 부분까지 학습을 시도 하는 경우가 많은 것 같다. 나 또한 그랬다...

하지만 여러분들이 만약 편미분 공식을 통해 간단한 문제를 풀어내면서 편미분을 완전히 이해했다고 한 초등학교 3학년 학생을 본다면, 어떤 마음이 들겠는가. 아마 그 학생이 편미분을 제대로 이해하고 활용한다고 생각하기 보다 공식 하나 딸랑 외워서 수학적 허세를 부린다고 생각할 확률이 높다. 물론 세상에는 초등학생 때 편미분을 제대로 이해한 엄청난 괴물 친구들도 존재한다....

아마 이런 생각은 면접을 진행하는 시니어 개발자들도 할 것이다. 면접관의 깊은 꼬리질문을 모두 극복하면 엄청난 인상을 줄 수 있겠지만, 아마 대부분은 책 몇번 읽고 프로젝트에서 한 두번 써본 것이 전부일 것이다.

결국 이 문제는 신입이 신입답지 못하기 때문에 발생한다. 신입 개발자인 우리는 사회가 신입에게 요구하는 역량에 집중해야 한다. 그 이상의 역량을 키우는 것은 신입의 기본적 역량을 모두 키우고 난 후에 해도 늦지 않다. SOCAR 의 시니어 엔지니어인 지두현님 의 세션과 내가 현재까지 경험하며 느낀 신입 개발자의 기술적 역량 은 다음과 같다.

• 코딩 능력: 코딩 테스트, 클린코드, OOP
• CS
• 자기 분야에 대한 기본적인 전문성(백엔드, 프론트엔드 등)

어떤 역할이든 각 단계에 요구되는 사항이 있다. 이렇게 빠르게 변화하는 세상에서 모든 것을 다 잘하기는 쉽지 않다. 아니 불가능하다. 현재 나의 위치를 객관적으로 파악하고, 나의 위치에서 요구되는 역량을 우선적으로 기르자 ❗️

📌 현재 나의 역할에서 가장 필요한 것이 무엇인지 고민하고, 우선순위를 고려한 의사결정과 행동을 하자

코딩 테스트의 벽

카카오에 재직 중이신 멘토님과 코딩 테스트에 대해서 이야기를 주고 받다가, 멘토님께서 빌게이츠가 오더라도 코딩 테스트를 통과하지 못하면 빅테크에 취업하기는 힘들 것이라고 하셨다... 😂

나는 코딩 테스트를 너무 늦게 시작했다. 혹여나 이 글을 읽는 분들은 빨리 시작하기를 바란다. 2학년 부터 바로 시작하는게 좋은 것 같다... 2 ~ 3개월이면 된다고 했는데, 나는 2 ~ 3개월 동안 했음에도 불구하고 아직 안된다. 나는 빡대가린가... 물론 하루 종일 알고리즘만 하는 것이 아니라 많은 시간을 백엔드 역량을 기르는 학습에 투자했고, 프로젝트 및 CS 복습 등 다른 것에 더 집중했다. 그럴 수 밖에 없는게, 4학년인 입장에서 이력서에 제대로된 프로젝트도 없는 상황이면, 쉽사리 코딩 테스트에 많은 시간을 할애하기는 힘들다. 😱

하지만 코딩 테스트를 통과하지 못하면, 내가 아무리 뛰어난 포트폴리오를 만들어도 면접관들에게 보여주지 못한다. 이 불편한 진실을 애써 외면하려 했지만, 이제는 정확히 인지하고 받아드려야 할 것 같다.

📌 앞으로 최우선 순위는 코딩 테스트다. 백날 스프링 공부해봐야 결국 이거 못 뚫으면 취업하기 너무 힘들다.

📝 피드백

하고 싶은 것이 아닌 해야 하는 것

나는 코딩테스트가 싫어요...

지난 일주일 동안, 멘토링과 상담, 세션 등을 통해 과거의 나는 하고 싶은 것을 해야 하는 일이라고 합리화 하고 해야할 일은 애써 외면 했던 것 같다. 이제 4학년 1학기가 앞으로 일주일 뒤면 종강이다. 더 이상 나는 해야 할 일을 외면할 시간이 없다. 현재 내가 생각하는 일의 우선순위는 다음과 같다.

1. 데브코스 커리큘럼
2. 코딩 테스트
3. OOP & 클린코드
4. CS

그렇다 나는 무능했다.... 😭

📌 지금은 하고 싶은 일이 아닌 해야할 일을 할 때다.

열정 전염

부모님들이 어렸을 때 말씀해주었던 친구 잘 만나고, 대학 잘 가야한다는 말이 뭔 말인지 알 것 같다... 🤣

데브코스에서 가장 만족스러운 부분은 열정이 전염 되는 것이다. 나태해지고 싶다가도 게더에 들어가서 열심히 하고 있는 팀원들을 보면, 사그러들었던 열정이 다시 피어오르는 것 같다. 주위 환경이 중요하다는 것을 다시 한번 인지할 수 있었다...🔥

그래서 그런가 이렇게 혼자 있을 때면 뭔가 짜릿하다.

캠의 중요성

맨날 머리를 만져야 하는 것은 너무 귀찮다.

코로나 시국에 학교를 다니면서 비대면 수업을 많이 경험했었다. 대면 수업과 비대면 수업을 모두 경험해봤던 나는 수업에 대한 집중도 측면에서 대면이 압도적으로 더 좋다고 생각했다. 너무 딴짓을 많이 할 수 있다.. 그렇다보니 데브코스에서도 이렇게 비대면으로 진행하는 것에 대한 불안감이 조금 있었다.

하지만 실제로 진행해보니 비대면으로도 충분히 집중하며 효율적으로 진행할 수 있다는 것을 알게 되었다. 이전과 달라진 점은 바로 캠을 켠다 는 것이다. 캠을 켜고 있으니 언제 누가 나를 볼지도 모른다는 생각 때문에 온전히 학습에 집중할 수 있었다. 아무도 나한테 관심 없겠지만, 타인이 나에게 관심이 많다고 생각하는 것은 인간의 특성이라고 한다.

혹시나 이 글을 읽는 여러분들도 온라인으로 활동을 진행할 때, 과정과 성과가 생각보다 마음에 들지 않아 오프라인으로 전환하려고 한다면 캠을 켜는 것에 대해 한번쯤 고려해보는 것을 추천한다 😄

📝 피드백

Gradle

나는 이때까지 Gradle 을 몰랐다... 아니 알려고 하지도 않았다...

인텔리제이를 통해 스프링 프로젝트의 초기 세팅을 진행할 때, 항상 gradle 을 선택한다. 그리고 단순히 의존성이 필요할 때마다 외부 라이브러리에 대한 의존성을 추가하는 것 외에 크게 신경써본 경험이 없었다. IDE 의 편리함 때문에 어떤 기술을 선택하고 사용하는데 별 생각을 안했던 것 같다. 그렇다 이 모든 것은 나태한 내 책임이 아니고 IDE 탓이다..

강의에서 gradle 을 설명하는데, 당연히 알고 있는 개념이라고 생각했지만 들으면 들을 수록 내가 너무 모른다는 것을 인지할 수 있었다. 그래서 이번주 RBF 에서는 gradle 을 확실히 정리하여 발표하려고 한다.

build.gradle 의 파일 이름이 왜 build 로 시작할까?, 중괄호 앞에 붙어 있는 plugins, configurations 는 어떤 기능을 할까?, 위와 같은 코드는 왜 자동으로 작성되어 있을까?

어찌 보면 당연히 품어야 하는 의문인데, 자동에 대한 편리함에 찌들어 생각하려 하지 않았다.... 😂

📌 항상 근거를 가지고 기술을 선택하고, 내가 사용한 기술은 누군가 왜 라고 물어본다면 설명할 수 있어야 한다.