한 달 동안 AI에게 내 코드를 대부분 작성하게 했습니다. 그 결과는 이렇습니다.

Source: Dev.to

위에 제공된 텍스트를 한국어로 번역하려면 실제 번역할 내용이 필요합니다. 번역하고 싶은 본문을 복사해서 여기에 붙여 주시면, 원본 포맷과 마크다운을 그대로 유지하면서 한국어로 번역해 드리겠습니다.

무해하게 시작되었다

나는 빈 편집기를 바라보며 간단한 CLI 도구를 만들려고 했습니다—며칠 안에 끝낼 수 있을 정도의 일. 하지만 여러분도 알다시피 상황은 언제든지 변합니다: 스택‑오버플로우의 무한 루프, 법률 문서처럼 읽히는 문서들, *“뭘 만들고 있는 거지?”*와 “이걸 어떻게 해야 하지?” 사이를 오가며 끊임없이 컨텍스트를 전환하는 일.

그래서 많은 사람들이 지금 하는 것처럼 나는 AI 어시스턴트를 켰습니다.

Prompt: “Write a CLI tool in Golang that accepts a port number and kills any process running on that port.”

몇 분 후 나는 작동하는 코드를 손에 넣었습니다. 단순히 동작하는 것이 아니라 다듬어졌습니다: 오류 처리, 유용한 메시지, 크로스‑플랫폼 호환성까지. 몇 시간을 들여야 할 부분을 순식간에 해결한 것이죠.

멋지죠?

고속 라이딩

명백한 사실: AI가 당신을 막을 수 없게 만든다

• 일주일 걸리던 프로젝트가 갑자기 이틀 안에 끝난다.
• 마찰이… 사라진다.
• 까다로운 정규식에 막혔나요? AI가 처리한다.
• 특정 라이브러리 API가 기억 안 나나요? AI가 보여준다.
• 미친 듯이 괴롭히는 이상한 버그? AI가 세 가지 가능한 해결책을 제시한다.

모멘텀이 진짜 중독제다. 실제로 일을 끝낸다. 벽에 부딪혀서 프로젝트를 중간에 포기하지 않는다. 무언가를 배포하고, 뿌듯함을 느끼며, 다음 일로 넘어간다.

과부하와 완벽주의에 시달리는 사람에게(죄송합니다), 이것은 혁명적으로 느껴진다.

The Downside Appears

A side‑project that turned sour

Two weeks in I shipped a simple tool that pulled data from an API and displayed it nicely. AI had written most of it—API calls, data parsing, error handling, the whole deal.

It worked. I was proud. I moved on.

A week later someone reported a bug: the data wasn’t displaying correctly in a specific case.

I opened the code and stared at it. I realized I had no idea how it worked. I could tell you what it did, but not why it worked that way, nor could I debug it because I didn’t understand the decisions AI had made.

So I did what felt natural—I asked AI to fix the bug. It did. The bug disappeared. But I felt… weird. I’d shipped a fix I didn’t understand, for a project I didn’t understand, to solve a problem I didn’t fully grasp. I was essentially a copy‑paster, but with better branding.

When complexity bites

A month into the experiment I tackled something more complex: multiple files, tricky state management, the kind of thing where small changes have big ripple effects.

Something broke—no clear error, just wrong behavior.

I spent three hours trying to fix it: pasting code into AI, getting suggestions that almost worked but not quite, watching the bug mutate into different bugs, feeling my confidence erode.

The truth about AI:

• It’s great at writing code that works.
• It’s okay at fixing code.
• When you’re deep in the weeds of a complex system you don’t fully understand, AI can’t save you.

Because it doesn’t understand the context either. It doesn’t know the history of decisions you made. It can’t see the system as a whole—it just sees tokens and patterns.

That night, at 2 AM, staring at code I’d technically “written” but didn’t understand, I realized something:

I’d outsourced the thinking, not just the typing.

It’s not just about understanding your code (though that’s huge). It’s about growth.

I looked back at that month of AI‑assisted development and asked myself: “What did I learn?”

The honest answer? Not much.

• I shipped more projects than usual, sure.
• But I hadn’t become a better developer.
• I hadn’t leveled up my problem‑solving.
• I hadn’t really engaged with the interesting parts of the problems I was solving.

I’d become really good at… prompting, assembling pieces, shipping fast.

But the deep satisfaction that comes from genuinely solving a hard problem? That was gone.

And the scary part: I could feel myself getting dependent. I’d start a project and immediately think, “I’ll just have AI handle that part.” I was avoiding the hard stuff—the stuff that actually makes you grow.

나에게 효과적인 방법

✅ AI의 좋은 활용법

❌ AI의 나쁜 활용법

내가 따르는 규칙

스스로 디버깅할 수 없는 코드는 절대 배포하지 않는다.

AI가 생성한 코드를 커밋하기 전에 나는 스스로에게 묻는다:

1. 이 코드가 한 줄 한 줄 무엇을 하는지 설명할 수 있는가?
2. 왜 이렇게 작성되었고, 다른 방식이 아닌지 이해하고 있는가?
3. 일요일 새벽 3시에 이 코드가 고장난다면, AI 없이 고칠 수 있는가?

이 중 어느 하나라도 “아니오” 라면, 절대 배포하지 않는다. 그게 전부다.

구체적인 예시

최근에 특정 포트에서 실행 중인 프로세스를 종료하는 CLI 도구를 만들었습니다. 간단한 작업이었죠. AI가 어떻게 도와줬는지 보세요:

# Prompt to AI
Write a Go CLI that:
- Accepts a port number as an argument
- Finds the PID(s) listening on that port
- Kills those processes (cross‑platform)
- Provides helpful error messages

AI가 생성한 코드:

package main

import (
    "flag"
    "fmt"
    "os"
    "os/exec"
    "runtime"
    "strconv"
    "strings"
)

func main() {
    port := flag.Int("port", 0, "Port number to free")
    flag.Parse()

    if *port  65535 {
        fmt.Println("Please provide a valid port number (1‑65535).")
        os.Exit(1)
    }

    pids, err := findPIDs(*port)
    if err != nil {
        fmt.Printf("Error finding PID(s): %v\n", err)
        os.Exit(1)
    }

    if len(pids) == 0 {
        fmt.Printf("No process is listening on port %d.\n", *port)
        return
    }

    for _, pid := range pids {
        if err := killPID(pid); err != nil {
            fmt.Printf("Failed to kill PID %s: %v\n", pid, err)
        } else {
            fmt.Printf("Killed PID %s listening on port %d.\n", pid, *port)
        }
    }
}

// findPIDs returns a slice of PIDs (as strings) listening on the given port.
func findPIDs(port int) ([]string, error) {
    var cmd *exec.Cmd
    portStr := strconv.Itoa(port)

    switch runtime.GOOS {
    case "windows":
        // netstat -ano | findstr :
        cmd = exec.Command("netstat", "-ano")
    default:
        // lsof -i : -t
        cmd = exec.Command("lsof", "-i", ":"+portStr, "-t")
    }

    out, err := cmd.Output()
    if err != nil {
        // If the command returns a non‑zero exit code but still produces output,
        // we treat the output as valid (e.g., no matches on Windows returns exit code 1).
        if exitErr, ok := err.(*exec.ExitError); ok && len(exitErr.Stderr) == 0 {
            return []string{}, nil
        }
        return nil, err
    }

    // Split output by newlines and trim spaces.
    lines := strings.Split(strings.TrimSpace(string(out)), "\n")
    var pids []string
    for _, line := range lines {
        pid := strings.TrimSpace(line)
        if pid != "" {
            pids = append(pids, pid)
        }
    }
    return pids, nil
}

// killPID attempts to terminate the process with the given PID.
func killPID(pid string) error {
    var cmd *exec.Cmd
    switch runtime.GOOS {
    case "windows":
        cmd = exec.Command("taskkill", "/PID", pid, "/F")
    default:
        cmd = exec.Command("kill", "-9", pid)
    }
    return cmd.Run()
}

저는 모든 라인을 검토하고, 몇 가지 주석을 추가하고, 작은 테스트 스위트를 작성한 뒤에야 커밋했습니다. 이것이 현재 제가 따르는 워크플로우입니다.

TL;DR

• AI는 보일러플레이트, 조사, 막힘 해소, 리뷰, 테스트, 문서 작성을 빠르게 도와줄 수 있습니다.
• 그러나 핵심 로직, 보안, 성능, 아키텍처, 실제 운영 디버깅에 대한 이해를 대체해서는 안 됩니다.
• 개인 규칙을 세우세요: 스스로 디버깅할 수 없는 코드는 절대 배포하지 않는다.

AI를 파트너로 활용하고, 생각을 대신해 주는 대체물로 여기지 마세요. 🚀

Boilerplate에서 배운 점

• 포트로 프로세스를 찾는 방법을 보여줬다 (전에 해본 적 없는 것이었다).
• 내가 생각하지 못했던 크로스‑플랫폼 고려사항을 제시했다.
• 도움이 되는 오류 메시지를 작성하는 데 도움이 되었다.

내가 직접 한 일

1. 전체 구조와 흐름을 결정했습니다.
2. 핵심 로직을 작성했습니다 (프로세스를 찾고, 안전하게 종료하는 작업).
3. 에지 케이스를 수동으로 테스트했습니다 실패 모드를 이해하기 위해.
4. 커밋하기 전에 모든 코드를 읽었습니다.
5. 누구든 물어보면 전체 프로그램을 설명할 준비를 했습니다.

결과: 나는 5일이 아닌 2일에 만들었고, 실제로 내가 만든 것을 이해했습니다.

Windows(당연히)에서 버그가 보고되었을 때, 나는 정확히 어디를 봐야 할지 알았습니다—추측도 없고, 최선을 기대하며 AI에 오류를 복사‑붙여넣기도 하지 않았습니다.

코딩할 때 AI를 사용해야 할까?

더 나은 질문은 당신의 목표가 무엇인가?

• 사이드 프로젝트를 빠르게 출시하고 성장에는 신경 쓰지 않나요?
  진행하세요. AI에게 모든 코드를 작성하게 하고, 빨리 배포하고, 어떤 일이 일어나는지 배우세요.

• 진지한 무언가—오래 지속되어야 하고, 새벽 3시에 프로덕션에서 깨질 수도 있는 것을 만들고 있나요?
  당신이 무엇을 만들고 있는지 이해해야 합니다. AI를 도구로 사용하고, 사고를 대체하는 것으로 쓰지 마세요.

• 경력 초기에 성장하려고 하나요?
  조심하세요. 어려운 문제를 직접 고민하는 것을 대체할 수 있는 것은 없습니다; 그 고민 자체가 학습이 일어나는 곳입니다.

• 경력이 풍부하고 단지 더 빠르게 진행하고 싶나요?
  AI를 현명하게 활용하세요. 당신의 실력보다 낮은 작업은 AI에게 맡기고, 실력에 맞거나 그 이상인 작업에 집중하세요.

My Current Balance (One Month Later)

• AI writes about 50‑60 % of my code.
• I read 100 % of it.
• I understand 100 % of it.
• I could debug 100 % of it if I had to.

The speed gains and momentum are still there, and the growth has returned: the satisfaction of solving hard problems and the confidence that comes from truly understanding what I’ve built.

요약

AI는 놀라운 도구이며—내 인생에서 개발자 생산성에 일어난 최고의 일일지도 모릅니다. 모든 도구와 마찬가지로 능력을 증폭시킬 수도 있고 버팀목이 될 수도 있습니다. 차이는 도구 자체에 있는 것이 아니라 그 사용 방법에 있습니다.

• AI를 활용하세요. 더 빠르고, 더 생산적이며, 덜 좌절하도록 받아들이세요.
• 이해하지 못한 코드를 절대 배포하지 마세요. 2시(새벽) 생산 환경 문제를 디버깅하고 있는 미래의 당신이 감사할 것입니다.

당신의 경험은 어떠신가요?

당신에게 맞는 균형을 찾으셨나요? 이야기를 듣고 싶습니다. 아래 댓글에 AI‑지원 코딩에 대한 생각을 공유해주세요!