[Go 2주 완성 #04] Day 7: 다형성의 재해석, 인터페이스 - 가상 함수 없이 다형성 구현하기
![[Go 2주 완성 #04] Day 7: 다형성의 재해석, 인터페이스 - 가상 함수 없이 다형성 구현하기](/og/s/go-series-04-interface.webp)
이 글의 핵심
C++ 가상 함수와 상속 대신 Go 인터페이스로 다형성을 구현하는 방법. implements 키워드 없는 암시적 인터페이스(Duck Typing)와 io.Reader, io.Writer 같은 소형 인터페이스 설계 패턴을 배웁니다.
시리즈 안내
📚 Go 2주 완성 시리즈 #04 | 전체 목차 보기
이 글은 C++ 개발자를 위한 2주 완성 Go 언어 커리큘럼의 Day 7 내용입니다.
이전: #03 객체지향 ← | → 다음: #05 에러 처리
💡 초보자를 위한 한 줄: Go 인터페이스는 C++처럼
class X : public Shape를 안 써도 됩니다. 필요한 메서드만 구현하면 자동으로 인터페이스를 만족합니다(Duck Typing).io.Reader,io.Writer같은 작은 인터페이스를 조합하는 패턴을 익히면 됩니다.
들어가며: “implements 키워드가 없는데 어떻게 다형성이 되죠?”
C++에서 다형성을 쓰려면 클래스 선언부에 상속을 명시하고 virtual 키워드로 가상 함수를 선언해야 했습니다.
class Circle : public Shape { // ← 명시적 상속 선언 필수
double Area() const override { ... }
};Go는 다릅니다. 명시적 상속 선언이 없습니다. 어떤 타입이 인터페이스에 정의된 메서드를 구현만 하면, 컴파일러가 자동으로 “이 타입은 이 인터페이스를 만족한다”고 인식합니다.
type Circle struct { radius float64 }
func (c Circle) Area() float64 { ... } // ← 이것만으로 Shape 인터페이스 만족!이게 바로 “오리처럼 걷고 오리처럼 운다면 오리다” (Duck Typing) 철학입니다. 이 글에서 배울 내용:
- 인터페이스의 정의와 암시적 만족
- 표준 라이브러리의 핵심 인터페이스
- 빈 인터페이스와 타입 단언·타입 스위치
io.Reader·io.Writer·error를 엮는 실전 패턴- 인터페이스 설계 패턴
C++ 개발자 관점: C++ 백그라운드에서 Go로 전환하며 겪은 차이점과 함정을 중심으로 설명합니다. 포인터, 동시성, 메모리 관리 등 핵심 개념을 비교하며 정리했습니다.
실무에서의 체감
C++ 위주로 서버를 다루던 환경에서 Go를 도입할 때 흔히 드는 인상은 문법과 툴체인이 단순해 보인다는 점입니다. 프로덕션에서는 그 단순함이 빌드·배포·동시성 코드 가독성으로 이어지는 경우가 많습니다. 자주 언급되는 장점:
- 개발 속도: 팀·도메인에 따라 다르지만, 네트워크·CLI 코드를 빠르게 완성하기 쉬운 편입니다.
- 안정성: GC가 있어 수동 할당 해제 부담이 줄어듭니다.
- 배포: 단일 바이너리로 옮기기 쉬운 구조입니다.
1. 인터페이스 기본: 메서드 집합
C++ vs Go: 다형성 구현
// C++: 가상 함수로 다형성
class Shape {
public:
virtual double Area() const = 0;
virtual double Perimeter() const = 0;
virtual ~Shape() = default;
};
class Circle : public Shape {
double radius;
public:
Circle(double r) : radius(r) {}
double Area() const override {
return 3.14159 * radius * radius;
}
double Perimeter() const override {
return 2 * 3.14159 * radius;
}
};
class Rectangle : public Shape {
double width, height;
public:
Rectangle(double w, double h) : width(w), height(h) {}
double Area() const override {
return width * height;
}
double Perimeter() const override {
return 2 * (width + height);
}
};
// 다형성 사용
void printShapeInfo(const Shape& s) {
std::cout << "Area: " << s.Area() << "\n";
std::cout << "Perimeter: " << s.Perimeter() << "\n";
}
int main() {
Circle c(5.0);
Rectangle r(4.0, 6.0);
printShapeInfo(c);
printShapeInfo(r);
}// Go: 인터페이스로 다형성 (명시적 상속 불필요)
// 패키지 선언
package main
import (
"fmt"
"math"
)
// 인터페이스 정의
type Shape interface {
Area() float64
Perimeter() float64
}
// Circle 타입
type Circle struct {
Radius float64
}
// Circle은 Area()와 Perimeter()를 구현하므로 자동으로 Shape 만족
func (c Circle) Area() float64 {
return math.Pi * c.Radius * c.Radius
}
func (c Circle) Perimeter() float64 {
return 2 * math.Pi * c.Radius
}
// Rectangle 타입
type Rectangle struct {
Width, Height float64
}
// Rectangle도 Area()와 Perimeter()를 구현하므로 Shape 만족
func (r Rectangle) Area() float64 {
return r.Width * r.Height
}
func (r Rectangle) Perimeter() float64 {
return 2 * (r.Width + r.Height)
}
// 다형성 사용
func printShapeInfo(s Shape) {
fmt.Printf("Area: %.2f\n", s.Area())
fmt.Printf("Perimeter: %.2f\n", s.Perimeter())
}
func main() {
c := Circle{Radius: 5.0}
r := Rectangle{Width: 4.0, Height: 6.0}
printShapeInfo(c)
printShapeInfo(r)
}핵심 차이점:
- Go는
implements키워드가 없습니다 - 메서드만 구현하면 자동으로 인터페이스를 만족합니다
- 타입과 인터페이스 간의 결합도가 낮습니다
2. 암시적 인터페이스 만족 (Duck Typing)
Duck Typing의 장점
// Go: 나중에 인터페이스 추가 가능
package main
import "fmt"
// 기존 타입 (인터페이스 모름)
type Dog struct {
Name string
}
func (d Dog) Speak() string {
return "Woof!"
}
type Cat struct {
Name string
}
func (c Cat) Speak() string {
return "Meow!"
}
// 나중에 인터페이스 정의 (기존 타입 수정 불필요)
type Speaker interface {
Speak() string
}
func makeSpeak(s Speaker) {
fmt.Println(s.Speak())
}
func main() {
dog := Dog{Name: "Buddy"}
cat := Cat{Name: "Whiskers"}
// Dog와 Cat은 Speaker를 만족 (명시적 선언 없이)
makeSpeak(dog)
makeSpeak(cat)
}C++과의 비교:
- C++: 기반 클래스를 미리 정의하고 상속해야 함
- Go: 나중에 인터페이스를 추가해도 기존 타입 수정 불필요
3. 표준 라이브러리 인터페이스
Go 표준 라이브러리는 작고 강력한 인터페이스로 가득합니다.
io.Reader와 io.Writer
// Go: io.Reader 인터페이스
type Reader interface {
Read(p []byte) (n int, err error)
}
// io.Writer 인터페이스
type Writer interface {
Write(p []byte) (n int, err error)
}활용 예시:
// Go: io.Reader 활용
package main
import (
"bytes"
"fmt"
"io"
"os"
"strings"
)
func processData(r io.Reader) error {
data, err := io.ReadAll(r)
if err != nil {
return err
}
fmt.Println(string(data))
return nil
}
func main() {
// 1. 파일에서 읽기
f, _ := os.Open("file.txt")
defer f.Close()
processData(f) // *os.File은 io.Reader
// 2. 문자열에서 읽기
sr := strings.NewReader("Hello from string")
processData(sr) // *strings.Reader는 io.Reader
// 3. 바이트 버퍼에서 읽기
buf := bytes.NewBufferString("Hello from buffer")
processData(buf) // *bytes.Buffer는 io.Reader
}fmt.Stringer 인터페이스
// C++: operator<< 오버로딩
class Person {
std::string name;
int age;
public:
Person(const std::string& n, int a) : name(n), age(a) {}
friend std::ostream& operator<<(std::ostream& os, const Person& p) {
os << p.name << " (" << p.age << ")";
return os;
}
};
// 사용
Person p("Alice", 30);
std::cout << p << "\n";// Go: fmt.Stringer 인터페이스
package main
import "fmt"
type Person struct {
Name string
Age int
}
// fmt.Stringer 인터페이스 만족
func (p Person) String() string {
return fmt.Sprintf("%s (%d)", p.Name, p.Age)
}
func main() {
p := Person{Name: "Alice", Age: 30}
fmt.Println(p) // "Alice (30)" - String() 자동 호출
}error 인터페이스
// Go: error 인터페이스
type error interface {
Error() string
}
// 커스텀 에러 타입
type ValidationError struct {
Field string
Value string
}
func (e ValidationError) Error() string {
return fmt.Sprintf("validation failed: %s = %s", e.Field, e.Value)
}
// 사용
func validate(email string) error {
if !strings.Contains(email, "@") {
return ValidationError{
Field: "email",
Value: email,
}
}
return nil
}
func main() {
if err := validate("invalid"); err != nil {
fmt.Println(err) // "validation failed: email = invalid"
}
}4. 빈 인터페이스와 타입 단언
interface{} (any)
// C++: void* (타입 안전하지 않음)
void* ptr = new int(42);
int* p = static_cast<int*>(ptr); // 수동 캐스팅// Go: interface{} 또는 any (타입 안전)
package main
import "fmt"
func printAny(v interface{}) {
fmt.Printf("Value: %v, Type: %T\n", v, v)
}
func main() {
printAny(42)
printAny("hello")
printAny(3.14)
printAny([]int{1, 2, 3})
}타입 단언 (Type Assertion)
// Go: 타입 단언
package main
import "fmt"
func process(v interface{}) {
// 안전한 타입 단언 (ok 패턴)
if s, ok := v.(string); ok {
fmt.Println("String:", s)
return
}
if i, ok := v.(int); ok {
fmt.Println("Int:", i)
return
}
fmt.Println("Unknown type")
}
func main() {
process("hello") // "String: hello"
process(42) // "Int: 42"
process(3.14) // "Unknown type"
}타입 스위치 (Type Switch)
// Go: 타입 스위치 (여러 타입 처리)
package main
import "fmt"
func describe(v interface{}) {
switch t := v.(type) {
case string:
fmt.Printf("String: %s (length %d)\n", t, len(t))
case int:
fmt.Printf("Int: %d\n", t)
case bool:
fmt.Printf("Bool: %t\n", t)
case []int:
fmt.Printf("Int slice: %v\n", t)
default:
fmt.Printf("Unknown type: %T\n", t)
}
}
func main() {
describe("hello")
describe(42)
describe(true)
describe([]int{1, 2, 3})
describe(3.14)
}5. 실전 패턴: 암묵적 구현·any·단언·표준 입출력·에러
암묵적 구현(implicit implementation)을 실무에서 쓰는 법
- 인터페이스는 보통 “소비하는 쪽”에서 정의합니다. “이 함수는
io.Reader만 받는다”처럼 필요한 메서드만 밝히면, 그 메서드를 가진 모든 타입이 넘어올 수 있습니다. - 구현체 타입은 인터페이스 이름을 몰라도 됩니다. 덕분에 기존 타입을 수정하지 않고 테스트용 목(mock)이나 어댑터만 추가하는 식으로 확장하기 좋습니다.
- 관용구로 “인터페이스는 받고, 구조체는 반환한다”(accept interfaces, return structs)가 자주 인용됩니다. 공개 API는 좁은 인터페이스로 받고, 생성자는 구체 타입 포인터를 돌려줍니다.
// HTTP 핸들러 예: ResponseWriter와 Request는 인터페이스/구조체 조합으로 설계됨
func Handler(w http.ResponseWriter, r *http.Request) {
io.WriteString(w, "ok") // w는 io.Writer를 만족
}interface{}와 any
- Go 1.18 이전에는 빈 인터페이스를
interface{}로 썼고, 이후any는interface{}의 별칭입니다. 스타일 가이드는 보통any선호를 권합니다. - 모든 타입이
any에 대입 가능하지만, 그만큼 컴파일 타임 검사가 사라지므로 이후에 타입 단언·타입 스위치로 좁혀야 합니다. - JSON 디코딩처럼 런타임에만 타입이 정해지는 데이터에서 특히 자주 씁니다(과제 4와 연결).
타입 단언과 타입 스위치 — 실전 체크리스트
| 상황 | 권장 |
|---|---|
| 한두 가지 타입만 올 수 있음 | v.(ConcreteType) 또는 s, ok := v.(string) |
| 여러 타입을 한 함수에서 분기 | switch v := x.(type) { ....} |
nil 인터페이스 값 | 동적 타입이 없어 단언이 실패하거나 주의 필요 — “nil 인터페이스” 트랩은 #05에서도 다룸 |
// 단언 실패 시 패닉을 피하려면 반드시 ok 형태 사용
if n, ok := v.(int); ok {
_ = n
}io.Reader, io.Writer, error로 이어 붙이기
표준 라이브러리는 아주 작은 인터페이스를 조합해 큰 동작을 만듭니다.
- io.Copy(dst Writer, src Reader): 읽기·쓰기 스트림을 연결. 파일·버퍼·네트워크·
bytes.Reader모두 동일하게 처리됩니다. - io.MultiWriter: 한 번의
Write를 여러Writer(파일 + 해시 등)로 동시에 보냅니다. - error: 메서드
Error() string하나뿐인 인터페이스라 어떤 커스텀 타입이든 에러로 쓸 수 있습니다. 도메인별 필드를 실어 보내고, 호출부에서는errors.As로 복원합니다(#05).
package main
import (
"bytes"
"fmt"
"io"
"strings"
)
func main() {
r := strings.NewReader("hello")
var buf bytes.Buffer
if _, err := io.Copy(&buf, r); err != nil {
fmt.Println(err)
return
}
// buf는 io.Writer를 구현 — 동일 패턴으로 파일·해시 등에도 연결 가능
fmt.Println(buf.String())
}한 줄 요약: 입출력은 io.Reader/Writer로 추상화하고, 실패는 error로 명시하며, 타입이 섞일 때만 any와 단언으로 좁힌다.
6. 인터페이스 설계 원칙
작은 인터페이스 (Small Interfaces)
Go의 철학: “인터페이스는 작을수록 좋다”
// ✅ 좋은 예: 작은 인터페이스
type Reader interface {
Read(p []byte) (n int, err error)
}
type Writer interface {
Write(p []byte) (n int, err error)
}
type Closer interface {
Close() error
}
// 필요하면 조합
type ReadWriter interface {
Reader
Writer
}
type ReadWriteCloser interface {
Reader
Writer
Closer
}// ❌ 나쁜 예: 큰 인터페이스
type Database interface {
Connect() error
Disconnect() error
Query(sql string) ([]Row, error)
Insert(table string, data map[string]interface{}) error
Update(table string, id int, data map[string]interface{}) error
Delete(table string, id int) error
BeginTransaction() error
CommitTransaction() error
RollbackTransaction() error
}
// 너무 많은 메서드 - 구현하기 어렵고 테스트하기 힘듦인터페이스 분리 원칙
// ✅ 좋은 예: 인터페이스 분리
type Querier interface {
Query(sql string) ([]Row, error)
}
type Inserter interface {
Insert(table string, data map[string]interface{}) error
}
type Transactional interface {
BeginTransaction() error
CommitTransaction() error
RollbackTransaction() error
}
// 필요한 기능만 요구
func fetchData(q Querier) ([]Row, error) {
return q.Query("SELECT * FROM users")
}7. 실습 과제
과제 1: 도형 인터페이스
// Go: 다양한 도형 구현
package main
import (
"fmt"
"math"
)
type Shape interface {
Area() float64
Perimeter() float64
}
type Circle struct {
Radius float64
}
func (c Circle) Area() float64 {
return math.Pi * c.Radius * c.Radius
}
func (c Circle) Perimeter() float64 {
return 2 * math.Pi * c.Radius
}
type Rectangle struct {
Width, Height float64
}
func (r Rectangle) Area() float64 {
return r.Width * r.Height
}
func (r Rectangle) Perimeter() float64 {
return 2 * (r.Width + r.Height)
}
type Triangle struct {
A, B, C float64 // 세 변의 길이
}
func (t Triangle) Area() float64 {
// 헤론의 공식
s := (t.A + t.B + t.C) / 2
return math.Sqrt(s * (s - t.A) * (s - t.B) * (s - t.C))
}
func (t Triangle) Perimeter() float64 {
return t.A + t.B + t.C
}
func printShapeInfo(s Shape) {
fmt.Printf("Type: %T\n", s)
fmt.Printf("Area: %.2f\n", s.Area())
fmt.Printf("Perimeter: %.2f\n", s.Perimeter())
fmt.Println()
}
func main() {
shapes := []Shape{
Circle{Radius: 5},
Rectangle{Width: 4, Height: 6},
Triangle{A: 3, B: 4, C: 5},
}
for _, shape := range shapes {
printShapeInfo(shape)
}
}과제 2: 커스텀 Writer
// Go: 커스텀 Writer 구현
package main
import (
"bytes"
"fmt"
"io"
"os"
)
// 대문자로 변환하는 Writer
type UpperWriter struct {
w io.Writer
}
func NewUpperWriter(w io.Writer) *UpperWriter {
return &UpperWriter{w: w}
}
// io.Writer 인터페이스 만족
func (uw *UpperWriter) Write(p []byte) (n int, err error) {
upper := bytes.ToUpper(p)
return uw.w.Write(upper)
}
func main() {
// 표준 출력을 대문자로
uw := NewUpperWriter(os.Stdout)
fmt.Fprintln(uw, "hello world") // "HELLO WORLD"
// io.Copy 같은 함수와 조합 가능
io.WriteString(uw, "go is awesome\n") // "GO IS AWESOME"
}과제 3: 인터페이스 조합
// Go: 여러 인터페이스 조합
package main
import (
"fmt"
"io"
"os"
)
// 여러 인터페이스를 만족하는 타입
type File struct {
*os.File
}
// File은 io.Reader, io.Writer, io.Closer를 모두 만족
// (os.File이 이미 구현하고 있으므로 임베딩으로 자동 만족)
func processReadWriteCloser(rwc io.ReadWriteCloser) {
// Read, Write, Close 모두 사용 가능
defer rwc.Close()
data := []byte("test data")
rwc.Write(data)
}
func main() {
f, err := os.Create("temp.txt")
if err != nil {
panic(err)
}
// *os.File은 io.ReadWriteCloser 만족
processReadWriteCloser(f)
}과제 4: 타입 단언 실습
// Go: 타입 단언으로 JSON 파싱
package main
import (
"encoding/json"
"fmt"
)
func parseJSON(jsonStr string) {
var data interface{}
if err := json.Unmarshal([]byte(jsonStr), &data); err != nil {
fmt.Println("Parse error:", err)
return
}
// 타입 스위치로 처리
switch v := data.(type) {
case map[string]interface{}:
fmt.Println("Object:")
for key, value := range v {
fmt.Printf(" %s: %v\n", key, value)
}
case []interface{}:
fmt.Println("Array:")
for i, item := range v {
fmt.Printf(" [%d]: %v\n", i, item)
}
default:
fmt.Printf("Other type: %T\n", v)
}
}
func main() {
parseJSON(`{"name":"Alice","age":30}`)
parseJSON(`[1, 2, 3, 4, 5]`)
}정리: Day 7 학습 체크리스트
완료해야 할 항목
- 인터페이스는 메서드 집합임을 이해
- 명시적
implements없이 자동 만족 (Duck Typing) -
io.Reader,io.Writer,fmt.Stringer등 표준 인터페이스 활용 - 빈 인터페이스(
interface{},any)와 타입 단언 - 타입 스위치로 여러 타입 처리
- 작은 인터페이스 설계 원칙
- 실습 과제 4개 완료
C++에서 Go로 전환 포인트
| C++ | Go | 비고 |
|---|---|---|
virtual 함수 | 인터페이스 메서드 | 명시적 vs 암시적 |
| 명시적 상속 | 암시적 만족 | Duck Typing |
| 기반 클래스 포인터 | 인터페이스 변수 | 더 유연 |
RTTI (dynamic_cast) | 타입 단언 | 더 간결 |
| 다중 상속 | 인터페이스 조합 | 더 안전 |
1주 차 완료!
축하합니다! 1주 차를 완료했습니다. 지금까지 배운 내용:
- ✅ Go 기본 문법과 철학
- ✅ 포인터와 자료구조 (Slice, Map)
- ✅ 구조체와 메서드
- ✅ 인터페이스와 다형성 2주 차에서는 Go의 진짜 강점인 동시성 프로그래밍을 배웁니다!
📚 시리즈 네비게이션
| 이전 글 | 목차 | 다음 글 |
|---|---|---|
| ← #03 객체지향 | 📑 전체 목차 | #05 에러 처리 → |
| Go 2주 완성 시리즈: | ||
| 커리큘럼 • #01 기본 문법 • #02 자료구조 • #03 객체지향 • #04 인터페이스 • #05 에러 처리 • #06 고루틴·채널 • #07 테스팅 • #08 REST API • #09 context·우아한 종료 |
한 줄 요약: Go 인터페이스는 명시적 상속 없이 메서드만 구현하면 자동으로 만족됩니다. 작은 인터페이스로 높은 재사용성을 얻으세요.
같이 보면 좋은 글 (내부 링크)
이 주제와 연결되는 다른 글입니다.
- [Go 2주 완성 #03] Day 5~6: 클래스 없는 객체지향 - 상속을 버리고 합성을 취하다
- C++ 개발자를 위한 2주 완성 Go 언어(Golang) 마스터 커리큘럼
- C++ 가상 함수 | “Virtual Functions” 가이드
이 글에서 다루는 키워드 (관련 검색어)
Go interface, Duck Typing, io.Reader, 타입 단언 any, Go 다형성, C++ 가상함수 비교, Golang 인터페이스, Go 2주 완성 등으로 검색하시면 이 글이 도움이 됩니다.
실전 팁 (Go)
go fmt,go vet, 필요 시golangci-lint로 기본 품질을 맞춥니다.if err != nil을 습관화합니다. 에러를 삼키면 운영에서 원인 추적이 어렵습니다.go test ./...로 패키지 단위 회귀를 확인합니다. 성능은go test -bench로 측정할 수 있을 때만 다룹니다.
실전 체크리스트 (Go)
코드
- 외부 호출·I/O 실패 시 에러가 처리되거나 로깅되는가?
- 고루틴·채널 사용 시 블로킹·누수 가능성을 검토했는가?
모듈
-
go.mod/go.sum이 팀과 합의된 범위인가?
자주 묻는 질문 (FAQ)
Q. 이 내용을 실무에서 언제 쓰나요?
A. C++ 가상 함수와 상속 대신 Go 인터페이스로 다형성을 구현하는 방법. implements 키워드 없는 암시적 인터페이스(Duck Typing)와 io.Reader, io.Writer 같은 소형 인터페이스 설계 패… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.
Q. 선행으로 읽으면 좋은 글은?
A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.
Q. 더 깊이 공부하려면?
A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.
관련 글
- C++ 개발자의 뇌 구조로 이해하는 Go 언어 [#47-2]
- C++ 개발자를 위한 2주 완성 Go 언어(Golang) 마스터 커리큘럼
- C++ vs Go | 성능·동시성·선택 가이드 완전 비교 [#47-1]
- [Go 2주 완성 #01] Day 1~2: Go 언어의 철학과 기본 문법 - C++ 개발자의 첫인상
- [Go 2주 완성 #02] Day 3~4: 메모리와 자료구조 - 포인터 연산은 없지만 포인터는 있다
심화 부록: 구현·운영 관점
이 부록은 앞선 본문에서 다룬 주제(「[Go 2주 완성 #04] Day 7: 다형성의 재해석, 인터페이스 - 가상 함수 없이 다형성 구현하기」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.
내부 동작과 핵심 메커니즘
flowchart TD A[입력·요청·이벤트] --> B[파싱·검증·디코딩] B --> C[핵심 연산·상태 전이] C --> D[부작용: I/O·네트워크·동시성] D --> E[결과·관측·저장]
sequenceDiagram participant C as 클라이언트/호출자 participant B as 경계(런타임·게이트웨이·프로세스) participant D as 의존성(API·DB·큐·파일) C->>B: 요청/이벤트 B->>D: 조회·쓰기·RPC D-->>B: 지연·부분 실패·재시도 가능 B-->>C: 응답 또는 오류(코드·상관 ID)
- 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
- 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
- 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
- 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.
프로덕션 운영 패턴
| 영역 | 운영 관점 질문 |
|---|---|
| 관측성 | 요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가 |
| 안전성 | 입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가 |
| 신뢰성 | 재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가 |
| 성능 | 캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가 |
| 배포 | 롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가 |
| 용량 | 피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가 |
스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.
확장 예시: 엔드투엔드 미니 시나리오
앞선 본문 주제(「[Go 2주 완성 #04] Day 7: 다형성의 재해석, 인터페이스 - 가상 함수 없이 다형성 구현하기」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.
- 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
- 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
- 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
- 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
- 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.
handle(request):
ctx = newCorrelationId()
validated = validateSchema(request)
authorize(validated, ctx)
result = domainCore(validated)
persistOrEmit(result, idempotentKey)
recordMetrics(ctx, latency, outcome)
return result문제 해결(Troubleshooting)
| 증상 | 가능 원인 | 조치 |
|---|---|---|
| 간헐적 실패 | 레이스, 타임아웃, 외부 의존성, DNS | 최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검 |
| 성능 저하 | N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스 | 프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거 |
| 메모리 증가 | 캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납 | 상한·TTL·힙/FD 스냅샷 비교 |
| 빌드·배포만 실패 | 환경 변수, 권한, 플랫폼 차이, lockfile | CI 로그와 로컬 diff, 런타임·이미지 버전 핀 |
| 설정 불일치 | 프로필·시크릿·기본값, 리전 | 스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화 |
| 데이터 불일치 | 비멱등 재시도, 부분 쓰기, 캐시 무효화 누락 | 멱등 키·아웃박스·트랜잭션 경계 재검토 |
권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.
배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.