나는 미래를 받아들였는가? - 개발자 AI 코딩 툴과 협업하는 법

안녕하세요. 프롭테크 플랫폼에서 백엔드 개발자로 근무 중인 3년차 백엔드 개발자 정정일입니다.

요즘 개발자들 사이에서 AI 코딩 툴의 비중이 점점 커져가고 있습니다.

GitHub Copilot, ChatGPT, Claude Code… 이미 많은 개발자들이 사용하고 있고, “AI 없이 개발하면 뒤처진다"는 말까지 나오고 있죠.

저도 AI 코딩 어시스턴트를 사용한 지 벌써 몇 달이 지났습니다. 처음엔 신기했습니다. “와, 이제 AI가 코드도 짜주네!”

하지만 시간이 지나면서 이런 생각이 들었습니다.

“나는 이 도구를 제대로 쓰고 있는 걸까?”

단순 반복 작업만 시키고, 중요한 건 여전히 제가 직접 하고 있었습니다. AI가 작성한 코드를 온전히 믿지 못해 검증하는 과정을 거쳐야하기 때문에, “차라리 간단한 일만 시키는 게 낫지 않을까?” 하는 생각에 어느정도 거리를 두고 활용하고 있었습니다.

그러던 어느 날, 별 생각 없이 어떤 책을 읽다가 머리를 쌔게 맞은 문장을 만났습니다.

“미래는 이미 와 있다. 다만, 모두에게 균등하게 온 것은 아니다” - 윌리엄 깁슨

이 문장을 읽는 순간, AI 코딩 툴이라는 “미래"를 마주하고도 막연한 불안감 때문에 제대로 활용해볼 생각도 못하고 있는 제 모습을 돌아보게 됐습니다.

“아, 나는 미래를 받아들이지 못하고 있었구나.”

이 글은 제가 AI 코딩 툴을 제대로 활용하기 위해 겪었던 시행착오들을 공유하고자 합니다. 토큰 효율 50-92% 개선, TDD와 AI의 결합, 그리고 직접 겪으며 깨달은 “AI와 협업하는 법"에 대한 이야기입니다.

제한적으로만 사용하고 있던 AI

제가 그동안 구체적으로 어떻게 개발에서 AI를 활용하고 있었는지 돌이켜보니

• 파라미터 타입 일괄 변경
• 테스트 코드 작성
• 간단한 함수 리팩토링
• 내가 작성한 코드에 대한 코드 리뷰

이런 단순하지만 하기 귀찮은 작업들 혹은 내가 놓친부분은 없는지 확인을 보통 시키고 있었습니다.

핵심 비즈니스 로직, 복잡한 API등과 같은 작업은 여전히 제가 직접 하고 있었습니다.

왜 그랬을까요? 사실 생각해보면 당연합니다. “너무 신뢰하면 안 될 것 같아서”

“AI가 작성한 코드를 제대로 검증하려면 매번 꼼꼼히 봐야 하는데, 내가 놓치는 경우들이 있을 수 있지 않을까?” “너무 AI에게 의존하다보면 내 실력이 떨어지는 건 아닐까?” “AI가 관리하는 컨텍스트가 너무 많아져 내 이해 범위를 넘어서는 내가 이해하고 있지 않은 코드들이 쌓이진 않을까?“

이런 막연한 불안감 때문에 어느정도 거리를 두고 있었던 것 같습니다.

그제서야 떠오른 토비(Toby)님의 말씀

“미래는 이미 와 있다. 다만, 모두에게 균등하게 온 것은 아니다” 라는 문구를 책에서 읽는 순간 참 스스로를 돌이켜보게 됐습니다.

흔히들 개발자가 AI에 일부 대체될거라고들 많이 말씀 하십니다. 저 또한 그런 생각을 하고 있구요. 누구나 어렵지 않게 그릴 수 있는 미래입니다. 생각해보면 미래도 아니네요. AI에 등장 이후로 개발자 채용시장이 어느정도 차가워졌다는 걸 개발자분들은 몸소 체감하실겁니다.

또 누군가는 “개발자는 AI에게 대체되는 것이 아니라 AI를 잘활용하는 개발자에게 대체될 것 이다” 라고도 말씀 하셨습니다.

물론 미래는 확신할 수 없지만 아주 높은 확률로 AI를 잘 활용하는 능력은 개발자의 중요한 역량중 하나가 될 것이라 생각합니다. 1명의 개발자가 AI와 협업하여 10명의 개발자보다 더 많은 일을 해낼 수 있는 시대가 올지도 모릅니다.

아니죠, 올지도 모른다는 잘못된 표현인 것 같고 확실히 오고 있습니다.

“그런데 왜 나는 그 미래를 지금 내것으로 만들지 못하고 있었지?”

이런 생각에 머리를 한대 크게 맞은 것 같았습니다.

그리고 얼마 전 2025년 7월에 참관했던 토비님 밋업 “31년차 개발자가 전하는 AI시대, 개발자로 살아가는 법”의 내용이 다시 떠올랐습니다.

• 개발자는 더 이상 고정된 직능이 아니라 AI와 함께 계속 새롭게 정의될 유동적인 개념이 될 것
• AI와 협업하는 능력이 개발자의 핵심 역량이 될 것
• 앞으로 효율적인 개발자는 작업의 성격과 복잡성에 따라 AI와의 협업 모델을 유연하게 전환할 수 있는 ‘모드 전환자(Mode Switchers)’

당시에는 그냥 “그렇구나” 하고 들었지만, 정작 저는 여전히 AI를 제한적으로만 사용하고 있었습니다.

그 문장을 읽고 나서야, 토비님 말씀이 진짜로 와닿았습니다.

“아, 나는 미래를 손에 쥐고도 제대로 쓰지 못하고 있었구나.”

결심: 제대로 협업해보자

그래서 결심했습니다.

사이드 프로젝트를 진행하면서 AI와 제대로 협업하는 법을 배워보자!

평소 관심있던 사이드 프로젝트 아이디어가 있었습니다. 다만 귀찮은 마음에 미뤄두고 있었는데, 이참에 AI와 협업하면서 진행해보기로 했습니다.

처음에는 간단한 규칙만 새워두고 시작했습니다. 기획서를 작성하고 해당 기획서에 대한 요구사항을 분석하여 Issue로 정리하는 것부터 AI와 협업했습니다. 이미 Claude code가 github cli를 사용할 수 있었기에, Issue 작성도 AI에게 맡겼습니다. 다만 정확하지 않은 분석은 제가 직접 수정해주었습니다.

만들어진 이슈를 바탕으로 Claude Code와 함께 개발을 시작했습니다.

AI에게 특정 이슈를 맡기고 구현을 같이 협업하기 시작했습니다. 하다보니 신기한 일이 생겼습니다. AI가 코드를 작성하는 중간중간에 제가 자연스럽게 끼어들게 되더라고요.

“어라? 그거 그렇게 하면 안되는데?”

예를 들어 이런 경우 였습니다. Claude에게 특정 기능을 맡기고 API를 구현하던 중이었습니다.

Claude가 Service 레이어에서 바로 JOOQ 쿼리를 작성하고 있었습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

@Service
class UserService(
    private val dslContext: DSLContext  // 어?
) {
    fun getUsers(): List<User> {
        return dslContext.select(USER.ID, USER.EMAIL)
            .from(USER)
            .fetch()  // Service에서 직접 쿼리를?
    }
}

“잠깐, Service에서 직접 쿼리를 날리면 안 되지. 설계에 부합하지 않는데. 쿼리는 Repository레이어에서 해야하잖아.”

제 사이드 프로젝트는 MVC 계층 구조가 명확합니다. Service는 비즈니스 로직만, Repository가 데이터베이스 접근을 담당합니다.

중간에 끼어들어 Claude에 수정을 요청하고 제가 다시 이 규칙을 말할 필요 없게 Claude가 볼 수 있도록 CLAUDE.md에 작성하게 됩니다.

→ CLAUDE.md에 추가: “Service는 Repository를 통해서만 데이터베이스에 접근”

“더 나은 방식이 있는데..”

사용자 인터랙션을 처리하는 코드를 작성하던 중이었습니다.

AI가 작성한 코드:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

@Service
class InteractionService {
    fun recordLike(userId: UUID, contentId: UUID) {
        // 좋아요 기록
        likeRepository.save(Like(userId, contentId))

        // 통계 업데이트
        statisticsService.updateLikeCount(contentId)  // 동기로?

        // 알림 발송
        notificationService.sendLikeNotification(userId, contentId)  // 이것도 동기로?
    }
}

“잠깐, 통계 업데이트랑 알림 발송은 비동기로 처리해야 더 나은 구조라고 생각하는데?”

이렇게 말하면 Claude는 어떤 대답을 했을까요?

“아, 맞는 말씀입니다! 메인 트랜잭션과 독립적인 작업들은 비동기로 처리하는 것이 좋습니다. 코루틴을 사용하여 비동기 처리를 구현해보겠습니다.”

“음 코루틴도 괜찮긴 한데, 통계 업데이트나 알림 발송이 실패해도 좋아요 기록 자체는 성공해야 하잖아. TransactionalEventListener를 쓰면 메인 트랜잭션이 커밋된 후에 독립적으로 실행되니까, 알림이 실패해도 좋아요는 저장되고. 그리고 도메인 이벤트로 관심사도 명확하게 분리되고. Spring Event가 더 적합할 것 같은데?”

“맞습니다! Spring Event를 사용하여 비동기 처리를 구현해보겠습니다.”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

@Service
class InteractionService {
    fun recordLike(userId: UUID, contentId: UUID) {
        likeRepository.save(Like(userId, contentId))

        // 이벤트 발행 (비동기)
        eventPublisher.publishEvent(
            LikeRecordedEvent(userId, contentId)
        )
    }
}

@Component
class InteractionEventListener {
    @Async
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    fun handleLikeRecorded(event: LikeRecordedEvent) {
        statisticsService.updateLikeCount(event.contentId)
        notificationService.sendLikeNotification(event.userId, event.contentId)
    }
}

이렇게 되면 다시금 제가 CLAUDE.md에 규칙을 추가하게 됩니다.

→ CLAUDE.md에 추가: “메인 트랜잭션과 독립적인 작업은 Spring Event로 비동기 처리”

“잠깐! 그거 진짜 지우면 안 되는데?”

사용자 삭제 기능을 구현할 때였습니다.

Claude가 작성한 코드를 보니

1
2
3
4
5
6

fun deleteUser(userId: UUID) {
    dslContext
        .deleteFrom(USER)
        .where(USER.ID.eq(userId))
        .execute()  // 진짜로 지우려고?!
}

“잠깐! 그거 물리적으로 지우면 안 되는데?”

프로젝트는 Soft Delete 규칙이 있습니다. 데이터는 물리적으로 지우지 않고, deletedAt만 기록합니다.

법적 이슈나 데이터 복구 때문에 실제로 DB에서 지워버리면 안 됩니다.

1
2
3
4
5
6
7
8

// 올바른 방법
fun deleteUser(userId: UUID) {
    dslContext
        .update(USER)
        .set(USER.DELETED_AT, LocalDateTime.now())
        .where(USER.ID.eq(userId))
        .execute()
}

다시금 제가 CLAUDE.md에 규칙을 추가하게 됩니다.

→ CLAUDE.md에 추가: “물리적 삭제 금지, Soft Delete만 허용. deletedAt 필드 사용”

이렇게 제 CLAUDE.md는 피로 쓰인 규칙들로 점점 더 두꺼워져 갔습니다.

너무 방대해지는 CLAUDE.md

제가 다시 말할필요 없도록 인터럽트할 때마다, CLAUDE.md에 규칙을 추가했습니다. 일종에 개발 컨벤션 문서처럼 돼가고 있었습니다.

• Repository 패턴 규칙
• Spring Event 비동기 처리 규칙
• Soft Delete 규칙
• SELECT asterisk 금지 규칙
• Audit Trail 필수 규칙
• KDoc 작성 규칙
• REST Docs 작성 규칙
• …

규칙이 계속계속 쌓이다 보니, 어느새 CLAUDE.md가 2,144줄이 되어있었습니다. 당연하게도 이는 곧 문제로 이어집니다.

CLAUDE.md 한 파일이 2,144줄, 약 40,000 토큰이 돼버린건데

이러면 매번 Claude Code가 CLAUDE.md 2000줄이 넘는 규칙을 읽게 되니 컨텍스트가 금방 차버리고 중간에 내용을 까먹는 경우들도 발생하게 됩니다. 또 토큰양이 어마무시 하다보니 제 토큰 리밋을 순식간에 동나게 해버리더라구요.

API 하나 개발하는데 40,000 토큰…, 게다가 추가적인 CLAUDE.md 뿐 아니라 실제 구현과정에서도 토큰을 사용할텐데 이건 너무 비효율적입니다. “어떻게하면 개선할 수 있을까?” 라는 생각이 당연히 들기 시작했습니다.

Skills: 필요한 컨텍스트만 불러오기

고민하다보니 최근에 Claude Code에 Skills 라는 기능이 추가된 걸 알게 됐습니다.

Skills란? Skills는 Claude Code가 특정 작업을 수행할 때 참고할 수 있는 모범 사례(best practices)와 지침을 담은 문서 모음입니다. 마치 전문가의 노하우가 정리된 가이드북 같은 역할을 합니다.

Claude Code는 작업을 시작하기 전에 관련된 Skill 문서를 자동으로 읽어서 참고합니다.

작업별로 필요한 컨텍스트만 로드할 수 있고, 필요에 따라 직접 /skill [이름] 명령어로 불러올 수 있습니다. 또 여러 개를 조합해서 쓸 수도 있다고 했습니다.

보고 바로 “이거다!” 싶었습니다.

2,144줄의 거대한 CLAUDE.md를 8개의 독립적인 Skill 파일로 분리했습니다.

.claude/skills/
├── README.md                 # Skill 사용 가이드
├── quick-reference.md        # 빠른 참조
├── core-principles.md        # TDD, SOLID
├── mvc-layers.md            # Controller/Service/Repository
├── testing-guide.md         # 테스트 템플릿
├── api-design.md            # REST API 설계
├── database-query.md        # JOOQ, Soft Delete
├── code-style.md            # 로깅, 네이밍
├── spring-event.md          # Spring Event
└── pr-guide.md              # PR 작성

.claude/skills/README.md에 Claude가 Skill에 대해 빠르게 이해할 수 있도록 설명을 적어주고 각 스킬은 500줄 이하로 유지했습니다.

결과는 꽤나 놀라웠습니다.

이제 API 하나 개발할 때는 /skill core-principles.md,/skill mvc-layers, /skill testing-guide, /skill api-design 이런 식으로 필요한 컨텍스트만 로드하고 시작할 수 있게 됐습니다.

사이드 프로젝트 Skills 구성을 보실 수 있게 남길테니 궁금하신 분들은 보셔도 좋을 것 같습니다.

Claude Code 검증을 자동화하다

그런데 한 가지 고민이 또 생겼습니다.

AI가 코드를 작성하면, 제가 하나하나 검증해야 했습니다. 당연하게도 어떤 방식으로 코드를 작성 했는지 잘못된 부분은 없는지 확인하는 과정을 거쳐야했으니까요. AI가 작성한 코드더라도 최종적으로 제가 승인했다면 그 책임 역시 온전히 제가 져야합니다.

실시간으로 인터럽트할 수 있다고 해도, 놓치는 부분이 있을 수 있었습니다.

“검증 부담을 자동화로 나눌 수 없을까?”

방법은 어렵지 않게 떠올랐습니다. AI와의 협업이라지만 다른 사람의 코드를 확인하고 검증하는 과정을 개발자들은 “코드 리뷰"라는 이름으로 이미 많이 해왔습니다.

“단지 대상이 AI가 됐을 뿐이죠.“

개발자들이 이미 많이 하는 것들은 자동화 도구들이 많았습니다. 예를 들어 테스트 커버리지 측정, 정적 코드 분석과 같은 도구들이죠. 자연스레 제가 회사에서 다른 개발자분들과 협업할때도 사용하는 툴들을 도입하게 됐습니다.

Jacoco - 테스트 커버리지

• AI가 작성한 코드에 테스트가 충분한지
• 커버리지가 기준치 이상인지

Detekt, reviewDog - 정적 코드 분석

• Kotlin 코드 스타일을 지키는지
• 잠재적인 버그는 없는지

ArchUnit - 아키텍처 규칙 검증

• Controller는 Service만 의존하는지
• Service는 Repository만 의존하는지
• 순환 참조는 없는지
• Soft Delete 규칙을 지키는지

이 도구들이 CI/CD에서 자동으로 돌아가고, PR에 데코레이션으로 결과가 남습니다.

예를 들어 Jacoco 테스트 커버리지가 부족하면 PR에 빨간 X가 뜨고, 충분하면 초록 사과가 뜹니다. 제가 직접 로컬에서 하나하나 검증할 필요도 없게 누구나 PR을 열면 바로 확인할 수 있도록 말이죠.

그리고 한 가지를 더 추가했습니다.

Gemini Assistant를 PR 코드 리뷰어로 설정해두었습니다.

Claude Code가 작성한 코드를 Gemini가 PR에서 리뷰하도록 말이죠. “AI가 AI 코드를 리뷰한다고?” 싶으실 수 있는데, 실제로 효과가 꽤 컸습니다.

• “이 함수는 null 체크가 필요해 보입니다”
• “이 쿼리는 인덱스가 없어서 성능 이슈가 있을 수 있습니다”
• “테스트 케이스가 부족합니다”

이런 피드백을 Claude Code에게 다시 전달하면, 코드를 개선해서 다시 작성하고 Commit한 후 Push합니다.

이게 실제로 효과가 있을까?

놀랍게도 AgentCoder 연구(2024)에서 이를 검증하는 연구를 진행했습니다. Programmer agent가 작성한 코드를 Test executor agent가 검증하고 피드백을 주는 방식으로요.

결과는 꽤나 놀라웠습니다.

• HumanEval 벤치마크: 74.4% (1회) → 79.9% (5회 반복)
• MBPP-ET 벤치마크: 80.3% → 89.1%

AI끼리 리뷰를 반복할수록 성능이 올라갔습니다.

그리고 더 흥미로운 건, 단일 AI끼리의 협업보다 여러 AI의 협업이 훨씬 효과적이었다는 점입니다. AI가 생성한 코드를 다른 AI가 리뷰하고, 그 피드백을 다시 반영하는 교차검증이 실제로 성능을 더욱 올렸습니다.

• Multi-agent 접근: 87.8%-89.9%
• Single agent: 61.0%-61.6%

그래서 저는 PR단위의 Gemini Assistant 코드리뷰를 도입했고, 이렇게 하니 제 검증 부담이 확 줄었습니다.

1. Claude Code가 코드를 작성하고
2. 자동화 도구들(ArchUnit, Jacoco, Detekt)이 검증하고
3. Gemini가 코드 리뷰하고
4. 저는 PR 데코레이션과 리뷰 코멘트를 보고 판단할 수 있게 됐습니다.

제가 실제로 두 AI와 함께 협업하는 PR 을 보시면 작업 과정의 이해가 좀더 용이하실 것 같습니다.

이렇게 되니 AI에게 더 복잡한 작업도 맡길 수 있게 됐습니다.

직접 써보며 깨달은 것

돌이켜보면, 처음에는 막연한 불안감 때문에 AI를 제한적으로만 사용했습니다.

• “AI를 너무 신뢰하면 안 될 것 같아서”
• “내가 AI에게 맡기기만 하고 아무것도 모르는 바보가 될까봐”

하지만 사이드 프로젝트에서 직접 AI와 협업하며 써보니, 역설적인 깨달음을 얻게됐습니다.

AI에게 더 많은 일을 맡기려면, 내가 더 잘 알아야 한다.

위에서 언급했던 인터럽트 경험들처럼, AI가 코드를 작성하는 중간에 자연스럽게 끼어들 수 있었던 이유는 제가 알고 있었기 때문입니다.

만약 제가 몰랐다면 그냥 AI가 작성한 코드를 그대로 사용했을지도 모릅니다. 나중에 버그가 나거나, 코드 리뷰에서 지적받았을 수도 있겠죠.

그렇게에 AI와의 협업에서 개발자의 아주 중요한 능력은 “실시간으로 AI의 작업을 인터럽트할 수 있을 정도로 잘 아는 것” 이라는게 크게 느껴졌습니다.

TDD가 생각보다 중요하더라

프로젝트를 진행하면서 토비님이 강조하신 “TDD를 하지 않으면 안 된다” 는 말을 직접 체감하기도 했습니다.

테스트 코드를 먼저 작성하도록 하고 AI에게 구현을 맡기니, AI의 작업을 객관적으로 검증할 수 있더라고요.

AI가 요구사항대로 테스트 작성 → AI가 코드 작성 → 테스트 실행 → 통과/실패 확인 → 실패시 분석 및 재작성

테스트는 일종의 안전망이자 검증 수단이었습니다. AI가 Goal에 도달했는지 확인하는 용도가 되기도 했고, AI에게 “정확히 무엇을 원하는지” 가장 명확하게 전달하는 수단인 것 같았습니다.

리팩토링이나 기능을 추가할 때도 테스트가 있으니 기존 기능에 문제가 없는지 바로 확인할 수 있었습니다.

그렇게 때문에 TDD를 도입한 후, AI에게 더 복잡한 작업을 맡길 수 있게 됐습니다.

시나리오 기반으로 테스트를 작성하라 요청하니 테스트 코드만으로도 “어떤 기능을 만들려고 하는구나”, “예외 처리가 부족한 부분이 있는 것 같은데?” 라는 판단도 가능했죠.

작업 특성에 따라 협업 모델 바꾸기

또한 AI와 인간의 세 가지 협업 모델을 실제로 적용해봤습니다.

AITL (AI-in-the-Loop): 아키텍처 설계나 핵심 비즈니스 로직은 제가 방향을 잡고, AI는 코드를 작성하도록 했습니다.

HITL (Human-in-the-Loop): API 엔드포인트 구현이나 테스트 코드 작성은 AI가 주도하되, 제가 코드 리뷰하며 검증했습니다. 가능하면 최대한 AI와의 협업을 하는 모든 순간에 “딸깍딸깍 금지!” 를 실천하려고 했습니다. 무조건 수락하지 않고 질문했습니다.

• “왜 이렇게 작성했어?”
• “다른 방법은 없어?”
• “이 코드의 장단점은 뭐야?”

토비님이 “딸깍딸깍 절대 하지말기” 를 강조하시며 하셨던 말씀중에 기억에 남는 말이 있는데

“AI를 시니어 개발자라고 생각해봐라. 시니어 개발자가 옆에서 자세한 설명을 하면서 코드를 만드는 것을 도와주는데, 코드 입력만 하고 설명은 다 무시하는 주니어 개발자라고 생각해 보면 그 중요성을 알 수 있다”

실제로 저는 협업하는 거의 대부분의 과정에서 항상 Claude Code의 실행계획을 확인하고 질문, 반박, 재계획, 실행의 프로세스를 거쳤습니다. 이러면서 자연스레 작업의 방향성을 조정하고 이해할 수 있었습니다. 질문은 곧 학습의 기회이기도 했고 실행계획의 검증이 되기도 했습니다.

Claude Code의 실행계획을 보면 저희 개발자들과 생각 및 개발과정이 꽤나 비슷하단 걸 알 수 있습니다. 저는 저 과정속에서 다른 인간 개발자분과 이야기하듯 다른 대안을 제시하기도 Claude code의 반박에 납득하기도 했죠.

HOTL (Human-on-the-Loop): 파라미터 일괄 변경, Claude Rule, Skill 수정과 같은 단순 작업은 AI가 자율적으로 수행하고, 저는 결과만 확인하는 경우도 간혹 있었습니다. (ex.PR-CLAUDE.md Skills로 분리)

위에서 언급했듯 PR에 자동화 도구들이 검증해주니, 최종적인 확인에서 제가 개입하는 정도로 충분한 작업들도 있었죠. 작업 특성에 따라 모드를 전환하는 게 핵심이라고 느꼈습니다.

결국

AI에 반박할 수 있는 개발자가 되어야 한다.

이게 제가 내린 결론이었습니다.

• AI가 작성한 코드가 맞는지 틀린지 판단하려면, 제가 그 기술을 알아야 합니다.
• AI가 잘못된 방향으로 가고 있을 때, 제가 반박할 수 있어야 합니다.
• AI를 통해 계속 공부하면서 성장해야 한다고 생각합니다..

맞는지 틀린지도 판단하지 못하는데 믿고 맡기는건 제가 도태되는 지름길 같다고 느꼈습니다.

잘 쓰면 엄청난 생산성과 학습에 도움이 되는데, 아무생각없이 “그냥 AI야 해줘” 하는 개발자가 돼버리면 경험도, 지식도 제게는 아무것도 남지 않을 것만 같다 느꼈습니다. 이는 절대 좋지 않은 결과를 초래하겠죠. 이런점에서 마치 **“양날의 검”**같다고 느껴졌습니다.

그렇기에 앞으로도 반박할 수 있도록 꾸준히 공부하고 노력해 나가려 합니다. 역량 강화 및 학습에도 AI를 적극 활용해서 말이죠.

그 과정에서 증강 개발자(Augmented Developer) 로 성장할 수 있을 것 같다 생각합니다.

앞으로는

아직은 AI와의 협업도 부족한 점이 많은 것 같습니다. 저보다 더 나은 방법들로 훨씬 잘 활용하시는 분들도 많으실거라 생각이 듭니다. 그러니 늦은 만큼 더 열심히 해야겠죠.

“미래는 이미 와 있다. 다만, 모두에게 균등하게 온 것은 아니다”

저는 이 문장의 의미를 이제는 알 것 같습니다.

미래는 이미 저희 곁에 있는 것 같습니다. AI 코딩 툴, 자동화 도구들… 모두 제 손에 있었습니다.

다만 그것을 제대로 받아들이고 활용할 수 있는 능력은 균등하게 주어지지 않는 것 같습니다.

처음에는 막연한 불안감 때문에 AI를 제한적으로만 사용했지만 직접 부딪혀보니 잘 느껴지게 됐습니다.

AI에게 더 많은 일을 맡기려면, 내가 더 잘 알아야 한다.

물론 아직 부족한 점이 너무 많은지라 앞으로도 저는 AI가 작성한 코드를 검증할 수 있도록 계속 공부하려고 합니다. AI의 제안에 무조건 수락하지 않고, 질문하고 반박하려고 합니다. 비효율을 발견하면 바로 개선하려고 합니다.

AI를 단순 어시스트가 아닌 학습 파트너이자 협업 도구로 활용하려고 합니다.

여러분도 손에 쥔 미래를 제대로 활용하고 계신가요?

저는 이제 겨우 시작한 것 같습니다.

참고 자료

• 토비님 밋업 참관기 - 31년차 개발자가 전하는 AI시대 개발자로 살아가는 법
• AI와 협업으로 진행하는 제 사이드 프로젝트 - GrowSnap
• AgentCoder: Multiagent-Code Generation with Iterative Testing and Optimisation (2024) - Multi-agent 교차검증 효과 연구