개발도 쉽게 풀어가야 합니다.

melangyun·2020년 8월 2일
53
post-thumbnail

개발은 마법일까요?


학창 시절, 개발자는 어렵고 신비한 일을 하는 것 같았습니다. 여전히 개발은 어려운 일인 것은 물론 맞지만, 상경대학을 다녔던 저는 개발자란 무언가 만들어야겠다 마음먹고 타자로 알 수 없는 무언가 밤새 타탁 타닥 치면 뚝-딱 무언가 만들어 내는 피가 1과 0으로 흐르는 마법사쯤으로 생각했습니다.

그래서 저는, C언어로 처음 개발을 접했을 땐 (그냥 for문과 if문정도였지만), 정말 재미있고 신비로웠습니다. 마치 해리포터가 호그와트에 첫 방문했을 때의 느낌이었을까요?
어느 날엔 switch문 처음 써서 음료 가격 뽑아내는 자판기 만들고, 자랑까지 했었다구요.
짜잔!!!! scanf로 음료 번호 입력하면 음료수 가격이 나와요!

하지만, 공부를 조금씩 더 해가고 몇 번의 작은 프로젝트를 거치면서 저는 점차 마음만 먹으면 뚝딱 해버리는 마법사의 모습보다는 온갖 신을 찾는 미신쟁이가 되었습니다. 항상 서버를 켤 때마다 하느님... 부처님... 예수님.... 구글신님.... 제발... 이번엔 제발 되게 해 주세요... 을 되뇌입니다.
마법사에 빙의해 개발을 하겠다는 결심을 하고 덤벼도 안 하느니만 못한 삽질을 해서 그나마 몇 시간 후에는 아예 기능이 돌아가지 않는 삽질을 할 때가 생각보다 빈번합니다.

위의 사진은 어느 유머사이트에서 전 세계 프로그래머들이 공통으로 하는 작업이라는 추천수가 꽤 많은 게시물에 올라온 짤방 중 하나인데요, 이러한 짤방이 국가를 불문하고 하나씩은 떠도는 것을 보면 재미있기도 하지만, 비단 저뿐만 아니라, 세계 개발자들의 공통적인 마음이 아닐까 합니다.

사실은 기도한다고 해결되지도, 어느 날 마법사가 되지도 않아요

사실은 알고 있답니다..

아직 너무 적은 경험을 갖고 있어서도 더욱더 그렇겠지만, 저는 단지 마음만 먹고 노력하면 그 마음처럼 프로젝트를 뚝딱 완성해버리지는 못합니다.
매일 모르는 것은 산더미에, 끝없는 구글링과 둔하게 느껴지는 내 뇌를 끝없이 굴리고, 이해하려고 부단히 애를 쓰고, 가끔 아무개의 신이나 찾아야지 겨우겨우 무언가 에러를 뿜어내는 2% 부족한 개발을 할 수 있습니다. 학습한 내용마저 한 달을 주기로 절반은 잊습니다.
(아마 평생 그럴 것 같아요)
아주 약간은 다행이게도, 제가 느끼기엔 가끔 만나는 정말 타고나신 분들이 아니라면, 사실 저 같은 노력형 개발자들이 다수인 것 같습니다.
사실, 이제는 "마음만 먹으면 뚝딱!" 이런 개발을 목표로 하기보다는, "삽질이라도 조금씩이라도 쌓아가면 먼 미래의 언젠가는 통달할 날이 있겠지." 라는 조금은 해탈한 생각을 합니다.

개발도 쉽게 풀어가야 하는 것 같습니다.

공감하시겠지만, 개발자는 알 수 없는 언어를 공부한다고 어느 날 뚝딱 사용해버리는 마법사가 아닙니다.
극단적 예시일 수 있겠지만 밑의 알 수 없는 1과 0의 기계어의 나열을 보고 기계어를 공부해 이해할 사람은 거의 없습니다.

0101 0001 0000 0000 0000 0111
0101 0001 0000 0000 0000 1000
0000 0000
0100 1000
0110 1001


도서관에서 전공서적을 뒤적이는 것보단, 구글링을 좋아하고, 사실 개념이 조금만 어려워져도 구글링보다는 친절한 설명이 함께하는 유튜브 강좌님들을 찾는 것이 개발자들이고, 그들 또한 평범한 사람인 것 같습니다.

저는 욕심을 주체하지 못해 한번에 스스로의 능력에 맞지 않는 어려운 주제를 들고 공부를 하는 실수를 현재 진행형으로 자주 합니다.
기반하는 개념부터 차근차근 꼼꼼히 짚고가야 그나마 이해가 될 것을, 욕심만 앞서 어려운 주제로 끙끙거리고 "나는 바보인가..?"하는 조바심을 낼 때가 꽤 많습니다.
그렇게 투머치한 욕심으로 공부한건 적용도 오래걸리고 돌아서면 잊고 ㅠㅠ

요즘 들어서는 예전의 과한 욕심을 버리고 천리길도 한걸음부터 의 마음으로 살려고 하고있습니다.

스스로 개발을 어렵게 하는 것


쉽게 풀어가야 동기부여가 잘되고 성취감 있고 재미있게 개발할 수 있는 것 같습니다. 하지만 나도 모르게 스스로 개발 난이도를 높이는 것들이 있습니다.
정말 짧은 경력이지만 제가 겪거나 옆에서 간접적으로 경험한 것을 바탕으로 나도 모르게 자주 범하는 실수들을 몇 가지 뽑자면 아래와 같을 것 같습니다.
(주관적인 경험과 기준으로 작성한 것입니다.)

1. 본인의 능력치에 맞지 않는 과한 욕심부리기(오버 스택)

새로운 스택을 배우는 것은 좋은 일입니다. 하지만 본인의 능력치는 고려하지 않고 현재 프로젝트에서 실제 그 스택들의 메리트가 별로 없음에도, 그냥 많이 쓰는 거니까, 혹은 요즘 핫하더라 해서 특별한 목적 없이 과하게 따라 쓰기 시작하면 높은 확률로 개발이 힘들어졌던 것 같습니다.

그 기술을 학습할 수 있는 충분한 시간이 있어도 실제로 작동 가능한 코드를 짤 때까지의 시간으로 인해 심적으로 굉장히 지치는 경우가 많았고,
지치지 않기 위해 기본 흐름만 보고 만들고자 하면, 추후엔 디테일한 이해도 부족으로 무언가 엉키기 시작하기 일수였습니다.
시간이 없는 상태에선 마음이 급하여 기본 기능을 짜다가도 이해도 부족으로 막히고 검색하는데 시간에 쫓겨 이해보다는 자꾸 긁어오게 되고... 이 악순환에 들어 서면 개인적으로는 힘들기도 하지만 정말 " 재미 " 가 없더라고요.

같은 시간을 들여 10개 기술에 대한 튜토리얼 수준으로 겨우 만든 사람보단, 1~2가지 기술(혹은 언어)로 인터페이스와 응용방식을 공부하고, 필요에 따라 새로운 스택을 도입한 개발자가 더 재미도 있으면서 더 퀄리티 있는 개발을 할 수 있을 것이라고 생각합니다.

당근마켓 정창훈 CTO님은 "당근마켓 성장과 개발 스택의 변화" 테크 세미나에서 개발 스택에 관하여 아래와 같이 언급하며
새로운 스택에 대하여 상황에 맞게 도입해야 한다는 신중함을 표현합니다.

...
개발 언어의 성능이 부족하고 느려서 서비스가 크지 않는 경우는 없습니다.
단지 서비스가 크지 않아서 사라질 뿐입니다.
...
당근 마켓에서 Docker는 2019년 도입하였습니다. 굉장히 늦은 편이죠,
Docker가 요즘에 핫한 기술이며 분명 장점은 있습니다. 하지만 저희는 저희의 상황에 맞게 도입하려 했습니다.
Docker를 도입하면서 아직도 해결되지 않은 부분들이 있고, 개발적으로 이전보다 훨씬 더 힘든 부분들이 많습니다.
...


2. 변수명을 신중하게 짓지 않는 것

어떤 개발자던, 현재 기능을 구현할 때에는 오로지 그 코드들에 몰입하여 코드를 씁니다.
그 말인즉슨, 코드를 짤 당시에는 너무나 당연한 기능들이며 당연한 파일명이나 변수명이기 때문에 가벼운 생각으로 짓고 넘어가기 쉽습니다.
하지만 1~2달 후 (기억이 희미해지고) 기능 변경이나 추가가 필요하여 그 코드를 봐야 할 때엔, 코드들을 다시 몰입하여 해석을 해야 한다는 것입니다.

현재 코드를 짤 당시의 당연했던 부분들이 1~2달 후에도 당연할 수 있을까요? 또, 협업자가 있을 경우 나에게 당연한 것들이 그 협업자에게도 당연할 수 있을까요?
물론, 모든 코드와 기능들을 살펴보고 실행시켜보고 물어보며 맥락상 추론을 할 수는 있을 것입니다. 하지만 이러한 것들이 쌓여 많아진다면 코드를 읽는 데에 피로감이 상당히 증가합니다.

아래는 제가 이전에 했던 실수를 정말 간단히 나타낸 것입니다.
카카오 로그인 API는 회원가입과 로그인이 동일한 API를 사용하며 동일한 응답을 반환해 줍니다.
따라서, 제 서버는 이 카카오 로그인 시 db에서 이 유저의 auth 정보를 찾아 현재 회원가입을 하는 유저인지, 기존 유저(단순 로그인)인지 판별해 줍니다.

// authModel에서 OAuthId로 auth 관련 정보를 찾습니다.
const auth:Auth|undefined = this.authModel.findByOAuthId(oAuthId);
// 없다면 undefined, 존재한다면 Auth 정보를 반환할 것입니다. (Auth|undefined)
return { register : !!auth }
// `!` 연산자는 boolean값으로 치환 해 주며, true -> false , false -> true 로 반환됩니다.
// object 는 truthy하여 !object -> false 이며,
// undefiend는 falsy하여 !undefined -> true입니다.
// 따라서 Auth object가 존재할 경우 { register : true } 가 반환될 것이고, Auth 정보가 없다면 { register : false }가 반환될 것입니다.

처음에는 이런 식으로 클라이언트에 boolean을 전달했습니다.
하지만 단순히 생각해 보아도, register이 boolean을 갖는 것은 자연스럽지 못하며, 단순히 이 응답을 받았을 때엔 뜻하는 바를 한 번에 파악할 수 없습니다.
이러한 피드백을 받고 고친 것인데요,

const user:Auth|undefined = this.authModel.findByOAuthId(oAuthId);
return { isRegistered : !!auth }

이것 또한 위에 register보다는 한결 나아졌지만, 논리적으로 옳지 못합니다. 회원가입을 한 유저이건, 단순히 로그인을 한 유저이건 "register"되어 있는 것은 동일하기 때문입니다.
저희 프런트엔드 개발자 예이님의 의견을 수렴해 아래와 같이 변수명을 매우 직관적이고 쉽게 수정하였습니다.

const auth:Auth|undefined = this.authModel.findByOAuthId(oAuthId);
return { isNew : !auth }

위 세 가지의 네이밍으로 1년을 코딩하여 코드가 쌓였다고 한다면,
1년 후의 제가, 혹은 새롭게 합류한 개발자 분이 이해하려 한다고 생각할 때 세 가지 코드의 직관성은 매우 다를 것이고, 이것이 의미하는 바가 무엇인지 파악하기 위해 에너지를 비할 수 없게 소모하게 될 것입니다.
변수명을 신중히 쉽고 직관적이게 짓는 것은 당시에는 아주 사소한 차이 일 수 있겠지만 시간이 흐르고 쌓인다면 코드의 가독성을 높이고 피로도를 낮추는 방법이라고 생각합니다.

3. 주석을 달지 않는 것

저는 개발을 할 때에 조그마한 철학이 있습니다. 바로 누군가 내가 개발하는 것을 이어서 할 지라도, 바로 이어 할 수 있게 개발하자라는 것입니다.
왜냐하면, 개발은 다른 사람과의 협업이 필수적이기 때문입니다. 또, 1년, 아니 1~2개월만 흐르게 되어도 스스로 코드에 대한 기억이 희미해져 새로운 코드처럼 코딩을 하기에 저 스스로를 위한 것이기도 합니다.

가독성은 개발에 대한 피로도와 직결되고, 코드 가독성을 가장 드라마틱하게 올릴 수 있는 것은 주석이라고 생각합니다.

예를 들어 아무리 엉망인 코드를 써도

// 유저 등록 부분

이라는 주석이 달려있다면, "아, 이 부분은 유저를 등록하는 부분이구나"라는 생각을 갖고 보게 되겠죠.

사실 코드를 쓸 때, 항상 가독성을 생각하고 코딩하고자 노력하지만 주석 없이 가독성이 높은 코드가 가능할지는 잘 모르겠습니다.
주석을 다는 적절한 방법들이 많겠지만 저는 복잡한 로직에만 자잘한 설명을 다는 편이고, function단위로 무조건 어떤 기능을 갖고 있는지 간단히 적어놓습니다. 또한 수정이 필요할 수 있거나 체크가 필요한 곳에 REVIEW주석 등을 달곤 합니다.

주석을 다는 데에 사용하는 굉장히 유용한 VSCode extension 있어 간단히 추천을 하고 넘어가겠습니다.
바로 Comment Anchor라는 extension인데요, 아래와 같이 주석을 달면 좌측에 주석 목록이 생기며, 항목을 클릭하면 바로 주석에 해동하는 line으로 화면이 이동됩니다.

파일 별로 주석 목록도 있고, 한번에 이동할 수 있어서 상당히 유용히 사용하고 있습니다.
추가 기능도 있는데, 관심이 있으시다면 찾아보세요!


4. 타인의 조언(or 의견)을 듣지 않는 것

저는, 어떠한 문제에 부딪히고 제가 갖고 있는 키워드로는 마땅한 답안이 없는 것 같다면 다른 개발자 분들께 짬짬이 의견을 물어보곤 합니다.
저는 그때마다 제가 고민한 방법들은 단편적인 방법이었을 뿐이며, 같은 문제를 두고 정말 무궁무진한 방법이 있다는 것을 배웁니다. 제 창의력과 기술력의 한계를 느끼기도 하고, 해결할 수 있는 새로운 키워드(때로는 새로운 스택)를 얻기도 하며 다른 분들의 방법을 배우기도 좋습니다.
(그리고 다른 분 에게 물어보려고 정리하다가, 혹은 설명해주다가 스스로 깨닫는 경우도 종종....) 😂
그렇기 때문에 어떠한 문제에 부딪혔을 때 다른 사람들의 조언이나 의견을 듣지 않고 오로지 그것이 해결될 때까지 매달려 있는 것은, 사고방식과 창의력을 닫아버리는 것과 동일한 것 같습니다.

또, 보편적인 인간관계에서 조언 자체가 그리 쉽게 할 수 있는 것이 아니기도 하며, 본질적으로 위하는 마음과 고민에서 나온다고 생각하기 때문에 조언을 듣고 모두 반영하지는 않아도 한 번쯤은 고민해보는 것은 정말 필요한 것 같습니다.


한 가지 썰을 풀자면, 언젠가 경험했던 학생 프로젝트에서는, 본인이 개발을 잘 한다 는 자부심으로 가장 구현하기 어려워 보이는 문제를 들고 가 막히는 부분을 공유하지 않고 혼자 일주일을 앓다가 결국 시간에 쫓기어 다른 학생들끼리 머리를 맞대어 짧은 시간에 해결한 적이 있습니다...

어디에서 막혀있는지 먼저 묻고 다 함께 해결하려고 해도 본인의 방식을 고집하더군요. 사실 이 경우는 팀원 전체에게도 생산성과 협업의 측면에서 굉장한 손해이며, 다양한 풀이법을 경험해 보지 못한 본인에게도 손해였습니다. 빠르게 공유하고 집단 지성으로 해결했다면, 그 홀로 고민했던 시간에 해결 한 방안을 개선할 수 있는 코딩을 해볼 수도 있겠고, 다른 기능을 구현하면서 공부를 더 할 수 있지 않았을까요?
또, 그 경우에는 쉬이 풀리지 않는 문제를 잡고 있었던 그분도 그 코딩이 재미있었을까요? 답답하고 좌불안석의 마음으로 코딩을 했을 것이라고 생각합니다.
사실 이게 드문 일이라고 생각하지는 않습니다.

학생 프로젝트뿐만 아니라, 프러덕트를 만들면서도 그냥 얕잡아 보이기 싫어서, 내가 저 사람보다는 잘하는 것 같아서, 혹은 그냥 (물어보기에) 눈치가 보여서 의견을 잘 듣지 않거나 물어보지도 않고 끙끙거리는 경우도 심심치 않게 듣는 것 같습니다.

다른 시선으로 바라볼 수 있는 의견과 피드백은 정말로 너무 소중한 것입니다!🥺

개발을 쉽게 풀어가자

제겐, 개발은 쉽지 않습니다. 아니, 너무 어려워요!
하지만, 그나마 쉽게 풀어갈 수는 있다고 생각하고, 스스로 어렵게 만들어서는 안된다고 생각합니다.
이왕 개발하는 거 가능한 간단하고 재미있게 하자고요!




비록 저는 지금 쪼랩의 백엔드 개발 이지만 마음만 먹으면 뚝딱! 해버리는 개발자를 장래희망으로 살아가고 있습니다.
이 글은 잠시나마 함께 일하셨던 디자이너 세영님의 글 [UX] 쉬운 말을 써야 한다 를 보고 영감을 받아 작성하였습니다.



[참조]

[Tech Seminar] 당근마켓 성장과 개발 스택의 변화

profile
개발을 즐겁게!

9개의 댓글

comment-user-thumbnail
2020년 8월 3일

좋은 글 잘 읽고 갑니다. vscode 익스텐션 코멘트를 다른걸 사용하고 있었는데 한번 사용해봐야겠어요 좋아보이네요 :)

1개의 답글
comment-user-thumbnail
2020년 8월 11일

좋은글 너무 감사합니다. 변수명이랑 주석다는 부분에서 반성하게 되네요..!

1개의 답글
comment-user-thumbnail
2020년 8월 11일

엑스텐션 잘 설치하고 갑니다~

1개의 답글
comment-user-thumbnail
2020년 8월 23일

지당하신 말씀입니다.

답글 달기
comment-user-thumbnail
2020년 9월 5일

좋은 글과 익스텐션 정보 감사합니다, 변수명을 신중하게 짓지 않는 것 부분의 2번째 코드에 const user:Auth|undefineduser라는 변수가 있는데 아래에서는 auth라는 변수를 사용하는 것으로 보아 오타가 있으신 것 같아요.

답글 달기