AI 시대에 프로그래밍을 즐기는 법

출처: Dev.to

It’ s widely accepted that as AI writes more and more of our code, opportunities decrease for newcomers to gain the skills needed to become professional programmers. At the same time, experienced people bemoan the way AI is causing them to gradually lose the skills they took so long and worked so hard to gain.
AI가 점점 더 우리의 코드를 작성하면서 신규 개발자들이 전문 프로그래머가 되기 위해 필요한 기술을 습득할 기회가 줄어든다는 것이 일반적인 인식이다. 동시에 경력 있는 사람들은 AI가 그들이 오랫동안 노력해 얻은 기술을 서서히 잃게 만들고 있다고 불평한다.

Programming, like mathematics and perhaps music, sits in the middle between science and art. As science, it’s all about capturing and organising knowledge, and as art, it’s the application of creativity to problem- solving. Enjoyment - deep satisfaction or an emotional rush - can be had from either or both of these.
프로그래밍은 수학과 비슷하게 과학과 예술 사이에 위치해 있다. 과학적으로 보면 지식을 포착하고 조직화하는 데 초점을 맞춘다, 예술적으로는 창의성을 활용한 문제 해결에 집중한다. 깊은 만족감이나 감정적 쾌감을 얻는 즐거움은 이 두 요소 중 하나 또는 모두에서 나타날 수 있다.

But the perception is that AI is depriving us of opportunity, both to learn and to be creative.
하지만 인식상 AI는 우리에게 학습하고 창의적인 기회를 제공하는 것을 방해하고 있다고 여겨진다.

Code written by a human reveals a lot about the coder. Their depth of knowledge of the coding language, their creative use of variable and function names, and even the visual layout of a script. You can often tell at a glance whether the writer truly cared about the code they wrote, or whether it was just a means to an end, to ensure their next pay packet arrives on time.
인간이 작성한 코드는 개발자의 배경에 대해 많은 것을 드러낸다. 언어에 대한 깊이 있는 지식, 변수와 함수 이름의 창의적인 사용, 그리고 스크립트의 시각적 레이아웃까지이다. 한눈에 보면 작성자가 진심으로 코드를 cared about했는지, 아니면 단순히 다음 급여를 받기 위한 수단으로 썼는지 알 수 있다.

As AI improves, it makes fewer mistakes, but it also produces code that is increasingly hard for any human to read and truly understand. Since the job of a human in the coding loop is increasingly not to write but to validate code, this is becoming a problem.
AI가 발전함에 따라 실수도 줄어들지만, 인간이 읽고 진정으로 이해할 수 있는 코드를 생성하게 된다. 인간은 점점 더 코드를 작성하는 것이 아니라 검증하는 역할로 전환하고 있다. 이는 문제가 되고 있다.

So here’ s my recent story, a series of happy accidents.
그래서 나는 최근 일어난 일들을 공유한다. 행복한 우연들의 연속이다.

I’ ve been using agentic AI for about a year. First with Copilot in VS Code, then more recently with Claude Code at the command line. At the start, I found Copilot to make a lot of mistakes and to produce rather repetitive, poorly- structured code, but looking back, a lot of that was probably down to my own ignorance of how to control the process.
저는 약 1년 동안 에이전트 AI를 사용해 왔습니다. 처음엔 VS Code의 Copilot을 이용했고, 최근에는 명령 줄에서 Claude Code를 사용했습니다. 초기에는 Copilot이 많은 실수를 했고 구조가 나빠 복잡한 코드를 많이 내놓았지만, 되돌아보면 대부분은 제自身의 프로세스 제어 방법을 몰랐기 때문이었다.

The biggest problem I had was in validating JS or Python code. There was just so much of it, often using features of both languages I never fully got to grips with. I’ ve never been a first- class programmer and most of my own code is pure vanilla. The project I was working on was AllSpeak, based on an English- like scripting language I’ d written years earlier to help me create products without having to be a coding expert. AI gave me the chance to bring it up to date.
가장 큰 문제는 JS나 Python 코드를 검증하는 것이었다. 양이 많았고, 내가 완전히 익숙하지 못한 양 언어를 모두 사용하고 있었다. 나는 1급 프로그래머는 아니었고 대부분 순수한 기본 코드만 썼다. 내가 작업 중인 프로젝트는 AllSpeak으로, 몇 년 전에 만든 영어와 유사한 스크립트 언어 기반이었다. 이 언어로 제품을 전문가 없이 만들 수 있게 해 주려는 목적이었다. AI 덕분에 업데이트할 기회를 얻었다.

But it was when Copilot started offering me AllScript fragments - uninvited - that I had a complete rethink.
하지만 Copilot이 무단으로 AllScript 조각을 제공하기 시작하면서 나는 완전한 재고심을 하게 되었다.

The assumption usually made is that code must be written in a modern, high- level language like JS or Python. This is quite valid when a human is doing the coding, but it falls down badly for AI. The problem is, these languages are too complex, and they suffer from inconsistencies AI finds difficult to spot.
보통 우리는 코드가 현대적인 고수준 언어인 JS나 Python과 같은 언어로 작성되어야 한다고 가정한다. 이는 인간이 코딩할 때는 타당하지만 AI에게는 맞지 않는다. 문제는 이러한 언어들이 너무 복잡하고, AI가 찾기 어려운 불일치성을 가지고 있다는 점이다.

Documentation is often out of date, and new versions of the language can break older code. Additionally, many features of these language are there as guardrails to stop humans making coding errors that gobble up memory or lie in wait to misbehave in the future.
문서화는 종종 오래돼 있고, 언어의 새 버전은 기존 코드를 깨뜨리기도 한다. 또한 이러한 언어의 많은 기능들은 인간이 메모리를 소모하거나 나중에 잘못 작동할 수 있는 오류를 방지하기 위한 안전장치 역할을 한다.

Since AI doesn’ t make the same mistakes as humans it doesn’ t need these guardrails; in fact it makes AI’ s job harder, not easier.
AI는 인간이 범하는 실수를 동일하게 만들지 않기 때문에 이러한 안전장치가 필요 없으며, 오히려 AI의 작업을 더 어렵게 만든다.

An obvious path revealed itself. If the agent was trying to write code in AllSpeak, why not let it finish the job? I built an AGENT.md file that instructed the agent to code in my language wherever possible, and gave links to the repo and to documentation that would help it do this without making errors.
명백한 해법이 나타났다. 에이전트가 AllSpeak으로 코드를 작성하려 한다면 왜 그대로 맡기지 않을까? 나는 AGENT.md 파일을 만들어 에이전트에게 가능한 한 내 언어로 코딩하도록 지시하고, 오류 없이 수행할 수 있도록 레포와 문서 링크를 제공했다.

The benefit was immediate. Instead of having to wade through huge piles of JS and Python, I could now see the application being built in something much closer to English.
이점은 즉시 나타났다. 이제 나는 거대한 양의 JS와 Python을 뒤지지 않고, 영어에 훨씬 가깝게 작성되는 애플리케이션을 볼 수 있게 되었다.

But it went much further than this. Every now and then, the agent would guess at a construct that wasn’ t valid, using its knowledge of other coding languages. This was usually down to limitations in the available documentation, but I figured that if the agent wanted to use such a construct, as long as it was syntactically valid and consistent with the rest of the language, it should probably be added.
그것을 훨씬 더 넘어섰다. 가끔 에이전트는 다른 코딩 언어에 대한 지식을 바탕으로 유효하지 않은 구문을 가정했다. 이는 보통 문서화 제한 때문이었지만, 만약 에이전트가 그런 구문을 사용하고 싶다면, 그것이 문법적으로 타당하고 전체 언어와 일관된다면 추가하는 것이 좋다고 생각했다.

So I set up a permanent second session that deals with additions and changes to AllSpeak, and a rule that if the agent can suggest an improvement, it should do so.
그래서 영구적인 두 번째 세션을 만들어 AllSpeak의 추가와 수정을 담당시켰고, 에이전트가 개선점을 제안하면 그대로 실행하도록 하는 규칙도 만들었다.

Because AllSpeak is growing in this way, it might be regarded as an impediment to coding, given that it was designed in the first place to make coding simpler. But this changes when AI is doing the coding. The human’ s job becomes not to write code but to read it, and because the language is close to English, the meanings of new syntax can be made fairly obvious.
AllSpeak이 이렇게 성장하면서 코딩에 장애가 된다고 여겨질 수 있다. 원래는 코딩을 단순하게 만들기 위해 설계된 것이었기 때문이다. 하지만 AI가 코딩을 할 때는 상황이 달라진다. 인간의 역할은 코드를 작성하는 것이 아니라 읽는 것으로 바뀌고, 언어가 영어와 유사하기 때문에 새로운 구문의 의미는 비교적 명확해질 수 있다.

I can pile in a load of new syntax that reduces repetitive boilerplate to a few words. I no longer have to remember all the syntax, merely to recognise it. This is a big difference.
새 구문을 많이 넣어 반복적인 boilerplate 코드를 몇 단어로 줄일 수 있다. 더 이상 모든 구문을 기억할 필요 없이 인식만 하면 된다. 이것이 큰 차이점이다.

The final part of this story so far (there may be more to come) was that I’ m just an individual with a limited budget. Claude Code does a superb job, but it can get expensive. The pricing is non- linear; spending more gives you exponentially more tokens, but I was ending up not using my allowance. Reducing the cost meant I overran and had to top up.
이 이야기의 마지막 부분(아직 더 있을 수도 있다) 은 내가 개인 사업자이며 예산이 제한적이라는 점이었다. Claude Code는 훌륭하지만 비용이 많이 든다. 가격 정책은 비선형적이다. 더 많이 쓰면 토큰 수가 급격히 늘지만, 나는 허용량을 충분히 사용하지 못했다. 비용을 줄이려니 과도하게 쓰고 보충해야 했다.

Then I saw a mention that DeepSeek costs about 50 times less (yes, that’ s 2%) than Claude Code, so I had to try it. And it’ s true; after a couple of weeks of daily but not intensive work it’ s cost me $0.46.
그 후 DeepSeek이 Claude Code보다 약 50배(정확히는 2%) 저렴하다는 언급을 보았다고 해서 시도해 봐야겠다고 생각했다. 그리고 사실이 그랬다. 며칠 동안 일상적으로(하지만 집중적이지 않게) 작업한 결과 비용은 $0.46에 불과했다.

However, it’ s not as good at coding as Claude. It’ s quick, but it makes more errors, and from the verbose output it emits while working, it seems to struggle from time to time.
하지만 코딩 면에서는 Claude보다 뛰어나지 않다. 빠르긴 하지만 오류를 더 많이 내며, 작동 중인 verbose 출력을 보면 가끔씩 어려움을 겪는 것 같다.

How much of this is down to my still less- than- perfect documentation is hard to tell, but I definitely have to intervene more often.
이게 얼마나 내 문서가 완벽하지 않아서 발생한 건지 알기 어렵지만, 확실히 더 자주 개입해야 한다.

I understand that deepseek- v4- flash is optimised more for managing huge datasets than it is for coding, which could well be the explanation.
DeepSeek v4-flash는 대용량 데이터를 관리하는 데 최적화되어 코딩에 최적화되지 않았다는 점을 이해할 수 있다.

But this limitation brings an unexpected benefit. When working with Claude Code, I often felt myself to be merely a bit player. I gave the requests, but then had little part to play in how things were done as mistakes were few and far between.
이 제한점이 오히려 예상치 못한 이점을 가져왔다. Claude Code와 작업할 때 나는 종종 조연에 불과한 존재로 느꼈다. 요청은 했지만, 실수가 거의 없어 내가 어떻게 진행되는지에 큰 역할을 하지 못했다.

With DeepSeek I feel more like an equal. We have different roles; DS does the coding and I review it.
DeepSeek과 작업할 때는 더 같은 입장이 된다. 역할이 다르다. DS는 코딩을 하고, 나는 그것을 검토한다.

And because it’ s written in something close to English, I can follow it far more easily than I would have, had it been JS or Python. I can spot things that aren’ t right and suggest improvements. I’ ve started to feel like a programmer again, that I really have a role to play in the coding process.
그리고 언어가 영어와 유사하기 때문에 JS나 Python일 때보다 훨씬 쉽게 따라갈 수 있다. 올바르지 않은 점을 포착하고 개선점을 제안할 수 있다. 다시 프로그래머로서의 역할을 되찾았다는 느낌이 든다. 내가 코딩 과정에 실제로 관여하고 있다는 것을 깨달았다.

And that’ s where the enjoyment has returned.
그리고 그곳에서 즐거움이 돌아왔다.

So what started as a series of serendipitous accidents followed by a cost- saving trial has turned out to be a partnership of equals, restoring my enjoyment of the coding process. One conclusion I draw from this is that maybe instead of always assuming the latest model is better, consider whether it leaves you with a real part to play in that process, or whether you’ ll get more enjoyment out of taking on the role of teacher and helping a lesser model do its job, while saving money at the same time. Don’ t forget, happy people produce better results.
이것은 우연의 연속과 비용 절감 시도로 시작된 것이지만, 두 모델 간의 평등한 파트너십으로 발전해 코딩 즐거움을 되찾았다. 여기서 나는 최신 모델이 무조건 낫다고 가정하기보다, 내가 실제 참여할 수 있는 역할이 있는지, 아니면 더 낮은 수준의 모델을 가르쳐 함께 일하며 비용도 절감하는 것이 더 즐겁게 만들 것임을 고려해야 한다고 생각한다. 기억하자, 행복한 사람들은 더 좋은 결과를 만든다.