딸깍의 소중함

RafaelRafael
4 min read
🤖
망한 제목에 망한 글이 따라온다. 제목도 좀 딸깍 해줘

시작

문득 일을 하다가 meme(밈)이 가진 전달력이 아주 대단하다는 생각을 했다. 별거 아닌 단어 하나를 사용하는데, 해당 밈을 아는 사람에게는 그 밈에 내포된 여러가지 복합적인 의미가 한 번에 전달되는 것이다. 예를 들면 딸깍 같은 단어이다. 전혀 배경을 모르는 사람은 내가 이건 딸깍을 하겠습니다 혹은 이 부분은 딸깍으로 처리하겠습니다 라고 하면 ‘미친 사람인가 갑자기 왠 딸깍이여..?’ 싶을 것이다. 하지만 나와 같이 일 하는 다른 개발자님은 무슨 의미인지 알기 때문에 별 다른 설명 없이도 의사 소통이 가능하다. 불필요한 부연 설명 없이 짧은 단어나 이미지 한 장으로 설명할 수 있다는 점이 meme 소통이 생산성을 높여 준다는 생각이 들었다. (이 소통 방식 자체가 딸깍이다)

그래서 딸깍이 뭐냐고?

뭐 옛날에 많이 쓰던 날먹 비슷한 단어이기도 하고.. 아래 짤이 많은 것을 설명해준다고 생각합니다.

[딸깍 - 나무위키] 참조하십시오..

나무위키를 참조하니 생각나는 농담.. 최고의 욕은 ‘나무위키 참조했냐?’ 보다 ‘너는 나무위키라도 좀 읽어보고 와라’ 라고.. (나는 나무위키 좋아하는데)

헤어나올 수 없는 딸깍

아무튼 요점은 나는 요즘 일하면서 딸깍을 많이 한다는 것이다. 나 그리고 같이 일하는 동료 개발자와의 사이에서 딸깍은 코드 작업 중 일부를 LLM에게 시키는 것을 의미한다. 나는 심지어 문제에 따라서 chatGPT 와 claude를 번갈아 사용한다. 즉 LLM을 업무 보조 용도로 상당히 적극적으로 사용하게 되었다는 말이다. 예전에는 혼자서 실컷 개발을 하다가 막히는 부분이 생기거나, 잘 모르는 부분에 대해서 질문을 하는 검색 엔진 대용으로 LLM을 썼는데, 이제는 거의 인턴과 함께 일 하는 수준으로 LLM을 굴린다. 그러다보니 코드를 작성하는 방식에도 변화가 많이 생겼다.

예전에는 데이터 흐름에 따라서 하나씩 기능을 만들어 나가는 방향을 선호했다. 대충 아래와 같은 순서로 작업하는 경우가 많았다.

  1. 특정 데이터를 분석하고 어떤 형태로 파싱할지 결정

  2. 파싱하는 함수 작성

  3. 컴포넌트에 데이터 뿌리는 부분 만들기

  4. 컴포넌트 스타일링

  5. 리팩토링

React native를 가지고 일 할 때도 animation이나 gesture handling을 죽어라 작업할 때도 큰 차이는 없었다. 데이터를 분석하는 것과 비슷했다. 유저의 행동에 따른 이벤트를 분석하고 해당 Event나 Gesture에 따라 반응해야 하는 부분을 작성하는 것이기 때문에 데이터 흐름을 기반으로 하는 것과 유사하게 작업이 가능했다. 나는 설계에 장점이 있는 사람이 아니었기 때문에 미리 크게 크게 설계를 해두고 작업하지 않았고, 일단 기능 명세에 있는대로 동작하도록 다 만들고 재사용할 부분이나 컨벤션에 맞지 않는 부분 등 비효율적인 부분을 제거해 나가는 방식을 선호했다.

그런데 요즘에는 조금 달라졌다. 물론 kotlin + spring 환경에서 작업하는 시간이 더 많았기 때문일수도 있다. controller에서 시작하는 것 보다 infrastructure나 domain 부터 다 잡고 시작하는게 재미있더라. 여기서 느낀 점도 나중에 이야기해보면 좋겠다.

어떻게 달라졌냐고

그러니까 결론부터 이야기하면 크게 크게 구조를 먼저 잡아두고 세세한 것은 LLM에게 시키는 방식으로 바뀌었다. 물론 구조를 짤 때도 애매하면 LLM에게 조언을 구하기는 하지만, 대부분은 미리 작성한 타입을 주고 “이 데이터를 이 타입으로 변환할거야, 코드 짜봐” 같은 일을 많이 시킨다. 그리고 내가 하는 것보다 매우매우 빠르게 잘 나온다.(왠만하면) 물론 세부적인 체크는 해줘야 한다. 내용이 길어지거나 할 일이 많아지거나 하면 후반부에 지능이 급격하게 떨어지는 건지 당이 떨어지는 건지 모르겠지만 갑자기 이상한 소리를 하는 경우도 있다. 그런데 모델이 발전함에 따라 그런 일도 줄어들고 있고 (특히 이제 막 나온 claude sonnet 3.7은 3.5보다 훨씬 잘 하는 것 같다) 시간 단축이 되는 것은 확연한 사실인 것 같다.

실제로 최근에 FE 프로토타입을 만들어야 해서 claude를 사용했는데 기본적인 기능을 갖추는 데 세 시간도 안걸렸다. 물론 그 뒤로 세부적인 고도화를 하거나 그런 부분은 직접 하고 있지만, 전부 직접 했으면 훨씬 오래 걸렸을 것이다. 특히 tailwind class 붙여서 그럴싸하게 스타일 넣어봐 하면 나보다 예쁘게 잘 만들어서 좋다…

요약하자면 자꾸 하다보니 프롬프팅 하는 능력은 점점 좋아지고 있는 것 같고, 요즘 내 업무의 대부분은 구조를 짜고 세부 코드를 인공지능에게 만들도록 시킨 뒤 코드 리뷰를 하는 식으로 이루어진다 이 말이다.

자나깨나 뒤통수 조심

하지만 조심해야 한다. 시간이 급하다고 인공지능이가 내민 코드를 전혀 검토하지 않고 쓰다간 통수를 씨게 맞을 수가 있다. 그리고 내 질문에 따라 방향성이 잘못 결정되어버려서 인공지능 꼬맹이랑 같이 동굴 속에서 나오지 못하고 기절하게 되어버리는 경우도 있을 수 있다. 얼마 전 큰 데이터를 차원에 따라 이리 저리 다양한 형태로 사용해야 할 필요가 있었는데(라고 생각했다), 인공지능이는 dataframes 라는 jetbrains에서 만든 kotlin 라이브러리를 극찬했고 우린 바로 사용에 들어갔으며.. 인공지능이 제시하는 코드를 사용하려다 타입 지옥에 빠져 다 죽고 말았다. 꽥

그리고 열 받아서 dataframes를 빼고 나니 한 시간도 안되어 기능을 다 만든 후 극적으로 살아나고야 말았던 것이다

결론 같은 것은 없는 그저 근황 에세이 같은 글이라 마무리를 어떻게 해야 할 지 모르는데, 저는 잘 지내고 있고, 개발자 둘이 일하면서 네 명이 일을 하는 것 같은 느낌으로(각자 LLM 달고) 일을 한다 이 말입니다. 앞으로는 개발 이야기가 1도 없는 순수 에세이를 적어보고 싶다는 생각을 하며 마무리를 지어봅니다. 다음 번엔 글 자체도 딸깍을 해볼까..

0
Subscribe to my newsletter

Read articles from Rafael directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Rafael
Rafael

Software Engineer 7 years of experience in building services with React and React Native. Currently developing services using Kotlin and Spring Boot.